Skip to main content

ISO 26262:2018 · The standard, part by part

ISO 26262, part by part.

What each of the twelve parts covers, the clauses it is organised into, and where to learn it. A map for finding your way around the standard before you open it.

Jump to the partsBrowse 83 concept guides
  • 12 parts
  • 4 lifecycle groups
  • 83 concept guides

How the parts fit together

Four groups, one lifecycle.

The development parts follow the V-model from concept to production. Management, supporting processes and analyses run across all of it.

  • Foundations

    The shared vocabulary, and how functional safety is managed and confirmed across the whole lifecycle.

    Part 1Part 2

  • Concept and development

    The left arm and base of the V: from item definition and HARA down to system, hardware and software design.

    Part 3Part 4Part 5Part 6

  • Production and support

    Taking safety into the field, and the processes every phase relies on: interfaces, changes, tools, proven in use.

    Part 7Part 8

  • Analyses and guidance

    ASIL decomposition and safety analyses, the informative guidelines, semiconductors and the motorcycle adaptation.

    Part 9Part 10Part 11Part 12

Parts 1 to 12

What each part covers.

The main clauses of each part, cited by the standard's clause numbers, with our own one-line summary of what each one covers. Each part links to the guides on this site that teach it, free to preview.

  1. Part 01

    Vocabulary

    Defines the terms, definitions, and abbreviations used across all other parts, from "item" and "element" to "ASIL" and "safety goal". Getting the vocabulary right is the foundation for every work product.

    1. Clause 3What every term used across the series means
    2. Clause 4The abbreviations used across the series
    • Item and element
    • Fault, error, failure
    • ASIL
    • Safety goal
    • Safety case
    • Systematic vs random failures

    Learn it:Faults and Failures

  2. Part 02

    Management of functional safety

    Overall safety management: safety culture, competence, the safety plan, confirmation measures (reviews, audits, assessments), and how responsibility is organized across the safety lifecycle.

    1. Clause 5Safety culture, competence and quality across the whole organisation
    2. Clause 6Running safety on one project: roles, the safety plan, the safety case and confirmation measures
    3. Clause 7Safety responsibilities that continue once the product is released for production

    Learn it:Safety Plan DevelopmentConfirmation MeasuresFunctional Safety Assessment & Audit

  3. Part 03

    Concept phase

    Where every project starts: describe what the item does and where its boundaries lie, work out what could go wrong and how much each risk matters (the HARA, which sets the ASILs), and decide at a functional level how each safety goal will be met.

    1. Clause 5Describing the item: its function, its boundaries and its interfaces
    2. Clause 6Rating hazardous events by severity, exposure and controllability to set ASILs and safety goals (HARA)
    3. Clause 7Turning safety goals into functional safety requirements allocated to the architecture

    Learn it:Hazard Analysis & Risk Assessment (HARA)Functional Safety ConceptItem Definition & Concept-Phase Initiation

  4. Part 04

    Product development at the system level

    How the system itself is engineered: the safety requirements become a technical safety concept and an architecture, hardware and software agree on the interface between them (the HSI), and the finished system is put together, tested and finally validated in the vehicle.

    1. Clause 5Getting system-level development started
    2. Clause 6Deriving technical safety requirements and the system architecture
    3. Clause 7Putting hardware, software, systems and the vehicle together, testing at every step
    4. Clause 8Confirming at vehicle level that the safety goals are met

    Learn it:Technical Safety ConceptThe Hardware-Software Interface (HSI)Verification & Validation

  5. Part 05

    Product development at the hardware level

    Hardware safety requirements, design, and the quantitative hardware metrics: SPFM, LFM, and PMHF, plus evaluation of safety mechanisms and diagnostic coverage.

    1. Clause 5Getting hardware development started
    2. Clause 6Working out what the hardware must do for safety
    3. Clause 7Designing the hardware, from architecture to detailed circuits
    4. Clause 8The single-point and latent fault metrics (SPFM, LFM)
    5. Clause 9Residual risk from random hardware failures (PMHF, or evaluating each cause individually)
    6. Clause 10Integrating and testing the hardware

    Learn it:Hardware MetricsSafety Mechanisms & DiagnosticsFMEDA: Quantitative Hardware Safety Analysis

  6. Part 06

    Product development at the software level

    Software safety requirements, architectural and unit design, implementation, and the ASIL-dependent verification methods from unit testing through software integration.

    1. Clause 5Getting software development started: methods, languages and guidelines
    2. Clause 6Working out what the software must do for safety
    3. Clause 7Designing the software architecture
    4. Clause 8Designing and coding the individual software units
    5. Clause 9Checking each unit on its own
    6. Clause 10Combining the units and checking the result
    7. Clause 11Testing the software on its target hardware

    Learn it:Software Architectural & Unit DesignSoftware Coding Guidelines

  7. Part 07

    Production, operation, service and decommissioning

    Carrying safety into the field: production process requirements, operation and service instructions, field monitoring, and decommissioning.

    1. Clause 5Planning for safety in production and in the field
    2. Clause 6Making sure production reproduces the safety-relevant design
    3. Clause 7Operation, service, field monitoring and end of life

    Learn it:Production, Operation, Service & Decommissioning

  8. Part 08

    Supporting processes

    Cross-cutting processes: interfaces with distributed developments (DIA), specification of safety requirements, configuration and change management, documentation, tool qualification, and proven-in-use arguments.

    1. Clause 5Splitting safety work between customer and supplier (the DIA)
    2. Clause 6Writing and managing safety requirements
    3. Clause 7Keeping versions and baselines under control
    4. Clause 8Assessing and approving changes
    5. Clause 9Planning and carrying out verification
    6. Clause 10Keeping the safety documentation in order
    7. Clause 11Classifying and qualifying the software tools you rely on
    8. Clause 12Reusing software components developed elsewhere
    9. Clause 13Using hardware elements that were not developed to the series
    10. Clause 14Arguing safety from field experience (proven in use)
    11. Clause 15Applications that fall outside the scope of the series
    12. Clause 16Combining with safety-related systems built to other rules

    Learn it:Development Interface AgreementConfidence in the Use of Software ToolsChange Impact Analysis for Carryover & Modified Systems

  9. Part 09

    ASIL-oriented and safety-oriented analyses

    ASIL decomposition, criteria for coexistence of elements (freedom from interference), dependent failure analysis (DFA), and safety analyses such as FMEA and FTA.

    1. Clause 5Splitting a requirement across redundant elements (ASIL decomposition)
    2. Clause 6Letting elements of different ASILs share one system
    3. Clause 7Finding failures that could defeat independence (dependent failure analysis)
    4. Clause 8Safety analyses such as FMEA and FTA

    Learn it:ASIL DecompositionDependent Failure Analysis (DFA)Freedom from Interference (FFI)

  10. Part 10

    Guidelines on ISO 26262

    Explanations rather than requirements: how to read and apply the rest of the series, with worked examples on topics such as developing an element before its vehicle is known (SEooC) and how safety requirements are layered.

    1. Clause 4The core ideas behind the series
    2. Clause 5Guidance on safety management
    3. Clause 6Guidance on the concept phase and system development
    4. Clause 7How safety requirements flow from goals down to hardware and software
    5. Clause 8Guidance on hardware development
    6. Clause 9Developing an element before its vehicle is known (SEooC)
    7. Clause 10A worked proven-in-use example
    8. Clause 11Guidance on ASIL decomposition
    9. Clause 12Systems that must keep working after a fault (availability)
    10. Clause 13Notes on confidence in software tools
    11. Clause 14Safety-related special characteristics in production

    Learn it:Safety Element out of Context (SEooC)Proven in Use

  11. Part 11

    Guidelines on application to semiconductors

    Applying ISO 26262 to semiconductor components: base failure rates, dependent failures, intellectual property (IP) integration, and detailed semiconductor-specific analysis techniques.

    1. Clause 4How a semiconductor component is divided up and analysed
    2. Clause 5Guidance for particular technologies: digital, analogue, programmable logic, memories and sensors
    • Base failure rates
    • Semiconductor dependent failures
    • IP integration
    • Digital and analogue components
    • Programmable logic (PLD, FPGA)
    • Memories and sensors

    Learn it:ISO 26262 and SemiconductorsSoft Errors & Transient Faults

  12. Part 12

    Adaptation for motorcycles

    Tailors the standard to motorcycles, including the MSIL (Motorcycle Safety Integrity Level) classification scheme, its mapping to ASILs, and adapted HARA, confirmation measures, and safety validation.

    1. Clause 5How the series is adapted to motorcycles
    2. Clause 6Safety culture in motorcycle development
    3. Clause 7Confirmation measures for motorcycles
    4. Clause 8Hazard analysis for motorcycles and the MSIL classification
    5. Clause 9Integrating and testing on the motorcycle
    6. Clause 10Validating safety on the motorcycle
    • MSIL classification
    • MSIL to ASIL mapping
    • Adapted HARA
    • Adapted confirmation measures
    • Safety validation for motorcycles

    Learn it:Motorcycle Adaptation

