ISO 26262 Part 2 Functional Safety Management: Safety Culture, Safety Plan, Roles, and Confirmation Measures Explained

Hello, automotive engineers and safety professionals! Welcome to the second deep-dive post in our comprehensive ISO 26262 series at PiEmbSysTech. In this article, we will thoroughly explore ISO 26262 Part 2 – Management of Functional Safety, which many industry veterans consider the most critical part of the entire standard for organizational success.

Why is Part 2 so important? Because the most sophisticated safety analyses, the most elegant safety architectures, and the most rigorous testing campaigns will all fail if the organizational foundation beneath them is weak. Part 2 defines how an organization establishes, maintains, and demonstrates its capability to develop functionally safe products. It covers everything from cultivating a genuine safety culture, through defining roles and competencies, to planning safety activities, building the safety case, and performing independent confirmation measures.

If Part 1 (Vocabulary) gives you the language to speak about functional safety, Part 2 gives you the organizational machinery to actually achieve it. Let us explore every aspect in detail.

Table of Contents

1. What is ISO 26262 Part 2 and How is It Structured?
2. Overall Safety Management vs Project-Dependent Safety Management
3. Safety Culture – The Non-Negotiable Foundation
4. Competence Management – Right People, Right Roles
5. Quality Management System and Functional Safety
6. Management of Safety Anomalies
7. Project-Independent Tailoring of the Safety Lifecycle
8. Roles and Responsibilities – Project Manager vs Safety Manager
9. The Safety Plan – Blueprint for Safety Activities
10. The Safety Case – Compiling the Evidence
11. Confirmation Measures – Reviews, Audits, and Assessments
12. Independence Levels (I0, I1, I2, I3) and ASIL Mapping
13. Release for Production
14. Safety Management After Development – Production, Operation, Service & Decommissioning
15. Field Monitoring and Post-SOP Modifications
16. Key Work Products of Part 2
17. Common Challenges in Implementing Part 2
18. Best Practices for Functional Safety Management
19. Frequently Asked Questions
20. Conclusion

1. What is ISO 26262 Part 2 and How is It Structured?

ISO 26262 Part 2: Management of Functional Safety specifies the requirements for functional safety management for automotive applications. It is a normative part of the standard that applies to every organization involved in the development, production, operation, service, or decommissioning of safety-related E/E systems in road vehicles.

Part 2 addresses two distinct but complementary dimensions of safety management. The first dimension covers project-independent requirements – these are organizational-level requirements that apply to the company as a whole, regardless of any specific product or project. They include establishing a safety culture, implementing competence management, integrating functional safety into the quality management system, and defining processes for managing safety anomalies. The second dimension covers project-specific requirements – these are the management activities that must be performed within the context of a specific item development project, including defining roles and responsibilities, creating a safety plan, building a safety case, performing confirmation measures, and managing the release for production.

The standard also addresses safety management during post-development phases – production, operation, service, and decommissioning – recognizing that functional safety must be maintained throughout the entire lifecycle of the vehicle, not just during development.

Structure of Part 2 (ISO 26262-2:2018)

Part 2 is organized into three main normative clauses. Clause 5: Overall Safety Management covers the project-independent organizational requirements, including safety culture, competence management, quality management system integration, management of safety anomalies, and project-independent tailoring of the safety lifecycle. Clause 6: Project-Dependent Safety Management covers the project-specific requirements, including roles and responsibilities, safety planning and coordination, the safety case, confirmation measures (confirmation reviews, functional safety audits, and functional safety assessments), and release for production. Clause 7: Safety Management Regarding Production, Operation, Service, and Decommissioning covers the post-development safety management requirements. Additionally, Annex A provides an overview of the objectives, prerequisites, and work products for each clause.

2. Overall Safety Management vs Project-Dependent Safety Management

Understanding the distinction between overall safety management and project-dependent safety management is essential for implementing ISO 26262 Part 2 effectively.

Overall safety management (Clause 5) establishes the organizational infrastructure that exists independently of any specific product development project. Think of it as building the factory – you need walls, power, machinery, and trained workers before you can produce any product. Similarly, an organization needs a safety culture, competent personnel, a quality management system, and defined processes before it can execute any specific functional safety project. These organizational capabilities are established once and maintained continuously, serving all projects within the organization.

