CRA readiness · · 6 min read
The template for a technical documentation pack is public. What is not public is which sections a reviewer actually reads twice.
Most organisations building a CRA technical documentation pack for the first time work from the Annex structure and assume completeness is the goal: every section present, every heading populated. In review, completeness is rarely the first question. The first question is whether the document was written by someone who understands the product, or assembled from templates by someone who does not.
A reviewer forms an opinion quickly on whether the document reflects the product or reflects a process someone ran once to generate it. The tell is inconsistency: a risk assessment that references a component the SBOM does not list, or a secure development description that does not match the branch and release process in use. None of these are large errors individually. Together, they suggest the document was not maintained alongside the product.
A reviewer is not looking for a perfect document. They are looking for evidence that someone owns it.
Short, direct answers to the risk assessment questions, written in the language of the product rather than the language of the regulation. A change log for the documentation itself, showing it moves when the product does. Cross-references that resolve — a claim in the conformity assessment that points to a specific test record, not a general statement that testing occurred.
None of this is exotic. It is the difference between documentation treated as a deliverable and documentation treated as a live artefact with an owner.
CRA SCOPE CHECKER
Enter your website. We read what you make and sell, then ask only the few questions the regulation turns on.
About 60 seconds. No account. PDF report on request.
CRA readiness
The reporting duties arrive well before the main obligations. They are the first point where a product organisation is measured on process, not intention.
System safety
Most programmes have traceability on paper. Fewer can follow a single hazard to the verification that closed it without a manual reconstruction.
Engineering practice
When safety and product security work in separate structures, the contradictions surface late — usually in a customer review.
CRA readiness
The first SBOM run is usually a success. The second one, three months later, is where the gap between having a tool and having a process becomes visible.
System safety
Run separately, the two standards produce two item definitions, two review cadences and two sets of evidence that quietly contradict each other.
System safety
A hazard analysis that stops at a mitigation statement has done half the job. The other half is writing something a test engineer can act on.
CRA readiness
Most organisations can produce a vulnerability handling policy on request. Fewer can produce evidence that it was followed on the last three findings.
System safety
A safety case is usually written as an argument about a specific, frozen configuration. Continuous updates make that assumption false on day one.