Skip to main content
Technical

Evaluating ISO 26262 Safety Culture: Evidence Over Slogans

Three engineers at a lab workbench: one points at a measurement plot on a laptop, a senior colleague listens and another takes notes, with a prototype car on a lift and test equipment behind them.

How to evaluate a safety culture in an ISO 26262 organization from evidence rather than slogans: where safety collides with the schedule, which five project records show the real culture, what the functional safety audit and assessment already see, and three common misreadings.

Every automotive supplier has a safety policy, and many have the posters to match. Neither tells you much about the safety culture. The culture shows in what the organization does when functional safety competes with cost or a launch date, and in the records those decisions leave behind. This article explains where to find those records, how to read them, and what they cannot tell you.

Why ISO 26262 cares about culture at all

Random hardware failures can be handled with diagnostics, redundancy and safety mechanisms. Systematic failures are different. They come from wrong requirements, design errors and process slips, and duplication alone does not catch them: a wrong requirement copied into two channels fails in both. The defence lies upstream, in competent people, disciplined processes and independent checks. That is why ISO 26262 asks every organization in the safety lifecycle to build and sustain a safety culture, next to its own rules and processes, the handling of safety anomalies, competence management and quality management.

The standard offers no culture score and no culture certificate. What it does offer is a set of contrasting examples of poor and good practice, and each of them describes behaviour rather than belief: whether a decision can be traced to a person, whether cost and schedule always win, whether dissent is valued or punished. Behaviour can be observed. Values on a slide cannot.

Start at the collision points

A late radar firmware delivery on an automatic emergency braking project leaves six weeks of validation to fit into three. Two lanes follow. When the schedule wins: the validation campaign is cut, failing cases are closed as not reproducible, and the vehicle releases on the original date; an evaluator later finds slides without a decision owner, tickets closed without rationale and no trace of the trade-off. When safety decides: the gap is logged as a safety anomaly and escalated with its effect on the safety case, and the release waits for the finished validation or a reviewed change of scope; an evaluator finds a named owner and date, a completed validation and a reviewed rationale.
Same pressure, same handbook. Different decisions leave different records, and the records are what an evaluator can read.

Culture is easiest to read where safety and another goal pull in opposite directions. Take an automatic emergency braking (AEB) project. The radar supplier delivers a firmware update three weeks late, and six weeks of validation now have to fit into three before the release milestone.

In one organization the validation campaign is cut to fit, two failing test cases are closed as not reproducible, and the vehicle releases on the original date. In another, the gap is logged as a safety anomaly and escalated with its effect on the safety case. The release waits until the validation is finished, or until any cut in scope is justified and reviewed, and the rest of the release evidence is in place. Both organizations can work from the same process handbook. A year later, only the second can show what was decided, by whom and why.

So an evaluation starts by finding these moments: late deliveries, budget cuts, defects found close to start of production. Then it reads the decision records around them. Where a hard trade-off left no record at all, that absence is the first finding.

Five records worth reading

Five document cards, each with what to read and a warning sign. Safety anomaly records: how each was closed, by a verified fix or by showing no unreasonable risk, with a reviewed rationale either way; warning, closed as not reproducible the week before a gate. Tailoring rationales: why an activity was dropped or changed and who reviewed it; warning, agreed in a meeting with nothing in the plan. Appointments and resources: named safety roles against real workload, budget and answered escalations; warning, a safety manager at 20 percent on three projects. Independence of checks: who reviewed, audited and assessed whose work and to whom they report; warning, the assessor reports to the manager whose release it is. Lessons learned: whether a finding changed a process, template or training; warning, the same finding in three projects in a row. A note says to read the closure of anomalies, not their count.
Five records an ISO 26262 project usually holds already. The culture is in what they contain.

Evaluating a culture does not need new paperwork. Where an activity applies, a project developed to ISO 26262 already produces its record. The question is what is written in it.

  • Safety anomaly records. ISO 26262 accepts two ways to close a safety anomaly: a measure that resolves it and is verified to work, or an evaluation showing that no unreasonable risk remains. Either way, the rationale is written down and reviewed, and an anomaly that cannot be closed goes up the line. Read how anomalies were closed, not how many there were: a low count can mean few defects, or people who stopped reporting.
  • Tailoring rationales. A project may drop a safety activity or perform it differently, but the change belongs in the safety plan with a reason that someone reviews. A shortcut agreed in a meeting leaves nothing to review, and that is how processes drift, as our article on safety culture, competence and accountability shows.
  • Appointments and resources. People responsible for safety need the authority and the resources to act on it. Compare the named safety manager with their real workload, and check whether the escalations they raised were answered.
  • Independence of the checks. Confirmation reviews, the functional safety audit and the functional safety assessment are only as strong as the distance between the checker and the checked. The independence required rises with the ASIL. For an ASIL D item, the assessor cannot answer to the department that built it, neither for budget nor for the release decision.
  • Lessons learned. ISO 26262 expects improvement fed by earlier projects and by field experience. When the same finding turns up project after project, nothing was learned.

What the assessor already sees

Safety culture is not a separate audit item, but the confirmation measures are not blind to it. The functional safety audit judges whether the project really follows the processes in its safety plan, and can recommend improvements. The functional safety assessment judges the functional safety the item achieves, and its scope covers the rationales behind closed safety anomalies. The example assessment agenda the standard gives for an ASIL D item starts with safety management, and its first point is whether the organization's culture is actually applied in the project.

Two limits are worth keeping in mind. A clean audit shows that the process was followed, not that it was used honestly when it hurt. And an assessment report judges one item, while culture belongs to the organization that produced it. One good report proves less than the same pattern across several projects.

Three misreadings

  • "We have a safety manager, so the culture is fine." A title without authority, time and a working escalation route protects nobody. The safety manager plans and coordinates the safety activities. Release for production needs sufficient safety evidence and a signature from the person responsible for the release, who is not automatically the safety manager.
  • "Our policies prove our culture." Policies state the intended culture. Decisions under pressure show the real one. Ask for examples, not for agreement.
  • "Culture is checked once, at the end." The assessment is meant to progress with the development, and culture erodes a little with every deadline. Evidence gathered only at the release gate is evidence the team has had time to tidy.

Where to go from here

This article stops at what to look for. The Safety Culture & Competence concept goes further: how to run a structured culture assessment, which indicators move before a recall does, how safety metrics get gamed, and how to make the commitment hold when it costs a launch date.

Abbreviations

  • AEB - Automatic Emergency Braking.
  • ASIL - Automotive Safety Integrity Level, A (lowest) to D (highest).
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