Project-dependent safety management (Clause 6) defines the management activities performed within the context of a specific item development project. Using our factory analogy, this is the production plan for a specific product – which machines to use, which workers to assign, what quality checks to perform, and when to ship. For each new ISO 26262 project, a safety plan is created, roles are assigned, the safety case is built, confirmation measures are scheduled, and a release for production decision is made.

The relationship between the two is hierarchical: the overall safety management framework provides the organizational foundation upon which each project-dependent safety management instance is built. An organization with a mature overall safety management system can execute individual projects more efficiently and consistently, because the fundamental processes, competencies, and culture are already in place.

3. Safety Culture – The Non-Negotiable Foundation

The very first substantive topic that c Part 2 addresses is safety culture, and this is not by accident. The standard recognizes that processes, tools, and documentation are necessary but insufficient conditions for achieving functional safety. The people in the organization must genuinely value safety, and this value must permeate every decision, every trade-off discussion, and every interaction – from the boardroom to the engineering bench.

What Does the Standard Require?

ISO 26262-2:2018, Clause 5.4.2 requires the organization to establish, foster, and maintain a safety culture that supports and encourages the effective achievement of functional safety. The standard does not prescribe a specific implementation methodology for safety culture – it recognizes that culture is inherently organization-specific. However, it expects demonstrable evidence that the organization takes safety culture seriously and actively cultivates it.

Key Elements of an Effective Automotive Safety Culture

A genuine safety culture manifests through several observable behaviors and organizational characteristics. Management commitment is the most critical element – senior leadership must visibly and consistently prioritize safety, allocate adequate resources, and demonstrate through their decisions that safety considerations will not be sacrificed for schedule or cost pressures. If engineers perceive that raising safety concerns leads to negative career consequences or schedule pressure, the safety culture is broken regardless of what the policy documents say.

Open communication is equally essential. Engineers must feel empowered to raise safety concerns, report anomalies, and challenge assumptions without fear of retaliation or dismissal. A culture where “bad news travels fast” to the people who need to hear it is a healthy safety culture. A culture where problems are hidden, minimized, or only escalated when it is too late is a dangerous one.

Continuous learning from incidents, near-misses, and lessons learned – both from within the organization and from the broader industry – demonstrates a mature safety culture. Organizations that conduct thorough root cause analyses of safety anomalies, share lessons learned across projects and departments, and proactively improve their processes based on this feedback are exhibiting the kind of learning culture that ISO 26262 envisions.

Accountability and empowerment mean that every person involved in safety-related activities understands their responsibility and has the authority to act on safety concerns. The safety manager, in particular, must have the organizational authority to stop or delay a release if safety evidence is insufficient – and this authority must be genuinely supported by management, not just written on paper.

Integration with daily work means that safety thinking is not a separate “compliance exercise” but is woven into the fabric of everyday engineering decisions. When an engineer instinctively considers the safety implications of a design change, when a project manager proactively allocates time for safety analysis in the schedule, and when a test engineer designs test cases that specifically target safety-critical scenarios – safety culture is alive and well.

4. Competence Management – Right People, Right Roles

Competence management is a formal requirement of ISO 26262 Part 2 (Clause 5.4.4) that ensures the people performing safety-related activities have the necessary skills, knowledge, experience, and qualifications to do so effectively. This is not merely about having people with impressive resumes – it is about systematically matching competencies to roles and continuously developing the organization’s human capability.

What the Standard Requires

The organization shall ensure that persons involved in the execution of the safety lifecycle have a sufficient level of skills, competence, and qualification corresponding to their responsibilities. The standard allows the organization to define its own criteria for what constitutes “sufficient” – but the criteria must be documented, applied consistently, and demonstrably effective.

Competence Dimensions

Effective competence management in an ISO 26262 context typically evaluates multiple dimensions. Domain knowledge means understanding of the specific automotive domain – how the vehicle systems work, what the operational environments are, and what the failure modes look like. A functional safety engineer working on electric power steering must understand steering system dynamics, not just abstract safety theory. Standard knowledge means familiarity with ISO 26262 itself – its structure, requirements, terminology, methods, and work products. Many organizations require formal training and certification (such as the TÜV Functional Safety Engineer certification) as evidence of this competence. Technical skills means proficiency in the specific engineering disciplines required for the role – hardware design, software development, system architecture, safety analysis methods (FMEA, FTA, FMEDA), requirements engineering, or testing. Experience means demonstrated track record of performing similar activities in previous projects, with documented outcomes. Soft skills such as communication, critical thinking, and the ability to challenge assumptions constructively are also important, particularly for safety managers and reviewers who must navigate organizational dynamics.

