Skip to main content
Technical

ISO 26262 Safety Culture: Competence and Accountability

Three engineers look at a laptop together beside a vehicle test rig with a steering wheel and wiring in a development workshop.

Why ISO 26262 Part 2 regulates the organization: what safety culture means in the standard, how processes drift through the normalization of deviance, why responsibility needs authority and competence, and which of four checks asks which question.

Accident investigations keep finding two causes side by side: a technical fault, and an organization that let it through. A requirement nobody challenged, a test result explained away, a finding that waited for a milestone. ISO 26262 spends a whole part, Part 2, on that second cause.

Why a standard about electronics regulates the organization

Random hardware failures come from physical effects in the hardware, from wear and ageing to a particle flipping a memory bit. They occur unpredictably but at rates that can be estimated, and they are handled with diagnostics, redundancy and safety mechanisms. Systematic failures have a specific cause, such as a wrong requirement, a design error or a slip in a production process, and they recur whenever the triggering conditions return. Two identical channels built from one wrong requirement fail the same way on the same input, so duplication alone does not catch them.

Architecture and diversity can limit some effects, but the main defence is upstream: competent people, defined processes and independent checks. So ISO 26262-2:2018, Clause 5 asks the organization for a safety culture, its own rules and processes, a way to handle safety anomalies, competence management and a quality management system. Clause 6 applies this to each project, and Clause 7 keeps safety responsibilities assigned after release for production.

What ISO 26262 means by safety culture

ISO 26262-1 places safety culture in the lasting values, attitudes, motivation and knowledge of an organization, and makes the test whether safety comes first when it competes with other goals, in what people decide and do. The definition admits that cost and schedule pull the other way, and asks which side wins.

Decisions show that; policy statements do not. Part 2 requires the organization to create, foster and sustain such a culture, and its informative Annex B lists observable signs of a poor and a good one. In a poor culture nobody can trace who decided what; in a good one, decisions carry a name. In a poor culture the reward system pays for shipping fast and cheap; in a good one it penalizes shortcuts. A quick test: what happened to the last engineer who brought bad news late in a project?

How good cultures drift

A step chart. A flat teal line marks what the safety plan and the process say. A red line, the practice the team treats as normal, steps down at four bends, each followed by 'nothing happened': a design review held after the build, a cold test run at one temperature corner of three, an open safety finding carried to the next gate, and 'seen before, no failure' accepted as a rationale. The gap between the lines is labelled the drift nobody decided. Below, a hallway agreement with no owner, date or reasoning becomes the next baseline, while a written deviation with owner, date, rationale and reviewer stays an exception.
Each bend looked reasonable at the time. The sum is a different process.

Cultures rarely fail through one bad decision. They drift. The sociologist Diane Vaughan named the mechanism the normalization of deviance in her study of the 1986 Challenger launch decision, where O-ring erosion on earlier flights had been accepted because the flights came back. A rule is bent under pressure, nothing bad happens, and the bend becomes the new baseline. The next bend starts from there, and every step looks reasonable to the people taking it.

What works against drift is visibility. A deviation that is written down, owned and reviewed stays an exception. ISO 26262 builds this in: tailoring a safety activity needs a written rationale, and a safety anomaly is closed with evidence, not because the milestone arrived.

Responsibility needs authority and competence

A triangle with responsibility at the top, authority bottom left and competence bottom right, and one appointed person in the middle holding all three in writing. Each side shows the failure when the opposite corner is missing: no authority, the person sees the problem but cannot get it funded or escalated in time; no competence, they sign off work they cannot judge; no responsibility, someone decides but nobody owns the outcome.
Remove one corner and the failure shows up on the opposite side.

A common structural flaw is giving someone safety responsibility without the means to act on it. Part 2 asks that people with safety responsibility have sufficient authority, and that everyone working in the safety lifecycle has the skills, competence and qualification their tasks call for, backed by evidence of competence management rather than job titles.

On a project, Clause 6 starts with appointments: a project manager and a safety manager, the second with the responsibility and authority to plan and coordinate the safety activities. The safety manager is not automatically the person who signs the release. Release for production is an authorization based on evidence: the safety case, the confirmation measure reports and the functional safety assessment where one applies. What the safety manager needs is a working escalation route, agreed in writing before the deadline arrives.

Four checks, four questions

An electric power steering system, with steering wheel, torque sensor, assist motor, ECU and rack, ringed by four checks. Verification, ISO 26262-8 Clause 9: does a work product meet its specified requirements? Safety validation, ISO 26262-4 Clause 8: are the safety goals achieved in the vehicle? Functional safety audit, ISO 26262-2 Clause 6: is the project following the processes it committed to? Functional safety assessment, ISO 26262-2 Clause 6: is the achieved functional safety convincing? A strip below explains that ISO 26262-2 Table 1 sets, per confirmation measure and ASIL, whether the measure applies and how independent its reviewer must be, with four rising bars: I0 another person if performed (recommended), I1 another person (required), I2 another team, I3 another department.
One item, four checks, four different questions.

ISO 26262 separates four checks that are easy to blur. Verification asks whether a work product meets its requirements (ISO 26262-8, Clause 9). Safety validation asks whether the safety goals are achieved in the vehicle (ISO 26262-4, Clause 8). The functional safety audit asks whether the project follows the processes it committed to. The functional safety assessment judges the functional safety the item achieves.

The audit, the assessment and the confirmation reviews of key work products are the confirmation measures of Part 2, Clause 6. For each measure and ASIL, Part 2, Table 1 says whether it is required, recommended or not specified, and how independent the reviewer must be, on a scale from I0 to I3. Even at I0, a measure that is performed is done by someone other than the author; I3 adds separate management, resources and release authority.

A late finding on a steering project

Picture an electric power steering (EPS) project six weeks before start of production. A cold-chamber test shows that at minus 40 °C, the cross-check between the two channels of the steering torque sensor detects a fault too late for the system to reach a safe state within the fault tolerant time interval. A technical safety requirement is not met.

In one organization the result is logged as a test-bench artefact, does not reproduce on the second run and is closed as a quality issue, so the release gate stays green. In another, it is recorded as a safety anomaly and analysed, closed only with a verified fix or a reviewed rationale, escalated if that cannot happen in time, and the release decision waits for the evidence. Both can have the same process handbook. The difference is what the engineer who raised the issue expects to happen to them.

Four misconceptions

  • "Few reported anomalies means a healthy project." It can mean fewer defects, or that people stopped reporting. Read it together with how anomalies are closed.
  • "A training certificate proves competence." It proves attendance, and sometimes knowledge. Part 2 asks for competence matching the responsibility, and ISO 26262 does not require a personal certificate.
  • "Safety culture is the safety manager's job." Resources, priorities and rewards are set by management, and only management can change them.
  • "The auditor and the assessor check the same thing." The auditor checks that the processes are followed. The assessor judges whether the item achieves functional safety. Neither replaces verification inside the project.

Where to go from here

The Safety Culture & Competence concept takes Part 2 into practice: the full Annex B mirror, the independence matrix, competence records, anomaly closure, and commitment that holds when it costs a launch date.

Abbreviations

  • ASIL - Automotive Safety Integrity Level, A (lowest) to D (highest).
  • EPS - Electric Power Steering.

Featured image: Engineers in Workshop by ThisIsEngineering on Pexels, cropped.

Related on the Platform

Read the full Safety Culture & Competence concept

From HARA to Safety Mechanisms - master every concept with clear, practical explanations and real-world examples.

Browse Concepts

Comments

Loading comments