Technical documentation under the CRA: content and upkeep

This guide shows every part, the rules on retention and language and a structure that avoids file chaos. Art. 13 and Art. 31 apply from 11 December 2027 (Art. 71(2) CRA).

The eight parts under Annex VII

The documentation contains these details as far as they are relevant to the product.

If a requirement does not apply to your product, include a clear justification (Art. 13(4) CRA).

The rules around the documentation

• Timing: Draw it up before placing the product on the market (Art. 13(12), Art. 31(2) CRA).
• Upkeep: Update it as needed, at least during the support period (Art. 31(2) CRA).
• Retention: At least ten years after placing on the market or for the support period, whichever is longer (Art. 13(13) CRA).
• Authorities: On a reasoned request, you send the market surveillance authority the documents in a language it can easily understand (Art. 13(22) CRA).
• Notified body: Documentation and correspondence are in an official language of its Member State or a language it accepts (Art. 31(4) CRA).
• High-risk AI: For products under Art. 12 that are also subject to other acts with technical documentation, you draw up a single set of documentation (Art. 31(3) CRA). Regulation (EU) 2025/327 on the European Health Data Space amends this provision with effect from 26 March 2027.
• Small companies: Micro and small enterprises can use a simplified format. The Commission sets the form by implementing act (Art. 33(5) CRA); as of November 2026 it has not been published yet.

The structure in six steps

1. Clarify product and role. Record whether the product falls under the CRA, which class it belongs to and which role you have.
2. Create a file per version. The documentation belongs to a version. A new version takes over what still applies.
3. Draw up the risk assessment. It is the core: it determines which requirements are met and how.
4. Prove the requirements. Give every requirement of Annex I a status, reasoning and evidence.
5. Test and bring together. Add test reports, SBOM and user information.
6. Release and maintain. Release the state. Changes to the product, risks or standards trigger an update.

What a change triggers

Common gaps

• Risk assessment without a link: It stands alone and does not explain how the requirements are met.
• Support period without reasoning: The end date is set, the thinking behind it is missing.
• Only the product: The vulnerability handling procedures are not described.
• Outdated states: The documentation describes an earlier version.

Example from machine building

The example is invented. A manufacturer builds the KB-800 controller. It falls under the CRA and the Machinery Regulation.

• Structure: One file per version with risk assessment, SBOM and requirements.
• Assessment: One requirement does not apply because the product processes no personal data. The reasoning is in the file.
• Upkeep: Version 2.0 takes over the assessment of 1.0, and changed points are checked again.

Checklist

• Product, class and role are recorded.
• The risk assessment is part of the documentation.
• Every requirement of Annex I has a status and proof, exceptions are justified.
• The support period and the thinking behind it are described.
• SBOM, disclosure policy and contact address exist.
• Test reports cover the product and vulnerability handling.
• Standards applied are listed, including partial application.
• The EU declaration of conformity is included.
• Retention and upkeep are settled.

Technical documentation in Complass

No more folders of Word files where nobody knows which version applies. In Complass every product version has its file:

• Product file: Requirements, support period, SBOM and conformity status sit together per product and version.
• Requirements: You assess every requirement. A new version can take over the assessment of the previous one.
• Completeness check: It shows open points. It does not assess conformity, and the declaration stays with the manufacturer.
• Documents: Technical documentation, risk assessment, EU declaration of conformity and user information start as drafts from the file. "[missing: …]" shows what is still needed.
• Release: Release freezes a document with a checksum.
• Documents for market surveillance: The released documents of a version are compiled as a ZIP package.

Frequently asked questions

Do we have to publish the documentation?

No. You keep it for the market surveillance authorities. For users, the information under Annex II applies.

Do we have to publish the SBOM?

Annex I Part II no. 1 requires you to draw up an SBOM, not to publish it. Annex VII no. 8 names it on a reasoned request from the authority. If you make the SBOM available to users, state where it can be accessed (Annex II no. 9).

Is our existing Machinery Regulation documentation enough?

Not by itself. The documentation under the CRA must contain the details from Annex VII. Much of it can be reused, and both can be maintained together.

Do we need separate documentation for every version?

The CRA prescribes no filing structure. Annex VII does ask for details of the software versions that affect the requirements. One file per version makes that easiest to follow.

Does anyone check the documentation in advance?

That depends on the conformity assessment procedure. In procedures with a notified body it is part of that body's review. The market surveillance authority can also request documents on a reasoned request.

In a demo we use the demo company to show you how a product file becomes a draft of the documentation.

Request a demo Try it for 14 days

Read more

• Guide "Does the CRA apply to you?"
• Guide "SBOM under the CRA"
• Guide "Vulnerability handling under the CRA"
• Whitepaper on the CRA for manufacturers
• The CRA in Complass

Not legal advice. This guide gives a general overview and does not replace an assessment of the individual case. The wording of Regulation (EU) 2024/2847 in the Official Journal is authoritative. As of November 2026.