HARA: Hazard Analysis & Risk Assessment (ISO 26262) Step-by-Step Guide

Hello, automotive safety engineers and functional safety professionals! HARA (Hazard Analysis and Risk Assessment) is one of the most critical activities in the entire ISO 26262 functional safety lifecycle. It is the process where you identify what can go wrong with your system, assess how dangerous each failure scenario is, and define the safety goals that will guide every downstream development decision – from system architecture to hardware metrics to software testing coverage.

In this comprehensive step-by-step guide at PiEmbSysTech, we will walk you through the complete HARA process from start to finish – covering the prerequisites, the methodology, the detailed classification of Severity, Exposure, and Controllability, the ASIL determination, the derivation of safety goals, and a fully worked example using an Electric Power Steering (EPS) system. We will also provide a HARA table template and discuss common pitfalls, best practices, and the tools used in industry. Let us begin.

1. What is HARA? – Definition and Purpose

HARA (Hazard Analysis and Risk Assessment) is the systematic process defined in ISO 26262 Part 3, Clause 7 for identifying potential hazards caused by malfunctioning behavior of E/E (Electrical/Electronic) systems in vehicles, assessing the risk associated with each hazardous event, and determining the safety goals and ASIL (Automotive Safety Integrity Level) classifications needed to reduce risk to an acceptable level.

The fundamental question HARA answers is: “What could go wrong with this E/E function, how bad could it be, and what safety goals do we need to prevent unacceptable harm?”

HARA has three primary objectives: first, to identify and classify all hazardous events that could arise from malfunctioning behavior of the item under analysis; second, to assign an ASIL to each hazardous event based on its severity, exposure probability, and controllability; and third, to formulate safety goals – the top-level safety requirements that prevent or mitigate each identified hazard.

2. Where HARA Fits in the ISO 26262 Safety Lifecycle

HARA is performed during the Concept Phase of the ISO 26262 safety lifecycle, after the item definition has been established and before the Functional Safety Concept is developed. Its position in the V-model is at the very top – the outputs of HARA (safety goals and ASIL classifications) cascade down through every subsequent development phase.

The flow is: Item Definition → HARA → Safety Goals → Functional Safety Concept → Technical Safety Concept → Hardware/Software Development → Integration → Validation. Everything after HARA depends on the quality and completeness of the HARA. If a hazard is missed during HARA, no downstream process will address it. If an ASIL is classified incorrectly, all subsequent development effort will be either insufficient (creating a safety risk) or excessive (wasting resources).

3. Prerequisites for HARA – The Item Definition

Before HARA can begin, a complete item definition must be established. The item definition describes the system or function being analyzed and provides the context needed for hazard identification. ISO 26262 requires the item definition to include the following eight elements:

1. Functional description: What does the item do? Describe all functions and operating modes (e.g., “The EPS provides speed-dependent steering assist torque to the driver based on measured steering torque and vehicle speed”).

2. Interfaces and interactions: What inputs does the item receive and what outputs does it produce? What other vehicle systems does it interact with? (e.g., vehicle speed signal from CAN bus, driver steering torque sensor input, electric motor torque output).

3. Environmental conditions: What environmental conditions affect the item? (temperature range, vibration, EMC environment, water ingress exposure).

4. Legal requirements: What regulations apply? (e.g., UN Regulation No. 79 for steering systems).

5. Known hazards: Any hazards already identified from prior designs, field experience, or similar systems.

6. Boundary of the item: What is included in the analysis scope and what is explicitly excluded?

7. Assumptions: Documented assumptions about operating conditions, driver behavior, and system environment.

8. Preliminary architecture (if available): A high-level view of how the function is implemented, which can help identify failure modes – though HARA should be performed at the functional level, independent of implementation.

4. Who Performs the HARA? – Team Composition

HARA should not be performed by a single engineer working alone. The standard requires a multidisciplinary team approach because the analysis requires both deep system knowledge and safety engineering expertise. A well-composed HARA team typically includes a functional safety engineer (who understands the ISO 26262 methodology, ASIL classification, and safety goal formulation), system engineers (who understand the item’s functions, interfaces, and behavior in detail), domain experts (who understand the vehicle dynamics, driver behavior, and real-world operational scenarios relevant to the item), and a HARA facilitator (who guides the structured brainstorming sessions and ensures consistency across hazardous events).

