Compliance Does Not Build Safe Products

The phrase ISO 26262 compliant or ASIL compliant appears frequently in automotive technical discussions, project updates, and marketing material. It often conveys confidence that a product has been developed according to the standard and can therefore be considered safe. While compliance with ISO 26262 is an essential objective, it should never be mistaken for proof of absolute safety.

After years of leading functional safety organizations, supporting global development teams, conducting assessments, and working with customers across multiple programs, I have found that the strongest indicator of a successful safety program is not the volume of completed work products but the quality of the engineering decisions that those work products capture.

A project can produce every required document, complete every planned review, and satisfy every process milestone while still carrying significant technical risk. Conversely, another project may have minor documentation deficiencies yet demonstrate a robust architecture, well-reasoned safety mechanisms, and convincing evidence that the identified hazards have been addressed. Neither situation should be considered ideal, but they illustrate the distinction between process compliance and engineering confidence.

ISO 26262 recognizes this distinction. The standard defines activities, expected work products, and confirmation measures that establish confidence in the development process. It does not claim that completing documents automatically produces a safe product. The objective is to develop sufficient evidence that the implemented design satisfies the safety goals under the defined assumptions and operating conditions.

This distinction becomes especially important as projects mature. Requirements are written before the architecture is fully stabilized. Safety analyses are updated while interfaces continue to change. Diagnostic concepts evolve alongside hardware and software designs. These iterations are normal. The risk arises when organizations begin treating documents as the primary measure of progress instead of verifying whether the underlying engineering assumptions remain valid.

A common example that appears during safety assessments is teams often focus on demonstrating that every required work product exists, all checklists are completed, templates are populated, and repositories updated and organized. Yet when the discussions move to the core of the arguments about what makes a system safe, fundamental engineering questions may remain unanswered.

• Why is it alright to use this method that does not detect this fault?
• Can you demonstrate that this fault will not be latent?
• What common resources were evaluated and why are they acceptable from a common cause of failure standpoint?
• Does the safety case present a coherent engineering argument, or does it simply reference documents?

These questions require engineering judgment supported by objective evidence.

Another misconception is that functional safety can be added near the end of development or that they are just diagnostics. In reality, many of the most significant safety decisions occur long before detailed design begins. Architectural partitioning, hardware redundancy, diagnostic concepts, communication strategies, assumptions of use, and development interface agreements all influence what becomes technically achievable later in the program. Once these decisions are established, correcting deficiencies often becomes expensive, disruptive, or impractical.

Organizations that consistently deliver successful safety programs typically share several characteristics.

• Functional safety activities begin alongside system engineering rather than after it.
• Architectural decisions are evaluated from both functional and safety perspectives.
• Safety analyses evolve together with design changes instead of becoming periodic documentation exercises.
• Assessment findings are treated as opportunities to improve engineering quality rather than simply close compliance gaps.
• Engineers are encouraged to challenge assumptions, even when documentation appears complete.

An assessment should not become an exercise in verifying whether every template has been completed. Its purpose is to determine whether sufficient, consistent, and technically credible evidence supports the claim that the product satisfies its safety objectives. Good assessors therefore spend as much time evaluating engineering rationale and consistency as they do reviewing work products.

The same principle applies to the safety case. A safety case is not a collection of references or an archive of completed documents. It is a structured engineering argument that explains why the product can be considered acceptably safe for its intended application. Every referenced analysis, requirement, verification activity, and assessment contributes to that argument. If the argument is weak, adding more documents rarely strengthens it.

We should move away from asking, is this project compliant and ask do we have a strong and convincing case that this product will behave safely under the conditions for which it was designed?