CRA Annex VII defines the mandatory technical documentation for products with digital elements. Rather than a one-time filing at release, the technical file is a living record maintained throughout the product lifecycle.
This guide details the required elements of Annex VII, the three core evidence categories, and timing rules for updates.
Core Contents of Annex VII
Before placing a product on the market, manufacturers must compile a technical file containing:
- General product descriptions, intended use cases, versions, and user profiles.
- Architecture diagrams, security design decisions, and applied technical standards.
- Documented cybersecurity risk assessments under Article 13.
- Technical controls implemented to meet each Annex I essential requirement.
- Verification and test records demonstrating security functionality.
- The signed EU Declaration of Conformity.
- Documented vulnerability handling procedures and intake workflows.
- A current Software Bill of Materials (SBOM) for all software components.
The Three Categories of Compliance Records
Annex VII documentation divides into three functional categories:
1. Internal Technical Documentation
This includes system architecture, threat models, security design choices, and test reports. These records must be created contemporaneously during development.
2. Annex II User Information
Article 13 requires manufacturers to provide users with clear security instructions at the time of purchase. This includes secure setup guidance, support period end dates, and reporting contacts for vulnerabilities.
3. EU Declaration of Conformity
The Declaration of Conformity is the manufacturer's signed legal attestation that the product satisfies CRA essential requirements. The declaration must be finalized before affixing the CE marking and distributing products.
Lifecycle Timing and Update Triggers
Manufacturers must maintain and update technical documentation across four key milestones:
Pre-market compilation. The complete technical file, risk assessment, SBOM, and signed declaration must exist before the initial product release.
System updates. Substantial software updates that alter interfaces, authentication mechanisms, or risk profiles require updating the risk assessment and technical documentation.
Vulnerability handling. The technical file must log all received vulnerability reports, triage evaluations, and applied patches over time.
Long-term retention. Manufacturers must retain the complete technical file for ten years after market release, or for the duration of the support period if longer.
Traceability Across Risk Assessments and Controls
Technical files must demonstrate clear traceability. Auditors expect to trace directly from an identified risk to the implementing control, test verification record, and resulting declaration.
Maintaining interconnected evidence in a centralized compliance platform prevents scattered records and ensures immediate readiness for regulatory reviews.
Summary
Annex VII technical documentation proves conformity with CRA essential requirements. Establishing structured documentation workflows during development ensures compliance before the December 2027 deadline.
The practical challenge for most manufacturers is not producing the documentation but managing it as a coherent, controlled set across multiple products and multiple product versions.
A controlled documentation set has three properties. First, every document has a defined location and version history. Second, access to create or modify documents is controlled, and changes are logged. Third, the current version of every required document is identifiable without ambiguity.
Scattered documentation, where different artefacts are maintained in different systems by different teams, fails these tests. The documentation exists in aggregate but is not a controlled set. When it needs to be produced for a conformity assessment or an audit, the assembly process is itself a risk.
The investment required to build a controlled documentation infrastructure is modest. The cost of not having one surfaces at the worst possible moment.
Keeping Documentation Proportionate
The CRA’s technical documentation requirements are substantial, but the regulation explicitly requires that documentation be proportionate to the product concerned. A small connected sensor has different documentation obligations than a complex industrial control system classified as an important product under Annex III.
Proportionality applies to depth, not to coverage. A proportionate risk assessment for a simple product is thorough but concise. It covers all required elements but does not introduce analysis that is not relevant to the product’s actual risk profile. The same is true for other documentation elements.
Proportionality is not a licence to omit required elements. It is permission to calibrate the depth of each element to the complexity and risk of the product. Getting that calibration right is one of the practical skills that distinguishes manufacturers who build compliance programmes that work from those that produce documentation that satisfies a checklist but does not actually support the decisions it is supposed to record.