Navigating ISO 26262 and IEC 61508-3 Functional Safety Standards for Safety-Critical Software

Yashaswini Maregowda

March 18, 2026

For companies building software that controls vehicles, robots, or any system where a malfunction can endanger lives, two standards define how you prove that your product is safe: ISO 26262 for automotive, and IEC 61508-3 for safety-critical software across industries.

Most teams don't engage with these standards proactively. They encounter them when an OEM demands a safety case, when an assessor flags a traceability gap, or when a recall triggers a root cause investigation. By that point, the cost of catching up is significant: months of rework to reconstruct the evidence chain, delayed launches while documentation is backfilled, and safety cases that reflect what should have happened rather than what actually did.

The pattern is consistent. Engineering builds the product. A separate effort reconstructs the safety argument after the fact. And assessors can tell the difference.

Both ISO 26262 and IEC 61508-3 are well-designed standards. They work. But they demand something that most development organizations struggle to deliver: continuous, bidirectional traceability from hazard analysis through requirements, design, implementation, and verification, maintained in real time across every change. Teams that build this discipline from the start find that compliance becomes a natural output of their engineering process. Teams that defer it find that the rework compounds with every release.

This guide breaks down what these standards actually require, how they relate to each other, and the real-world pitfalls that derail teams, along with practical advice on how to get compliance right from the start.

ISO 26262: Functional safety standard for the automotive industry

ISO 26262 is the international standard governing functional safety of electrical and electronic (E/E) systems in road vehicles. First published in 2011 and significantly revised in 2018, it covers the entire product lifecycle from concept through development, production, operation, service, and decommissioning.

The standard is built around a structured safety lifecycle modeled on the V-model development process. At its core, it demands that teams:

Start with Hazard Analysis and Risk Assessment (HARA): HARA identifies potential hazards caused by E/E system malfunctions and evaluates each one based on three factors: severity of potential harm, probability of exposure, and controllability by the driver. The output is a set of safety goals, each assigned an Automotive Safety Integrity Level (ASIL) from A (lowest risk) to D (highest risk, demanding the most rigorous development process).

Refine safety goals into traceable requirements: Safety goals flow into a Functional Safety Concept, which defines system-level measures to achieve each goal. These are then decomposed into Technical Safety Requirements allocated to hardware and software. Every link in this chain, from hazard through safety goal, through functional safety requirement, through technical requirement, through implementation and verification, must be bidirectionally traceable and documented.

Verify and validate at every level: The V-model demands that each phase of development has a corresponding verification activity: unit testing against detailed design, integration testing against architecture, and system-level validation against safety goals. Test results must trace back to the requirements they verify.

Qualify the tools: ISO 26262 Part 8 requires that every development tool used in a safety-related project be classified and, where necessary, qualified. A compiler that silently introduces bugs or a test tool that skips test cases can undermine the entire safety case.

Manage changes rigorously: The standard mandates a systematic approach to analyzing, controlling, and documenting changes throughout the lifecycle. Even a minor code change can cascade through safety-critical paths.

Why it matters to the business

While ISO 26262 is not technically a legal mandate, it has become a de facto market requirement. Original Equipment Manufacturers (OEMs) routinely require suppliers to demonstrate compliance. The 2018 revision expanded the scope to include trucks, buses, motorcycles, and semiconductors, meaning more components and more suppliers fall under its umbrella with each passing year. Modern vehicles include integrated circuits, and the amount of code per vehicle has increased, making functional safety both more critical and more complex than ever.

Failing to comply risks reduced New Car Assessment Program (NCAP) safety ratings, costly product recalls, loss of supplier contracts, and reputational damage that can take years to recover from. The less visible cost is often even more significant. The engineering time consumed by manual compliance activities that could have been automated, and the release delays that accumulate when safety evidence has to be reconstructed rather than captured as work happens.

IEC 61508-3: The software foundation for safety across industries

If ISO 26262 defines functional safety for the road, IEC 61508 defines it for everything else.

IEC 61508 is the parent standard for functional safety of E/E/PE (electrical, electronic, and programmable electronic) systems. Where ISO 26262 focuses specifically on road vehicles, IEC 61508 is applicable to any industry where programmable systems perform safety functions: industrial automation, process control, energy, machinery, and increasingly, robotics.

Part 3 of IEC 61508 is the section that matters most for software teams. It establishes lifecycle activities, techniques, and measures for the design and development of safety-related software, graded by Safety Integrity Level (SIL) from SIL 1 (lowest) through SIL 4 (most stringent). IEC 61508-3 requires:

