OT Cyber Physical Risk and Safety Guide: Integrating cyber scenarios into HAZOP, LOPA and safety studies

Process safety studies assume that failures are random and independent, but a cyber attacker can trigger an upset and disable the safeguards meant to catch it at the same time, so a plant that looks safe on its HAZOP can be unsafe under attack. The UK Health and Safety Executive says plainly in its IACS guidance that normal risk assessment processes such as HAZOP are not sufficient for cyber threats, because they do not consider multiple simultaneous contingencies or the capabilities of malicious actors. This guide shows how to run a cyber process hazard analysis (cyber PHA) that starts from existing HAZOP, LOPA and bow-tie work, identifies "hackable" scenarios where every barrier depends on programmable systems, and turns the results into engineering changes, security levels and maintenance priorities. It is for process safety engineers, control system engineers, OT security leads and the facilitators who run these workshops. Safety instrumented system controls are covered in depth in the Safety Instrumented Systems Security Guide; this guide is about the risk method that connects safety and security.

Key takeaways

• Cyber is a common cause failure. One compromise can initiate a deviation and defeat the basic process control system, alarms and a programmable safety layer together, which breaks the independence that LOPA credits rely on.
• Start from the existing PHA, not a blank sheet. The worst-case consequences and safeguards are already documented; the cyber question is which scenarios an attacker could cause and which safeguards they could defeat.
• Find the hackable scenarios. A scenario where the initiating event and every barrier run on firmware or software is the priority; Shell's ISA-TR84.00.09 based method requires at least one barrier with no cyber escalation factor for fatality scenarios.
• Prefer engineering out over securing in. Relief valves, mechanical overspeed trips and hardwired, non-programmable interlocks remove cyber risk outright; network and identity controls reduce it.
• Feed results into security levels and maintenance. The output should set IEC 62443 target security levels for zones, name the controls that protect each critical barrier, and rank those controls for maintenance like any safety-critical element.

Why HAZOP alone misses cyber risk

A HAZOP applies guide words (more, less, no, reverse, other than) to process parameters at each node, identifies causes and consequences of each deviation, and records safeguards. LOPA then estimates scenario frequency by multiplying the initiating event frequency by the probability of failure on demand (PFD) of each independent protection layer. Both assume the causes are equipment failures or human errors with estimable frequencies, and that protection layers fail independently.

The ATT&CK for ICS impact techniques describe the outcomes the study is looking for: T0831 Manipulation of Control, T0832 Manipulation of View, T0878 Alarm Suppression, T0837 Loss of Protection and T0880 Loss of Safety. The TRITON attack on a safety controller is the reference case for the last two.

What the standards and regulators expect

• IEC 61511-1 clause 8.2.4: requires a security risk assessment of the SIS, and clause 11.2.12 requires the design to be resilient against the risks identified. The cyber PHA is the natural way to deliver 8.2.4 for a process unit.
• ISA-TR84.00.09: the ISA technical report on cybersecurity related to the functional safety lifecycle, which shows how to perform that assessment; the Shell method described below is based on its 2017 edition.
• IEC 62443-3-2: security risk assessment for system design, which partitions the system into zones and conduits and assigns target security levels. Consequence data from HAZOP and LOPA is its key input; see the IEC 62443-3-2 OT Risk Assessment Guide.
• UK HSE OG86 (Edition 2): HSE's operational guidance for inspectors at major accident hazard sites. It states that following its process may meet the BS EN 61511 clause 8.2.4 requirement, assesses risk per zone based on the consequence of compromise and the zone's criticality "without taking credit for any existing cyber security countermeasures", treats any system that could defeat a SIS as part of that risk, and expects inspectors to check whether countermeasures are appropriate for the threat scenarios.
• Cyber-informed engineering: the US Department of Energy's CIE approach, backed by the 2022 National Cyber-Informed Engineering Strategy, aims to "engineer out" cyber risks from the earliest design phase and prioritise the worst consequences. The method behind it is covered in the Consequence-driven OT Risk (CCE) Guide.

The cyber PHA method step by step

The InTech description of Shell's approach, based on ISA-TR84.00.09-2017, gives a practical sequence. The steps below follow it, with the inputs and outputs a facilitator needs.

1. Review the existing PHA: take the HAZOP, LOPA and bow-tie studies for the unit and identify the worst-case health, safety, security and environment consequences. Filter to scenarios at or above the site's high-consequence threshold, typically potential fatality, major environmental release or long outage.
2. Map each safeguard to its technology: for every initiating event and barrier, record whether it is mechanical, hardwired or programmable, which controller or system implements it, and which zone it sits in. Use the asset inventory and architecture drawings; see the OT Asset Visibility Guide.
3. Identify hackable scenarios: a scenario is flagged when the initiating event and all control barriers can be compromised by a cyber attack. The InTech article gives SIS, PLC-controlled fire water pumps and fire and gas systems as examples of hackable barriers, and a pressure relief valve and a non-programmable SIF as non-hackable ones.
4. Assess cyber escalation factors: in bow-tie terms, threats and vulnerabilities against each barrier are escalation factors. Ask how each barrier could be defeated: remote engineering access, shared credentials, a writable logic solver, bypass by an operator account, alarm suppression from the HMI.
5. Rate the risk: use the site risk matrix with the usual consequence categories plus a business loss category based on time to restore production after a worst case such as ransomware on all IACS servers and workstations.
6. Add or harden barriers: where a scenario could cause a fatality, add at least one barrier with no cyber escalation factor. If that is not possible, the team assumes a higher likelihood of the top event and specifies robust countermeasures.
7. Assign criticality to cyber controls: rate each security control by the barrier it protects and put it into maintenance and testing plans.
8. Record and close out: recommendations go into the same action tracking as PHA recommendations, with owners and dates, and the study is revalidated with the PHA cycle and at every significant change.

