Technical documentation · Annex VII
CRA technical documentation, built from the records you already keep.
Annex VII asks for a file that describes the product, its design, its vulnerability handling, its risk assessment, its support period and its tests. Most of that already exists as operational records — SBOMs, triage decisions, policies, test reports. Vellaci assembles them per product into fourteen Annex VII-oriented sections with version history, and exports the package when an authority or notified body asks.
Who is affected?
Every manufacturer placing a product with digital elements on the EU market from 11 December 2027, whatever its class. The content requirement is the same for default, important and critical products; what differs is who reviews it — the manufacturer alone under internal control, or a notified body.
What evidence is needed?
The file itself, plus what it points to: the SBOM per version, the CVD policy and contact address, the risk assessment, test reports and the EU declaration of conformity — kept for ten years or the support period, whichever is longer.
At a glance
- Who is this for?
- Compliance leads and product engineering at manufacturers preparing Annex VII technical documentation for conformity assessment before 11 December 2027.
- What problem does it remove?
- Technical documentation written as a one-off document months before an audit, disconnected from the SBOMs, decisions and test reports it is supposed to describe.
- Where does it fit in the workflow?
- Downstream of every other workflow: sections reference the SBOMs, vulnerability handling, risk assessment and evidence already recorded for the product, and export as one package.
- What evidence does it produce?
- Fourteen Annex VII-oriented sections per product with status
- Section version history with author
- ZIP technical package (product record, SBOMs, sections, evidence index)
- How does implementation work?
- Each new product gets the fourteen sections automatically. Your engineers fill them; the Implementation engagement sets up the workspace per product and migrates existing documents as evidence.
- What does it connect to?
- Evidence vault (files and links)
- SBOM ingestion
- REST API and organisation export
What happens after you request a demo?
- We reply within two business days with two proposed times.
- A live walkthrough with a Vellaci operator on the seeded demo workspace, focused on your products and your reporting path.
- If it fits, a written proposal: plan, implementation package, deliverables, prerequisites and exclusions. If it does not, we say so.
What happens after you sign up?
- Confirm your e-mail and create the workspace — no credit card for the free Evaluation.
- Add a product and upload one SBOM (UI, API, CLI or GitHub).
- See matched vulnerabilities ranked by exploitation evidence and run your first CRA review; subscribe only when you choose a plan.
Annex VII, point by point
What the regulation asks for, and where it lives in Vellaci.
Left: Annex VII of Regulation (EU) 2024/2847, summarised (official requirement). Right: the section that holds it in Vellaci and where its content comes from. Reviewed 2026-10-05.
| Annex VII | Official requirement (summary) | Vellaci section | Where the content comes from |
|---|---|---|---|
| 1 | General description: intended purpose, software versions affecting compliance, photographs or illustrations for hardware, user information and instructions (Annex II). | Product overview · Intended purpose · User instructions | Product registry and versions; your user documentation attached as evidence. |
| 2(a) | Design and development, including where applicable drawings and a description of the system architecture. | Architecture | Written by your engineers; diagrams attached as evidence. |
| 2(b) | Vulnerability-handling processes, including the SBOM, the coordinated vulnerability disclosure policy, evidence of a contact address and the technical solutions for secure update distribution. | SBOM · Vulnerability handling · Secure update mechanism | SBOMs per version, triage decisions, CVD policy and security.txt status already recorded in Vellaci. |
| 2(c) | Production and monitoring processes and their validation. | No dedicated section — attach as evidence | Your process documents, linked to the product in the evidence vault. |
| 3 | The cybersecurity risk assessment under Article 13, including how the Annex I Part I requirements apply. | Cybersecurity risk assessment · Known risks | Risk assessment drafted per product; accepted risks from triage with their reasons. |
| 4 | Information taken into account to determine the support period under Article 13(8). | Support period rationale | Support period and rationale on the product record. |
| 5 | Harmonised standards, common specifications or certification schemes applied, or the solutions adopted where none were applied. | Security controls | Readiness controls mapped to Annex I Part I, with evidence. |
| 6 | Reports of tests verifying conformity of the product and of the vulnerability-handling processes. | Testing evidence | Test and penetration-test reports in the evidence vault, linked to the product. |
| 7 | A copy of the EU declaration of conformity. | Conformity documentation | Declaration and notified-body references where applicable. |
| 8 | Where applicable, the SBOM, further to a reasoned request from a market surveillance authority. | SBOM | The SBOM bound to the exact version, exportable on request. |
The fourteen sections each product gets: Product overview, Intended purpose, Architecture, Cybersecurity risk assessment, Security controls, Dependencies, SBOM, Vulnerability handling, Support period rationale, Secure update mechanism, Testing evidence, Known risks, User instructions, Conformity documentation. Each has a status (empty, draft, review, approved), an editor, guidance and a version history.
Evidence and technical documentation. The documentation workspace for one product: sections with status, guidance, version history and the ZIP package export.
See this screen with sample dataWhat manufacturers should implement
Obligations behind the file, and the evidence each leaves.
Technical documentation is the end of the chain. The rows below are the obligations whose records feed it.
How to read this. Official requirement summarises the text of Regulation (EU) 2024/2847 with its reference. What your team does is Vellaci’s operational interpretation, not legal advice. Vellaci workflow and Evidence describe what the product does today. Methodology · reviewed 2026-10-05.
- Official requirement
- Identify and document vulnerabilities and components contained in the product, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies.
- What your team does (interpretation)
- Generate an SBOM in the build for every released version, keep it with that version rather than overwriting it, and make sure components carry identifiers (purls) that vulnerability data can be matched against.
- Vellaci workflow
- SBOM ingestion per product version (UI, API, CLI, GitHub/GitLab), original file preserved, components normalised and deduplicated. How it works
- Evidence produced
- Original SBOM file with SHA-256 checksum, bound to the version
- Parse record and warnings
- Component inventory per version and diff against the previous version
- Official requirement
- Systematically document, proportionately to the nature and the cybersecurity risks, relevant cybersecurity aspects of the product, including vulnerabilities the manufacturer becomes aware of and relevant information provided by third parties, and update the risk assessment where applicable.
- What your team does (interpretation)
- Keep the reasoning, not just the status. A 'not affected' without a justification is not documentation; neither is a status that was silently overwritten.
- Vellaci workflow
- Append-only decision history and hash-chained audit log; VEX states with CycloneDX justification codes per product version. How it works
- Evidence produced
- Per-product VEX statements with justification
- Audit log entries with before and after values
- CycloneDX VEX export per version
- Official requirement
- Apply effective and regular tests and reviews of the security of the product.
- What your team does (interpretation)
- Decide which tests run per release and per period (SAST, dependency scanning, penetration tests, reviews), and keep the reports where an assessor can find them per product.
- Vellaci workflow
- Test reports attached to products and requirements in the evidence vault, with review dates; readiness controls show which are missing or overdue. How it works
- Evidence produced
- Test reports linked to the product, with checksum and review date
- Readiness control status per requirement
- Official requirement
- Provide mechanisms to securely distribute updates so vulnerabilities are fixed or mitigated in a timely manner — automatically where applicable — and disseminate available security updates without delay and, unless otherwise agreed for a tailor-made product, free of charge, with advisory messages.
- What your team does (interpretation)
- Document how updates are signed, delivered and applied per product, and be able to show which release fixed which vulnerability and when it was made available.
- Vellaci workflow
- Secure update mechanism section per product in the technical documentation; fixed versions recorded on findings. How it works
- Evidence produced
- Update mechanism description with version history
- Finding → fixed version → release date
- Official requirement
- Handle vulnerabilities effectively for the support period, and determine that period so it reflects the time the product is expected to be in use; it is at least five years unless the product is expected to be in use for less.
- What your team does (interpretation)
- Record a support end date and its rationale per product, keep handling vulnerabilities for every version still inside it, and plan what happens at end of support.
- Vellaci workflow
- Support period with rationale per product, end-of-support alerts, vulnerability handling per supported version. How it works
- Evidence produced
- Support period and rationale on the product record
- Version list showing which versions are still supported
- Official requirement
- Undertake an assessment of the cybersecurity risks of the product, take its outcome into account during planning, design, development, production, delivery and maintenance, document it and update it as appropriate during the support period.
- What your team does (interpretation)
- Write the risk assessment per product, link it to the Annex I controls it justifies, and revisit it when vulnerabilities or incidents change the picture.
- Vellaci workflow
- Risk assessment section in the per-product technical documentation workspace, with version history; per-product obligations view. How it works
- Evidence produced
- Versioned risk assessment section with author and status
- Link between findings and the assessment they updated
- Official requirement
- Draw up the technical documentation before placing the product on the market, containing at least the elements in Annex VII, and keep it, with the EU declaration of conformity, at the disposal of market surveillance authorities for at least ten years after placing on the market or for the support period, whichever is longer.
- What your team does (interpretation)
- Assemble the Annex VII file progressively from records you already keep — SBOMs, vulnerability handling, risk assessment, support period, test reports — instead of writing it once before an audit.
- Vellaci workflow
- Fourteen Annex VII-oriented sections per product with status, version history and evidence links, exported as a ZIP technical package. How it works
- Evidence produced
- Section versions with author and approval status
- ZIP technical package (product record, SBOMs, sections, evidence index)
FAQ
Technical documentation questions, answered.
Operational guidance, not legal advice. The Official Journal text governs.
- What is CRA technical documentation?
- The file a manufacturer draws up before placing a product with digital elements on the EU market to show how it meets the essential cybersecurity requirements. Article 31 and Annex VII of Regulation (EU) 2024/2847 set its minimum content: general description, design and vulnerability-handling processes including the SBOM, the cybersecurity risk assessment, support-period information, standards applied, test reports and the EU declaration of conformity.
- When is it required?
- Before the product is placed on the market once the regulation applies in full on 11 December 2027, and it has to be kept up to date during the support period. It is retained for at least ten years after placing on the market or for the support period, whichever is longer (Article 13(13)).
- Who reads it?
- Market surveillance authorities on request, and the notified body when the product's conformity route involves one (important products in Class II, some Class I products, and critical products). Many manufacturers also share parts of it with large customers under agreement.
- Does Vellaci write the documentation for us?
- No. Vellaci structures it into fourteen sections per product, pre-links the records it already holds (SBOMs, decisions, support period, evidence) and keeps version history. Your engineers write the content; conformity assessment remains your process.
- Is the documentation per product or per version?
- Per product, with references to versions. Annex VII asks for the software versions affecting compliance, and the SBOM is per version; Vellaci keeps both and exports the package for a product with its SBOMs.
- Can we export it?
- Yes. The technical package export produces a ZIP with the product record, the SBOMs, the documentation sections and an evidence index. A full organisation export is also available at any time.
Want the long-form explanation first? Read the Annex VII guide or draft a product risk assessment worksheet.
Read next
- Guide
CRA technical documentation: what Annex VII requires and how to keep it current
The contents of the technical documentation under Article 31 and Annex VII — product description, design and vulnerability-handling processes, risk assessment, support period, standards, test reports, declaration and SBOM — with a structure you can maintain per product for ten years.
- Guide
CRA conformity assessment: Modules A, B + C and H, notified bodies and CE marking
The conformity assessment procedures of Article 32 and Annex VIII explained by product class, how harmonised standards give a presumption of conformity, when a notified body is needed, and what the declaration of conformity and CE marking require.
- Guide
The CRA support period: how long, how to decide and what to publish
Article 13(8) requires a support period of at least five years unless the product is used for less, during which vulnerabilities are handled and security updates provided. How to determine it, document the rationale, publish it and manage end of support.
- Guide
CRA evidence management: what to keep, for how long, and how to keep it provable
The Cyber Resilience Act is evidenced with records, not statements. Which records an authority, notified body, customer or auditor will ask for, the ten-year retention rule, and the properties — provenance, integrity, linkage, retrievability — that make a record count.
- Docs
Evidence vault
Files, links, versions, legal hold, retention.
- Docs
Product registry
Products, versions, lifecycle, classification, exposure context.
Start the file from what you already have.
Add a product, upload its SBOM and see the documentation sections pre-linked to your records — or have the workspace set up with you.