Optionally, the team may include human factors specialists (particularly valuable for controllability assessment), test engineers (who can provide insight into real failure behaviors observed in testing), and field quality engineers (who can contribute knowledge from warranty claims and field failures on similar systems).

5. Step 1 – Identify Operational Situations

The first step in the HARA process is to systematically identify all relevant operational situations – the driving scenarios and conditions in which the vehicle (and the item under analysis) will operate. Operational situations define the context in which a malfunction could lead to a hazard.

Typical categories of operational situations include:

Category	Examples of Operational Situations
Speed range	Standstill, parking (<10 km/h), urban (30–60 km/h), rural (60–100 km/h), highway (100–200+ km/h)
Road type	Straight road, curved road, intersection, roundabout, highway on-ramp, narrow lane
Traffic density	No traffic, light traffic, heavy traffic, stop-and-go, pedestrian area
Road surface	Dry asphalt, wet road, icy road, gravel, uneven surface, speed bump
Weather and visibility	Clear day, rain, fog, snow, nighttime, glare from sun
Driver state	Attentive, distracted, fatigued, hands on wheel, one hand on wheel
Vehicle maneuver	Straight driving, lane change, overtaking, braking, accelerating, cornering, parking

The goal is to identify operational situations that are relevant to the item – that is, situations where a malfunction of the item could plausibly lead to a hazardous event. You do not need an exhaustive list of every conceivable scenario – the focus should be on situations that are relevant to the item’s function and that represent the range of conditions the vehicle will encounter.

6. Step 2 – Identify Malfunctioning Behaviors

The second step is to identify all malfunctioning behaviors of the item – the ways in which the item’s function could deviate from its intended behavior. Malfunctioning behaviors are analyzed at the functional level, not the component level – we ask “what could the function do wrong?” not “which component could fail?”

Common malfunctioning behavior categories include:

Loss of function: The function stops operating entirely. Example: EPS assist torque drops to zero – the driver loses power steering.

Unintended activation: The function activates when it should not. Example: EPS provides assist torque when the driver is not turning the steering wheel.

Incorrect output (too much): The function provides excessive output. Example: EPS provides more assist torque than requested – the steering turns more than the driver intended.

Incorrect output (too little): The function provides insufficient output. Example: EPS provides less assist torque than requested – the steering feels heavier than expected.

Incorrect output (wrong direction): The function provides output in the opposite direction. Example: EPS provides assist torque in the opposite direction to the driver’s input – the steering turns against the driver.

Intermittent or oscillating behavior: The function oscillates or behaves erratically. Example: EPS assist torque oscillates rapidly – the steering vibrates or judders.

Delayed or late response: The function responds slower than expected. Example: EPS assist torque is delayed – the steering feels sluggish during quick maneuvers.

HAZOP guide words (no, more, less, reverse, part of, other than, early, late, before, after) are commonly used to systematically generate malfunctioning behaviors for each item function.

7. Step 3 – Combine into Hazardous Events

A hazardous event is the combination of a malfunctioning behavior with a specific operational situation. Not every combination of malfunction and operational situation produces a hazardous event – only combinations where the malfunction could plausibly lead to a hazard (potential harm to people) are recorded.

For example, “loss of EPS assist” combined with “driving straight on highway” is a hazardous event because the sudden increase in steering effort could cause the driver to deviate from the lane. “Loss of EPS assist” combined with “vehicle parked with ignition off” is not a hazardous event because no harm can result.

The HARA team systematically considers each malfunctioning behavior against each relevant operational situation and documents the hazardous events in a structured table. Each hazardous event entry includes a description of the malfunction, the operational situation, the resulting hazard (what could happen), and the potential harm (injury to people).

8. Step 4 – Classify Severity (S)

Severity classifies the worst-case potential injury to vehicle occupants and other road users if the hazardous event results in an accident. ISO 26262 defines four severity levels:

