CRA technical documentation: build evidence from each release

Start with an evidence index

A folder full of documents is difficult to review when nobody can explain which release each file describes. Start with a small index: requirement or risk, product/version, evidence location, owner, status and review date.

The CRA includes technical-documentation obligations. Our engineering approach below is a way to organise supporting material; it is not a complete legal conformity checklist or a prescribed file format.

A practical evidence map

Capture evidence where the work happens

Link a security pull request to the risk or gap it resolves. Attach the test outcome to the same issue and identify the first release that includes the fix. Keep the previous version’s evidence when a new release changes the result.

Use the repository and delivery tooling for records that originate there. Reserve a document store for material that does not fit the code workflow, while keeping stable links in the index.

Check whether an outsider could follow the trail

Choose one requirement and ask a colleague to follow it from the decision to the shipped build. Can they see what changed, who reviewed it and what test supports the conclusion? Note any broken links or missing permissions.

Separate evidence that exists from evidence that someone intends to create. Keep unresolved gaps explicit, with owners and next actions. An inventory of missing work is more useful than a polished dossier that conceals uncertainty.

Define the handover

Agree which engineering artefacts Dotgrey Continent will produce, which records your team owns and which formal documents require regulatory input. Manufacturer approvals and the applicable conformity route remain separate responsibilities.

A release evidence manifest can make the handover easier to automate. The downloadable example uses placeholder paths and owner roles; adapt it to your product rather than treating it as an official CRA schema.