CRA technical documentation: what Annex VII requires and how to keep it current
Article 31 of the Cyber Resilience Act requires manufacturers to draw up technical documentation before placing a product on the market, containing everything needed to assess conformity with the essential requirements, and to keep it for ten years or the support period, whichever is longer. Annex VII lists what it must contain.
By the Vellaci teamPublished Updated 4 min readOperational guidance, not legal advice
Key facts
- Legal basis
- Art. 31; Annex VII; retention Art. 13(13)
- When
- Before placing on the market; updated during the support period
- Retention
- 10 years after placing on the market or the support period, whichever is longer
- Who may ask
- Market surveillance authorities; notified bodies during assessment
- Includes the SBOM
- Yes, where applicable (Annex VII(2)(b) and (3))
What Annex VII requires
| Annex VII item | Content | Practical source |
|---|---|---|
| 1. General description | Intended purpose, software versions affecting compliance, hardware and photographs where relevant, user information and instructions per Annex II | Product registry, versions, user documentation |
| 2. Design, development, production; vulnerability handling | Architecture and how components interact; processes for secure development; vulnerability-handling processes including the SBOM, CVD policy, contact address and update distribution | SDLC policy, architecture docs, SBOM per version, CVD policy, update mechanism description |
| 3. Cybersecurity risk assessment | The assessment under Art. 13(2)–(3), including how each Annex I Part I requirement applies or why it does not | Risk assessment record with requirement mapping |
| 4. Support period | The determined support period and the information taken into account | Support period record with rationale |
| 5. Standards and specifications | Harmonised standards, common specifications or certification schemes applied in full or in part; solutions adopted where they were not | Standards mapping, gap list |
| 6. Test reports | Reports of the tests carried out to verify conformity with Annex I Part I and Part II | Security testing, penetration tests, code review, SCA results |
| 7. EU declaration of conformity | Copy of the declaration per Annex V | Declaration document |
| 8. SBOM | Where applicable, the SBOM on reasoned request of an authority | SBOM per version from the pipeline |
A structure that stays maintainable
Documentation that lives in a folder is out of date the day after the audit. Structure it per product as living sections with version history and links to evidence that already exists elsewhere: the SBOM stays in the SBOM system and the documentation links to the version; test reports are attached as evidence with review dates; the risk assessment references the controls in the readiness framework. Vellaci organises fourteen sections per product along Annex VII, with change history, evidence links and a ZIP export that a notified body or authority can open without an account.
Keeping it current
- Tie documentation review to releases: every version placed on the market updates the general description, the SBOM link and, where relevant, the risk assessment.
- Review the risk assessment when a severe incident or exploited vulnerability occurs; both are new information about the product's risk.
- Version the CVD policy and update policy; keep superseded versions.
- Store test reports with dates and scope; a two-year-old penetration test does not evidence the current version.
- Assign an owner per section and a review date; overdue reviews are readiness findings.
What good looks like per section
General description: name every version placed on the market with its release date, the intended purpose in the words used in marketing and user documentation, and the hardware it runs on. A notified body will compare this with the product it is handed.
Design and development: architecture at the level of trust boundaries — what talks to what, over which protocols, with which authentication — plus the secure development lifecycle you actually follow (threat modelling, code review, dependency policy, signing). Link the policy documents rather than restating them.
Vulnerability handling: the SBOM per version, the CVD policy and contact, the triage process with its SLAs, how advisories are published and how updates reach users. This is the section most often thin, and the one authorities read first after an incident.
Risk assessment: a table of Annex I Part I requirements against the product's risks, controls and residual risk, with 'not applicable' entries justified. Update it when incidents change the picture.
Tests: reports with date, scope, tool or tester, findings and their disposition. A finding fixed in a later version should point at that version.
Retention in practice
Ten years from placing on the market is longer than most tooling and most employment relationships. Store the documentation in a system with retention policies, legal hold and export, keep evidence files checksummed, and make sure the archive of a discontinued product survives the team that built it. Vellaci's evidence vault applies retention categories and legal hold per record and produces a complete export with an integrity manifest.
Documentation for simplified cases
Microenterprises and small enterprises may provide certain documentation in a simplified form the Commission will specify. The obligation to have the documentation remains; the form may be lighter. Until the simplified format is available, follow Annex VII proportionately.
Frequently asked questions
- Is the documentation public?
- No. It is made available to market surveillance authorities on reasoned request and to notified bodies during conformity assessment. Only the declaration of conformity and the user information are user-facing.
- In which language?
- In a language easily understood by the relevant authority — in practice English is commonly accepted, but authorities may request the documentation in their official language.
- Where does evidence of Article 14 reporting belong?
- Reporting cases are part of the vulnerability-handling record and support the process description in Annex VII(2). Keep the case files, submissions and user communications retrievable for the same ten years.