Level	Description	Injury Examples
S0	No injuries	No human harm possible from the hazardous event
S1	Light and moderate injuries	Bruises, minor whiplash, small cuts; treated and released
S2	Severe and life-threatening injuries (survival probable)	Bone fractures, internal injuries, concussion; hospitalization required but survival probable
S3	Life-threatening injuries (survival uncertain) or fatal	Severe head trauma, spinal cord injury, fatal collision; survival uncertain

Severity is always assessed at the worst-case realistic outcome. If a malfunction at highway speed could realistically cause a head-on collision with oncoming traffic, the severity is S3 – even if many instances of the same malfunction might result in less severe outcomes. The SAE J2980 recommended practice provides additional guidance for severity assessment.

9. Step 5 – Classify Exposure (E)

Exposure classifies how frequently the specific operational situation (in which the hazardous event occurs) is encountered by the general driver population.

Level	Description	Approximate Duration/Frequency
E0	Incredible	Essentially never encountered in the vehicle’s lifetime
E1	Very low probability	<1% of average operating time
E2	Low probability	1% to <10% of average operating time
E3	Medium probability	~10% of average operating time
E4	High probability	>10% of average operating time

Exposure is assessed for the operational situation, not for the probability of the malfunction occurring. The question is “how often is the vehicle in this driving scenario?” – not “how often does the malfunction happen?”

10. Step 6 – Classify Controllability (C)

Controllability classifies the probability that the driver (or other road users) can take timely corrective action to prevent the harm once the hazardous event occurs.

Level	Description	Driver Population Able to Control
C0	Controllable in general	Essentially all drivers can handle it
C1	Simply controllable	≥99% of drivers can avoid harm
C2	Normally controllable	≥90% of drivers can avoid harm
C3	Difficult to control or uncontrollable	<90% of drivers can avoid harm

Controllability must consider the general driver population – including distracted, fatigued, elderly, and inexperienced drivers – not just expert test drivers. For autonomous vehicles with no human driver, controllability is effectively C3 for all hazardous events.

11. Step 7 – Determine the ASIL

Once S, E, and C are classified for each hazardous event, the ASIL is determined by looking up the combination in the standard’s determination table. If any parameter is at its lowest level (S0, E0, or C0), the result is automatically QM. The complete lookup table is provided in our ASIL Levels Explained article. The highest combination (S3 + E4 + C3) results in ASIL D. Each step down in any parameter reduces the ASIL by approximately one level.

12. Step 8 – Formulate Safety Goals

Safety goals are the top-level safety requirements derived from the HARA. Each safety goal addresses one or more hazardous events and inherits the highest ASIL among the hazardous events it addresses. Safety goals describe what must be achieved to prevent the hazard, not how it will be achieved (the “how” comes in the Functional Safety Concept).

Good safety goal examples:

“The EPS shall not apply unintended steering torque.” Clear, measurable, addresses the hazard directly.

“The EPS shall provide steering assist within the specified torque range.” – Quantifiable, testable.

“The EPS shall not cause sudden loss of steering assist without providing a warning to the driver.” – Addresses the degradation behavior.

Poor safety goal examples:

“The EPS shall be safe.” – Vague, not testable.

“The EPS software shall not have bugs.” – Implementation-specific, not a safety goal.

“The microcontroller shall not fail.” – Component-specific, not at the item level.

Each safety goal must also specify its safe state – the operating mode of the item that does not contribute to the hazardous event. The safe state may be the de-energized state (motor off), a reduced-capability state (reduced assist), or a continued-operation state with degraded performance.

13. Step 9 – Define Safe States and FTTI

For each safety goal, two additional attributes must be defined:

Safe state: The mode of operation that ensures no contribution to the hazardous event. For an EPS system, the safe state might be “no electric assist (manual steering)” – the driver can still steer mechanically. For a brake-by-wire system, the safe state might be “maintain hydraulic backup braking.”

FTTI (Fault Tolerant Time Interval): The maximum time between the occurrence of a fault and the item reaching the safe state before the hazardous event occurs. FTTI is a critical design constraint – it determines how quickly the safety mechanism must detect and respond to faults. For a steering system at highway speed, the FTTI may be on the order of milliseconds to a few hundred milliseconds, because the vehicle’s trajectory changes rapidly. The FTTI is composed of the fault detection time + fault reaction time + safe state transition time.

