What auditors look for in an ISO 26262 safety case (and where most fall short)

Key takeaways

• The ISO 26262 safety case is now assessed as a structured argument, not a binder of evidence. Assessors test the argument graph first; the evidence is what closes leaf claims, not what carries them.
• Three failure patterns dominate ASIL B and ASIL D audit findings: unresolved sub-claims hidden by evidence density, argument-evidence binding that supports a near-claim rather than the actual claim, and a case that calcifies at start of production (SOP) instead of staying current with the product.
• ASPICE 4.0 (2023) and ISO/PAS 8800 are tightening expectations on bidirectional traceability and on how AI-related arguments fold into the same case structure.
• Software-defined vehicle (SDV) programs treat the safety case as a living artifact. Each over-the-air (OTA) update is a change to the product that must be re-argued and re-released in the case.
• LHP's Functional Safety Certifiable Framework delivered ASIL D certification on the Sonatus Automator Safety Interlock in 7 months instead of the 12-month industry-typical estimate by treating the safety case as a continuous artifact rather than a SOP-bound binder.

A finished ISO 26262 safety case is supposed to argue, on the record, that the product is acceptably safe. Most safety cases delivered to assessors in 2026 do something different. They assemble evidence in volume and leave the assessor to reconstruct the argument. That gap is where audits now fail, and it is the single biggest reason Automotive Safety Integrity Level (ASIL) B and ASIL D programs miss their certification window.

Why this matters now

Three pressures have converged on the safety case in the last 24 months. Automotive SPICE (ASPICE) 4.0, published by VDA QMC in December 2023, sharpened the assessment bar on bidirectional traceability and on the integrity of the argument that ties evidence to safety claims. ISO/PAS 8800:2024, published December 13, 2024, addresses AI in safety-relevant automotive systems by tailoring applicable clauses of ISO 26262-4, ISO 26262-6, and ISO 26262-8 and extending the SOTIF (ISO 21448) concepts for functional insufficiencies. UN Regulation 155 has applied to new vehicle types since July 2022 and to all newly produced vehicles in contracting parties since July 2024, tying the cybersecurity case to type approval and making a combined safety-and-security argument the practical artifact assessors review.

A fourth pressure sits underneath those three. Software-defined vehicle (SDV) programs treat the safety case as a living artifact rather than a one-time submission. An over-the-air (OTA) software update is a change to the product, which means the case must be re-argued and re-released alongside it. Programs built around binders that close at start of production cannot absorb that cadence.

The consequence for engineering leaders is concrete. A safety case that passed an external assessment in 2022 can fail an equivalent assessment in 2026 on the same content. The bar moved. The specific way it moved is that assessors are now testing the argument itself, not only the evidence behind it.

What is an ISO 26262 safety case, exactly?

ISO 26262 Part 2 names the safety case as a required work product. The standard's definition is short: a structured argument that the product is acceptably safe for its intended operational context, supported by evidence. Three things are doing the work in that sentence.

The argument is the structured reasoning that links the top-level safety claim to the sub-claims that decompose it: each safety goal is met, each ASIL allocation is justified, each safety mechanism behaves as required. Most LHP engagements use Goal Structuring Notation (GSN), or a tabular equivalent, to make the argument graph explicit.

The evidence is the body of analyses, reviews, and verification artifacts that close out the leaf claims. Hazard Analysis and Risk Assessment (HARA) outputs, Failure Modes, Effects, and Diagnostic Analysis (FMEDA) results, Fault Tree Analysis (FTA) branches, requirements traces, Modified Condition / Decision Coverage (MC/DC) coverage reports, and integration test results all sit at the bottom of the argument graph as evidence.

The binding is what most programs do not formalize. Each piece of evidence has to attach to the specific sub-claim it supports, and the auditor has to be able to walk from any safety claim down to the evidence and back up. The binding is the trace.

A safety case that reads as a 400-page document organized by ISO 26262 part numbers is usually not yet a safety case. It is the raw material a safety case is built from.

Where do ISO 26262 safety cases fall short under audit?

Three failure patterns dominate findings on ASIL B and ASIL D programs. The first is the most common. The third is the most expensive to fix late.

Argument structure: unresolved claims hidden by evidence density

The assessor selects a safety claim at ASIL B or above and asks the team to walk down the argument graph to the evidence that closes it. On a healthy program, every sub-claim has a documented argument strategy and at least one cited evidence item. On many programs, mid-graph sub-claims are present in the index but no argument actually develops them. The team has assembled evidence underneath the gap, and the gap reads as covered because the evidence is dense. An assessor trained on the GSN convention sees the gap in minutes.

The fix is not more evidence. The fix is to write an argument strategy for every sub-claim before the evidence is assembled, and to review the argument graph as a freestanding artifact, separate from the evidence binder.

Argument-evidence binding: evidence that supports a near-claim, not the claim

The assessor selects a leaf claim and asks which evidence item closes it. The evidence item is real, high-quality, and supports a claim that is a paraphrase of the leaf claim, not the leaf claim itself. The most common example is verification evidence reporting coverage against a software-level requirement when the safety claim is stated at the system level. Both items exist. Neither is wrong on its own. The trace between them is missing or implicit.

The fix is binding discipline at requirements decomposition. When a system-level safety requirement is decomposed to software-level requirements, the decomposition rationale becomes part of the argument, and the system-level claim cannot be closed by software-level evidence alone. An LHP functional safety expert recently described this binding work as the argument LHP is most often hired to retrofit. It is also the most labor-intensive item to retrofit late in a program.

Maintenance over the lifecycle: the case calcifies at SOP