Implementing a Competence Management System

In practice, organizations typically implement competence management through a combination of a competency matrix (mapping required competencies to each role in the safety lifecycle), individual competency profiles (documenting each person’s current competencies against the role requirements), training programs (formal courses, workshops, and certifications to address competency gaps), mentoring and coaching (pairing less experienced engineers with senior safety experts), and periodic reviews (reassessing competencies as roles evolve and as standards are updated). The competency matrix is a particularly valuable tool because it makes visible both the strengths and the gaps in the organization’s safety capability, enabling targeted investment in training and hiring.

5. Quality Management System and Functional Safety

ISO 26262 Part 2 does not exist in isolation – it is designed to integrate with the organization’s existing quality management system (QMS). Most automotive organizations already comply with IATF 16949 (in conjunction with ISO 9001), which provides a comprehensive quality framework for automotive production and service. ISO 26262 builds upon and extends this foundation for safety-specific activities.

The standard requires that the organization’s QMS encompasses the necessary processes for the management of functional safety. This means that configuration management, change management, documentation control, supplier management, nonconformance handling, corrective and preventive actions, and other QMS processes must be applicable to and adequate for safety-related work products and activities. In many cases, existing QMS processes can be adapted for ISO 26262 use with relatively minor modifications — for example, the existing change management process may need additional gates or approvals for safety-related changes, and the existing document control system may need enhanced traceability capabilities.

The integration with the QMS is particularly important for ASIL classification outcomes. When a HARA results in a QM (Quality Management) rating for certain hazardous events, it means that no specific ISO 26262 safety requirements apply – but the standard quality management processes (as defined by the QMS) are still expected to be followed. The QMS provides the baseline, and ISO 26262 adds safety-specific requirements on top of that baseline proportional to the ASIL.

6. Management of Safety Anomalies

A safety anomaly is any condition, event, or deviation that has the potential to compromise functional safety – whether it is an error in a safety analysis, a defect found in safety-related code, a discrepancy between a safety requirement and its implementation, a gap in the safety case, or a field failure report that suggests a potential safety issue.

ISO 26262 Part 2 requires the organization to have a defined process for the identification, documentation, evaluation, and resolution of safety anomalies. This process must ensure that every safety anomaly is tracked from discovery to resolution, evaluated for its potential impact on safety goals, resolved through appropriate corrective actions, and documented with complete traceability.

The safety anomaly management process should be integrated with (or at minimum aligned with) the organization’s existing nonconformance and corrective action processes from the QMS. However, safety anomalies often require additional scrutiny – the evaluation must consider the potential impact on ASIL requirements, safety goals, and the overall safety case, not just general product quality. The safety manager should be involved in the evaluation of all safety anomalies to ensure that the safety implications are properly understood and addressed.

A mature organization treats safety anomalies not just as problems to be fixed but as learning opportunities. Patterns in safety anomalies can reveal systemic weaknesses in processes, tools, training, or organizational communication – providing valuable input for continuous improvement of the overall safety management system.

7. Project-Independent Tailoring of the Safety Lifecycle

ISO 26262 recognizes that not every project requires the full, unmodified application of every requirement in the standard. Tailoring is the process of adapting the safety lifecycle activities to the specific characteristics and context of the development project. Part 2 addresses project-independent tailoring – the organizational-level decisions about which lifecycle activities are generally applicable and which may be adapted based on defined criteria.

Tailoring must always be justified and documented. The rationale for omitting or modifying any standard requirement must be recorded and must demonstrate that the tailored approach provides an equivalent or sufficient level of functional safety. Tailoring is not a mechanism for cutting corners – it is a mechanism for intelligent application of the standard to diverse development scenarios, such as the reuse of existing components (proven in use), the development of components out of context (SEooC), or the modification of existing products (where only the modified portions may require full ISO 26262 treatment).

8. Roles and Responsibilities – Project Manager vs Safety Manager

