System safety · · 5 min read
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.
A hazard analysis workshop typically ends with a mitigation column filled in: 'system shall detect and respond to sensor fault'. This reads as progress, and it is usually where the analysis is filed as complete. It is also, on its own, untestable — nothing in that sentence tells a verification engineer what evidence would satisfy it.
Turning a mitigation statement into a requirement is a distinct piece of engineering work, and it usually needs someone who understands both the hazard analysis and the system's actual behaviour under fault injection. 'Detect and respond to sensor fault' becomes several requirements: a fault detection requirement with a latency bound, a response requirement naming the safe state, a requirement covering the transition itself, and a requirement covering what happens if detection fails. Each one needs its own verification method stated at the point it is written, not inferred later by whoever picks up the test plan.
If two competent engineers would design different tests from the same requirement, the requirement is not finished.
Untestable requirements do not fail loudly. They pass review because they sound reasonable, and they fail later — in an audit, or worse, in the field — because the verification that was supposed to close them was actually closing something narrower or something different. The cost of writing a precise requirement is paid once, early. The cost of an imprecise one is paid repeatedly, later, by whoever has to reconstruct what was actually meant.
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.
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.