What goes in a CRA technical file: Annex VII part by part, and what satisfies each
The eight parts of the Annex VII technical documentation, with the evidence that satisfies each one and where it comes from inside your business.
Parts 1 and 2 below are quoted from Annex VII of Regulation (EU) 2024/2847. Parts 3 to 8 are described rather than quoted, because I could not retrieve verbatim text for them from a source I trust. Check all of it against the official text before you build a file on it. This is not legal advice.
Knowing what the technical file contains is the easy half. Every summary on the internet can list eight headings. The half that decides whether your file survives contact with a market surveillance authority is knowing what evidence actually satisfies each heading, and which department in your own company already has it.
So this page does both. The list, then the mapping.
The eight parts, and where the evidence lives
| Part | What Annex VII asks for | Where it comes from in your business |
|---|---|---|
| 1 | A general description of the product: intended purpose, the software versions that affect compliance, photographs or illustrations of external features and internal layout for hardware, and the Annex II user information | Product management and technical writing. The Annex II information is a deliverable that ships with the product, not a file-drawer item |
| 2 | A description of design, development and production: design information and drawings, the specifications of your vulnerability handling processes including the SBOM, and the production and monitoring processes | Engineering and whoever owns the build pipeline. This is the part that documents how you work, not what you produced |
| 3 | The cybersecurity risk assessment, and how the essential requirements in Annex I apply to the product in light of it | The risk assessment itself. If it was written after the product shipped, it shows |
| 4 | The support period, with the reasoning behind its length | Product and commercial leadership. Article 13(8) sets a five-year floor, but the file has to justify the number you chose rather than assert it |
| 5 | The harmonised standards you applied, with their Official Journal references, and how you met the requirements where you did not apply a standard | Whoever ran conformity. Where no standard was applied, the alternative reasoning has to be written out |
| 6 | Test reports demonstrating conformity with the essential requirements | Internal test evidence, external test evidence, or both, depending on your class and route |
| 7 | A copy of the EU Declaration of Conformity | The declaration itself, per Annex V. It sits inside the file as well as standing alone |
| 8 | The software bill of materials, where an authority asks for it | The build pipeline again, but the archived per-release version rather than the live one |
Parts 1 and 2, in the Regulation's own words
These two carry most of the detail, so they are worth reading exactly rather than in summary. Part 1, a general description of the product with digital elements, including:
- its intended purpose
- versions of software affecting compliance with essential cybersecurity requirements
- where the product is a hardware product, photographs or illustrations showing external features, marking and internal layout
- user information and instructions as set out in Annex II
Part 2, a description of the design, development and production of the product and vulnerability handling processes, including:
- necessary information on the design and development of the product with digital elements, including, where applicable, drawings and schemes
- necessary information and specifications of the vulnerability handling processes put in place by the manufacturer, including the software bill of materials
- necessary information and specifications of the production and monitoring processes
The three parts teams underestimate
Part 1, the Annex II user information
This is not documentation about the product for the file. It is documentation that goes to the user, in the box or in the download, and Annex II lists what it has to contain. The single point of contact for reporting vulnerabilities and the end date of the support period both live here. Which means a decision nobody has made yet, how long you will support this thing, has to be printed on something a customer keeps.
Part 2(b), the vulnerability handling specifications
The wording is specifications of the vulnerability handling processes, including the software bill of materials. A scan output is not a specification. What is being asked for is a description of the process you run: who receives reports, how they are triaged, how updates get built and distributed, and how the SBOM is produced and maintained. Annex I Part II is the requirement; this is where you show the machinery.
Part 4, justifying the support period
Article 13(8) puts the floor at five years, or the expected use time where a product is expected to be in use for less. The file is not satisfied by writing five years in a box. It has to carry the reasoning: what you know about how long this product stays in service, and why the period you picked matches it. Pick a number without a reason and you have created a commitment you cannot defend and cannot easily shorten later.
What the file has to survive
Article 13(13) requires the technical documentation and the EU Declaration of Conformity to be kept at the disposal of market surveillance authorities for at least ten years after the product is placed on the market, or for the support period, whichever is longer.
That has a design consequence people miss. A file assembled out of links to internal wikis, ticket systems and CI artefacts is a file that decays. Ten years is long enough for the wiki to migrate, the CI vendor to change and the repository to be archived. The parts of the file that reference evidence rather than containing it need to reference something that will still resolve in year eight.
Why none of this backfills
The technical file describes how you actually built and maintained the product. A risk assessment that shaped design decisions reads differently from one written afterwards to match them. A vulnerability handling process with a history of handled reports reads differently from a policy published last month. Test evidence accumulated across releases reads differently from a single test run in the final quarter.
That is the real argument for starting in 2026 rather than 2027, and it has nothing to do with beating a queue. The evidence takes time to exist because it is a record of work.
If you want the shorter version of this, we have a plain-language piece on what a technical file is and why it matters. If you do not yet know your class, the classifier will tell you in about a minute at vandorisk.com/classify, and the class decides whether this file is something you sign yourself or something a notified body reviews.