CRA technical documentation — what to prepare and how to maintain it

CRA technical documentation is not a one-off document prepared for an audit. Article 31 requires it to be drawn up before the product with digital elements is placed on the market and updated as appropriate, at least during the support period.

If architecture, decisions and test results have to be reconstructed from email, tickets and team memory, the problem is not a missing template. The problem is the absence of a maintained product-and-evidence model.

What Annex VII covers

The exact content depends on the product, but Annex VII identifies at least these groups of information.

1. General product description

This includes the intended purpose, software versions affecting compliance with essential cybersecurity requirements, and the information and instructions supplied to users.

2. Design, development, production and vulnerability handling

The documentation should contain enough information to understand the design and architecture, component relationships and the manufacturer’s vulnerability-handling processes.

CRA explicitly refers here to the SBOM, coordinated vulnerability disclosure policy, evidence of a vulnerability-reporting contact address and the technical solutions used for secure update distribution.

3. Cybersecurity risk assessment

The record should show the risks against which the product is designed, developed, produced, delivered and maintained, and how the Annex I requirements apply.

4. Basis for the support period

The documentation needs more than an end date. It should retain the information the manufacturer used to determine that period.

5. Standards and technical solutions used

Where relevant harmonised standards, common specifications or cybersecurity certification schemes are used, the documentation identifies them and the parts applied. Where they are not used, the manufacturer needs to document the solutions adopted to meet the applicable requirements.

6. Test reports

Evidence of tests performed to verify the product and vulnerability-handling processes against applicable requirements.

7. EU declaration of conformity

A copy of the declaration for the product.

8. SBOM when required by a market-surveillance authority

Annex VII provides for the relevant SBOM to be made available following a reasoned request where necessary for the authority to check compliance.

Use an index, not one giant PDF

A practical model is a documentation index tied to a product version.

Area	Source artefact	Owner	Version / date	Review evidence
intended purpose	product record	Product Owner	v3.4	approval
architecture	diagram + description	Engineering	v3.4	review
risk assessment	risk register	Security/Product	v3.4	decisions
SBOM	build/release artefact	Engineering	release 3.4.2	hash / log
testing	reports	QA/Security	release 3.4.2	result
CVD	policy	Security	rev. 5	approval
support period	decision record	Product/Management	2026-09	rationale

Technical documentation can consist of many artefacts. What matters is being able to identify which artefact applies to which version and who confirmed that it was current.

Four patterns that create unnecessary cost

“We have a policy, so this is covered”

A policy describes how the organisation intends to work. It does not prove that a specific product release was assessed and tested.

“The architecture is in the repo; everyone knows where”

After a team change or eighteen months, “everyone knows” stops being a usable evidence source.

“The SBOM is generated in the pipeline”

Good — but the documentation still needs to tie that artefact to the product, release and vulnerability process.

“We will export everything before the audit”

If source records are inconsistent, an export only exposes that inconsistency faster.

How Pulsar can organise the documentation trail

The current Pulsar product model confirms areas for documents, evidence, risks, controls, reports and analysis history. That allows documentation to operate as linked records instead of a folder containing final files only.

The target record should answer:

which product and version an artefact belongs to;
which requirement or risk it supports;
who created and approved it;
when it was current;
which action or decision it proves;
what changed since the previous review.

Pulsar does not supply protected standards content and does not replace technical documentation produced by the manufacturer. It helps maintain structure, ownership and traceability.

See documents and evidence in Pulsar GRC

Sources

Sources checked: 12 September 2026.