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

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.

‍

‍

Why it matters to the robotics team

The robotics industry is one of the fastest-growing areas where IEC 61508 applies directly. As industrial robots, autonomous mobile robots, and service robots become more prevalent, working alongside or in close proximity to humans, the functional safety of their software is no longer optional. The robot safety standard ISO 10218 builds on IEC 61508 principles, and any robot system that uses programmable electronics for a safety function (emergency stop, speed limiting, collision avoidance) must demonstrate that its software meets the appropriate SIL.

For robotics teams accustomed to rapid iteration and agile development, the documentation and process demands of IEC 61508-3 can feel overwhelming. But the standard doesn't require you to abandon agility; it requires you to demonstrate that your process is controlled, traceable, and proportionate to the risk. The teams that navigate this well are the ones that embed safety evidence capture into their existing workflows, so compliance scales with development velocity rather than against it.

How ISO 26262 and IEC 61508-3 relate to each other

Understanding this relationship is critical, especially for companies that supply components across multiple industries. A component qualified under one standard is not automatically acceptable under the other, and the mapping between them is less straightforward than most teams expect.

IEC 61508 is the parent standard. It is a generic framework applicable across all sectors. ISO 26262 is one of several domain-specific adaptations, tailored for automotive. Others include IEC 62304 for medical devices. However, ISO 26262 is not simply a subset of IEC 61508. Key differences include:

‍

‍

For companies developing components used in both automotive and other domains, the lack of a standardized framework for cross-certifying between ISO 26262 and IEC 61508 means that following a rigorous, well-documented process from the beginning is the best insurance against costly re-certification later.

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.

‍

‍

Treating safety documentation as a post-hoc exercise is a common mistake

Engineering builds the product, and then a separate team backfills the safety case, writing HARA reports, safety plans, and functional safety concepts after decisions have already been made.

However, this approach fails because assessors can tell the difference between documentation that guided decisions and documentation that was reverse-engineered from a finished product. Both ISO 26262 and IEC 61508 require that safety activities are integrated into each lifecycle phase, influencing design choices in real time. As a result, a safety plan written after the architecture is frozen cannot demonstrate that safety was considered during architectural decisions.

Therefore, safety documentation should be generated as a byproduct of the development process itself, not as a separate workstream. When Safety Plans, Functional Safety Concepts, and V&V evidence emerge automatically from the way the team already works, the documentation is always current, always honest, and always audit-ready.

This is the principle behind platforms like Ketryx, which overlay existing development tools to produce compliance artifacts from actual engineering activity rather than manual reconstruction.

Losing traceability across the safety lifecycle

HARA results may live in one spreadsheet, safety goals in a Word document, requirements in a dedicated tool, code in Git, and test results in a test management system. Consequently, nobody maintains the links between them until an assessor asks for the chain.

This fails because both standards demand complete, bidirectional traceability. Broken chains are among the most common audit findings, and they create rework, delay releases, and fundamentally undermine the safety argument. Moreover, this problem is especially acute across supply chains. OEMs define safety goals, Tier 1 suppliers decompose them into technical requirements, and Tier 2 suppliers implement components. Since each organization typically uses its own tools and documentation formats, traceability often becomes fragmented. If it is not managed systematically across this chain, the result is predictable: inconsistent deliverables, broken links, and the inability to demonstrate evidence during assessments.

To address this, traceability must be automatic, real-time, and continuous. For ISO 26262, this means live traces from HARA through safety goals across all systems and subsystems. Similarly, for IEC 61508, it means requirements linked to design, code, and test evidence at every SIL level.

Underestimating tool qualification

Teams often adopt compilers, test frameworks, and CI/CD tools without formally assessing their impact on safety-related outputs. Yet this fails because ISO 26262 Part 8 and IEC 61508-3 both require tool qualification proportionate to the tool's potential to introduce or fail to detect errors.

Every tool in the toolchain should be classified early, and its impact level and error detection capability should be determined. For higher-impact tools, qualification activities should be planned at the start of the project rather than as an afterthought. The cost of qualifying a tool at project start is a fraction of the cost of discovering during assessment that your entire test suite ran on an unqualified framework.

Misapplying SIL or ASIL decomposition

Sometimes a safety function is assigned ASIL D or SIL 3, and the team decomposes it into two ASIL B(D) sub-functions in order to reduce the rigor required for each. However, this is often done without rigorously demonstrating independence between the redundant paths. This approach fails because decomposition, while powerful, comes with strict conditions in both standards.

It requires demonstrating that decomposed elements are sufficiently independent, including freedom from common cause failures and dependent failures. Without a strong independence argument, the actual risk reduction may be less than what the decomposition assumes. The appropriate approach is to perform a thorough Dependent Failure Analysis (DFA) before relying on decomposition. The independence argument should then be documented explicitly, covering hardware, software, and systematic failure modes.

Treating the standard as a one-time certification event

In many cases, the product passes its initial functional safety assessment, and the team then reverts to business-as-usual development for updates, patches, and feature additions. However, this fails because functional safety is a lifecycle commitment, not a gate. Both ISO 26262 and IEC 61508 require that modifications to safety-related systems be analyzed for their safety impact. Modern vehicles and robots experience continuous code changes through over-the-air updates, hotfixes, and new features.

Therefore, each change must be traceable, impact-assessed, and verified to the appropriate integrity level. To manage this effectively, change management must be embedded into everyday development workflows. Every code commit, requirement change, or design update should automatically trigger an impact analysis that identifies downstream dependencies.

Keeping hardware and software safety activities separate creates major integration challenges

The hardware team performs its FMEA and safety analysis independently, while the software team performs theirs separately. They eventually meet during integration and discover that assumptions made on one side do not hold on the other. This fails because IEC 61508-3 explicitly requires collaboration between hardware and software specifiers. The hardware FMEA should raise questions about how software will defend against hardware failures. Likewise, ISO 26262 Parts 5 and 6 must be addressed together because safety mechanisms frequently span both domains, such as a diagnostic software routine detecting a hardware fault.

To prevent this issue, teams should create shared safety artifacts that span hardware and software and schedule joint review sessions during concept and design phases. Additionally, requirements and risk management tools should provide a unified view across both domains so that cross-domain dependencies are visible to everyone.

‍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.

‍

‍

How Ketryx makes functional safety practical

Ketryx provides an Agentic AI platform purpose-built for teams working under ISO 26262 and IEC 61508, designed to make compliance a natural byproduct of development, not a burden on top of it.

For automotive teams, Ketryx accelerates functional safety compliance by overlaying your existing development tools without disrupting active programs. The platform automatically creates and maintains traces from HARA through safety goals across all systems and subsystems. When a safety goal changes, downstream impacts are surfaced immediately. When a test verifies a requirement, the link is captured without manual effort. The safety case stays current with every commit, every test run, and every review, not just when someone finds time to update a document.

For robotics teams, Ketryx is designed specifically to make robotics development safer and faster. By integrating with existing development tools, it maintains real-time traceability and automates safety documentation without disrupting your active programs. Ketryx generates safety plans, requirements, and validation evidence as a development byproduct, eliminating the manual, time-consuming tasks that slow robotics teams down and introduce errors into the safety case.

Ketryx eliminates the trade-off between development speed and compliance rigor. Your engineers keep working in the tools they already know: Jira, GitHub, and other DevTools while Ketryx operates in the background: enforcing SOPs, capturing evidence, maintaining traceability, and generating audit-ready documentation from actual work, not from manual reconstruction. As a result, teams release faster, assessments go more smoothly, and the safety case reflects reality.

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.

‍