A complete software safety lifecycle: From specification of software safety requirements through architecture, design, implementation, integration, verification, and validation, each phase has defined objectives, required activities, and expected work products. The standard is explicit: you must be able to show that each phase was performed and that its outputs informed the next phase. A safety lifecycle that exists only as a retrospective narrative won't hold up.

Graded techniques and measures: The standard provides tables of techniques and grades them as "highly recommended," "recommended," or "no recommendation" at each SIL. Higher SILs demand more rigorous approaches. For SIL 4, formal methods are highly recommended; for SIL 1, simpler measures may suffice.

Bidirectional traceability: IEC 61508-3 requires that all requirements are addressed in design and code, that detailed requirements trace back to high-level requirements, and that no surplus, untested code exists. The standard doesn't just require that every requirement has code; it requires that every piece of code has a requirement. Orphaned code, left over from prototyping or feature branches, is a finding waiting to happen.

Hardware-software collaboration: The standard explicitly requires evidence of close collaboration between hardware and software teams. The hardware FMEA must inform software requirements, asking how software will defend against specific hardware failure modes.

Tool qualification: Any development or testing tool that could introduce errors or fail to detect them must be classified and potentially qualified.

Common pitfalls that affect functional safety

Whether you're working under ISO 26262 or IEC 61508-3, these are the mistakes we see again and again. Each one is avoidable, but only if you address it before it becomes a crisis.

Functional Safety Common Pitfalls

  1. Post-hoc safety documentation

    • Engineering builds the product, then a separate team backfills the safety case. Assessors can tell the difference.
    • Generate documentation as a byproduct of development, not a separate workstream.

  2. Broken traceability chains

    • HARA in a spreadsheet, requirements in a tool, code in Git, tests elsewhere. Nobody maintains the links until an assessor asks.
    • Traceability must be automatic, real-time, and continuous across all lifecycle phases.

  3. Unqualified tools

    • Teams adopt compilers, test frameworks, and CI/CD tools without assessing their impact on safety-related outputs.
    • Classify every tool early. Plan qualification before development begins, not at audit time.

  4. Misapplied ASIL/SIL decomposition

    • ASIL D decomposed to two ASIL B(D) sub-functions without rigorously demonstrating independence between redundant paths.
    • Perform thorough Dependent Failure Analysis (DFA) before relying on decomposition.

  5. One-time certification mindset

    • Product passes initial assessment, then the team reverts to business-as-usual for updates, patches, and OTA changes.
    • Embed change management into everyday workflows. Every commit triggers impact analysis.

  6. Siloed HW/SW safety activities

    • Hardware and software teams perform FMEAs independently, then discover during integration that assumptions don't hold.
    • Create shared safety artifacts spanning HW and SW. Schedule joint reviews during concept and design.

Practical roadmap for getting started

Whether you're starting your first project or scaling an existing program, this five-step approach works for both ISO 26262 and IEC 61508.

Functional Safety Practical Roadmap

  1. Understand scope and classification: For ISO 26262, this begins with Item Definition and HARA, that is, identifying hazards, classifying them, and assigning ASILs. For IEC 61508, it begins with hazard and risk analysis to determine the required SIL for each safety function.

  2. Choose the tools and qualify them early: The toolchain requirements management, version control, static analysis, test management, and CI/CD form the backbone of your safety case. Select tools that support traceability and process enforcement natively, and plan qualification activities before development begins, not at audit time.

  3. Embed safety into the development workflow: The most successful functional safety programs are the ones where compliance is invisible to developers. When documentation is generated automatically from the tools your team already uses, when traceability links are maintained in real time, and when process gates are enforced by tooling rather than by manual checklists, compliance becomes a natural output of good engineering, not a parallel bureaucracy.

  4. Plan for the full lifecycle: Safety doesn't stop at first release. Build your processes to support production monitoring, field issue tracking, change impact analysis, and safe modification throughout the product's operational life and eventual decommissioning.

  5. Invest in people: Both standards require evidence of competence management and safety culture. Train not just your safety engineers, but every developer, tester, and manager who contributes to a safety-related product. A team that understands why the process exists is far more effective than one that follows it blindly.

Conclusion

ISO 26262 and IEC 61508-3 exist for a reason, and they are the engineering community's best answer to the question of how to build systems that people can trust with their lives. They are well-designed. They are comprehensive. And they work.

The challenge has never been the standards themselves. It's the execution, the gap between what the standard requires and what teams actually do in practice. That gap is where traceability breaks, where documentation drifts from reality, where change management falls through the cracks, and where safety cases crumble under audit scrutiny.

Every pitfall described in this guide traces back to the same root cause: safety activities deferred, performed in isolation, or reconstructed after the fact. And every solution traces back to the same principle: capture compliance evidence as a byproduct of the engineering work itself, continuously, from the start.

Closing that gap is what Ketryx was built to do.