CRA Technical Documentation: What Annex VII Requires and How to Build Your Technical File
Your EU Declaration of Conformity is a one-page statement. The technical documentation is everything that makes that statement true. Get the file wrong - or fail to produce it on request - and the DoC is worthless.
TL;DR / Key points
- Under Regulation (EU) 2024/2847, technical documentation, CE marking, and the EU Declaration of Conformity are enforceable from 11 December 2027.
- The technical file must demonstrate compliance with the Annex I essential requirements and contain at least the elements listed in Annex VII.
- It must be retained for 10 years after the product is placed on the market, or for the support period if longer.
- The file is a living document - it must be kept up to date throughout the support period.
- No CRA harmonised standard has been published in the Official Journal yet, so manufacturers must map directly to Annex I for now.
- Start today: assign owners per section and reuse artefacts you already produce.
This post is general guidance, not legal advice. Consult a qualified legal or compliance professional for advice specific to your product and situation.
Annex I vs Annex VII: two different things
People often conflate these two annexes. They serve different purposes.
Annex I sets out the essential cybersecurity requirements - the substantive obligations your product and your processes must meet. It is split into two parts: Part I covers security properties of the product itself (secure by default, minimal attack surface, data minimisation, and so on); Part II covers vulnerability-handling processes (SBOM, CVD policy, security updates for the support period).
Annex VII sets out the minimum content of the technical documentation - the evidence package you must assemble to demonstrate that you have met Annex I. Think of Annex I as the exam questions and Annex VII as the list of things your answer sheet must contain.
Both matter. Annex I tells you what to do. Annex VII tells you what to document and keep.
What Annex VII actually requires
Article 31 of the CRA states that the technical documentation must contain all relevant data or details of the means used by the manufacturer to ensure that the product and the manufacturer's processes comply with the essential cybersecurity requirements in Annex I. It must at least contain the elements set out in Annex VII.
Those elements, as applicable to the product, include:
| Section | What goes in it |
|---|---|
| General description | Product name, intended purpose, relevant software versions; for hardware, photographs or diagrams of external features and internal layout |
| Design, development & production | Architecture documentation, secure development lifecycle evidence, vulnerability-handling processes |
| Cybersecurity risk assessment | The Article 13 risk assessment - required to be included in or explicitly referenced by the technical file |
| SBOM | Machine-readable (CycloneDX or SPDX), covering at least top-level dependencies; lives inside the technical file, need not be public |
| Harmonised standards / technical specifications | List of harmonised standards applied; where none exist, the other technical specifications or methods used to meet Annex I |
| Test reports | Reports of tests performed to verify conformity with the essential requirements |
| Vulnerability-handling & post-market documentation | CVD policy, processes for handling reported vulnerabilities, security update procedures |
| Support period information | The factors taken into account when determining the support period |
The EU Declaration of Conformity (Annex V) is kept together with the technical file, but it is a separate document - it is the signed statement that references the file, not part of the file itself. See our CE marking and EU Declaration of Conformity guide for detail on the DoC.
The standards gap - and what to do about it now
Annex VII requires manufacturers to list the harmonised standards they applied. There is a practical problem: as of June 2026, no CRA harmonised standard has been published in the Official Journal, so the Article 27 presumption of conformity is not available for any product category.
The standardisation request (M/606) was accepted by CEN, CENELEC, and ETSI in April 2025, and the organisations have committed to delivering standards ahead of the December 2027 deadline. Several drafts - including the horizontal EN 40000 series and ETSI's EN 304 6xx product drafts - are the furthest along, but none is ratified or cited in the Official Journal yet. The first standards are expected in the second half of 2026, with Official Journal citation to follow on a timetable the Commission has not yet confirmed.
What this means for your technical file today: you cannot tick the "harmonised standard applied" box, because no box exists yet. Instead, document how you meet each Annex I requirement directly - which technical specifications, internal standards, or recognised frameworks you used, and why they satisfy the requirement. When harmonised standards do arrive, you update that section of the file and gain the presumption of conformity. The rest of the file does not change.
Practical shortcut: Germany's BSI has published technical guideline TR-03183 (including Part 2 on SBOMs, updated August 2025) as detailed implementation guidance. It is not a harmonised standard and does not give presumption of conformity, but it is the most granular public reference currently available for mapping your practices to Annex I. Cite it in your technical file under 'other technical specifications used'.
The technical file is a living document
This is the point most teams miss. The technical documentation is not a one-off exercise completed before launch.
Article 31 of the CRA is explicit: the technical documentation must be drawn up before the product is placed on the market and continuously updated, where appropriate, at least during the support period. In practice, that means:
- Every significant software update that changes security-relevant behaviour should trigger a review of the general description and architecture sections.
- Every vulnerability handled should be reflected in the vulnerability-handling documentation, including how it was discovered, assessed, and remediated.
- Every change to your CVD policy or SBOM should be versioned and dated in the file.
- The risk assessment (see our Article 13 risk assessment guide) must be updated when the product changes substantially.
Market surveillance authorities can request the file at any time. If you cannot produce a current, coherent version, the product can be pulled from the market.
The 10-year retention rule
Manufacturers must keep the technical documentation and the EU Declaration of Conformity at the disposal of market surveillance authorities for at least 10 years after the product is placed on the market, or for the support period, whichever is longer.
For a product with a five-year support period placed on the market in 2027, the minimum retention period is 10 years - until 2037. For a product with a 12-year support period, it is 12 years.
A few practical implications:
- Version every update. A market surveillance authority may ask for the file as it stood at a specific point in time, not just the current version.
- Plan for staff turnover. The person who built the file may not be there in year seven. Ownership must be structural, not personal.
- Plan for company changes. Acquisitions, restructurings, and product discontinuations do not end the retention obligation.
How to build the file without starting from scratch
The good news: most of the content Annex VII requires is documentation your engineering and security teams already produce in some form. The task is to collect, version, and organise it - not to write it from scratch.
Set up a versioned folder (in your document management system, Git repo, or shared drive) with a sub-folder for each Annex VII section. Name an owner for each section — a person, not a team.
Architecture diagrams → General description. Threat models and risk registers → Article 13 risk assessment. Build pipeline SBOM output → SBOM section. Penetration test and security review reports → Test reports. Your security.txt or vulnerability disclosure page → CVD policy.
For each document, note which Annex I requirement(s) it evidences. This mapping is what a market surveillance authority or notified body will follow. Without it, a well-stocked file can still fail inspection.
Add a section titled 'Technical specifications applied in the absence of harmonised standards'. List the frameworks, guidelines, and internal standards you used and explain how each maps to the relevant Annex I requirement.
Tie file reviews to your release process. At minimum: review on every significant release, on every handled vulnerability, and annually even if nothing has changed. Log the review date and reviewer.
Run a dry-run: ask someone not involved in building the file to locate the current SBOM, the risk assessment, and the CVD policy within 30 minutes. If they cannot, the file is not ready for a market surveillance request.
How the technical file connects to the rest of your CRA obligations
The technical file is not a standalone deliverable. It is the hub that connects your other CRA obligations:
- Article 13 cybersecurity risk assessment - must be included in or referenced by the technical file. It is the analytical foundation for the whole file.
- SBOM - required under Annex I, Part II(1); machine-readable (CycloneDX or SPDX); covers at least top-level dependencies; lives in the technical file; does not need to be made public.
- EU Declaration of Conformity (Annex V) - kept together with the technical file; references it; must be updated when the file changes materially.
- CVD policy - required under Annex I, Part II(5); documented in the technical file; must be operational before you place the product on the market.
Use our CRA readiness checklist to track progress across all of these in one place.
The bottom line
The technical file is the evidence that your CE mark is earned, not assumed. It must exist before you place the product on the market, stay current throughout the support period, and be producible on request for at least 10 years.
Start now. Assign owners. Reuse what you have. Version everything. And when harmonised standards arrive - update the standards section and move on.
Stay current: Harmonised standards, Commission guidance, and implementing acts are still landing. Subscribe to The CRA Brief at /subscribe for plain-English updates as each piece of the puzzle arrives — no noise, no vendor pitches.
Related reading
CRA Substantial Modification: When Does a Software Update Re-Trigger Your Conformity Assessment?
Not every software update restarts your CRA conformity work. Here's where the line sits, what the Commission's 2026 draft guidance says, and how to build a lightweight gate into your release process.
Inside the ENISA Single Reporting Platform: How CRA Vulnerability Reports Actually Flow
The ENISA Single Reporting Platform is the only channel for CRA vulnerability reports from 11 September 2026 - but it isn't live yet. Here's how it works and what to build now.
CRA and AI Act: Do You Have to Comply with Both - and Can the Work Be Shared?
If your product has digital elements and contains AI, both the Cyber Resilience Act and the EU AI Act can apply. Here's how the two regimes interact - and how one cybersecurity workstream can serve both.