Clearly defined roles and responsibilities are essential for effective functional safety management. ISO 26262 Part 2 (Clause 6.4.2) requires that roles and responsibilities for all safety-related activities be specified within the project. Two roles receive particular attention in the standard: the project manager and the safety manager.

The Project Manager

The project manager has overall responsibility for the project, including schedule, budget, resources, and deliverables. ISO 26262 requires that the project manager be appointed at the initiation of a functional safety project and be given both the responsibility and the authority to achieve the project’s safety goals. The project manager must ensure that adequate resources (human, financial, and technical) are allocated to functional safety activities, that the safety plan is integrated into the overall project plan, and that safety milestones and deliverables are tracked alongside other project deliverables.

The Safety Manager

The safety manager is the person responsible for the planning, coordination, and tracking of safety activities throughout the safety lifecycle. This role carries significant responsibility and requires a unique combination of technical depth and organizational influence. Key responsibilities of the safety manager include creating and maintaining the safety plan, delegating safety tasks based on competence and qualification, monitoring the progress of all functional safety activities, coordinating confirmation measures (reviews, audits, assessments), managing the safety case, ensuring that safety anomalies are properly identified and resolved, and providing input to the release for production decision.

A critical aspect of the safety manager’s role is authority. The safety manager must have the organizational standing to escalate safety concerns to the highest levels of management, to delay or block a release for production if safety evidence is insufficient, and to ensure that safety considerations are given appropriate weight in trade-off decisions against schedule, cost, and feature scope. Without this authority – and without management’s genuine support for exercising it – the safety manager role becomes ceremonial and the safety process becomes a compliance checkbox rather than a genuine risk reduction framework.

Other Key Roles

Beyond the project manager and safety manager, ISO 26262 projects typically involve several other roles: system safety engineers (who perform HARA, develop the safety concept, and define safety requirements), hardware safety engineers (who design safety mechanisms, perform FMEDA, and calculate hardware metrics), software safety engineers (who implement safety-related software, perform unit testing, and ensure MISRA compliance), verification and validation engineers (who plan and execute safety testing at all levels), and confirmation reviewers, auditors, and assessors (who perform the independent confirmation measures). The standard does not prescribe a specific organizational structure – it focuses on ensuring that the necessary competencies and authorities are present and properly allocated, regardless of the organizational chart.

9. The Safety Plan – Blueprint for Safety Activities

The safety plan is one of the most important work products in ISO 26262 Part 2. It is the comprehensive planning document that specifies all safety activities to be performed during the development lifecycle, along with the methods, measures, tools, resources, prerequisites, responsibilities, and timelines for each activity.

What the Safety Plan Contains

A well-structured safety plan typically includes the identification and description of the item being developed, the applicable ASIL levels and safety goals, the safety lifecycle phases and activities to be performed (with references to the specific ISO 26262 clauses), the methods and techniques chosen for each activity (with justification, especially when the standard offers options at different ASIL levels), the tools to be used (including any tool qualification requirements), the roles and responsibilities for each activity, the schedule and milestones for safety activities integrated with the overall project timeline, the planned confirmation measures (confirmation reviews, audits, assessments) including their scope and required independence levels, the work products to be produced at each stage, the criteria for tailoring (if any standard activities are adapted or omitted), and the process for managing safety anomalies within the project.

Planning Hierarchy

In practice, the safety plan is often structured as a hierarchical set of documents rather than a single monolithic document. An overall safety plan provides the high-level framework and cross-cutting management activities. Below this, discipline-specific plans may be developed: a system safety plan, a hardware safety plan, and a software safety plan, each detailing the specific activities, methods, and criteria for their respective development domains. This hierarchical approach allows different engineering teams to work from their own detailed plans while maintaining alignment with the overall safety management framework.

Living Document

The safety plan is not a static document created once at the start of the project and then forgotten. It is a living document that is tracked and updated throughout the development lifecycle by the safety manager. As the project progresses, the plan is refined based on emerging safety analysis results, changes in project scope or timeline, lessons learned from confirmation reviews, and any safety anomalies that require changes to the planned approach. All changes to the safety plan must be managed through the configuration management and change management processes.

10. The Safety Case – Compiling the Evidence

