CRA readiness · · 5 min read
Most organisations can produce a vulnerability handling policy on request. Fewer can produce evidence that it was followed on the last three findings.
A policy document describing intake, triage, remediation and disclosure timelines is easy to write and easy to present. An auditor who asks for the record of the last three vulnerabilities handled under that policy is asking a different, harder question: did this actually happen, in this order, in this timeframe.
A timestamped intake record, independent of the reporter's own account, showing when the organisation first knew. A triage decision with a stated severity and the reasoning behind it, made by a named person. A remediation record that references the original report and shows the fix that closed it, including in versions still supported. A disclosure record showing what was communicated, to whom, and when, matched against the policy's own timelines.
The policy tells an auditor what should happen. The record is the only thing that tells them what did.
The most reliable way to make a vulnerability handling process auditable is to make the record a by-product of doing the work, rather than a separate write-up done afterwards for compliance purposes. If triage happens in a tracked system with timestamps and named owners as a matter of course, the audit trail exists without extra effort. If it happens over an ad hoc channel and gets written up later from memory, the record will not withstand scrutiny, however accurate the policy document is.
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 template for a technical documentation pack is public. What is not public is which sections a reviewer actually reads twice.
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.
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.