ISO 26262 is the international functional safety standard for electrical and electronic systems in road vehicles. Its purpose is to reduce the risk of harm caused by malfunctioning behavior of those systems, and it does this by imposing structure and rigor on the entire development lifecycle — not just on testing at the end. For a team that hasn't worked to a formal functional safety standard before, the biggest surprise usually isn't any single requirement; it's how much the standard changes the shape of the day-to-day development process.
ASIL classification sets the bar per component
ISO 26262 uses Automotive Safety Integrity Levels (ASIL A through D, plus QM for components determined not to require ASIL-level rigor) to classify the risk associated with a given function or component, based on a hazard analysis that considers severity, exposure, and controllability of the hazard the function could contribute to. The classification isn't uniform across a vehicle system — a component controlling braking behavior and a component controlling an infotainment display setting will typically land in very different ASIL categories, and the rigor required in development, verification, and documentation scales accordingly. Getting this classification right, with real hazard analysis rather than a guess, is foundational — it determines how much process overhead the rest of the project actually needs.
Traceability and hazard analysis become part of the daily process
Under ISO 26262, a requirement has to trace forward to the design element that implements it and the test that verifies it, and that traceability has to be maintained as the system evolves, not reconstructed at the end. Hazard analysis and risk assessment aren't a one-time exercise performed before coding starts either — they're revisited as the design matures and as changes are proposed, since a design change can introduce a new hazard or affect the mitigation for an existing one. Teams new to this often underestimate how much ongoing documentation discipline this requires compared to typical embedded development, where traceability is often informal or reconstructed only when needed.
Structured, V-model-style development isn't optional process theater
ISO 26262 development tends to follow a structured V-model: requirements and architecture flow down one side, implementation sits at the bottom, and verification and validation activities flow back up the other side, each tied to a corresponding downstream artifact. This isn't simply a preferred methodology — it's how the standard expects safety evidence to be organized and demonstrated. Teams used to more iterative, less formally structured embedded workflows often find this the hardest adjustment, both because it's a different way of working and because it demands more planning and documentation investment before code gets written than they're used to budgeting for.
Practical takeaway
The teams that underestimate ISO 26262 tend to underestimate it in the same way: they treat it as an extra set of documents to produce after the engineering is done, rather than a different way of doing the engineering itself. Planning for the process overhead — hazard analysis, traceability, structured verification — from the start of a program is what keeps a functional-safety project on schedule. This is the kind of process discipline we bring to firmware work for safety-relevant embedded systems.