The safety case is the definitive compilation of all evidence – arguments, analyses, reviews, test results, process records, and work products — that demonstrates the item achieves the required level of functional safety. If the safety plan tells you what to do, the safety case shows you what was done and proves it was done correctly.

Structure of the Safety Case

The safety case is structured as a logical argument supported by evidence. At the highest level, the argument is: “This item achieves its safety goals with an acceptable residual risk.” This top-level claim is supported by sub-arguments addressing each major area of the safety lifecycle: the HARA was performed correctly and all hazardous events were identified, the safety goals are correct and complete, the functional safety concept addresses all safety goals, the technical safety concept correctly implements the functional safety concept, the hardware development meets all hardware safety requirements and hardware metrics targets, the software development meets all software safety requirements with appropriate verification coverage, the system integration and testing confirm that all safety requirements are satisfied, all safety anomalies have been resolved, all confirmation measures have been completed with positive outcomes, and the product is ready for production.

Each sub-argument is supported by specific evidence – the work products produced during that lifecycle phase. The safety case must demonstrate complete traceability from safety goals through all levels of safety requirements to their implementation and verification.

Progressive Construction

The safety case is not assembled only at the end of development. Good practice – and the expectation of experienced assessors – is that the safety case is built progressively throughout the development lifecycle. As each phase is completed and its work products are finalized, they are added to the safety case. This progressive approach allows early identification of gaps and ensures that the final safety case compilation is a validation exercise rather than a panicked last-minute effort to gather and organize all evidence.

11. Confirmation Measures – Reviews, Audits, and Assessments

Confirmation measures are the ISO 26262 mechanism for providing independent assurance that safety activities have been performed correctly and that safety work products meet the requirements of the standard. They are, in essence, the “checks and balances” built into the safety process. Part 2 defines three types of confirmation measures.

Confirmation Reviews

A confirmation review is an examination of a specific work product to confirm that it meets the requirements of the ISO 26262 standard. The reviewer checks the correctness, completeness, consistency, adequacy, and contents of the work product against the corresponding ISO 26262 requirements. Confirmation reviews are performed on nine key work products identified in the standard, including the item definition, HARA and safety goals, functional safety concept, technical safety concept, hardware and software safety requirements specifications, hardware and software verification reports, and the safety case itself. The result is a confirmation review report that provides a judgement on whether the work product achieves its intended contribution to functional safety.

It is important to distinguish a confirmation review from a verification review. A verification review checks whether the work product satisfies the project’s technical requirements (did we build it right?). A confirmation review checks whether the work product satisfies the ISO 26262 standard’s requirements (did we follow the standard correctly?). The standard allows these two types of reviews to be combined, provided the combined review is performed with sufficient independence as required by the ASIL level.

Functional Safety Audit

A functional safety audit is an examination of the implemented processes with regard to the process objectives defined by ISO 26262. While confirmation reviews focus on individual work products, the audit focuses on whether the organization’s processes are being followed correctly as specified in the safety plan. The audit evaluates whether the planned safety activities were actually performed as described, whether the methods and techniques specified in the safety plan were actually used, whether the roles and responsibilities were properly executed, and whether any deviations from the planned process are justified and documented. The audit is mandatory for ASIL C and D and optional (but recommended) for ASIL B. A functional safety audit report documents the findings.

Functional Safety Assessment

A functional safety assessment is the highest-level confirmation measure. It is an examination of whether the functional safety achieved by the item complies with ISO 26262. The assessment takes a holistic view – considering the outputs of confirmation reviews, the results of the functional safety audit, the overall safety case, and any remaining open issues or safety anomalies. The assessment is typically performed by an experienced, independent assessor (often from a third-party organization such as TÜV SÜD, TÜV Rheinland, TÜV Nord, SGS, or Intertek) who evaluates the entire body of evidence and issues a recommendation. The result is a functional safety assessment report that provides one of three recommendations: acceptance (the item achieves the required functional safety), conditional acceptance (the item achieves functional safety subject to resolution of specified conditions), or rejection (the item does not achieve the required functional safety). The assessment is mandatory for ASIL C and D and recommended for ASIL B.

12. Independence Levels (I0, I1, I2, I3) and ASIL Mapping

One of the most practically important aspects of confirmation measures is the concept of independence levels. The standard recognizes that the value of a review, audit, or assessment depends on the independence of the person performing it from the work being evaluated. Higher ASIL levels require higher levels of independence to ensure that the confirmation is truly objective.

