Process Safety 101 for Cybersecurity Professionals

OT Cybersecurity Fundamentals — Estimated reading time: 12–14 minutes

Introduction

Cybersecurity professionals are trained to think about:

• Threat actors
• Vulnerabilities
• Access
• Privileges
• Network paths
• Malware
• Detection
• Incident response

Process engineers think about a different set of questions:

• What can go wrong with the process?
• What hazardous material or energy could be released?
• Which initiating events can create an unsafe condition?
• Which safeguards prevent escalation?
• How independent are those safeguards?
• What happens if one or more safeguards fail?

In OT cybersecurity, these two worlds eventually meet.

A cyberattack against a control system matters because it may change the physical process.

To understand the significance of that change, cybersecurity professionals need some basic process-safety vocabulary.

---

Occupational Safety, Process Safety, and Functional Safety Are Different

The words are sometimes used interchangeably.

They should not be.

Occupational Safety

Occupational safety generally focuses on hazards affecting individual workers during routine activity.

Examples include:

• Falls
• Electrical contact
• Hand injuries
• Vehicle incidents
• Lifting hazards
• Personal protective equipment

These are important, but they are different from major process hazards.

---

Process Safety

CCPS (Center for Chemical Process Saf ety) describes process safety as a disciplined framework for managing the integrity of operating systems and processes handling hazardous substances, with a focus on preventing and controlling incidents that can release hazardous material or energy.

OSHA’s Process Safety Management framework similarly focuses on preventing or minimizing catastrophic releases of toxic, reactive, flammable, or explosive chemicals.

Process-safety events can include:

• Loss of containment
• Fire
• Explosion
• Toxic release
• Overpressure
• Runaway reaction
• Major equipment damage
• Escalating hazardous conditions

The consequences may extend well beyond the person operating the equipment.

---

Functional Safety

Functional safety is narrower.

It addresses whether safety-related functions perform correctly when required.

In the process industries, IEC 61511 provides requirements covering the design, implementation, operation, and maintenance of Safety Instrumented Systems.

Functional safety is therefore part of the broader process-safety picture.

A useful hierarchy is:

Process Safety
→ hazard prevention and mitigation across the facility

Functional Safety
→ correct performance of safety-related functions

SIS / SIF
→ instrumented means of implementing some of those functions

---

Hazard Is Not the Same as Risk

Another fundamental distinction:

Hazard

A hazard is something with the potential to cause harm.

Examples:

• Flammable hydrocarbon inventory
• High-pressure gas
• Toxic material
• Rotating machinery
• High voltage
• Extreme temperature

The hazard may exist even when the plant is operating normally.

Risk

Risk considers the possibility of the hazardous event and its consequence.

Different organizations use different quantitative or qualitative methods, but conceptually risk depends on questions such as:

What can happen? The Scenario
How severe would it be? The Consequence
How likely is the scenario? The Probability
What safeguards prevent it? The Safeguards

Cybersecurity can change those answers.

For example, unauthorized modification of a controller may create a new initiating cause or defeat a safeguard assumed by the process-safety analysis.

---

Loss of Primary Containment

One phrase cybersecurity practitioners working in oil, gas, petrochemical, or chemical facilities will encounter frequently is:

LOPC — Loss of Primary Containment.

The concept is important because many major process incidents begin when hazardous material or energy escapes from the equipment designed to contain it.

Examples could include:

• Hydrocarbon released from piping
• Gas escaping from a vessel
• Chemical released through failed containment
• Material discharged because of overpressure

The cyberattack is not itself the hazardous event.

The attack may create conditions that make the hazardous event more likely.

For example:

Cyber manipulation
→ valve opens unexpectedly
→ vessel level falls
→ hydrocarbon is released
→ ignition occurs

The cybersecurity consequence needs to be traced all the way to the process consequence.

---

Think in Layers of Protection

Industrial processes rarely rely on one control.

Risk reduction typically involves multiple layers.

Depending on the facility and scenario, these might include:

• Inherently safer design
• Normal process design
• Basic Process Control System
• Alarms and operator intervention
• Safety Instrumented Functions
• Relief devices
• Physical containment
• Fire and gas systems
• Emergency response

The important idea is:

No single layer should casually be assumed to provide all required protection.

---

HAZOP and LOPA

Cybersecurity professionals do not need to become process-safety engineers.

But they should understand what two common techniques are trying to accomplish.

HAZOP

A Hazard and Operability Study examines process deviations systematically.

The team may consider deviations such as:

• High pressure
• Low pressure
• High level
• Low level
• High flow
• Reverse flow
• High temperature

and ask:

• What could cause this?
• What would happen?
• Which safeguards exist?
• Is additional protection required?

