Confirmation Measures in ISO 26262: Reviews, Audits & Functional Safety Assessment Explained
Hello, functional safety managers, safety engineers, and quality managers! Confirmation measures are the systematic activities that provide evidence of confidence that the functional safety work has been performed correctly, completely, and in compliance with ISO 26262. Without confirmation measures, even the most rigorous development process lacks the independent verification that auditors, OEM customers, and regulatory bodies expect. Confirmation measures are defined in ISO 26262 Part 2, Clause 6 and are one of the most audited – and most misunderstood – aspects of the standard.
In this comprehensive guide at PiEmbSysTech, we will explain all three types of confirmation measures, the four independence levels, the ASIL-dependent requirements, and practical guidance for planning and executing confirmation activities effectively. Let us begin.
Confirmation Measures in ISO 26262 Table of Contents
1. What Are Confirmation Measures and Why They Matter
Confirmation measures are the systematic activities defined in ISO 26262 Part 2, Clause 6 that provide confidence in the achievement of functional safety. They serve as the independent “checks and balances” on the safety development process – ensuring that the work products are correct, the processes are followed, and the safety goals are achieved. Without confirmation measures, the safety case relies solely on the development team’s self-assessment – which is insufficient for demonstrating compliance to external stakeholders.
Confirmation measures are distinct from verification activities (testing, analysis, review of technical correctness). Verification asks “does this work product meet its technical requirements?” Confirmation measures ask “does this work product meet the ISO 26262 requirements, and was the process followed correctly?” Both are needed – verification ensures technical correctness, confirmation measures ensure process compliance and safety standard adherence.
2. The Three Types of Confirmation Measures
ISO 26262 defines three types of confirmation measures, each addressing a different aspect of functional safety assurance:
1. Confirmation Review: Evaluates specific work products against ISO 26262 requirements. Checks whether each work product is correct, complete, consistent, and adequate in content and form. Applied to selected work products identified by the standard throughout the safety lifecycle.
2. Functional Safety Audit: Examines the implemented processes to verify that the organization is following its own safety plan and complying with ISO 26262 process requirements. Checks whether activities are performed as planned, resources are adequate, and procedures are followed.
3. Functional Safety Assessment (FSA): Evaluates the overall functional safety achieved by the item or element. The highest-level confirmation measure – it judges whether the safety goals have been adequately addressed and whether the safety case is convincing. Results in a recommendation of acceptance, conditional acceptance, or rejection.
3. Independence Levels – I0, I1, I2, I3
ISO 26262 defines four levels of independence for the persons performing confirmation measures:
| Level | Description | Practical Meaning |
|---|---|---|
| I0 | No specific independence requirement | The person may be from the same project team – self-assessment is acceptable |
| I1 | Different person from the author | Must be a different individual than the person who created the work product, but can be from the same team and report to the same manager |
| I2 | Different team | Must be a person independent from the team responsible for creation – reporting to a different direct superior (e.g., a separate safety department within the same company) |
| I3 | Different department / external organization | Must be independent regarding management, resources, and release authority from the department responsible — typically an external third-party assessor (TÜV, SGS, DNV, exida) |
The independence level increases with ASIL – higher-ASIL safety goals require greater independence to reduce the risk of bias and ensure objective evaluation.
4. ASIL-Dependent Independence Requirements
| Confirmation Measure | ASIL A | ASIL B | ASIL C | ASIL D |
|---|---|---|---|---|
| Confirmation Review | I0 | I1 | I2 | I2 |
| Functional Safety Audit | – | I0 (optional) | I2 | I2 |
| Functional Safety Assessment | – | I1 (recommended) | I2 | I2/I3 |
Key observations: ASIL A has minimal confirmation measure requirements (I0 for confirmation review, no audit or assessment required). ASIL B introduces confirmation reviews at I1 and optional audit/assessment. ASIL C and D require all three types of confirmation measures with I2 or I3 independence – ASIL D assessment is recommended at I3 (external third party). Functional safety audit is not required for ASIL A and is optional for ASIL B.
5. Confirmation Reviews – Work Product Evaluation
A confirmation review evaluates a specific work product against the ISO 26262 requirements for that work product. The reviewer checks correctness (is the content technically accurate?), completeness (are all required elements present?), consistency (does it align with upstream and downstream work products?), and adequacy (is the level of detail appropriate for the ASIL?). The reviewer must have the authority, competence, and qualification to perform the review. Assistants may support the review, but they must have at least I1 independence, and the lead reviewer must appraise their input to ensure an unbiased opinion.
6. Which Work Products Require Confirmation Review?
ISO 26262 identifies specific work products throughout the safety lifecycle that require confirmation review. Key work products include: the safety plan (Part 2), the HARA report and safety goals (Part 3), the FSC and TSC (Parts 3 and 4), the system architectural design with safety mechanisms (Part 4), the hardware safety requirements and FMEDA/hardware metric evaluation (Part 5), the software safety requirements and architectural design (Part 6), the software verification reports (Part 6), the tool qualification reports (Part 8), and the safety analysis reports (Part 9). The safety plan should identify all work products requiring confirmation review and schedule the reviews throughout the development lifecycle.
7. How to Conduct a Confirmation Review – Step by Step
Step 1 – Plan the review: Identify the work product to be reviewed, the applicable ISO 26262 requirements, the reviewer(s) with appropriate independence level, and the review schedule.
Step 2 – Prepare review materials: The reviewer receives the work product, the applicable ISO 26262 clauses, and any relevant upstream work products (e.g., when reviewing the TSC, the reviewer also needs the FSC and HARA report for consistency checking).
Step 3 – Conduct the review: The reviewer systematically evaluates the work product against each applicable requirement – checking form, content, completeness, consistency, and adequacy. Findings are classified as observations (minor suggestions), findings (specific non-conformities requiring correction), or critical findings (significant gaps that could impact safety).
Step 4 – Document the review report: The reviewer produces a confirmation review report containing the scope of the review, the review criteria (which ISO 26262 requirements were checked), the findings (with classification and required actions), and an overall judgment of the work product’s contribution to functional safety.
Step 5 – Track resolution: Findings must be addressed by the development team. The resolution of each finding should be documented and verified by the reviewer.
8. Functional Safety Audit – Process Compliance Check
The functional safety audit examines whether the organization’s implemented processes comply with its own safety plan and with the ISO 26262 process requirements. Unlike the confirmation review (which focuses on specific work products), the audit focuses on how the work is being done – whether procedures are followed, whether resources are adequate, whether competence management is effective, and whether the safety activities are executed as planned.
The audit is required for ASIL C and D (at I2 independence), optional for ASIL B, and not required for ASIL A. The auditor must have sufficient skills, competence, and qualification, and must be given sufficient authority to fulfill their responsibilities. The audit must be finalized before release for production.
9. Audit Scope, Inputs, and Outputs
Audit inputs: The safety plan (defining the planned safety activities and processes), the organization’s safety management documentation (procedures, work instructions, competence records), the actual project records (evidence of activities performed), and the scope definition (which lifecycle phases, which ASIL levels, which development interfaces).
Audit scope covers: Evaluation of the implemented process against the safety plan definitions, evaluation of the competence of the persons performing safety activities, evaluation of the adequacy and availability of resources (tools, facilities, time), evaluation of the management of safety anomalies and change requests, and verification that the DIA (Development Interface Agreement) is being followed for distributed development.
Audit output: A functional safety audit report containing the audit scope and criteria, the findings (non-conformities, observations, areas for improvement), recommendations, and the overall audit conclusion regarding process compliance.
10. How to Conduct a Functional Safety Audit
Step 1 – Define the audit plan: Scope, objectives, criteria, schedule, auditor assignment, and logistics.
Step 2 – Opening meeting: Present the audit plan to the auditee, confirm scope, clarify access to documentation and personnel.
Step 3 – Evidence collection: The auditor reviews documents (safety plan, process descriptions, project records, training records, tool qualification records), interviews key personnel (safety manager, project manager, safety engineers, developers), and observes activities where possible (review meetings, testing sessions).
Step 4 – Analysis and evaluation: The auditor evaluates the evidence against the ISO 26262 requirements and the organization’s own safety plan. Non-conformities are identified and classified.
Step 5 – Closing meeting: Present findings to the auditee, discuss observations, clarify any misunderstandings.
Step 6 – Audit report: Document all findings, recommendations, and conclusions. The auditee prepares a corrective action plan for any non-conformities.
11. Functional Safety Assessment (FSA) – The Highest-Level Measure
The Functional Safety Assessment (FSA) is the most comprehensive confirmation measure. It evaluates the overall functional safety achieved by the item – judging whether the safety goals have been adequately defined and achieved, whether the safety concept is appropriate, whether the development process was followed, and whether the safety case is convincing as a whole. The FSA is mandatory for ASIL C and D and recommended for ASIL B.
The FSA covers review of the HARA and safety goals, review of the safety concept (FSC, TSC), review of the safety analyses (FMEA, FTA, DFA), review of the hardware metrics evaluation, review of the software development evidence (coverage, testing), review of the confirmation reviews and audit findings, assessment of the overall safety case coherence and completeness, and a recommendation on whether the item achieves an acceptable level of functional safety.
12. FSA Scope, Timing, and Progressive Assessment
ISO 26262 recommends that the FSA be planned at the beginning of product development and performed progressively during the development lifecycle – not as a single block at the end. Progressive assessment means the assessor reviews work products as they are produced during each lifecycle phase (concept, system design, hardware design, software design, integration, validation), providing early feedback and allowing issues to be corrected before they cascade downstream.
Progressive assessment is more efficient and less risky than a single end-of-development assessment because it identifies issues earlier (when correction is less costly), spreads the assessment workload over the project timeline, and builds the assessor’s understanding of the project incrementally.
13. The FSA Report – Acceptance, Conditional, or Rejection
The FSA report contains the assessment scope and methodology, the assessment findings (categorized by severity), the evaluation of the safety case, and a recommendation that is one of three outcomes:
Acceptance: The assessor judges that the item achieves an acceptable level of functional safety. The safety case is complete and convincing. No significant open findings.
Conditional acceptance: The assessor judges that the item can achieve acceptable functional safety, subject to the resolution of specific identified findings. The findings are documented and their resolution must be verified before release for production.
Rejection: The assessor judges that the item does not achieve an acceptable level of functional safety. Significant gaps exist that require substantial rework. The project must address the identified deficiencies and undergo re-assessment.
14. Assessor and Reviewer Competence Requirements
ISO 26262 requires that persons performing confirmation measures have appropriate competence, including knowledge of the ISO 26262 standard and its application, understanding of the relevant engineering domain (hardware, software, system, or the specific application area), experience in performing the specific type of confirmation measure (review, audit, or assessment), and the ability to provide objective, unbiased judgment. For FSA assessors at I3 level, professional certifications such as TÜV Functional Safety Engineer (TÜV FSEng), Certified Functional Safety Expert (CFSE by exida), or equivalent qualifications demonstrate the required competence. The safety plan should document the competence requirements for each confirmation measure role.
15. Confirmation Review vs Verification Review
A common source of confusion is the difference between confirmation review (Part 2, Clause 6) and verification review (Part 8, Clause 9). Confirmation review checks whether the work product meets the ISO 26262 standard requirements – it is a compliance check. Verification review checks whether the work product meets the project-specific technical requirements – it is a correctness check. The independence requirements are different: verification review requires at least a different person from the author (I0/I1 equivalent), while confirmation review independence depends on the ASIL (I0 to I2). Some organizations merge the two activities for efficiency – conducting a single review that covers both technical correctness and ISO 26262 compliance – provided the merged review meets the higher independence requirement of the confirmation review.
16. Planning Confirmation Measures in the Safety Plan
The safety plan must include the schedule for all confirmation measures – specifying which work products require confirmation review (and the scheduled review dates), when the functional safety audit will be conducted, the scope and planned timeline for the FSA (including progressive assessment milestones), the assigned reviewer, auditor, and assessor (with their independence levels), and the competence requirements for each role. Planning confirmation measures early is critical because securing I3-level assessors (external third parties) requires lead time – TÜV and other assessment bodies have limited availability, and booking assessor time months in advance is standard practice.
17. Third-Party Assessment Bodies – TÜV, SGS, DNV
For ASIL D (and recommended for ASIL C), the FSA should be performed at I3 independence – by an external third-party assessment body. Leading automotive functional safety assessment providers include TÜV SÜD, TÜV NORD, TÜV Rheinland, SGS-TÜV Saar, DNV, exida, and CertX. These organizations provide assessors with deep ISO 26262 expertise who conduct the FSA, audit, and confirmation reviews independently. The assessment typically results in a functional safety certificate or compliance letter that provides external evidence of the item’s functional safety compliance – valuable for OEM customers, regulatory authorities, and the organization’s own safety case.
18. Confirmation Measures After ASIL Decomposition
A critical and frequently misunderstood aspect: after ASIL decomposition, the confirmation measure independence levels remain at the original (pre-decomposition) ASIL. An element developed to ASIL B(D) – where the development methods follow ASIL B – still requires ASIL D independence levels for its confirmation measures (I2/I3 for FSA). This is one of the items in the “(D)” suffix that does NOT change after decomposition. The rationale is that the overall safety case must be assessed at the ASIL of the safety goal, which remains unchanged.
19. Common Mistakes and How to Avoid Them
Mistake 1: Deferring all confirmation measures to the end of development. Performing reviews and the FSA only at the end creates a “big bang” of findings that are expensive and time-consuming to resolve. Plan progressive assessment and early reviews.
Mistake 2: Confusing confirmation review with verification review. They serve different purposes: confirmation review checks ISO 26262 compliance, verification review checks technical correctness. Both are needed, and their independence requirements differ.
Mistake 3: Not documenting the confirmation review report. A verbal “looks good” is not a confirmation review. Each review must produce a documented report with the scope, findings, and judgment. The absence of documented confirmation review reports is one of the most common audit findings.
Mistake 4: Using the decomposed ASIL for confirmation measure independence. After ASIL decomposition, confirmation measures use the original ASIL. ASIL B(D) requires ASIL D assessment independence.
Mistake 5: Not planning for assessor availability. External assessors (TÜV, SGS) have limited availability. Not booking assessor time early in the project can cause schedule delays at release for production.
Mistake 6: Treating the FSA as a pass/fail exam. The FSA is not an exam – it is a collaborative technical evaluation. Early and progressive engagement with the assessor produces better outcomes than a confrontational end-of-project assessment.
20. Frequently Asked Questions
Q1: Is the FSA mandatory for ASIL B?
The FSA is recommended (not mandatory) for ASIL B. In practice, many OEMs require their Tier-1 suppliers to provide FSA evidence for ASIL B projects, making it effectively mandatory in the supply chain even though the standard does not strictly require it.
Q2: Can the safety manager also be the confirmation reviewer?
It depends on the ASIL. For ASIL A (I0), yes. For ASIL B (I1), the reviewer must be a different person from the author of the work product — the safety manager can review work products they did not create. For ASIL C and D (I2), the reviewer must be from a different team, so the safety manager can only review if they are organizationally independent from the development team.
Q3: How does the FSA relate to the safety case?
The FSA evaluates the safety case – it assesses whether the safety case (the structured argument with supporting evidence that the item achieves functional safety) is complete, convincing, and adequately addresses all safety goals. The safety case is the subject of the assessment; the FSA report is the assessor’s judgment of the safety case.
Q4: Can confirmation measures be performed by an internal team?
Yes, for ASIL A (I0), ASIL B (I1), and even ASIL C (I2 – an independent internal safety department can provide I2 independence). For ASIL D, I3 is recommended for the FSA, which typically requires an external organization. However, large companies with truly independent internal assessment departments (separate management, separate budget, no release authority) may argue I3 independence internally.
Q5: What happens if the FSA results in rejection?
Rejection means the assessor judges that the item does not achieve acceptable functional safety. The development team must address the identified deficiencies – which may require significant rework of work products, additional testing, additional analysis, or even architectural changes. After corrections, a re-assessment is needed. Rejection is rare in practice because progressive assessment catches most issues early.
21. Conclusion
Confirmation measures – confirmation reviews, functional safety audits, and functional safety assessments – are the independent verification and validation activities that provide confidence in the achievement of functional safety. They are not optional add-ons but integral parts of the ISO 26262 safety lifecycle, planned in the safety plan and executed throughout development. Understanding the three types of confirmation measures, the four independence levels, and the ASIL-dependent requirements is essential for every functional safety professional – whether you are creating work products, reviewing them, auditing processes, or assessing the overall safety case.
This article is part of our comprehensive ISO 26262 series at PiEmbSysTech. For the foundational Part 2 coverage, see Part 2 – Functional Safety Management.
Stay safe. Stay independently confirmed. Keep engineering the future.
— The PiEmbSysTech Team
Discover more from PiEmbSysTech - Embedded Systems & VLSI Lab
Subscribe to get the latest posts sent to your email.