ISO 26262 Part 2, Table 1 defines four levels of independence:

I0 (No specific independence requirement): The person performing the confirmation measure can be someone who was involved in the creation of the work product. This is the lowest level of independence. For ASIL A and QM, there are generally no specific requirements for confirmation measures (beyond standard quality practices).

I1 (Different person): The confirmation measure shall be performed by a person who was not involved in the creation of the considered work product. This is the minimum level of meaningful independence – the reviewer is a different individual, but may be from the same team or report to the same supervisor.

I2 (Different department or group): The confirmation measure shall be performed by a person from a different department or group than the persons responsible for the creation of the considered work product. This provides a higher level of independence by removing the direct team dynamics and shared supervision that could compromise objectivity.

I3 (Different organization): The confirmation measure shall be performed by a person who is independent regarding management, resources, and release authority from the department responsible for the creation of the work product. This is the highest level of independence and is typically achieved by engaging an external assessment body. I3 independence ensures that the person performing the evaluation has no organizational or financial incentive to overlook issues.

ASIL-Dependent Independence Requirements

The required independence level varies based on the ASIL and the type of confirmation measure. For confirmation reviews: QM and ASIL A have no specific requirements. ASIL B requires I1 (different person). ASIL C requires I2 (different department). ASIL D requires I2 (different department) – not necessarily I3, although I3 is considered best practice. For functional safety audits: required for ASIL C (I1) and ASIL D (I2). Recommended for ASIL B. For functional safety assessments: required for ASIL C (I2) and ASIL D (I2 or I3, depending on the organization’s interpretation and the OEM’s expectations). Recommended for ASIL B. In practice, many OEMs require I3 (external third-party) assessments for ASIL D products, even though the standard technically allows I2.

13. Release for Production

The release for production is the formal decision that the item has been developed in accordance with ISO 26262, that the safety case provides sufficient evidence of functional safety, and that the product is ready for series production. This decision is the culmination of the entire development lifecycle and represents the point at which responsibility transitions from the development organization to the production and operations organizations.

The release for production decision must be based on sufficient evidence from the safety case – including successful completion of all planned safety activities, resolution (or documented acceptance) of all safety anomalies, positive outcomes from all confirmation measures (reviews, audits, assessments), and demonstrated achievement of all safety goals through verification and validation. A release for production report documents this decision, including the baseline of the product configuration, any residual conditions or limitations, and the date of the release. This report is added to the safety case as the final work product of the development phase.

14. Safety Management After Development – Production, Operation, Service & Decommissioning

Clause 7 of ISO 26262 Part 2 addresses the safety management requirements for the phases that follow development. Functional safety does not end when the product leaves the development lab – it must be maintained throughout the product’s entire lifecycle.

Production: The manufacturing processes must be controlled to ensure that safety-related characteristics established during development are preserved in every produced unit. This includes maintaining process controls, performing end-of-line testing, and ensuring that production variations do not compromise functional safety.

Operation: During the vehicle’s operational life, functional safety is maintained through proper use (as communicated through owner’s manuals and warnings), through the vehicle’s built-in diagnostic capabilities, and through regular maintenance and service.

Service: When a vehicle is serviced or repaired, the service procedures must maintain the functional safety of the E/E systems. This includes using correct replacement parts, following proper calibration procedures, and ensuring that software updates do not introduce new safety risks.

Decommissioning: At the end of the vehicle’s life, the decommissioning process must consider any safety implications – for example, ensuring that high-voltage battery systems in electric vehicles are safely disconnected before the vehicle is scrapped.

15. Field Monitoring and Post-SOP Modifications

Field monitoring is the process of systematically collecting, analyzing, and acting on field data related to the safety performance of the product after it has entered production (after Start of Production – SOP). This includes tracking warranty claims related to safety-relevant components, monitoring customer complaints and incident reports, analyzing data from vehicle diagnostic systems, and reviewing information from regulatory agencies and industry safety databases.

The purpose of field monitoring is to identify potential safety issues that were not discovered during development – either because they arise from operating conditions not fully anticipated during HARA, from manufacturing variations not caught during production testing, or from degradation patterns that emerge only over time and mileage. If field monitoring reveals a potential violation of a safety goal, the organization must initiate an investigation and, if necessary, implement corrective measures – which may include software updates, service campaigns, or in severe cases, product recalls.

