CRA Annex VII technical documentation: what the file has to contain
Article 31 of Regulation (EU) 2024/2847 requires technical documentation for a product with digital elements, and Annex VII lists what it has to contain at least. It is drawn up before the product is placed on the market and kept updated, where appropriate, at least during the support period. Like most obligations of the Cyber Resilience Act, this applies from 11 December 2027. This guide goes through the eight points of Annex VII, shows how to organise them per product and names the parts that cannot be filled from data a team already keeps. It summarises the regulation and is not legal advice: the text in the Official Journal is authoritative, and your team assesses how it applies to your product.
更新时间 2026年10月5日
How Attesly keeps CRA evidence per product · Attesly plans and pricing
What Annex VII lists
| Point | What the technical documentation contains |
|---|---|
| 1. General description | The intended purpose; the versions of software affecting compliance with the essential cybersecurity requirements; for a hardware product, photographs or illustrations showing external features, marking and internal layout; the user information and instructions set out in Annex II. |
| 2. Design, development, production and vulnerability handling | Necessary information on design and development, including, where applicable, drawings and schemes and a description of the system architecture; the vulnerability handling processes, including the software bill of materials, the coordinated vulnerability disclosure policy, evidence of a contact address for reporting vulnerabilities and a description of the technical solutions chosen for the secure distribution of updates; the production and monitoring processes and the validation of those processes. |
| 3. Cybersecurity risk assessment | The assessment of the cybersecurity risks against which the product is designed, developed, produced, delivered and maintained under Article 13, including how the essential cybersecurity requirements in Part I of Annex I apply. |
| 4. Support period | The relevant information that was taken into account to determine the support period under Article 13(8). |
| 5. Standards and specifications | A list of the harmonised standards, common specifications or European cybersecurity certification schemes applied in full or in part; where they were not applied, descriptions of the solutions adopted to meet the essential cybersecurity requirements, with a list of other relevant technical specifications applied; where something was applied only in part, which parts. |
| 6. Test reports | Reports of the tests carried out to verify the conformity of the product and of the vulnerability handling processes with the applicable essential cybersecurity requirements in Parts I and II of Annex I. |
| 7. EU declaration of conformity | A copy of the EU declaration of conformity. |
| 8. Software bill of materials | Where applicable, the software bill of materials, further to a reasoned request from a market surveillance authority, provided that the authority needs it to check compliance with the essential cybersecurity requirements in Annex I. |
Annex VII asks for at least this information, as applicable to the product concerned. The table shortens the wording. Read the points in the regulation itself before you rely on them.
Build it per product
The technical documentation describes one product in the versions that are on the market, not the company as a whole. That decides how to organise it.
- One file per product, stating the software versions it covers. With every release, ask which points change.
- Keep the order of Annex VII. A reader finds each point where the regulation puts it, and an empty point stays visible.
- Let separate documents stay separate. The risk assessment, the user information under Annex II and the EU declaration of conformity are documents of their own that form part of the file. Refer to their current version instead of copying text.
- Record what does not apply, and why. Where the risk assessment shows that an essential cybersecurity requirement is not applicable to the product, Article 13(4) expects the justification in the technical documentation.
- One set for high-risk AI systems. For products covered by Article 12 (high-risk AI systems) that are also subject to other Union legal acts providing for technical documentation, Article 31(3) provides for a single set of technical documentation.
当前有 Keep it 份
Article 31(2) expects the documentation to be drawn up before the product is placed on the market and to be continuously updated, where appropriate, at least during the support period. Article 13(13) sets how long it has to stay available to the market surveillance authorities. In practice the file changes when the product does:
- A new software version that affects the essential cybersecurity requirements (point 1).
- A new SBOM, or a change to the components or the architecture (point 2).
- A reassessed support period (point 4).
- A change to the standards or specifications you rely on (point 5).
- New test reports (point 6).
- A substantial modification within Article 3(30), which is an assessment you have to be able to show.
Keep the earlier versions. They show what the file said when a given release was placed on the market.
Evidence that is often still open
Some points follow from data a team already keeps: the product, its version, the SBOM. Others need text or evidence that someone has to write or collect. These are the items Attesly’s template cannot fill from the product record and marks as to be completed:
- The system architecture (point 2): how the software components build on or feed into each other, with drawings and schemes where they exist.
- The secure distribution of updates (point 2): a description of the technical solutions chosen. It sits inside the vulnerability handling item and is easy to overlook.
- The validation of the production and monitoring processes (point 2): Annex VII names the validation, not only the description.
- The reasoning behind the support period (point 4), not only its end date.
- The parts applied (point 5): which parts of a standard or specification were applied, and the solutions adopted where none was.
- Test reports (point 6), for the product and for the vulnerability handling processes.
- Photographs or illustrations of a hardware product (point 1).
- The copy of the EU declaration of conformity (point 7). A draft is not a declaration until it has been signed.
What Attesly does — and does not do
- Does: generate a technical documentation document per product from a template that follows the eight points of Annex VII; fill in what the product record already holds, such as the intended purpose, the version, the imported SBOM, the support period with the information recorded for it and the standards you entered; mark what is still to be completed; keep the risk assessment, the user information, the EU declaration of conformity and the coordinated vulnerability disclosure policy as documents of their own; let you complete a document in an editor and keep earlier versions in its history.
- Does not: write your architecture description or test reports, judge whether the content is correct or sufficient, carry out a conformity assessment, certify products or give legal advice. Attesly is not a notified body.
Attesly’s readiness score counts whether technical documentation exists for a product. It is an aid for finding gaps, computed from your own inputs.
See plans and pricing, book a call, or read how to keep product evidence and SBOMs current and how to prepare an Article 14 report.