The Living Compliance Passport
One link that shows a buyer your product's current position against the applicable regulations, which may include Cyber Resilience Act, Product Liability Directive, DORA, and the AI Act, derived from your own engineering data and re-derived when your product changes. You send the link instead of the static compliance pack. BETA - expected release Q1 2027.
Answer the question that gates the deal
Procurement asks whether you are compliant before it evaluates what you built. The Passport answers it in one link instead of one quarter.
Proves position, not intent.
Each obligation is shown as met, open or not applicable, with the reasoning written out and the evidence attached.
Stays true after you ship.
The position is re-derived from your engineering data, so what a buyer sees is the product you run today, not the one you documented last quarter.
Covers multiple regimes.
Your compliance posture against AI Act, CRA, PLD, DORA, NIS2 and other frameworks derived from one set of product facts, so they stay consistent instead of drifting apart.
Your documentation is the evidence. The passport is the surface that keeps it current and puts it in front of a buyer.
Derived, not drafted
The Passport is computed from your product parameters and your engineering system of record. Every statement traces back to the provision it comes from, and the same inputs always produce the same output. Nothing on the page is model-generated prose about your compliance posture.
Connect sources, derive position, publish link
You describe the product once and point Grecta at the systems where it changes. No questionnaire, no spreadsheet, no annual re-interview. The engine resolves applicability under each regime, maps the obligations that follow, and binds every one to the artefact that satisfies it. Gaps are returned as gaps.
The position becomes a URL you can send, public or private. Each re-derivation is versioned, so the current page is live and every prior state stays addressable.
96
Hours to first passport
26
EU frameworks
618
Obligations mapped
What sits behind the link
Scope statement.
The product, the version, the components inside scope and the date the position was last derived. Anything outside scope is named, because a passport that quietly covers half a product is worse than none.
Regime-by-regime position.
Each regime answered separately, starting with whether it applies at all. A regime that does not apply is shown as not applicable with the basis, which is itself an answer procurement rarely gets.
Evidence binding.
Every obligation is bound to the artefact that satisfies it, with the date it was produced and last reviewed. Open obligations show as open with a target date rather than being left out.
Version history.
Every derivation is retained and stays addressable. If a defect claim ever arrives under the Product Liability Directive, the record of what you knew and when already exists.
Where Live Compliance Passport earns its place
Health technology.
Clinical and patient-facing software carries Annex III exposure alongside MDR and CRA obligations. Hospital procurement runs a full evidence review before any pilot, and a stalled review costs a budget cycle.
Financial services.
Creditworthiness and risk-scoring features sit squarely in Annex III, and DORA raises the bar on third-party evidence. Bank vendor onboarding will ask for documentation you cannot assemble in the two weeks they allow.
HR technology.
Recruitment and candidate-ranking systems are high-risk under Annex III by default, and buyers now face their own deployer obligations under Article 26. They will ask what you hand them to satisfy those.
Connected products and industrial software.
The Cyber Resilience Act applies to products with digital elements, and the revised Product Liability Directive treats software as a product capable of being defective. Enterprise buyers are already writing both into contracts.
Put a passport on your next RFP
The compliance question is going to arrive before the demo. Answer it with a link. Join the waitlist, or ask for a specimen passport to see the real output.
Join the pilotFAQ
No. Grecta produces the artefacts and the derived position. Certification, where it exists for a regime, is issued by notified or accredited bodies and not by software. For most AI Act categories the conformity assessment infrastructure is not yet fully in place, so anyone offering certification today is misrepresenting what they have.
You choose, per product. Public passports are open and indexable and can be linked from your website or your RFP responses. Private passports are access-controlled, issued per buyer, revocable, and logged so you know who opened them and when. Most companies run both.
Both force a re-derivation. Regime amendments are applied centrally and propagate to every affected passport. Product changes propagate from your own sources. In both cases the previous version is retained, and you are told what moved and why before your buyers see it.
The packs give you the artefacts: notices, literacy programme, technical documentation scaffolding, DDQ bank. The Passport is the live layer over them. It binds each obligation to the artefact that satisfies it and flags when your product has moved away from what the artefact says.
Then the Passport says so and shows why. A reasoned not-applicable is one of the more useful things you can hand a reviewer, because the alternative is silence and silence reads as evasion.
Your system parameters and read access to the engineering source where your product actually changes. No production data, no customer records, and no access to live environments.
Regulatory change, without the monitoring
When DORA, CRA, PLD or AI Act obligations move, we work out what changed and what it means for products like yours. One email, only when something actually happens.
Subscribe to waitlistNo digest, no roundup, no news you already saw on LinkedIn.