Post-SOP modifications – any changes to the product after the release for production – must be managed through a formal change management process that evaluates the impact of the change on functional safety. Even seemingly minor changes (a component substitution, a software bug fix, a manufacturing process adjustment) can potentially affect safety if they touch safety-related elements. The standard requires that the safety lifecycle be tailored for modifications based on the nature and extent of the change.

16. Key Work Products of Part 2

ISO 26262 Part 2 defines several essential work products that must be produced and maintained as evidence of functional safety management. These work products form the management backbone of the safety case.

Evidence of safety culture: Documentation demonstrating how safety culture is established, fostered, and maintained within the organization. Competence management records: Records of competency assessments, training programs, certifications, and competency matrix maintenance. Safety plan: The comprehensive planning document for all safety activities within the project. Safety case: The compiled body of evidence demonstrating that functional safety has been achieved. Confirmation review reports: Reports from each confirmation review performed on key work products. Functional safety audit report: Report documenting the findings of the process audit. Functional safety assessment report: Report with the assessor’s recommendation (acceptance, conditional acceptance, or rejection). Release for production report: The formal documentation of the production release decision. Safety anomaly records: Tracked records of all identified safety anomalies and their resolution. Field monitoring data and reports: Collected and analyzed field performance data for safety-relevant functions.

17. Common Challenges in Implementing Part 2

Based on widespread industry experience, several challenges recurrently arise when organizations implement ISO 26262 Part 2 functional safety management.

Superficial safety culture: Many organizations create policy statements and hang safety posters on walls but fail to genuinely embed safety thinking into decision-making. The true test of safety culture comes when safety considerations conflict with schedule or budget — if safety consistently loses that battle, the culture is superficial regardless of the documentation.

Insufficient safety manager authority: The safety manager role is often assigned to a mid-level engineer without the organizational authority to influence major decisions. Without genuine authority – backed by management commitment – the safety manager becomes a documentation administrator rather than a safety leader.

Late confirmation measures: Organizations frequently push confirmation reviews, audits, and assessments to the end of the development cycle. When gaps are discovered late, they are expensive and time-consuming to fix, creating immense pressure to waive or minimize findings rather than properly address them.

Independence challenges: Achieving the required levels of independence – particularly I2 and I3 – can be difficult for smaller organizations or for highly specialized domains where few qualified independent reviewers exist. Ensuring that “independence” is not just organizational chart separation but genuine objectivity is an ongoing challenge.

Safety plan maintenance: Keeping the safety plan up-to-date as the project evolves requires disciplined effort. Many organizations create an initial safety plan but fail to maintain it, leading to a disconnect between what was planned and what was actually done – which becomes apparent during audits and assessments.

Integration with existing processes: Integrating ISO 26262 management requirements with existing project management, quality management, and engineering processes without creating excessive overhead or duplicative documentation requires careful process design and ongoing optimization.

18. Best Practices for Functional Safety Management

Based on successful industry implementations, the following best practices can significantly improve the effectiveness of functional safety management under ISO 26262 Part 2.

Start with safety culture, not with documents. Invest in genuinely changing organizational behavior before generating paperwork. Management workshops, cross-functional safety awareness sessions, and visible executive sponsorship are more valuable than an extra shelf of policy documents.

Appoint the safety manager early and give them real authority. The safety manager should be involved from day one of the project — not brought in after the architecture is already defined. They should have the organizational standing and management backing to influence design decisions, not just document them after the fact.

Build the safety case progressively. Do not wait until the end to compile the safety case. As each work product is completed and reviewed, add it to the safety case immediately. This makes gaps visible early and distributes the documentation effort across the project timeline.

Schedule confirmation measures at natural phase gates. Plan confirmation reviews to coincide with the completion of each major work product, not as a batch activity at the end. Space them throughout the development lifecycle so that findings can be addressed while there is still time and budget to do so.

Invest in competence management as a strategic capability. Functional safety expertise takes years to develop. Organizations that invest in long-term competence building – through formal training, certification programs, mentoring relationships, and knowledge management systems – build a sustainable competitive advantage.

