Understand how to apply HAZOP in Engineering: design intent, study nodes, guide words, deviations, causes, consequences, safeguards, and recommendations.
Check it out!
HAZOP, short for Hazard and Operability Study, is a structured technique for analyzing risks and operability problems based on the systematic examination of deviations from design intent. The team divides the system into manageable parts, defines relevant parameters, and uses guide words to trigger questions such as “what happens if there is more pressure?”, “no flow?”, “reverse flow?”, “lower temperature?” or “operation different from intended?”. For each plausible deviation, causes, consequences, safeguards, and recommendations are analyzed.
IEC 61882:2016 is the specific international reference for HAZOP studies. It provides guidance on definition, preparation, examination sessions, documentation, and follow-up. In Engineering, HAZOP should not be treated as a generic brainstorming meeting or as simply filling out a spreadsheet. The value of the technique depends on clear design intent, a competent multidisciplinary team, well-defined study nodes, appropriate guide words, consistent records, and subsequent treatment of recommendations.
What Is HAZOP and What Problem Does It Solve?
HAZOP was developed to systematically investigate how a system may deviate from its intended behavior and what risks or operability problems may result from those deviations. Its starting point is not a prior list of failures, but the design intent: what each part of the system is expected to do under defined conditions.
The technique is particularly powerful when system behavior depends on variables, sequences, flows, states, interlocks, or interfaces. Instead of asking only “what can go wrong?”, the facilitator leads the team through structured combinations of guide word + parameter, turning the analysis into a repeatable process.
Examples of parameters include flow, pressure, temperature, level, voltage, current, flow rate, concentration, speed, sequence, time, composition, availability, communication, or signal. Guide words introduce deviations such as none, more, less, part of, as well as, reverse, before, after, or other than — always adapted to the technical context.
When design intent, interfaces, and operating criteria are not yet sufficiently defined, HAZOP exposes a gap that precedes the risk analysis itself: the project needs to consolidate requirements and decisions before deviations can be assessed consistently.
Design Intent: The Reference for Recognizing a Deviation
Without clear design intent, there is no high-quality HAZOP. The team needs to know the expected function of the node, normal operating conditions, acceptable limits, existing interfaces, and which operating states need to be considered.
Intent is not limited to a nominal value. In a pumping circuit, for example, it may involve delivering a specified flow rate between two points, maintaining pressure within a range, preventing backflow, operating in normal and standby modes, and preserving safe conditions during startup, shutdown, and maintenance.
In electrical systems, the intent may involve feeding a bus from a specified source, transferring load under specific conditions, maintaining protection selectivity, preventing unintended paralleling, and preserving continuity for critical loads. In automation, it may involve receiving a valid signal, executing logic, issuing a command, and positioning an actuator within a defined time.
When requirements, diagrams, cause-and-effect lists, operating philosophy, or protection criteria are incomplete, HAZOP tends to expose the documentation deficiency even before the risk analysis is concluded. This is useful: gaps in design intent are, in themselves, engineering and integration risks.
Study Nodes: How to Divide the System
A complete HAZOP needs to break the system down into units of analysis known in many contexts as study nodes. The goal is to select sections homogeneous enough for design intent and parameters to be discussed coherently.
A node that is too large produces vague discussions and mixes different functions. A node that is too small increases the number of combinations without proportional benefit, making the study slow and repetitive.
Boundaries may follow equipment, process sections, functions, subsystems, operating modes, sequence steps, or interfaces. The criterion should consider how the system actually works and where changes in intent or conditions alter risk.
Before the sessions, the study leader should prepare the node list, applicable documents, intent for each node, and relevant parameters. This preparation reduces unproductive time and improves consistency between sessions.
Guide Words: How HAZOP Triggers Deviations
Guide words are systematic prompts used to explore variations from design intent. They should not be applied mechanically to every parameter. The facilitator selects combinations that make sense for the system being analyzed.
Some typical combinations are:
| Guide word | Possible interpretation | Example |
| None | absence of the function or parameter | no flow, no signal |
| More | value above intended | more pressure, more voltage |
| Less | value below intended | less flow rate, lower level |
| Reverse | opposite direction or logic | reverse flow, reverse sequence |
| Part of | incomplete composition | part of the supply available |
| As well as | additional undesired condition | contaminant present, additional signal |
| Before | premature occurrence | command before permissive |
| After | late occurrence | transfer after allowable limit |
| Other than | state different from intended | wrong equipment in operation |
The objective is not to fill every possible cell, but to use guide words to avoid relying exclusively on the memory or individual experience of the team.
Structure of a HAZOP Record Row
A record row needs to preserve the team’s reasoning. A robust structure normally contains:
- node or item analyzed;
- design intent;
- parameter;
- guide word;
- deviation;
- plausible causes;
- consequences;
- existing safeguards;
- risk assessment, when adopted;
- recommendation or action;
- owner and due date;
- status and closure evidence.
The spreadsheet is not the HAZOP; it is the memory of the study. If the record does not allow someone to reconstruct why a recommendation was made, traceability is insufficient.
How to Conduct a HAZOP Step by Step
1. Define Objective and Scope
The study needs to state which systems, phases, operating modes, and types of risk are included. A HAZOP performed during Basic Engineering Design may have a different objective from a pre-startup review, a modification review, or a procedural analysis.
Exclusions should also be recorded. Interfaces outside the scope need a defined owner and treatment because many significant risks arise precisely at system boundaries.
2. Gather Input Documentation
Documents vary by discipline. They may include PFDs, P&IDs, single-line diagrams, functional diagrams, I/O lists, cause-and-effect matrices, design descriptions, control philosophy, datasheets, specifications, layouts, procedures, interlock matrices, protection requirements, and operating information.
The documentation needs a maturity level compatible with the purpose of the study. If the baseline changes every day, the analysis quickly becomes obsolete.
3. Form the Team
HAZOP is a group technique. The team should bring together knowledge of design, operations, process, automation, electrical, mechanical, safety, maintenance, and other disciplines required by the system. Not all disciplines need to attend every session, but relevant knowledge must be represented.
Typical roles include leader or facilitator, secretary or recorder, and specialists. The facilitator leads the technique and controls the pace; they should not dominate all technical answers or steer the team toward predetermined conclusions.
4. Prepare Nodes and Design Intent
Before the session, the study structure should be ready. This allows the meeting to focus on analysis rather than on discovering which document to use or where each section begins.
5. Apply Guide Words and Parameters
For each node, the team selects relevant combinations. The deviation should be stated clearly, without confusing a consequence with a cause.
6. Identify Causes
The team asks what could produce the deviation. Causes may involve equipment failure, configuration error, utility failure, incorrect operation, signal loss, protection failure, blockage, external condition, maintenance, common-cause failure, or interaction with another system.
7. Identify Consequences
Consequences should be considered without automatically assuming safeguards will function. This separation helps the team understand the intrinsic severity of the scenario and the actual role of controls.
8. Record Existing Safeguards
Safeguards need to exist in the actual architecture or operation. A future action is not an existing safeguard. Likewise, the same function should not be counted several times if it depends on the same sensor, logic, or common element.
9. Assess Risk
Some organizations integrate a risk matrix into HAZOP. Others use specific criteria. What matters is that the assessment follows predefined criteria and is not manipulated to artificially reduce the number of recommendations.
10. Formulate Recommendations
The recommendation should respond to an identified technical need. “Assess further” or “check feasibility” tends to produce weak closure. Whenever possible, the action should state the objective, owner, due date, and expected evidence.
11. Close Actions and Verify Effectiveness
HAZOP does not end when the meeting ends. Recommendations need to be analyzed, accepted, implemented, or formally justified. Changes resulting from actions may even require revalidation of parts of the study.
A HAZOP recommendation without an owner, due date, evidence, and integration with management of change becomes only a documentation open item. Closure needs to demonstrate that the risk was effectively addressed and that affected documents were updated.
Causes, Consequences, and Safeguards: Three Layers That Must Not Be Mixed
In poorly conducted records, it is common to find a cause written as a consequence, a consequence written as a generic risk, and a safeguard described as a future action. This undermines the logic of the study.
Consider the deviation “no flow” in a cooling line. Causes may include a stopped pump, closed valve, blockage, or loss of power. Consequences may include temperature rise, reduced capacity, equipment degradation, or system shutdown. Safeguards may include an automatic standby pump, low-flow alarm, interlock, and response procedure.
A recommendation arises when safeguards are insufficient, lack adequate independence, are not evidenced, or leave risk above the acceptance criterion.
A Safeguard Is Not the Same as a Recommendation
A safeguard is an existing control in the scenario being analyzed. A recommendation is a proposed change to reduce risk, eliminate uncertainty, or resolve an operability problem.
This distinction is essential for residual-risk assessment. If the team includes as a safeguard something that has not yet been designed, procured, or installed, it artificially reduces the perceived exposure.
After implementation, the recommendation may become a safeguard — provided there is evidence that it was incorporated into the design and validated.
HAZOP and Operability Problems
Although frequently associated with process safety, HAZOP also investigates operability. A deviation may not cause an accident but may make the system unable to perform its function, complicate maintenance, prevent mode transitions, generate excessive alarms, increase recovery time, or create unintended operational dependence.
This aspect is important in Engineering Consulting because many design problems appear as availability, reliability, maintainability, and operational risks, not only as safety hazards.
A technically safe system may be operationally poor if it requires complex switching, has unclear interfaces, does not allow maintenance without downtime, or depends on human actions within time windows that are incompatible with reality.
HAZOP in Non-Process Systems
IEC 61882 presents the technique as applicable to systems and does not restrict its use to chemical plants. The adaptation, however, must respect the nature of the system.
Electrical Systems
Deviations related to voltage, current, frequency, energization, availability, switching sequence, selectivity, synchronization, grounding, supply, and protection state may be analyzed.
Automation and Control
Parameters may include signal, command, sequence, time, mode, permissive, state, communication, and actuator response. Logic failures and improper transitions can be explored without turning the study into a generic software analysis.
Data Centers
HAZOP may be selectively applied to power and cooling systems, especially for failure, transfer, redundancy, maintenance, and recovery sequences. The technique should be combined with appropriate availability and reliability methods when the question requires quantification.
Procedures
IEC 61882 itself covers procedural application. Guide words can explore steps that are omitted, performed before or after the intended point, executed in a different order, or carried out under an incorrect condition.
HAZOP vs. Bow Tie
HAZOP and Bow Tie answer different questions. HAZOP systematically works through nodes, parameters, and deviations to identify scenarios. Bow Tie deepens selected scenarios and organizes threats, the top event, consequences, and barriers.
An efficient use is to apply HAZOP for structured discovery and then develop Bow Tie for critical risks that require explicit barrier management. This avoids trying to turn HAZOP into a barrier-assurance tool and avoids using Bow Tie as a substitute for a systematic system review.
HAZOP vs. FMEA
FMEA starts from failure modes of components, functions, or processes. HAZOP starts from deviations from design intent triggered by guide words.
The techniques may find similar scenarios through different paths. FMEA tends to be natural when the system structure is component- and function-oriented; HAZOP is particularly strong in process systems, flows, variables, sequences, and operational interfaces.
The choice depends on the question, project maturity, and system type. In multidisciplinary projects, it is common to use different techniques in different subsystems.
HAZOP vs. FTA
FTA is deductive: it starts from a top event and logically decomposes combinations of causes. HAZOP is exploratory and systematic: it starts from design intent and provokes deviations.
A complex scenario identified in HAZOP may require FTA to investigate combined failures or dependencies. Likewise, FTA results may reveal areas that deserve a review of safeguards in HAZOP.
HAZOP vs. Risk Matrix
A matrix is a classification instrument. HAZOP is a scenario-identification and analysis technique. Integrating the two is useful, but HAZOP should not be reduced to filling in probability and impact.
The technical reasoning comes first: deviation, causes, consequences, safeguards. Classification is used to prioritize treatment and decision authority.
HAZOP and Management of Change
Changes in design, capacity, feedstock, logic, software, vendor, procedure, operating sequence, or interface may invalidate assumptions from the original study.
Management of Change should assess whether the impact requires partial or complete HAZOP review. Reusing an old study without checking adherence to current conditions creates a false sense of coverage.
Temporary changes also matter. Bypasses, degraded modes, provisional interventions, and startup configurations may introduce scenarios that are not present under nominal conditions.
Quality of Input Documents
HAZOP depends on documents that represent the actual design. Outdated diagrams, inconsistent cause-and-effect lists, unreviewed logic, and undefined interfaces make the session less reliable.
For this reason, a sound process includes revision control, temporary freezing of the study baseline, a list of documents used, and traceability of subsequent changes.
If the session identifies that a particular function is not sufficiently defined for analysis, the correct action may be to open an engineering item and return to it after definition — not to fill the row with an assumption.
Role of the Facilitator
The facilitator protects the methodology. They should keep focus on the node and deviation, prevent parallel discussions, ensure participation of specialists, test whether causes and consequences are plausible, and prevent the team from jumping too quickly to solutions before understanding the scenario.
They also need to recognize when a discussion requires deeper analysis outside the session. Detailed calculation, sizing, simulation, or failure investigation can become specific actions instead of consuming hours of group time without adequate data.
Role of the Secretary or Recorder
The record should be clear enough for another person to understand the reasoning later. This requires technical synthesis, terminological consistency, and verbal confirmation of the wording when necessary.
Records that are too short, such as “pump failure / shutdown / alarm / check,” do not preserve context. Records that are too long can hide the logic. Quality lies in capturing the relationships objectively.
How to Manage HAZOP Recommendations
The recommendation needs to enter a tracking system. A robust workflow includes:
- record with a unique identifier;
- owner responsible for the response;
- technical analysis and solution definition;
- due date;
- implementation;
- documentary evidence;
- effectiveness verification;
- approved closure;
- update of affected documents.
In projects, this can be integrated with the open-item system, requirements management, change control, interface matrix, design review, and commissioning.
The greatest value of HAZOP appears when critical safeguards stop being merely spreadsheet text and become verifiable requirements in design, FAT, SAT, functional testing, and integrated commissioning.
Support analysis and technical closure with Engineering Consulting →
HAZOP Across the Project Life Cycle
Conceptual and Basic Engineering
In these phases, HAZOP helps influence architecture before changes become expensive. The level of detail needs to match project maturity; components that are not yet defined should not be analyzed as though they were finalized.
Detailed Engineering
With greater detail, the study can verify logic, interlocks, equipment, interfaces, and specific operating conditions.
Procurement
Vendor changes and proprietary solutions may alter assumptions. Vendor documents need to be incorporated into the analysis baseline when they affect system function.
Pre-Commissioning and Commissioning
Recommendations that became requirements need to be verified through inspections, tests, FAT, SAT, functional tests, and integrated tests. Documentary closure without field evidence may be insufficient.
Operation
The study can be reviewed after changes, incidents, capacity changes, or relevant operating experience.
HAZOP and Commissioning
A powerful connection is to transform critical safeguards identified in HAZOP into test requirements. If the study depends on an alarm, interlock, trip, redundancy, transfer logic, or emergency sequence, commissioning needs to demonstrate its operation under relevant conditions.
This creates traceability between risk → safeguard → requirement → test → evidence. Without this chain, a project may close HAZOP actions through document review alone even when effectiveness depends on integrated system behavior.
Quality Indicators for a HAZOP
The number of recommendations does not measure quality. A study may produce few actions because the design is mature and safeguards are robust — or because the team was superficial.
More useful indicators include coverage of planned nodes, participation of required disciplines, percentage of overdue actions, closure time, percentage of recommendations with verified evidence, number of reopened actions, design changes after the study, and significant scenarios discovered late.
The objective is to monitor the risk-management process, not to encourage artificial production of rows.
Common Errors in HAZOP Studies
Starting Without Defined Design Intent
The session becomes a debate about how the system should work rather than an analysis of deviations.
Applying Every Guide Word Mechanically
This creates volume without value. Combinations should be technically relevant.
Accepting Generic Causes
“Human error” is rarely a sufficient explanation. The team should understand the mechanism, context, and conditions that make the error plausible.
Counting the Same Safeguard More Than Once
Functions with a common dependency do not become independent merely because they appear on different rows.
Reducing Risk With a Future Action
An unimplemented recommendation should not be treated as an existing safeguard.
Closing a Recommendation Without Evidence
“Design corrected” needs to be supported by the applicable document revision and, when necessary, by testing or inspection.
Not Reviewing the Study After Changes
A HAZOP frozen at an old revision loses alignment with the delivered system.
When HAZOP Is Not the Best Technique
HAZOP is powerful, but not universal. If the main question is to quantify the probability of a top event, FTA may be more appropriate. For component failure modes, FMEA may be more efficient. To visualize barriers for a critical scenario, Bow Tie may communicate better. For schedule and cost uncertainty, Monte Carlo addresses a different class of problem.
IEC 31010 reinforces the selection of techniques according to objective, data availability, complexity, and the decision required. Maturity in risk management appears precisely in the ability to choose the method rather than applying the same tool to everything.
Final Considerations
HAZOP is a discipline of structured reasoning about deviations. The technique starts from design intent, divides the system into nodes, uses guide words to provoke scenarios, analyzes causes and consequences, recognizes safeguards, and turns gaps into traceable recommendations.
In Engineering, its value increases when it does not end in the spreadsheet. Actions need to return to the design, requirements, management of change, procurement, and commissioning. When critical safeguards are verified by evidence and the study remains aligned with the actual configuration, HAZOP becomes an effective part of risk governance — not merely a compliance meeting.
Technical references
[1] INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 61882:2016 — Hazard and operability studies (HAZOP studies) — Application guide. Geneva: IEC, 2016. Available at: https://webstore.iec.ch/en/publication/24321.
[2] INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 31010:2019 — Risk management — Risk assessment techniques. Geneva: IEC, 2019. Available at: https://webstore.iec.ch/en/publication/59809.
[3] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 31000:2018 — Risk management — Guidelines. Geneva: ISO, 2018. Available at: https://committee.iso.org/sites/tc262/home/projects/published/iso-31000-2018-risk-management.html.
[4] UNITED STATES. Occupational Safety and Health Administration. 29 CFR 1910.119 — Process Safety Management of Highly Hazardous Chemicals. Washington, DC: OSHA. Available at: https://www.osha.gov/laws-regs/regulations/standardnumber/1910/1910.119.
Frequently asked questions
HAZOP stands for Hazard and Operability Study. It is a structured technique for examining deviations from design intent and identifying causes, consequences, safeguards, and recommendations.
IEC 61882:2016 is the specific international reference for HAZOP studies and provides guidance on application, preparation, examination sessions, documentation, and follow-up.
They are prompts used with system parameters to trigger deviations such as none, more, less, reverse, before, after, or other than. They should be applied only when technically relevant.
HAZOP starts from design intent and explores deviations using guide words; FMEA starts from failure modes of components, functions, or processes and analyzes their effects and causes.
No. HAZOP is suited to systematic scenario discovery; Bow Tie deepens selected scenarios and makes threats, the top event, consequences, and barriers explicit.
When changes in design, operation, capacity, vendor, logic, procedure, or configuration alter relevant assumptions of the study or introduce new scenarios.
Supplementary technical materials
Related solutions
- Project, Program, and Portfolio Governance
- Requirements, Evidence, and Acceptance Criteria Management
Related services
Key content on the topic
- Risk Management in Engineering Projects
- Risk Analysis in Engineering Projects
- Bow Tie in Engineering
- Risk Matrix in Engineering Projects
