# 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. 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. ### Four Criteria for Non-Device CDS 21st Century Cures Act, Section 520(o)(1)(E) Software must meet all four criteria to qualify as non-device CDS. Failing any one makes it a regulated medical device (SaMD). 1. **Data source restriction** Does **not** acquire, process, or analyze medical images, signals from IVD devices, or patterns from signal acquisition systems. Fails if: analyzes images, ECG patterns, genetic sequences, CGM data 2. **Medical information display** Displays, analyzes, or prints **medical information** about a patient or other medical information such as clinical guidelines or peer-reviewed studies. Fails if: does not display medical information 3. **Support, not replace, clinical judgment** Intended to **support or provide recommendations** to healthcare professionals about prevention, diagnosis, or treatment. Not to replace or direct clinical judgment. Fails if: patient-facing, time-critical, or replaces HCP judgment 4. **Independent reviewability** Enables the healthcare professional to **independently review the basis** for the recommendations so they do not rely primarily on those recommendations. Fails if: opaque algorithm, no transparency into reasoning Pass all four = Non-device CDS Fail any one = Regulated SaMD (medical device) ### 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: | Aspect | ISO 26262 | IEC 61508-3 | | -------------------------- | --------------------------------- | ---------------------------------- | | Parent standard vs. automotive adaptation | Automotive | Cross-industry | | Scope | E/E systems in road vehicles | Any programmable electronic safety system | | Risk classification | ASIL A–D Severity, exposure, controllability | SIL 1–4 Consequence severity, frequency | | Lifecycle model | Prescriptive V-model | Flexible managed safety lifecycle | | Techniques | Methods prescribed per ASIL level | Graded: highly recommended, recommended, or none per SIL | | Tool qualification | Part 8: classify and qualify all tools | Proportionate to error introduction risk | | Key terms | HARA, ASIL decomposition, latent faults metric | Safe failure fraction, HW fault tolerance, SIL allocation | **Key insight:** No standardized cross-certification path exists. A rigorous, well-documented process from the start is the best insurance against costly re-certification. ## 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 01. **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. 02. **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. 03. **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. 04. **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. 05. **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. 06. **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. ### 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. ### 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. ### 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. ### 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. ### 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. 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. 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. ### 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. ## 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.