Integrate, do not duplicate. Where possible, integrate ISO 26262 management activities with existing project management, ASPICE process, and quality management workflows. A single, integrated project plan that includes safety milestones is better than separate project and safety plans that inevitably diverge.

Learn from every project. After each project reaches release for production, conduct a formal lessons-learned exercise focused on the safety management process. What worked well? Where were the pain points? What should be improved for the next project? Feed these insights back into the overall safety management framework to drive continuous improvement.

19. Frequently Asked Questions

Q1: Does my organization need a dedicated safety department?

ISO 26262 does not mandate a specific organizational structure. Some organizations have a centralized functional safety department, others embed safety engineers within product development teams, and others use a hybrid model. What matters is that the required competencies are available, the roles and responsibilities are clearly defined, and the required levels of independence can be achieved for confirmation measures.

Q2: Can the project manager and safety manager be the same person?

The standard does not explicitly prohibit this, but it is generally considered poor practice – especially for higher ASIL levels. The project manager faces inherent pressure to meet schedules and budgets, while the safety manager must prioritize safety even when it conflicts with these constraints. Separating these roles helps ensure that safety considerations receive independent advocacy.

Q3: How detailed should the safety plan be?

The safety plan should be sufficiently detailed that a competent person can use it to understand what safety activities are planned, when they will be performed, by whom, using which methods and tools, and what work products will result. It should be detailed enough for planning and tracking but not so voluminous that it becomes unmanageable to maintain. Many organizations adopt a hierarchical approach with an overall safety plan and discipline-specific sub-plans.

Q4: Do we need external assessment for every ASIL D project?

The standard requires I2 independence for ASIL D functional safety assessments, which technically can be achieved by a different department within the organization. However, industry best practice – and many OEMs’ contractual requirements – expect I3 (external, third-party) assessments for ASIL D. This provides the highest confidence and is most defensible from a liability perspective.

Q5: What happens if a confirmation review identifies non-conformities?

Non-conformities identified during confirmation reviews must be documented and tracked as safety anomalies. The development team must address each finding – either by correcting the work product, by providing a documented rationale for tailoring, or by demonstrating through additional evidence that functional safety is not compromised. The safety manager tracks the resolution of all findings.

Q6: How does ISO 26262 Part 2 relate to Automotive SPICE (ASPICE)?

ASPICE evaluates the process capability and maturity of an organization’s software (and increasingly, systems and hardware) development processes. ISO 26262 Part 2 evaluates the functional safety management processes. They are complementary — a high ASPICE process capability level provides a strong foundation for ISO 26262 compliance. Many OEMs require both ASPICE assessment and ISO 26262 compliance from their suppliers. An ASPICE audit and an ISO 26262 functional safety audit can be coordinated to reduce duplication.

Q7: What is the difference between a verification review and a confirmation review?

A verification review checks whether a work product meets the project’s technical requirements – it evaluates technical correctness and completeness against the engineering specifications. A confirmation review checks whether a work product meets the ISO 26262 standard’s requirements — it evaluates compliance with the standard’s form, content, and process expectations. The two can be combined if the review is performed with sufficient independence as required by the ASIL.

20. Conclusion

ISO 26262 Part 2 – Management of Functional Safety is the organizational backbone of the entire functional safety standard. While the technical parts (4, 5, 6) often receive more attention from engineers, Part 2 is where the difference between genuine safety and compliance theater is determined. A strong safety culture, competent people in the right roles, a well-structured safety plan, a progressively built safety case, and rigorously executed confirmation measures – these are the elements that transform ISO 26262 from a documentation burden into a genuine risk reduction framework.

The organizations that excel in functional safety are not necessarily those with the largest budgets or the most sophisticated tools – they are the ones where safety thinking is authentically embedded in the culture, where the safety manager has real authority, where confirmation measures are valued as learning opportunities rather than feared as gotcha exercises, and where lessons from every project feed back into continuous improvement of the safety management system.

This article is part of our comprehensive ISO 26262 series at PiEmbSysTech. Next in our series: ISO 26262 Part 3 – Concept Phase, where we will explore item definition, hazard analysis and risk assessment (HARA), safety goals, and the functional safety concept. Be sure to check out our previous post on ISO 26262 Part 1 – Vocabulary and Key Terminology if you have not already.

Stay safe. Stay organized. Keep engineering the future.

— The PiEmbSysTech Team