System safety · · 6 min read
A safety case is usually written as an argument about a specific, frozen configuration. Continuous updates make that assumption false on day one.
The classical structure of a safety case — argument, evidence, tied to a defined configuration at a point in time — assumes the configuration holds still long enough for the argument to remain true. A product shipping monthly software updates breaks that assumption before the ink on the case is dry. The question stops being 'is the product safe' and becomes 'what has to be true for the case to remain valid after the next update'.
A safety case for a continuously updated product needs an explicit change impact process built into it as an argument component, not bolted on afterwards. That means classifying every update against the hazard analysis before release — does it touch a safety-relevant function, does it change timing or resource usage in a way that could affect a safety margin, does it alter an assumption a mitigation depended on. Updates that clear this classification with no impact can ship against the existing case. Updates that do not clear it trigger a defined, scoped re-verification, not a full re-assessment.
The safety case for a continuously updated product is really an argument about the update process, with the product configuration as one input to it.
Continuous deployment also gives an organisation something a fixed-release safety case never had: real operating data on how the product behaves after each change. Feeding that data back into the argument — confirming failure rates and fault behaviour match what the analysis predicted — turns the safety case into something that is actively checked against reality, rather than a document that asserts safety once and is never revisited until the next audit.
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.
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.