A safety case is the documented argument that a system is sufficiently safe to operate in its intended environment.
Not a checklist. Not a certificate. An argument. One that has to hold up when an independent assessor examines every link in the chain between your identified hazards and the evidence that each one is controlled.
The structure is specific: here’s the hazard, here’s the risk analysis that determined the required risk reduction, here’s the safety function designed to achieve that reduction, here’s the evidence that the function works as required. Repeat for every hazard in the system. Add the supporting evidence that the process itself was rigorous. That’s a safety case.
| Component | What it contains | Where it comes from |
|---|---|---|
| Hazard identification | Every identified hazard and the scenarios in which it can occur | Hazard and Risk Assessment (HARA) |
| Risk analysis | Severity, probability, and required risk reduction for each hazard | HARA and risk assessment methodology |
| Safety requirements | Functional and integrity requirements derived from the risk analysis | Requirements management |
| Safety function design | How each safety function is implemented in hardware and software | System design |
| Reliability evidence | Performance Level or SIL verification for each safety function | Reliability calculations |
| Verification and validation | Test evidence that each requirement has been met | V&V process |
| Residual risk assessment | Documented argument that remaining risk is acceptable | Safety team judgment |
Where safety cases come from
Safety cases don’t exist separately from the engineering process. They’re produced by it — or they should be.
In the IEC 61508 V-Model lifecycle, every stage of development generates artifacts that become part of the safety case: the hazard analysis, the safety requirements, the system design, the reliability calculations, the test reports. A safety case built at the end of a project is a documentation exercise. A safety case built continuously, as the development proceeds, is a living record of what was designed, why, and what evidence supports it.
The distinction matters for what the assessor receives. A safety case assembled after the fact has gaps where documentation wasn’t maintained, decisions weren’t recorded, and traceability wasn’t built in. A safety case built throughout the process is internally consistent because the artifacts were linked as they were created.
What assessors actually evaluate
Assessors don’t read safety cases cover to cover. On a typical 500-page technical file with a 4-week review window, they follow threads.
An assessor picks a hazard and traces it forward: to the safety function it requires, to the requirement that specifies that function, to the design decision that implements it, to the test evidence that validates it. If they can follow that thread in both directions without the chain breaking, the review moves quickly.
Every gap generates a question. Questions become follow-up rounds. Follow-up rounds become schedule delay.
What assessors care about most:
Traceability. The chain from hazard to validated safety function has to be explicit. Not implied. Not reconstructible if you know the right person to ask. Written down, linked, available in the document they’re reviewing.
Rationale at the point of decision. The risk graph that determined your required performance level should be adjacent to the hazard it evaluates. Not in an appendix. Not in a separate document that requires a request to access.
Consistent naming. One name per artifact, used identically across every document. Naming drift — “Emergency Stop Function” in the HARA, “E-Stop Safety Function” in requirements, “Emergency Shutdown” in the test plan — generates follow-up questions at scale.
Complete test traceability. Test evidence that doesn’t explicitly reference the requirement it validates is evidence that isn’t connected to the argument. The assessor can’t use it to close the traceability chain.
One assessor reviewing a safety case built on ASAP didn’t ask follow-up questions. Just asked for the output. That’s the result of a safety case where the traceability is structural rather than assembled after the fact.
What makes safety cases fail
Most safety cases that generate extended review cycles aren’t deficient because the engineering was wrong. They’re deficient because the documentation doesn’t reflect the engineering.
Three patterns that produce the most assessor questions:
Traceability documented after the engineering. When teams build the product first and document the safety case at the end, they reconstruct decisions made months earlier. Details are missing. Connections between design choices and safety requirements aren’t explicit. The safety case describes what the team thinks they built, not what the evidence proves.
Static deliverables from consultants. A consultant-produced safety case reflects the design at the point it was reviewed. When the design changes — and it will change — the safety case goes stale. An assessor reviewing an updated system against an unchanged safety case will find gaps. Those gaps require explanation, which requires the engineering team to reconstruct what changed and when.
Volume mistaken for completeness. A 700-page safety case with poor traceability is harder to assess than a 400-page case with clean chains. Assessors aren’t counting pages. They’re following arguments. Page count that doesn’t add to the argument is noise.
What a defensible safety case requires
Three structural properties that separate cases that pass from cases that generate questions:
The hazard analysis drives everything downstream. Every safety requirement traces back to a hazard. Every reliability calculation traces back to a requirement. Every test case traces back to a requirement. There are no orphaned artifacts — nothing in the safety case that can’t be connected back to a hazard in the Hazard and Risk Assessment.
Decisions and rationale coexist. The performance level or SIL that a safety function must achieve is stated alongside the risk analysis that derived it. The architecture decision that achieves PLd is described alongside the hazard that required PLd. The rationale and the conclusion live together, not in different sections that require navigation to connect.
The safety case reflects the current design. Not the design as it was six months ago. Not the design as documented in the last consultant engagement. The current design, with all the changes that have accumulated since certification work began. This requires either extraordinary discipline in manual documentation or a platform that maintains the connection between design and safety case as the design evolves.
Amazon built the methodology behind ASAP over five years inside Amazon Robotics, where it protected more than 1 million robots in 24/7 operation. ASAP generates a 500-page assessment-ready technical file with one click. The file is complete because the traceability was built in throughout the development process, not assembled at the end. That’s what reduced product launch timelines by 26 weeks and contributed to $30M+ in savings across Amazon programs.
FAQ: What Is a Safety Case?
What is a safety case in functional safety?
A safety case is the documented argument that a system is sufficiently safe to operate in its intended environment. It contains the identified hazards, the risk analysis that determined required risk reduction, the safety requirements derived from that analysis, the design of each safety function, evidence that each function performs as required, and a residual risk assessment arguing that remaining risk is acceptable. Assessors review safety cases to evaluate whether the argument holds.
What is the difference between a safety case and a technical file?
A technical file is the broader package of documentation required for regulatory compliance — it typically includes the safety case plus manufacturer information, design documentation, declarations of conformity, and instructions. The safety case is the central argument within the technical file, focused specifically on demonstrating that safety-related risks have been adequately controlled.
How long is a typical safety case?
It varies significantly by system complexity and standard. A safety case for a simple machine might be 50–100 pages. A safety case for a complex autonomous system following IEC 61508 across hardware, software, and firmware can exceed 500 pages. ASAP generates 500-page assessment-ready safety cases with one click. The length isn’t the goal — completeness of the argument and clarity of the traceability are.
What is the most common reason safety cases fail assessment?
Traceability gaps. The engineering work was done. The documentation exists. But the connections between hazards, requirements, design decisions, and test evidence weren’t made explicit. An assessor can’t close the argument if they have to ask where the link is. The documentation has to do the connecting, not the engineer answering follow-up questions.
How is a safety case different from a safety certificate?
A safety certificate is the document issued by an assessor or certification body confirming that a system has met the requirements of a standard. It’s the output. A safety case is the argument and evidence the assessor reviews before issuing that certificate. The safety case is the input; the certificate is what you receive after the assessor determines the argument is sound.
This post covers general functional safety engineering principles and is for educational purposes only. It is not engineering advice. Consult a qualified functional safety professional and your applicable standards body before making safety-critical design decisions.
ASAP generates assessment-ready safety cases with traceability built in throughout the development process, not assembled at the end. See what that looks like.