Now consider the cybersecurity connection.

A traditional initiating cause might be:

control valve failure.

A cyber-informed discussion may ask:

Could unauthorized logic modification produce the same process deviation?

The consequence remains physical even when the initiating mechanism is digital.

---

LOPA

Layers of Protection Analysis provides a semi-quantitative way to evaluate whether protection layers provide sufficient risk reduction for a scenario.

LOPA considers the initiating event, consequence, and independent protection layers rather than simply counting every listed safeguard.

ISA describes LOPA as a method for evaluating harmful-event likelihood using initiating-event frequency and the probability of failure of independent protection layers.

This concept of independence becomes extremely important for cybersecurity.

Suppose the BPCS and a claimed protection layer:

• Use the same controller
• Share the same engineering workstation
• Depend on the same network
• Use common credentials
• Depend on the same power supply
• Can both be modified through one remote-access path

A single cyber event might affect both.

The team must therefore ask whether the assumed independence remains credible.

---

BPCS and SIS

Two terms matter enormously.

Basic Process Control System — BPCS

The BPCS controls the process during normal operation.

It may:

• Regulate pressure
• Maintain level
• Control temperature
• Sequence equipment
• Start and stop machinery
• Provide operator control

The BPCS helps keep the process where operators want it.

---

Safety Instrumented System — SIS

The SIS performs safety-related functions intended to take or maintain the process in a safe state when specified hazardous conditions occur.

A typical Safety Instrumented Function may involve:

Sensor
→ Logic Solver
→ Final Element

For example:

High-high pressure switch
→ Safety logic solver
→ Emergency shutdown valve closes

That individual function is a SIF — Safety Instrumented Function.

The SIS is the system that implements one or more SIFs.

---

Independence Matters More Than Drawing Two Boxes

It is common to hear:

“The SIS must be physically separate from the BPCS.”

That statement captures an important design intention but is too simplistic as a universal rule.

The more important engineering concept is independence.

ISA guidance explicitly addresses separation of BPCS and SIS together with their relationship, common-mode impacts, fault tolerance, device selection, and other lifecycle considerations.

Physical and logical separation can support independence.

But the real question is:

Could one failure—or one cyber compromise—defeat both the control function and the protection credited against the same hazardous event?

Examples of common dependencies might include:

• Common engineering systems
• Shared networks
• Shared accounts
• Shared infrastructure
• Shared sensors
• Shared final elements
• Common power
• Common configuration-management processes

Cybersecurity therefore adds another dimension to independence analysis.

---

SIL Does Not Mean “Security Level”

Cybersecurity practitioners should also be careful with the acronym SIL.

In functional safety:

SIL = Safety Integrity Level

It represents the required risk reduction/integrity of a safety instrumented function within the functional-safety framework.

It is not the same as an IEC 62443 Security Level.

The two concepts solve different problems.

IEC 61511 SIL

Concerned with functional safety and the integrity of the SIF.

IEC 62443 SL

Concerned with cybersecurity requirements and resistance to defined classes of cyber threat.

A system can therefore require both:

functional-safety integrity

and

cybersecurity protection

without those numbers being interchangeable.

---

Functional Safety Is a Lifecycle

A SIS is not safe merely because someone installed a certified safety PLC.

ISA/IEC 61511 treats functional safety as a lifecycle involving activities including specification, design, implementation, operation, maintenance, modification, and eventual decommissioning.

This matters for cybersecurity because modifications to:

• SIS logic
• Engineering access
• Network connections
• Firmware
• Authentication
• Remote access
• Supporting infrastructure

may affect functional-safety assumptions.

Those changes therefore cannot always be treated as routine cybersecurity administration.

They may require engineering review and Management of Change.

---

Why Cybersecurity Professionals Need This Vocabulary

Imagine a SOC detects:

“Unauthorized logic change on controller.”

That is technically useful.

But operations and engineering need to know:

• Which controller?
• What process does it affect?
• Which variables changed?
• Did the process leave its safe operating range?
• Were alarms affected?
• Was a SIF involved?
• Are credited protection layers still available?
• Can the process continue safely?

Cybersecurity teams do not need to answer all of those questions themselves.

They need to understand why the questions matter and who must be involved.

The strongest OT incident response combines:

• Cybersecurity knowledge

• Process knowledge
• Control-system knowledge
• Functional-safety knowledge

---

Key Takeaway

Process safety asks:

What hazardous event are we preventing or mitigating?

Functional safety asks:

Will the safety function perform correctly when required?

Cybersecurity adds:

Could a deliberate digital action create the hazardous condition or interfere with the safeguards intended to control it?

Once those questions meet, cybersecurity is no longer only about protecting computers.

It becomes part of protecting the process.