14. Step 10 – Verify and Review the HARA

The completed HARA must be verified through a structured review process. ISO 26262 requires verification of the HARA to ensure completeness (all relevant hazardous events have been identified), consistency (S, E, C classifications are applied consistently across all hazardous events), correctness (the classifications are technically justified), and traceability (each safety goal is traceable to the hazardous events it addresses). The independence level of the review depends on the ASIL – ASIL D safety goals require independent review at the I2 level (person from a different team) or I3 level (external third party).

15. Complete Worked Example – Electric Power Steering (EPS) HARA

Let us walk through a complete HARA for an Electric Power Steering (EPS) system – one of the most common ASIL D systems in modern vehicles.

Item Definition Summary

The EPS provides speed-dependent electric steering assist torque to reduce driver steering effort. It receives inputs from a steering torque sensor, vehicle speed signal (via CAN), and steering angle sensor, and outputs electric motor torque to the steering column via an ECU-controlled brushless motor.

Selected Operational Situations

For this example, we consider: highway driving at high speed (>100 km/h, straight road, medium traffic), urban driving at moderate speed (30–60 km/h, intersections), parking maneuver at very low speed (<10 km/h), and cornering on a curved road at moderate speed (60–100 km/h).

Malfunctioning Behaviors Identified

M1: Loss of EPS assist (no assist torque). M2: Unintended steering torque (EPS applies torque without driver input). M3: Excessive assist torque (EPS over-assists). M4: Assist torque in wrong direction (EPS opposes driver).

Complete HARA Table

ID	Malfunction	Operational Situation	Hazardous Event	S	E	C	ASIL
HE-01	M1: Loss of EPS assist	Highway, >100 km/h, medium traffic	Driver cannot steer effectively; vehicle departs lane into adjacent traffic	S3	E4	C2	C
HE-02	M2: Unintended steering torque	Highway, >100 km/h, medium traffic	Vehicle suddenly turns into oncoming lane or barrier; driver may not overcome motor torque	S3	E4	C3	D
HE-03	M2: Unintended steering torque	Urban, 30–60 km/h, intersection	Vehicle turns unexpectedly into pedestrians or cross-traffic	S3	E4	C3	D
HE-04	M1: Loss of EPS assist	Parking, <10 km/h	Steering becomes very heavy; minor contact with curb or obstacle at low speed	S1	E3	C1	QM
HE-05	M4: Assist torque wrong direction	Cornering, 60–100 km/h, curved road	Vehicle steers out of curve into opposing lane or off road; very difficult to control	S3	E3	C3	C
HE-06	M3: Excessive assist torque	Highway, >100 km/h, lane change	Vehicle over-steers during lane change; enters adjacent lane too fast, collision risk	S3	E4	C2	C

Derived Safety Goals

Safety Goal	ASIL	Safe State	Addresses HE
SG-01: The EPS shall not apply unintended steering torque	ASIL D	EPS motor de-energized (no assist)	HE-02, HE-03
SG-02: The EPS shall provide steering assist within the specified torque range and direction	ASIL C	EPS motor de-energized (manual steering)	HE-01, HE-05, HE-06

16. HARA Table Template – Column-by-Column Explanation

A standard HARA table used in industry contains the following columns:

Column	Content	Example
HE-ID	Unique identifier for each hazardous event	HE-001
Item / Function	The system function under analysis	EPS steering assist
Malfunctioning Behavior	How the function deviates from intended behavior	Loss of assist torque
Operational Situation	The driving scenario context	Highway, >100 km/h, medium traffic
Hazardous Event Description	What happens when malfunction meets situation	Vehicle departs lane due to heavy steering
Potential Harm	Injury consequence to people	Side collision with adjacent vehicle — severe to fatal injuries
Severity (S)	S0, S1, S2, or S3	S3
Exposure (E)	E0, E1, E2, E3, or E4	E4
Controllability (C)	C0, C1, C2, or C3	C2
ASIL	QM, A, B, C, or D	ASIL C
Safety Goal Reference	Link to the safety goal addressing this HE	SG-02
Rationale / Justification	Justification for S, E, C classification	S3: Highway collision can be fatal. E4: Highway driving >10% of operating time. C2: Most drivers can compensate with increased steering effort.

