COMPLETE GUIDE TO HARA FOR ISO 26262

HARA, or Hazard Analysis and Risk Assessment, is one of the central work products in ISO 26262. It connects an automotive item's intended function, foreseeable malfunctioning behavior, operating situations, hazardous events, ASIL classification, and safety goals. Done well, HARA gives the safety program a defensible foundation. Done poorly, it creates weak safety goals, inconsistent requirements, and review problems that follow the project for months.

This guide explains HARA as a practical engineering workflow. It is written for functional safety engineers, systems engineers, safety managers, founders building safety-relevant products, and teams evaluating HARA software or ISO 26262 tools. The goal is not to replace the standard. The goal is to make the workflow easier to execute, review, trace, and improve.

Aegis SafeForge is an AI-assisted functional safety and cybersecurity workflow platform for HARA, TARA, requirements traceability, artifact generation, review control, and audit-ready evidence. In a HARA workflow, SafeForge helps teams move from project context to reviewed hazard analysis outputs while keeping human review, deterministic checks, and traceability in the loop.

What HARA Means in ISO 26262

HARA identifies hazardous events that can result from malfunctioning behavior of an item. Each hazardous event is assessed using severity, exposure, and controllability. Those three ratings lead to an Automotive Safety Integrity Level, usually expressed as QM, ASIL A, ASIL B, ASIL C, or ASIL D. The resulting ASIL helps determine the rigor expected for downstream safety activities.

The HARA is not just a table. It is a reasoning artifact. It captures why a scenario matters, which assumptions shaped the risk classification, and which safety goals are needed to reduce unreasonable risk. That is why HARA tooling should support review, rationale, traceability, and change history rather than only spreadsheet-style data entry.

Step 1: Start with a Strong Item Definition

The quality of HARA depends heavily on the item definition. The item definition describes the system or function being analyzed, its boundaries, interfaces, intended behavior, operating modes, dependencies, assumptions, and external context. If the item definition is vague, the hazard analysis will either miss relevant scenarios or create broad hazards that cannot be converted into useful requirements.

A practical item definition should answer a few basic questions: What function is being delivered? What vehicle context does it operate in? Which actors interact with it? Which operating modes matter? What is explicitly outside the item boundary? Which assumptions are inherited from adjacent systems? These answers become the raw material for identifying malfunctioning behavior and operational situations.

Step 2: Identify Malfunctioning Behavior

A malfunctioning behavior describes how the item can behave incorrectly from a functional safety perspective. For a steering-related function, this might include unintended steering assist, loss of assist, delayed assist, excessive assist, or assist in the wrong direction. For braking, it may include unintended braking, loss of braking support, delayed braking, or incorrect brake distribution.

Good malfunctioning behavior is specific enough to support analysis but not so narrow that the HARA becomes unmanageable. Teams should avoid vague entries such as "system fails" because they do not explain the functional deviation. They should also avoid implementation-level failure causes too early. HARA is about hazardous effects at the item level, not a component failure catalog.

Step 3: Define Operational Situations

Operational situations describe the circumstances in which the malfunctioning behavior occurs. Speed, road type, traffic density, weather, driver state, vehicle maneuver, and environmental conditions can all change severity, exposure, or controllability. A loss of a function while parking is usually a different hazardous event than the same loss during highway driving.

This is where many spreadsheet HARA processes start to drift. Teams copy scenarios, change a few words, and lose the reasoning behind why one row differs from another. A workflow tool should make operational assumptions visible and should preserve the connection between scenario, rating, safety goal, and reviewer decision.

Step 4: Form Hazardous Events

A hazardous event combines malfunctioning behavior with an operational situation and a resulting hazard. For example: unintended steering assist while driving on a curved highway may lead to unintended lane departure and potential collision. The hazardous event should be written in a way that reviewers can challenge. It should not hide the chain of reasoning inside a vague phrase.

A helpful pattern is: malfunctioning behavior, operational situation, hazardous consequence. This structure makes it easier to review whether the event is real, whether the scenario is credible, and whether the ratings are consistent with the risk argument.

Step 5: Rate Severity, Exposure, and Controllability

