What is a System Hazard Analysis?
System Hazard Analysis (SHA) is a comprehensive safety assessment method used to identify and evaluate hazards at the system level. Unlike component-level or a preliminary analysis, SHAs focus on how integrated systems behave under normal and abnormal conditions, and how failures or interactions can lead to unsafe outcomes.
SHAs are essential in industries where complex systems operate in dynamic environments—such as aerospace, rail, automotive, energy, defense, and healthcare. It helps organizations understand systemic risks, prioritize mitigations, and ensure compliance with safety standards.
Why the SHA Matters
Teams often treat the SHA as just another document required to meet the expectations of the industry and assessors; we hope that this article helps to change that perspective by highlighting the necessity and value of performing an SHA early during active development.
SHAs provide a structured approach to:
Identify hazards resulting from system-level functions, interfaces, and interactions.
Evaluate the severity and likelihood of those hazards.
Recommend design changes, safety features, or operational controls.
Support certification, regulatory approval, and stakeholder confidence.
It is performed after the Preliminary Hazard Analysis (PHA) and feeds into lower-level sub-system design decisions, Fault Tree Analysis (FTA), and Safety Requirements Allocation. SHAs are important to be completed during the early stages of system requirement and architecture refinement. For those of you asking, What about the Interface Hazard Analysis (IHA)?, the SHA is often the same level as an IHA and it is typically appropriate to combine the IHA with the SHA. This article isn’t going to go into the details of an IHA; that article will be separate.
SHA Across Industries
SHAs are used in every safety industry to drive architecture decisions for every safety system and product. They are critical in preventing late safety findings resulting in dramatically shorter design time and design cost. Whether your industries uses the term ‘SHA’ or not, you do perform a system level risk assessment that has the same intent.
Below are some examples of industries using SHAs:
Rail
Standards: EN 50126, EN 50716, IEC 62278
Aerospace
Standards: ARP4761, DO-178C, MIL-STD-882
Automotive
Standards: ISO 26262, SAE J3061
Energy & Power
Standards: IEC 61508, NERC CIP, ISO 31000
Healthcare & Medical Devices
Standards: ISO 14971, IEC 62304
Defense
Standards: MIL-STD-882E, NATO AOP-15
Key Steps in Conducting SHA
Define System Boundaries
Identify system functions, interfaces, and operational context. SHAs need to be complete with no gaps, it is the SHA author’s responsibility to ensure that each boundary of the system is clearly defined and agreed on with the applicable parties. If the end user is not yet defined or known, constraints related to the final product or system need to be created and properly documented to share with the user or integrator. This is accomplished with requirement management tools and/or user manuals.
2. Collect Inputs
A complete SHA is performed using the system requirements, system architecture description, and if applicable, past experiences from similar developments. These inputs are critical for creating a complete systematic analysis and limiting gaps when defining safety requirements early in the design process.
3. Identify Hazards
Use brainstorming, historical data, and structured techniques. Define the hazards that are expected to result from the entire lifecycle of the product or system being developed. Although there are other analyses to cover different stages of the life cycle, it is best practice to consider manufacturing, use, repair, and end of life now at the SHA stage.
Hazards are to be high level hazards, when defining the hazard, ask yourself, is this the top-level hazard for your responsibility based on the boundaries defined in the first step. If you are developing a train control system, an overspeed condition might not be the final hazard for your system, it is likely collision or derailment. The final hazard needs to be clear to any reader so the risk can be assessed properly.
Every system function and its associated requirement are to be analyzed at this stage. All possible failure modes for each function and system requirement are to be documented to demonstrate which are safety functions and which require safety functions to provide protection. This analysis is systematic and thorough with no gaps. This analysis is where you can claim a function has no effect on safety, but functions cannot be omitted until the SHA determines no further analysis is necessary.
4. Analyze Hazard Causes and Effects
Consider failure modes, environmental factors, and human interactions. Document what the effect of the failure is on the system, it is best practice to consider and document the effect at the level defined by the boundaries in your scope as well as one level above your responsibility. If your system controls the speed of a train and the effect of a failure results in the train being overspeed, the effect of the train going over speed needs to be considered and documented at the system level.
5. Assess Risk
Evaluate severity and likelihood; apply risk matrices or quantitative models. Your Safety Plan defines the risk matrix to apply throughout the entire development; these are typically defined within the applicable standard for your industry. Risk assessments at the system level can be subjective as defining probability and severity at this stage often requires additional information not yet available. It is critical document assumptions for each failure and ensure all assumptions are well thought out. The risk assessment is a direct input for planning mitigation methods.
6. Recommend Mitigations
Propose design changes, safety features, or procedural controls. Mitigations are based on the Safety Integrity Level (or equivalent). Proposed mitigations take shape as safety requirements to be injected into either the system design or lower-level sub systems, hardware, and/or software. It is important to consider how this mitigation could be implemented, verified, and validated. The best safety requirements include three parts:
the actual requirement containing a single ‘shall’ statement
A clearly defined hazard(s) the requirement is intended to mitigate
Guidance on implementing the mitigation method based on the existing system knowledge
7. Document and Review
Maintain traceability and update analysis as the system evolves. Safety requirements must be traced and tracked to ensure they are properly implemented, verified, and validated.
Reviewing each requirement with the designers is critical to ensure all parties agree on the intent of the requirement and the potential mitigation. This is why it is critical to clearly document the hazard being mitigated and provide guidance on implementation, an incorrectly implemented safety requirements is a useless safety requirement.
Final Thoughts
System Hazard Analysis is a cornerstone of modern safety engineering. It bridges the gap between early hazard identification and detailed failure analysis, ensuring that safety is built into the system from the ground up. Whether you're designing a high-speed train, a surgical robot, or a flight control system, an SHA helps you anticipate risks, protect lives, and meet regulatory expectations.