17. HARA Methods – HAZOP vs STPA vs Brainstorming

Several structured methods can be used to conduct the hazard identification step of HARA:

HAZOP (Hazard and Operability Analysis): The most commonly used method in automotive HARA. HAZOP uses guide words (no, more, less, reverse, part of, other than, early, late) applied to each system function to systematically generate malfunctioning behaviors. HAZOP is well-established, widely understood, and produces comprehensive results. It is particularly effective for systems with clearly defined input-output relationships.

STPA (Systems-Theoretic Process Analysis): A newer method developed at MIT that focuses on identifying unsafe control actions rather than component failures. STPA considers the system as a control structure and identifies hazards that arise from inadequate control — including missing controls, incorrect controls, and controls applied at the wrong time. STPA is particularly effective for complex systems with multiple interacting controllers, including ADAS and autonomous driving functions.

Brainstorming / Expert Judgment: Structured brainstorming sessions with domain experts. While less formal than HAZOP or STPA, this approach leverages deep experience and can identify hazards that structured methods might miss. Best used in combination with a structured method, not as a standalone approach.

Failure Mode and Effects Analysis (FMEA): While FMEA is primarily used for detailed failure analysis at the component level (in Part 5 hardware development), its principles of systematically considering failure modes can inform the HARA process at the functional level.

18. Industry Tools for HARA

HARA can be performed using various tools, from simple spreadsheets to dedicated functional safety platforms:

Microsoft Excel / Google Sheets: The most widely used approach, especially in smaller organizations. A well-structured HARA template in Excel can be effective for moderate-complexity items. Limitations include lack of traceability automation, version control challenges, and difficulty scaling to large multi-item analyses.

ENCO SOX: A dedicated model-based E/E system development tool that supports HARA as part of its ISO 26262 workflow, including automated ASIL calculation and traceability to downstream safety requirements.

Medini Analyze (Ansys): A leading functional safety analysis tool that supports HARA, FMEA, FTA, and FMEDA with integrated traceability. Medini provides a structured HARA worksheet with automated ASIL determination.

IBM DOORS / Polarion / Jama Connect: Requirements management tools that can be configured with HARA templates and provide traceability from safety goals through safety requirements to implementation and test cases.

APIS IQ-Software: Supports FMEA/FMEDA and can be used for HARA-adjacent analysis with risk classification.

19. Common HARA Mistakes and How to Avoid Them

Mistake 1: Starting HARA without a complete item definition. Without a clear understanding of what the item does, its interfaces, and its operating conditions, hazard identification will be incomplete. Always complete the item definition first.

Mistake 2: Analyzing at the component level instead of the functional level. HARA should identify malfunctioning behaviors (what the function does wrong), not component failures (which chip fails). Component-level analysis comes later in FMEA/FMEDA. At the HARA level, ask “what if steering assist goes in the wrong direction?” not “what if MOSFET Q3 short-circuits?”

Mistake 3: Confusing Exposure with probability of malfunction. Exposure classifies how often the operational situation occurs — not how likely the malfunction is. The malfunction probability is addressed separately through hardware metrics (PMHF) and systematic fault avoidance.

Mistake 4: Being too conservative with every classification. Classifying every parameter at the highest level “to be safe” results in inflated ASILs that waste development resources. Each classification must be justified with a technical rationale. Over-classification is not conservative – it is incorrect.

Mistake 5: Not considering all relevant operational situations. Missing an operational situation (such as cornering, or driving with a trailer) can cause hazardous events to be missed entirely. Use a structured checklist of operational situation categories.

Mistake 6: Performing HARA alone. A single engineer performing HARA will inevitably miss hazards due to individual blind spots. HARA requires a multidisciplinary team with diverse expertise.

Mistake 7: Not documenting the rationale. If the S, E, C classification rationale is not recorded, the HARA cannot be defended in a review or audit. Every classification must include a written justification explaining why that specific level was chosen.

20. Best Practices for a Robust HARA

