The CRA's technical documentation requirements are among the regulation's most concrete obligations, yet they are frequently misunderstood. Manufacturers sometimes treat technical documentation as a compliance deliverable to be produced at the end of the development process, assembled from whatever artefacts exist. The regulation treats it as a controlled, living record that must be created progressively, maintained throughout the product lifecycle, and available on request from the moment the product is placed on the market.
This post sets out what CRA Annex VII actually requires, the different types of evidence it encompasses, and the timing obligations that determine when documentation must exist.
What Annex VII Requires
Annex VII of the CRA sets out the minimum content of the technical documentation that must be drawn up before a product with digital elements is placed on the market. The documentation must, at a minimum, include:
- A general description of the product, including its intended purpose, versions, and intended users.
- Design and development documentation: the product architecture, design choices relevant to security, and any standards or specifications applied.
- The cybersecurity risk assessment conducted under Article 13.
- Information on the security properties implemented and the measures taken to address each essential requirement.
- Testing documentation: test plans, results, and confirmation that the product meets the essential requirements.
- A copy of the EU Declaration of Conformity.
- Information on the processes for handling vulnerabilities, including how vulnerabilities will be accepted, triaged, and addressed during the support period.
- The Software Bill of Materials for all software components included in the product.
The full list is detailed and, for products in Annex III (important products) or Annex IV (critical products), subject to additional requirements depending on the conformity assessment module applied. But the core principle is consistent across all product classes: the documentation must demonstrate, with evidence, that the essential requirements have been met.
The Three Categories of Evidence
The Annex VII requirements fall into three broad categories that operate differently in terms of how they are produced and when they must be created.
Technical documentation
This covers the product architecture, design decisions, security measures implemented, and test results. Technical documentation is produced during development and must reflect the product as it actually exists at the time of market placement. It cannot be written after the fact as a reconstruction; the documentation must be contemporaneous with the decisions it records.
In practice, this means that the security architecture decisions made during design, the threat model produced before development, and the test results generated before release must all be captured as they happen and retained as part of the controlled documentation set.
User information
Article 13 requires manufacturers to provide users with sufficient information to use the product securely. This includes security configuration guidance, instructions for secure installation, information about the support period and what happens when it ends, and a point of contact for vulnerability reporting.
User information is distinct from technical documentation in that it is intended for the end user rather than for the conformity assessment process. Both must exist. The user information must be available at the time of sale, not distributed separately after purchase.
EU Declaration of Conformity
The Declaration of Conformity is the manufacturer's formal statement that the product meets the essential requirements of the CRA. It must be signed by a person authorised to act on behalf of the manufacturer, must identify the product and the conformity assessment procedure applied, and must reference any harmonised standards or common specifications used.
The Declaration of Conformity must exist before CE marking is affixed, and CE marking must be affixed before the product is placed on the EU market. A Declaration of Conformity signed after the product has already been sold is not compliant, regardless of whether the product itself meets the requirements.
When Documentation Must Be Created and Updated
The timing of documentation is one of the most practically important aspects of the Annex VII requirements.
Before market placement. The complete technical documentation set, including the risk assessment, design documentation, test results, SBOM, and Declaration of Conformity, must exist before the product is placed on the market. For new products entering the EU market after December 2027, this is the starting point.
When the product changes. Significant updates to a product, including major software releases, changes to security-relevant features, updates that introduce new network interfaces or data processing, and changes that affect the risk profile, trigger a documentation review obligation. The risk assessment must be updated, and if the changes affect conformity, the Declaration of Conformity must be revised.
When new vulnerabilities are identified. The vulnerability handling records that form part of the technical documentation must be updated as vulnerabilities are received, triaged, and resolved. These records are living documents, not completed once at release.
Throughout the support period. The full technical documentation set must be retained and kept available for inspection for ten years after the product is placed on the market, or for the duration of the support period if that is longer. At the end of the support period, when the manufacturer notifies users that no further security updates will be provided, the documentation must reflect that decision and its date.
Linking Documentation to Risk Assessments and Lifecycle Decisions
One of the most common structural problems in CRA technical documentation is that the documentation elements are maintained independently without clear connections between them. A risk assessment exists in one document. Test results exist in another. The security measures described in the technical documentation do not reference the risks they address. The SBOM is maintained separately from the vulnerability records for the components it contains.
The regulation does not specify a documentation structure, but market surveillance authorities and notified bodies will expect to navigate from a risk to the control that addresses it, from a control to the evidence that it is implemented, and from a vulnerability to the decision made about remediation. A documentation set where these connections must be reconstructed by the reviewer is harder to assess and more likely to generate requests for clarification.
Building explicit links between risk assessment entries and the specific documentation elements that address them is worth the effort during initial documentation creation. It is considerably more effort to add these links retrospectively.
Building a Single, Controlled Documentation Set
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.