Teams moving from general embedded work into automotive quickly discover that ISO 26262 isn't a checklist bolted onto an existing process — it's a different process, and underestimating that gap is one of the most common early mistakes.
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.
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. A high ASIL doesn't always have to be carried by a single component either; our note on ASIL decomposition across redundant channels covers how that rigor can sometimes be split across independent elements instead.
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 — which is part of why disciplined version tracking, covered in our note on hardware version control, matters as much for safety-relevant firmware as for the hardware it runs on. 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.
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.
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. Teams that haven't opened a formal safety case yet can still build most of that discipline early, which is what we cover in our note on staying ASIL-ready before a safety case exists. This is the kind of process discipline we bring to firmware work for safety-relevant embedded systems — including systems like automotive OTA update pipelines and fleet telematics platforms that carry functional-safety implications of their own — see our automotive IoT development work for the full picture.