Use a structured method: HAZOP is the most widely used and well-proven method for automotive HARA. Apply guide words systematically to each function. For complex ADAS systems, consider STPA as a complementary method.

Involve the right people: Include system engineers who know the item deeply, safety engineers who know the methodology, and domain experts who understand real-world driving scenarios. Include vehicle dynamics expertise for chassis systems.

Iterate: HARA is not a one-time activity. As the design evolves and more information becomes available, the HARA should be reviewed and updated. New operational scenarios may be identified, or controllability assessments may change based on testing results.

Leverage prior art: If similar systems have been analyzed before (either within your organization or in published literature), use those analyses as a starting point. SAE J2980 provides additional guidance for S, E, C classification for vehicle motion control systems.

Ensure traceability: Every safety goal must trace to the hazardous events it addresses. Every hazardous event must trace to the malfunction and operational situation it combines. This traceability is audited during the functional safety assessment.

Review by independent reviewers: The HARA for ASIL C and D safety goals should be reviewed by persons independent of the HARA team. Fresh eyes catch blind spots.

21. Frequently Asked Questions

Q1: How many hazardous events should a typical HARA have?

It depends on the complexity of the item. A simple item (like a seat heater) might have 5–15 hazardous events. A complex chassis system (like EPS or ESC) might have 30–80+ hazardous events. There is no fixed number – completeness is what matters.

Q2: Who is responsible for performing the HARA – OEM or supplier?

The HARA is performed at the vehicle level and is typically the responsibility of the OEM or the system-level Tier-1 supplier. A component supplier (ECU, sensor, actuator) does not perform HARA because they do not have the vehicle-level context needed for hazard identification. However, the ASIL classification resulting from HARA is communicated to suppliers through the Development Interface Agreement.

Q3: Can the ASIL change after the HARA is completed?

Yes. The HARA is a living document that should be updated when significant design changes occur, when new operational scenarios are identified, when testing reveals that controllability was over- or under-estimated, or when field data provides new information about exposure or severity. The ASIL may increase or decrease as a result of these updates.

Q4: What is the relationship between HARA and FMEA?

HARA and FMEA are complementary but operate at different levels. HARA operates at the functional level during the concept phase — it identifies hazardous events and determines ASILs. FMEA operates at the component level during detailed design – it identifies how specific components can fail and whether safety mechanisms detect those failures. HARA defines what must be safe. FMEA verifies how the design achieves that safety.

Q5: What if the same hazardous event has different ASILs in different operational situations?

This is expected. “Loss of EPS assist at highway speed” and “loss of EPS assist while parking” are different hazardous events with different E and C classifications, resulting in different ASILs. The safety goal inherits the highest ASIL among all hazardous events it addresses.

Q6: Is HARA only for ISO 26262?

The HARA methodology defined in ISO 26262 is specific to automotive, but similar hazard analysis processes exist in other safety standards – FHA (Functional Hazard Assessment) in aerospace (ARP 4761), HAZOP in process industry (IEC 61882), and risk assessment processes in IEC 61508 for general industrial applications. The core principles of hazard identification and risk classification are universal across safety-critical industries.

22. Conclusion

HARA (Hazard Analysis and Risk Assessment) is the foundation of the entire ISO 26262 functional safety lifecycle. Every downstream activity – from the Functional Safety Concept to hardware metrics to software testing – depends on the quality and completeness of the HARA. By systematically identifying operational situations, malfunctioning behaviors, and hazardous events, and rigorously classifying Severity, Exposure, and Controllability to determine the ASIL, the HARA ensures that development effort is directed proportionally to actual safety risk.

The key to a successful HARA is combining a structured methodology (HAZOP or STPA), the right team (multidisciplinary, with deep system and domain knowledge), documented rationale for every classification, and a willingness to iterate as the design matures. HARA done well is the strongest foundation for a safe vehicle. HARA done poorly undermines everything built upon it.

This article is part of our comprehensive ISO 26262 series at PiEmbSysTech. For the foundational theory behind HARA, see our Part 3 – Concept Phase article. For detailed ASIL classification guidance, see ASIL Levels Explained.

Stay safe. Stay systematic. Keep engineering the future.

– The PiEmbSysTech Team