ISO 26262 FAQ

Straight answers about the standard.

How it is organised, where HARA lives, and what is guidance rather than requirement.

What are the 12 parts of ISO 26262?

ISO 26262:2018 has 12 parts: Part 1 Vocabulary, Part 2 Management of functional safety, Part 3 Concept phase, Part 4 Product development at the system level, Part 5 Product development at the hardware level, Part 6 Product development at the software level, Part 7 Production, operation, service and decommissioning, Part 8 Supporting processes, Part 9 ASIL-oriented and safety-oriented analyses, Part 10 Guidelines on ISO 26262, Part 11 Guidelines on application to semiconductors, and Part 12 Adaptation for motorcycles.

Which part of ISO 26262 covers HARA and ASIL determination?

Part 3, the concept phase. Its Clause 6 covers hazard analysis and risk assessment, where each hazardous event is rated for severity, exposure and controllability to determine its ASIL and derive the safety goals. Clause 7 then turns those goals into the functional safety concept.

Which parts are guidelines rather than requirements?

Part 10 (guidelines on ISO 26262) and Part 11 (guidelines on application to semiconductors) explain and illustrate how to apply the standard. The requirements an assessor checks live in Parts 2 to 9 and, for motorcycles, Part 12; Part 1 defines the vocabulary they all use.

Does this page reproduce the standard?

No. Every description on this page is written in our own words; the standard is only cited, by part name and clause number. The text of ISO 26262 is copyrighted by ISO and is available from iso.org or your national standards body.

Test yourself

Know your way around the parts?

Try the 7-question demo exam: four question formats, graded like the real exam, no account needed.

Start the demo examBrowse concept guides

We use cookies to measure how this site is used. Essential cookies stay on. Cookie Policy