Guide words for cyber deviations

Some teams run a short cyber pass alongside the normal HAZOP node review. The questions below adapt the familiar pattern to control system functions rather than process parameters.

Crediting protection layers in LOPA

The hardest workshop debate is how much credit a programmable layer should keep. A defensible approach, consistent with OG86's requirement to assess without assuming countermeasures, is:

Do not put a cyber "probability" in the LOPA arithmetic: there is no defensible frequency for a deliberate attack. Instead, decide which layers are independent of the cyber cause, and require the remaining risk to be acceptable with only those layers. OG86 also notes that if one zone can defeat a critical function in another, both zones are critical; its example is a BPCS zone that could defeat a SIS unless hardwired SIS enables prevent it.

Turning results into controls

The InTech article lists the mitigation types that came out of Shell's studies. Grouped by where they act:

• Engineer the hazard out: add a mechanical or hardwired barrier, a hardwired SIS enable, or a non-programmable trip where a fatality scenario has no non-hackable layer.
• Protect the barrier: software or hardware locks and separation of duties for SIS modes, trip limits and bypasses; keyswitches; data diodes for some instrument changes.
• Control identity and access: least privilege for engineering workstation accounts, password policy, and restricted and monitored remote access with periodic audits. See the OT and ICS Identity and Access Guide.
• Make changes visible: bypass management with real-time visibility and records, and audit reports checked against permit-to-work and management of change records.
• Set zone security levels: carry the consequence rating into IEC 62443 SL-T for each zone and conduit; see the IEC 62443-3-3 and 4-2 Security Levels Guide.
• Prepare to operate manually: CISA's fifth OT primary mitigation is to practise and maintain the ability to operate OT systems manually, which is the recovery side of the same scenarios. See the OT Incident Response Guide.

Running the workshop

• Team: an experienced PHA facilitator, a process engineer who knows the unit, a control and SIS engineer, an OT security specialist, operations, and maintenance. Bring the integrator for systems they manage.
• Inputs: current HAZOP and LOPA, bow-ties, SIL verification, SRS, cause and effect charts, network and zone drawings, asset inventory, remote access and account lists, recent ICS advisories for installed systems.
• Scope per session: a unit or system, not the whole site; aim for a few high-consequence scenarios per day rather than every HAZOP line.
• Outputs: list of hackable scenarios, layer credit decisions with rationale, recommendations with owners, SL-T per zone, and a register of safety-critical cyber controls.
• Sensitivity: the output is a targeting map for an attacker. Classify it, restrict distribution and keep it off general collaboration sites.

Choosing the depth

• Small sites or low hazard: a zone-level screening in the OG86 style (major accident, loss of essential service, or neither) may be enough, followed by standard controls.
• COMAH, Seveso or high-hazard units: a scenario-level cyber PHA for every scenario above the fatality threshold, revalidated with the PHA cycle.
• New projects: run cyber-informed design reviews at FEED and detailed design, when adding a mechanical barrier is cheap.

Measuring whether it works

• Percentage of high-consequence PHA scenarios assessed for cyber (target 100% for major accident scenarios).
• Number of fatality scenarios with no non-hackable barrier (target zero, or a documented risk acceptance).
• Cyber PHA recommendations closed on time, tracked alongside PHA actions.
• Safety-critical cyber controls with a test or verification in the last maintenance cycle.
• SIS bypasses and mode changes reconciled against permit-to-work and MOC each month.
• Time since last revalidation compared with the PHA revalidation interval.

Detection for these scenarios comes from monitoring logic downloads, mode changes, bypasses and remote sessions to the systems that implement critical barriers; see the OT Network Security Monitoring Guide.

Common failure patterns

• A separate security study nobody in process safety reads: without consequence data from the PHA, security ranks by asset count, and the results never change a safeguard.
• Full LOPA credit for an integrated SIS: the SIS shares a network or engineering workstation with the BPCS, so the cyber cause defeats both.
• Taking credit for existing security controls in the baseline: OG86 assesses without them, so a firewall rule cannot be the reason a zone is "not critical".
• Trying to put a number on attack frequency: invented frequencies make the arithmetic look rigorous and the conclusion arbitrary.
• Ignoring alarms and the HMI: operator response is credited even though the attacker controls what the operator sees.
• No revalidation after change: a new remote access route or a converged network quietly turns a non-hackable scenario hackable.

Framework mapping

Practitioner checklist

• Pull the current HAZOP, LOPA and bow-ties for each high-hazard unit and list scenarios above the fatality or major accident threshold.
• Record the technology, controller and zone behind every initiating event and safeguard in those scenarios.
• Flag hackable scenarios where every barrier is programmable or networked.
• Remove LOPA credit from layers that share a cyber dependency with the initiating cause.
• Require at least one non-hackable barrier for fatality scenarios, or a documented, approved alternative.
• Translate consequences into IEC 62443 target security levels for each zone and conduit.
• Register the cyber controls that protect critical barriers and include them in maintenance and testing.
• Track cyber PHA actions in the same system as PHA actions and revalidate on the PHA cycle and after MOC.
• Classify and restrict the study outputs.

Standards and references

• UK HSE: OG86 Cyber Security for Industrial Automation and Control Systems
• ISA InTech: Cyber-Related Process Hazard Analysis
• US Department of Energy: Cyber-Informed Engineering
• CISA: Primary Mitigations to Reduce Cyber Threats to Operational Technology
• MITRE ATT&CK for ICS: Loss of Safety
• MITRE ATT&CK for ICS: Loss of Protection
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Safety Instrumented Systems Security Guide · Consequence-driven OT Risk (CCE) Guide · IEC 62443-3-2 OT Risk Assessment Guide · Safety and Security Co-engineering Guide