Regulations

CRA technical documentation under Annex VII

The eight mandatory elements of CRA technical documentation under Annex VII: when to draw it up, how to keep it current and how long to retain it.

Michał Jaśniewski October 24, 2026 7 min read

Technical documentation is the proof that the product and the manufacturer’s processes meet the essential requirements of Annex I — and the only material a manufacturer has to defend itself before a market surveillance authority. Article 31(1) requires it to contain “all relevant data or details of the means used by the manufacturer” to demonstrate conformity, and Annex VII sets the minimum scope in eight points. It must exist before the product is placed on the market (Article 31(2)), be kept up to date at least throughout the support period, and remain available to the authorities for 10 years after the product is placed on the market or for the support period, whichever is longer (Article 13(13)).

Why this is not an "audit folder"

CRA technical documentation follows the logic of the EU’s New Legislative Framework for product legislation: the manufacturer draws up its own proof of conformity, and the authority checks it only after the fact.

The practical consequence is the opposite of a classic audit. There is no “audit date” to prepare for — the documentation has to be accurate at every moment the product is on the market.

The second consequence: Article 53 and Article 13(22) give the market surveillance authority the right to request the documentation, on a reasoned request, in a language it can easily understand. Answering “we’re gathering the material” already amounts to formal non-compliance within the meaning of Article 58.

The eight points of Annex VII

Annex VII lists what the documentation contains “at least”, as applicable to the product concerned.

1. A general description of the product. Its intended purpose, the versions of software affecting compliance with the essential requirements, and — for hardware products — photographs or illustrations showing external features, marking and internal layout. It includes the user information and instructions required by Annex II.

2. A description of the design, development, production and vulnerability handling processes. The most extensive point. It covers: information on the design and development of the product, including system architecture drawings explaining how software components build on or feed into each other and integrate into the overall processing; the necessary information and specifications of the vulnerability handling processes — including the software bill of materials (SBOM), the coordinated vulnerability disclosure policy, evidence that a contact address for reporting vulnerabilities has been provided, and a description of the technical solutions chosen for the secure distribution of updates; and information on the production and monitoring processes and their validation.

3. The cybersecurity risk assessment. The assessment under Article 13(2) and (3), showing how the requirements set out in Annex I Part I apply.

4. Information on the support period. The relevant factors taken into account in determining the support period under Article 13(8).

5. Standards and solutions applied. A list of the harmonised standards, common specifications or European cybersecurity certification schemes applied in full or in part. Where none were applied, a description of the solutions adopted to meet Annex I Parts I and II, including which parts of any standards were applied.

6. Test reports. Reports of the tests carried out to verify the conformity of the product and of the vulnerability handling processes.

7. A copy of the EU declaration of conformity.

8. The software bill of materials (SBOM). Where applicable, provided further to a reasoned request from a market surveillance authority.

Point 2 is the hardest, because it needs evidence from the process

Points 1, 4, 5 and 7 can be written. Points 2 and 6 require the process to actually run and leave a trail.

The CRA doesn’t ask whether the manufacturer has a CVD policy — Annex I Part II point 5 requires it to be put in place and enforced, and Annex VII point 2 requires that mechanism to be documented, together with evidence that a contact address has been provided.

The same goes for update distribution: Annex I Part II point 7 requires mechanisms to securely distribute updates, and the documentation has to describe the technical solution that delivers this — artifact signing, the distribution channel, verification on the product side.

For an engineering team this means one thing: the artifacts your pipeline already produces (security test results, SBOMs, signing logs, the CVD report register) are documentation material. Generating them automatically with every release costs less than reconstructing them once a year.

The risk assessment is never a one-off

Article 13(3) requires the cybersecurity risk assessment to be documented and updated as appropriate throughout the support period.

The minimum scope: a risk analysis based on the product’s intended purpose and reasonably foreseeable use, as well as the conditions of use, taking into account the expected length of time the product will be in use. The assessment indicates whether, and if so how, the security requirements in Annex I Part I point 2 apply, and how Part I point 1 and the vulnerability handling requirements of Part II are implemented.

Article 13(4) adds the element where documentation most often stumbles: if any essential requirement does not apply, the documentation must include a clear justification. A missing explanation is not a neutral gap — it is an open finding.

For products covered by Article 12 (high-risk AI systems) and by other Union legislation, the risk assessment can form part of the assessment required by that legislation, and Article 31(3) allows a single, combined set of technical documentation — provided it contains the Annex VII information as well as what the other acts require.

The support period has to be justified, not just declared

Article 13(8) sets a minimum of five years, unless the product is expected to be in use for less time — in which case the support period matches that expected use time.

The factors the manufacturer takes into account are listed: user expectations, the nature and intended purpose of the product, relevant Union law on product lifetimes and, optionally, the support periods of comparable products, the availability of the operating environment, the support periods of integrated third-party components, and guidance from ADCO and the Commission.

The information used to determine the support period is recorded in the technical documentation (Annex VII point 4). That is why a bare “we support it for 5 years” is a weak spot — the authority can ask why not longer, if the product realistically lives for eight years in customer installations.

A separate commitment runs under Article 13(9): each security update made available during the support period remains available for at least 10 years after it was issued, or for the remainder of the support period, whichever is longer.

Maintenance and retention periods

Three different figures that are often confused:

The importer has its own, parallel obligation: for 10 years after placing on the market, or for the support period if longer, it keeps a copy of the EU declaration of conformity and ensures the technical documentation can be made available to the authorities on request (Article 19(6)).

Language: the technical documentation and correspondence relating to the conformity assessment procedure are drawn up in an official language of the Member State where the notified body is established, or in a language acceptable to that body (Article 31(4)).

What may still change

Article 31(5) empowers the Commission to adopt delegated acts supplementing the elements in Annex VII, on condition that the administrative burden for microenterprises and SMEs stays proportionate.

Article 13(24) allows the Commission to specify, by implementing act, the format and elements of the SBOM referred to in Annex I Part II point 1. Until such an act applies, the manufacturer chooses a “commonly used and machine-readable” format itself (more in SBOM under the CRA).

The practical takeaway: structure the documentation modularly — eight points as eight separate, versioned artifacts, not one Word file. Adding an element by delegated act should not mean rewriting the whole thing.

Sources

For information only, not legal advice. This article covers the technical and process layer of the obligations under Regulation (EU) 2024/2847; full compliance also requires organizational and legal work on your side and does not replace legal advice or a formal conformity assessment. Current as of October 2026.

CRATechnical DocumentationConformity AssessmentRegulations