Severity evaluates the potential harm. Exposure evaluates how often the operational situation is expected to occur. Controllability evaluates whether the driver or other road users can avoid the harm once the malfunction occurs. These ratings are not just labels. They are engineering judgments that must be explainable to reviewers and auditors.

AI can help propose draft reasoning for severity, exposure, and controllability, but the final values should remain reviewable human decisions. In SafeForge, AI-assisted drafting is separated from deterministic safety logic and human approval. The platform can help structure the first pass, but the engineering team remains responsible for the final assessment.

Step 6: Derive ASIL Consistently

ASIL classification follows from the combination of severity, exposure, and controllability. This is exactly the kind of step that should be handled deterministically in software. A model may draft the row, but ASIL derivation should not depend on an LLM's free-form answer. If the same S, E, and C values are entered twice, the same ASIL result should appear twice.

Step 7: Write Safety Goals

A safety goal expresses the top-level safety requirement needed to prevent or mitigate the hazardous event. It should be clear, testable at the right level of abstraction, and traceable back to the HARA row. A weak safety goal often repeats the hazard without describing the safety intent. A strong safety goal defines what must be prevented, limited, detected, or controlled.

Teams should avoid writing safety goals as implementation details too early. The safety goal belongs above the technical safety concept. It should create a bridge from hazard analysis to functional safety concept and later technical requirements. For a deeper practical view, see our supporting article on writing safety goals from HARA outputs.

Step 8: Link HARA to Requirements Traceability

A HARA becomes powerful when it is connected to the rest of the safety lifecycle. Hazardous events should trace to safety goals. Safety goals should trace to functional safety requirements. Those requirements should trace to technical safety requirements, design elements, verification evidence, and review decisions. Without this chain, teams end up with approved documents that are difficult to defend when designs change.

Traceability is especially important when the system evolves. If an item boundary changes, a safety goal is modified, or a requirement is split, the team should be able to see which hazards, assumptions, and evidence are affected. This is one reason dedicated HARA software can outperform spreadsheet-only workflows in serious programs.

Step 9: Review, Challenge, and Approve

HARA review is not a ceremonial sign-off. Reviewers should challenge missing operating situations, inconsistent ratings, weak assumptions, unclear hazards, duplicated safety goals, and rows that have drifted from the item definition. A governed workflow should make unresolved items visible and should prevent unfinished analysis from becoming exported compliance evidence.

This is where workflow state matters. Draft, edited, needs review, approved, rejected, and superseded are not cosmetic statuses. They make the lifecycle of the artifact visible. For AI-assisted HARA, this control is even more important because teams need to distinguish between generated suggestions and reviewed engineering decisions.

Common HARA Mistakes

Where AI-Assisted HARA Tools Help

AI-assisted HARA tools can reduce blank-page work, suggest candidate hazards, normalize language, surface missing operational situations, and help engineers move faster through first drafts. The value is not that AI makes safety decisions. The value is that AI can prepare structured material for expert review.

The best architecture keeps probabilistic generation away from final safety logic. SafeForge is designed around that principle: AI-assisted drafting, deterministic checks, human review, approval workflow, and traceability from project context through approved artifacts. That combination makes the platform useful for speed and still compatible with regulated engineering discipline.

HARA Tool Selection Checklist

When evaluating HARA software or ISO 26262 tools, look beyond whether the tool can create a table. Ask whether it supports item definition context, reusable scenario libraries, deterministic ASIL derivation, reviewer assignment, approval states, audit history, export control, requirements traceability, and integration with cybersecurity workflows such as TARA. Also ask how the tool separates AI suggestions from final engineering decisions.

For small teams and startups, the right tool should also reduce setup burden. Legacy ALM platforms can be powerful, but they may require heavy configuration before they deliver value. The best functional safety workflow is one your team can actually adopt early, then scale as the program matures.

FAQs About HARA

Next Articles in This Cluster

This HARA guide is the pillar page for a broader ISO 26262 topic cluster. Continue with our articles on how to write safety goals from HARA outputs, ASIL decomposition explained with examples, traceability in ISO 26262, what a safety case is, and why HARA templates are not the same as governed HARA software.