CRA technical documentation: the Annex VII file, point by point
Updated 1 November 2026 · This guide explains the law in plain words. It is not legal advice.
The technical documentation is the file that shows how your product and your processes meet the Cyber Resilience Act (CRA) security requirements in Annex I. It must contain at least the eight items in Annex VII, exist before you put the product on the market, and stay up to date during the support period (Article 31). You keep it for at least 10 years after placing the product on the market, or for the support period if that's longer (Article 13(13)).
The eight items in Annex VII
| Point | What it asks for | Who usually writes it |
|---|---|---|
| 1 | A general description: intended purpose, software versions that affect security, photos or drawings of the hardware's outside, markings and internal layout, and the user information from Annex II | Product and hardware team |
| 2(a) | Design and development: drawings, schemes and a system architecture showing how software components fit together | Engineering lead |
| 2(b) | Vulnerability handling: the SBOM, the coordinated vulnerability disclosure policy, proof you gave a contact address for reports, and how updates are distributed securely | Engineering, with policy templates |
| 2(c) | Production and monitoring processes, and how you validated them | Operations or manufacturing |
| 3 | The cybersecurity risk assessment, including how each Part I requirement of Annex I applies | Engineering lead, often with outside help |
| 4 | The information you used to set the support period | Management and engineering |
| 5 | The harmonised standards, common specifications or certification schemes you applied, or a description of your own solutions where you applied none | Engineering lead |
| 6 | Reports of the tests you ran to check the product and your vulnerability handling against Annex I | Test team or lab |
| 7 | A copy of the EU declaration of conformity | Management |
| 8 | Where applicable, the SBOM, when a market surveillance authority asks for it with a reasoned request | Engineering |
The right-hand column is our suggestion, not the law. It's there to show how much of the file rests on knowledge only your team has.
The risk assessment holds it together
Point 3 is the heart of the file. Article 13(3) says the assessment must analyse risks based on the intended purpose and foreseeable use, and the conditions of use such as the operating environment and the assets you protect. It must state whether each Part I(2) requirement applies and, if so, how you meet it.
When a requirement doesn't apply to your product, the file must include a clear justification (Article 13(4)). A temperature sensor with no user accounts may have little to say about access control; say so, and say why.
Standards: mostly point 5 for now
No harmonised CRA standard had been cited in the Official Journal when we checked on 31 October 2026. The EN 40000 series is still in draft. Until standards exist, point 5 means describing your own solutions for the Annex I requirements, plus any other technical specifications you followed. That's more writing than ticking a standard, so allow time.
Format and language
The law doesn't set a template for most companies. If you go through a notified body, the documentation and correspondence must be in an official language of the member state where that body is based, or a language the body accepts (Article 31(4)).
If your product is also a high-risk AI system under the AI Act, you keep one single set of technical documentation covering both laws (Article 31(3), with Article 12).
A simpler form for micro and small firms
Micro and small enterprises may provide the Annex VII elements in a simplified format (Article 33(5)). The Commission has to define that form by implementing act, and notified bodies must accept it. Check the Commission's CRA page to see whether the form is out. It simplifies the presentation; the content still has to cover each element.
Keeping it alive
The file isn't a one-off. Article 31(2) says you update it where appropriate, at least during the support period. Each firmware release that changes the components or the security behaviour should bring a fresh SBOM, updated test reports and, where the risk changed, an updated risk assessment.
A simple folder per release, with the same structure every time, makes this bearable. So does dating every document.
What happens if it's missing
A market surveillance authority can ask for the documentation at any time and you must provide it in a language it can easily understand (Article 13(22)). Breaching the technical documentation duties in Article 31(1) to (4) can bring fines of up to €10 million or 2% of worldwide annual turnover, whichever is higher (Article 64(3)). See the fines guide for how that works.
What Proofsheet does here
The Paperwork pack (€249) includes an Annex VII technical file index. It lists each point, fills in what the app's analysis of your file can support, and marks plainly what you still have to add. From one upload the app generates the SBOM (CycloneDX 1.5 and SPDX 2.3), known CVEs for exact versions, and a map of the evidence to the 22 Annex I points as evidenced, partial or open. The pack also has a support-period record and templates for the vulnerability handling and update policies that point 2(b) asks about.
No software can write your architecture description, your production process or your risk method. Those need people who know the product. Everything the app generates is technical evidence, not a legal certificate.
See a sample report, or read about the SBOM and the declaration of conformity.