The assessor asks for the safety case as it stood at start of production (SOP), then for the current safety case, then for the change log that explains the differences. On a healthy program, each material change to the product produced a documented change to the case, ideally generated by the same change request that triggered the engineering work. On most programs, the SOP-vintage case is on a shared drive, the current product is two software releases ahead of it, and the changes between them live in Jira, in modeling tools, and in spreadsheets. Reconstructing the case at any baseline date is a manual effort sized in weeks.

The fix is configuration management discipline applied to the safety case as a first-class artifact, with the case under the same baseline rigor as the source code and requirements. This is the area where SDV-bound programs have the least slack and where late retrofit is most expensive.

How LHP approaches this

LHP runs safety case construction inside the LHP Functional Safety Certifiable Framework, the ASIL D-ready development methodology that delivered the Sonatus Automator Safety Interlock to ASIL D certification by UL Solutions in seven months instead of the one-year industry-typical estimate. The Framework treats the safety case as a continuous artifact: argument-graph structure is in place at concept, evidence binding is enforced at each independent assessment checkpoint, and the case is baselined at every milestone alongside the source code and requirements. Toolchain qualification, including non-compliant compilers like GCC (GNU Compiler Collection), is part of the package so the evidence is auditable rather than assertion-based.

For programs that already have a partial case, LHP runs a focused safety-case audit that walks the argument graph, tests the binding on a sample of ASIL B and ASIL D claims, and returns a prioritized remediation roadmap. The methodology is tooling-agnostic across the common safety-case tools and integrates with existing requirements management and modeling environments.

What this means for your next program

The safety case is becoming the shared artifact across safety, security, and AI compliance. ISO/PAS 8800 references the ISO 26262 case as the receiving structure for AI arguments. UN R155 cybersecurity arguments increasingly fold into the same artifact. Programs that learn to maintain the case as a living argument now will absorb the next two regulatory cycles without rebuilding the case each time. Programs that continue to assemble binders at start of production will rebuild them every cycle, and the rebuild cost will compound.

For an engineering leader inside a current ASIL B or higher program, the next step is concrete: pull the argument graph, not the evidence binder, and read it as a freestanding document. If the argument cannot be followed without the binder, that is the work to start this quarter, not the quarter before the assessment.

Frequently asked questions

When is a Goal Structuring Notation (GSN) graph required for an ISO 26262 safety case?

ISO 26262 Part 2 does not mandate GSN specifically; it requires a structured argument supported by evidence. GSN is the most common notation LHP sees in current engagements because it makes the argument graph explicit and assessor-readable, but a tabular equivalent that captures claims, strategies, sub-claims, and evidence with the same rigor is acceptable. The defensible posture is to choose a notation and apply it consistently across the program; mixing notations within a single case is what loses assessor confidence.

How is the safety case different from the safety plan and the assessment plan?

The safety plan describes what work will be done; the assessment plan describes how that work will be assessed; the safety case is the structured argument, supported by the resulting evidence, that the work makes the product acceptably safe. The safety case sits downstream of both plans and is the primary artifact an external assessor reads. A program with a strong safety plan and a weak safety case typically has the engineering rigor but has not formalized the argument.

What changes for the safety case under software-defined vehicle (SDV) and over-the-air (OTA) update programs?

Each OTA update that touches safety-relevant code is a change to the product and requires the case to be re-argued at the affected sub-claims and re-released. SDV programs that built their case as a SOP-bound binder cannot absorb that cadence and end up with a case that drifts from the deployed product. The pattern that works is to treat the case as a configuration item: under baseline control, regenerated at each release, with the argument graph and binding evidence kept current with the codebase.

How does ISO/PAS 8800 affect the ISO 26262 safety case structure?

ISO/PAS 8800:2024 addresses AI in safety-relevant automotive systems by tailoring applicable clauses of ISO 26262-4 (system development), ISO 26262-6 (software), and ISO 26262-8 (supporting processes), with functional insufficiencies handled through extensions of the SOTIF (ISO 21448) concepts. In practice, the AI argument attaches to the existing safety goal decomposition as additional sub-claims (data quality, training-distribution coverage, monitoring-runtime behavior), with new evidence types underneath them. The change is additive: existing ISO 26262 cases remain valid as a base; AI-specific scaffolding extends them rather than replaces them.

About LHP Engineering Solutions

Since 2001, LHP Engineering Solutions has helped companies deliver technology that must perform as intended, every time. Our clients operate in safety-critical, operation-critical, and mission-critical environments such as on-highway, off-highway, aerospace, defense, and oil & gas, where failure is not an option, and delays cost market share.

LHP helps organizations design, architect, validate, and monitor complex systems. Our global team of engineers supports the development of advanced technologies, including high-voltage power electronics, hybrid and electric powertrain controls, connectivity, and ADAS platforms, enabling OEMs and Tier-1 suppliers to bring next-generation products to market quickly and with confidence.

In compliance-driven industries, LHP uses our model-based systems engineering (MBSE) approach, enhanced through AI, to help companies move quickly while meeting rigorous standards, including functional safety, ASPICE, and cybersecurity. Our teams have helped global technology companies achieve functional safety certification and ASPICE compliance in months rather than years, and established enterprise-grade safety and cybersecurity management systems for leading OEMs.

When organizations must make major technology leaps, such as launching next-generation platforms, future-proofing vehicle architectures, or proving new concepts to secure market-defining programs, LHP delivers the engineering disciplines, solutions, and on-time execution required to succeed.

Because in industries where technology must perform as intended, precision engineering matters.