Safety Case

What a safety case actually does

A safety case is not just a compliance document. It is the structured argument that ties a safety claim to the evidence, assumptions, operational boundaries, and residual risks that make the claim credible in a real deployment. The core value is that the assurance case is explicit, testable, and limited to the context in which it was built.

That context matters because safety claims can become stale. A system may meet its intended safety requirements in one version, environment, or integration pattern, then quietly drift out of scope when software changes, hardware is swapped, or suppliers update components. In autonomous systems, the safety case has to stay connected to the actual operating picture, not just the original certification moment.

Why context and assumptions are part of the claim

The defining feature of a safety case is that it names the conditions under which the claim holds. Those conditions can include the environment, operator behaviour, usage constraints, maintenance assumptions, and dependencies on upstream components. If any of those assumptions change, the claim may need to be re-evaluated rather than merely re-stated.

In practice, that makes a safety case closer to a living assurance argument than a static report. Good safety engineering makes the boundaries visible so teams can see what is covered, what is excluded, and what must be monitored for drift. When those boundaries are vague, the assurance claim becomes hard to challenge and even harder to keep current.

Why cybersecurity belongs in the assurance argument

For autonomous vehicles and other connected systems, cybersecurity can directly affect whether the safety claim still holds. Attack paths, insecure interfaces, compromised updates, and altered data inputs can all undermine assumptions that were reasonable when the case was written. That is why a robust safety case should account for cyber threats wherever they can influence safe operation.

The safety and security relationship is especially important when external suppliers, software updates, or remote services sit inside the system boundary. A change in one component can invalidate the evidence chain if the new component introduces different trust assumptions, failure modes, or dependencies. The argument only remains credible when it reflects those interdependencies clearly, which is why co-engineering safety and security is often necessary in complex systems such as those covered by the Safety and Security Co-engineering Guide.

Change control, evidence maintenance, and assurance drift

A strong safety case depends on disciplined change management. Every meaningful update, integration, dependency shift, or operational change should be assessed against the original safety argument so the evidence remains aligned with reality. Without that discipline, the safety case can look complete while quietly losing validity.

This is why the best safety cases are maintained as part of the system lifecycle, not archived after approval. They should be revised when the system design changes, when suppliers modify delivered components, or when new hazards emerge in operation. The objective is not to produce more paperwork, but to preserve a trustworthy claim that still matches how the system actually behaves.

What reviewers should look for

Reviewers should ask whether the safety claim is traceable from requirements to evidence, whether the operating context is explicit, and whether the assumptions are realistic and monitored. They should also check that cyber-related dependencies, update paths, and third-party relationships are addressed wherever they can affect safe function.

A useful safety case does not prove that nothing can fail. It shows that the organisation understands the hazards, has bounded the claim, and can explain why the remaining risk is acceptable in that specific context. That is what makes it an assurance argument rather than a slogan.

Risk and Threat Considerations

Safety cases become risky when they stop reflecting the current system. If assumptions about software versions, integration behaviour, supplier components, or cyber exposure are no longer true, the assurance claim can become misleading even though the document still looks authoritative.

Failure mechanism: A change in software, connectivity, data flow, or supplier dependency can invalidate the evidence behind the claim, while attackers may target the gap between the documented assurance case and the system that is now actually deployed.

Impact: The result can be unsafe operation, delayed detection of assurance drift, or unjustified confidence in a system whose safety boundary has silently moved.

Practitioner Guidance

Why practitioners should care: Treat the safety case as a living control artefact, not a one-time deliverable. Its value depends on whether it still matches the deployed system, the approved operating context, and the current dependency chain.

What to watch for: Rework the assurance argument whenever the system changes in ways that can affect hazards, trust assumptions, or supplier behaviour. The most common failure is not a missing template, but an outdated claim that no longer reflects deployment reality.

Practitioner takeaway: A safety case is only as strong as the evidence discipline behind it, so keep the argument, the system, and the assumptions aligned throughout the lifecycle.

Related resources from NHI Mgmt Group

• How should organisations respond when an LLM passes broad safety tests but fails a specific use case?
• How should safety teams generate realistic edge-case scenarios for autonomous vehicle testing?
• What are the signs that AI safety testing is too generic for the use case?
• How should AV programmes build cybersecurity into a federal safety-case model?