Building One Framework from Three Standards — and Connecting Cybersecurity with Functional Safety

OT Cybersecurity Fundamentals – Estimated Reading Time 12  minutes

Note: This article presents a practical organizational integration model for OT cybersecurity, particularly for critical infrastructure and process industries. It is not an official combined NIST–ISA–IEC methodology. Using one reference does not automatically demonstrate compliance or conformance with another. Mapping a control to NIST CSF does not, by itself, demonstrate IEC 62443 conformance, and certification of an individual component does not certify the system in which it operates.

Introduction

Across the previous articles in this series, we introduced three important references for OT cybersecurity:

• NIST Cybersecurity Framework (CSF) 2.0 provides a common language for organizing and communicating cybersecurity risk.
• NIST SP 800-82 Rev. 3 provides OT-specific guidance for architectures, threats, vulnerabilities, safeguards, and control tailoring.
• ISA/IEC 62443 provides an industrial automation and control system framework covering lifecycle activities, roles, system architecture, risk assessment, zones and conduits, and security requirements.

A common question naturally follows:

Which one should an organization use?

It does not need to be an either-or decision.

These references address different layers of the same cybersecurity problem. The challenge is not that organizations use multiple standards. The challenge appears when they treat those references as competing frameworks, duplicate the same activities several times, or fail to connect governance decisions with engineering requirements.

A practical way to think about them is:

Govern with NIST CSF.
Apply OT-specific guidance with NIST SP 800-82.
Engineer and specify IACS security with ISA/IEC 62443.

For organizations operating safety-critical processes, there is another important connection.

Cybersecurity can intersect directly with functional safety.

In industries such as oil and gas, petrochemical processing, and other critical process sectors, a cyber event may affect not only production availability but also systems responsible for bringing a hazardous p rocess to a safe state.

That is where IEC 61511 enters the discussion.

IEC 61511 does not replace the three cybersecurity references. Instead, it provides the functional-safety lifecycle for Safety Instrumented Systems, or SIS, where those systems are in scope.

The objective is therefore not to create a new super-standard.

The objective is to create one practical operating model from complementary references.

---

Why Several References Are Needed

An OT cybersecurity program has to answer different types of questions.

Leadership may ask:

• Are we managing cybersecurity risk appropriately?
• Which risks require investment or executive attention?
• Who is accountable for accepting risk?
• How do we know whether the program is improving?

Cybersecurity teams may ask:

• Which safeguards should be implemented?
• How should monitoring work?
• How should remote access be controlled?
• How should vulnerabilities be managed?

Engineering and operations may ask:

• How should the control system be segmented?
• Which communications are operationally necessary?
• Can a control be implemented without disrupting production?
• What happens when a security dependency becomes unavailable?

Process-safety teams may ask:

• Could a cyber-related change affect a safety instrumented function?
• Does an SIS require separate treatment from the BPCS?
• Does the proposed change require Management of Change?
• Who is authorized to modify safety-related logic?

No single reference answers all of these questions in equal depth.

A layered approach is therefore useful.

Reference	Primary Role	Typical Question
NIST CSF 2.0	Governance and risk communication	What cybersecurity outcomes must we manage?
NIST SP 800-82 Rev. 3	OT-specific guidance and control tailoring	How should cybersecurity practices be adapted to OT?
ISA/IEC 62443	IACS engineering and lifecycle	How should security requirements be structured and implemented?
IEC 61511, where applicable	Functional safety and SIS lifecycle	How must safety instrumented functions remain dependable and protected?

Instead of asking:

“Which standard is best?”

a more useful question is:

“Which reference is best suited to the decision we are trying to make?”

---

Layer 1 — Govern with NIST CSF 2.0

The first layer is organizational governance and cybersecurity risk management.

NIST CSF 2.0 organizes cybersecurity outcomes around six Functions:

Govern → Identify → Protect → Detect → Respond → Recover

For an OT organization, these Functions provide a common structure for defining:

• Roles and responsibilities
• Risk-management objectives
• Risk acceptance and escalation
• Asset and process criticality
• Supplier and third-party expectations
• Required cybersecurity outcomes
• Current and target posture
• Improvement priorities
• Performance reporting

For example:

Govern

Who owns the OT cybersecurity program?

Who is authorized to approve remote vendor access?

Who can accept temporary cyber risk?

Who approves changes affecting critical control systems?

Identify

Which assets, software, networks, processes, suppliers, and dependencies exist?

Which systems can influence physical operation?

Which assets are safety-related?

Protect

What safeguards are required for:

• Access control
• Network segmentation
• Configuration management
• Backup and restore
• Engineering and highest privilege access
• Remote access (internal/external party)

Detect

How will the organization detect:

• Unauthorized access
• Abnormal network communication
• Unexpected configuration changes
• Changes to controller logic?

Respond

How will cybersecurity, operations, engineering, management, and safety personnel coordinate during an event?

An Incident Response Plan (IRP) specific to OT environment maybe required to cover certain aspects of OT Incident Response, including the framework to be used as the OT IR flow activities.

This OT IRP may also require several manuals related to Incident Response activities in OT, such as BCP, DRP, IT IRP, Backup and Recovery/Restore Management Procedure, Asset Criticality and Spare Part Management, etc. The discussion around some other topics related to the above entities will be covered under the future articles.

Recover

How will the organization restore not only systems, but trusted and safe operation?

NIST CSF provides the language for these outcomes.

It does not tell an engineering team exactly how to configure a PLC network, implement zones and conduits, or determine how an authentication control will affect an operational dependency.

That requires the next layer.

---

Layer 2 — Apply OT-Specific Guidance with NIST SP 800-82

A security objective may be correct in principle while its implementation is unsuitable for an OT environment.

OT systems often have requirements that differ from conventional enterprise IT:

• High availability
• Reliability requirements
• Safety dependencies
• Deterministic or time-sensitive behavior
• Long equipment lifecycles
• Legacy operating systems and devices
• Vendor dependencies
• Specialized industrial protocols
• Limited maintenance windows
• Limited computing resources

Consider a simple objective:

“Protect access to critical OT systems”

That objective makes sense. But implementing it requires additional questions:

• Where should authentication occur?
• Is MFA technically feasible?
• What happens if the identity service becomes unavailable?
• Can the PLC itself support the desired security capability?
• Should remote access terminate at a controlled access environment?
• How should vendor sessions be approved?
• Should sessions be monitored or recorded?
• Which compensating controls are required for legacy equipment?

This is where NIST SP 800-82 becomes valuable.

The principle is not:

“OT is difficult, so security should be weaker.”

The principle is:

“Security measures must reduce risk without creating unacceptable operational consequences”

A patch may remove a vulnerability but affect a critical engineering workstation.

A firewall rule may improve segmentation but interrupt an essential process dependency.

A new authentication system may strengthen access control while introducing a new single point of failure.

Security measures therefore require:

OT Context + Engineering Validation + Operational Ownership

---

Layer 3 — Engineer the IACS with ISA/IEC 62443

ISA/IEC 62443 moves the discussion closer to the industrial automation and control system itself.

It provides a structure for:

• Security lifecycle activities
• Roles and responsibilities
• System risk assessment
• Security requirements
• Zones
• Conduits
• Security levels
• Component and product capabilities

One of its most useful concepts is that segmentation should not simply mean:

“Put a firewall between IT and OT”

Instead:

Define assets with common security requirements
→ Establish zones
→ Identify required communications
→ Define conduits
→ Specify security requirements
→ Implement
→ Validate

This approach forces the organization to understand how the system actually operates.

Two systems located at the same Purdue level do not automatically belong in the same security zone.

Likewise, two systems in different architectural levels may still have operational dependencies that must be documented and protected.

Security architecture should reflect:

• Actual process function
• Risk
• Required communication
• Exposure
• Operational dependencies
• Security requirements

It is not merely the appearance of a reference diagram.

---

Connecting Cybersecurity with Functional Safety

For facilities containing Safety Instrumented Systems (SIS), cybersecurity decisions can intersect directly with functional safety.

An SIS may perform functions such as:

• Shutting down a compressor
• Closing an emergency shutdown valve
• Isolating part of a process
• Preventing escalation of a hazardous condition
• Bringing equipment to a defined safe state

IEC 61511 provides the functional-safety lifecycle used for Safety Instrumented Functions (SIF) in the process industry.

This includes areas such as:

• Hazard and risk assessment
• Safety requirements
• Safety Integrity Levels (SIL)
• Verification
• Validation
• Management of Change (MoC)
• Operations and maintenance

Cybersecurity and functional safety remain distinct disciplines.

But their boundaries can overlap.

For example, changing:

• SIS logic
• SIS engineering-workstation access
• Network architecture around the SIS
• Authentication mechanisms
• Communication paths
• Firmware or software

may create both cybersecurity and functional-safety considerations.

This means a cybersecurity change affecting the SIS should not automatically be treated as a cybersecurity-only decision.

Process safety, OT engineering, operations and maintenance, and cybersecurity teams may all need to participate.

SIS as a Security Zone

In a zone-and-conduit architecture, an SIS will often warrant treatment as a distinct zone because its security requirements and process consequences may differ from those of the Basic Process Control System (BPCS).

That does not mean every SIS automatically receives a predefined security level.

The target security level should come from the relevant risk assessment (in this case is using ISA/IEC 62443-3-2).

Depending on the assessed risk, the SIS zone may require stronger controls, more restrictive conduits, or additional assurance compared with less critical zones.

The architecture should be justified by risk—not by assuming that a particular label automatically requires a particular SL-T.

---

A Practical Four-Layer Model

The relationship can be summarized as:

Business and Operational risk
↓
NIST CSF 2.0 — Governance and Cybersecurity Outcomes
↓
NIST SP 800-82 — OT Context and Control Tailoring
↓
ISA/IEC 62443 — IACS Architecture, Requirements, and Lifecycle
↓
IEC 61511 — Functional-Safety Requirements where SIS is in Scope
↓
Implementation, Validation, Monitoring, and Improvement

This is not a hierarchy formally mandated by NIST, ISA, or IEC.

It is a practical integration model.

IEC 61511 applies where functional safety and SIS are relevant. A mining fleet-management system, conveyor control system, building automation system, or manufacturing cell may require a different safety framework or no SIS-specific layer at all.

The architecture must reflect the real system.

---

A Practical Roadmap

Organizations can begin with one important system or risk area and expand over time.

A practical sequence is:

1. Establish common governance and cybersecurity language using NIST CSF 2.0.
2. Map assets, processes, dependencies, architecture, suppliers, and risks.
3. Identify which systems perform production-control, enterprise-facing, and safety-related functions.
4. Use NIST SP 800-82 to evaluate OT-specific constraints and determine how safeguards must be tailored.
5. Use ISA/IEC 62443 to define zones, conduits, responsibilities, system requirements, and appropriate security-level targets.
6. Where SIS is involved, connect the cybersecurity work with IEC 61511 lifecycle and Management-of-Change processes.
7. Create traceability between risk, requirement, implementation, ownership, and evidence.
8. Validate measures both technically and operationally.
9. Monitor system changes and reassess risk throughout the lifecycle.

An organization does not need to transform its entire OT estate at once.

It can start with:

• Remote access (internal/external party)
• A critical process/production unit
• Industrial DMZ architecture (L3.5)
• Engineering workstations
• Backup and recovery
• A critical BPCS network
• An SIS zone

and expand from there.

---

Example — Remote Vendor Access (External Party)

Suppose a vendor needs remote access to maintain a critical control system.

Simply deciding to “install a VPN” is not enough.

NIST CSF Perspective

The organization defines outcomes such as:

• Protect access to critical systems
• Detect unauthorized activity
• Establish accountability
• Respond to misuse
• Maintain governance over third-party access

NIST SP 800-82 Perspective

The team asks:

• Is remote access operationally necessary?
• Which system must the vendor reach?
• What happens if remote access is unavailable?
• How should authentication work?
• How should authorization be limited?
• Can the session be monitored?
• Can access be disabled when maintenance ends?
• Are compensating controls required?

ISA/IEC 62443 Perspective

Those decisions become system requirements:

• Which zone contains the target system?
• Which zone provides remote-access services?
• Which conduit connects them?
• Which communication is permitted?
• Which roles can initiate the session?
• What actions may those roles perform?
• What evidence must be recorded?

IEC 61511 Perspective — Where SIS Is Involved

If the target includes or can affect an SIS:

• Does the activity require Management of Change?
• Does process safety need to approve the activity?
• Can the vendor only view diagnostic information?
• Is logic modification permitted?
• Which independent safeguards must remain available?
• How will the system be returned to a known state?

Some organizations may establish highly restrictive policies for remote modification of SIS logic, including prohibiting it entirely.

Such a decision should be an explicit policy and risk decision—not an accidental consequence of network design.

---

Example — Network Segmentation

Consider the objective:

Reduce unnecessary communication between enterprise IT and critical OT systems.

The references contribute at different levels.

NIST CSF establishes the desired protection outcome.

NIST SP 800-82 helps the team consider:

• Architecture
• Legacy dependencies
• Availability
• Required communication
• Industrial DMZ design
• Monitoring
• Firewalls
• Compensating controls

ISA/IEC 62443 then structures the implementation:

Assets → Zones → Required Communication → Conduits → Requirements

If an SIS exists, its security requirements and communication paths should be examined separately from ordinary BPCS communication.

Segmentation therefore becomes more than:

“Put a firewall between IT and OT”

It becomes:

Determine which assets share common security requirements, define which communications are operationally necessary, establish controlled conduits, and apply protections appropriate to the risk.

---

Build a Practical Crosswalk

One of the most useful ways to connect these references is through an internal crosswalk.

The crosswalk should establish traceability:

Objective
→ Risk
→ Requirement
→ Control
→ Security Level where applicable
→ Owner
→ Evidence

For example:

Program Objective	OT Requirement	References	Owner	Evidence
Protect remote access	Approved, authenticated, monitored sessions through a controlled access path	NIST CSF, NIST SP 800-82, IEC 62443; IEC 61511 where SIS is affected	OT Engineering / OT Operations & Maintenance / Cybersecurity / IT Engineering	Access records, configuration, session logs, approvals
Control network communication	Allow only required communication between defined zones	NIST CSF, NIST SP 800-82, IEC 62443	OT Engineering / IT Engineering / Cybersecurity	Architecture diagrams, firewall rules, validation records
Protect safety functions	Treat SIS-related requirements separately and manage relevant changes through the safety lifecycle	IEC 61511, IEC 62443, NIST CSF Govern	Process Safety / OT Engineering / Cybersecurity	MoC records, safety requirements, test evidence
Maintain recovery capability	Maintain tested backups and trusted restoration procedures	NIST CSF Recover, NIST SP 800-82, IEC 62443	OT Operations & Maintenance / OT Engineering	Backup tests, restore tests, procedures
Detect unauthorized activity	Monitor relevant access, communication, and configuration changes	NIST CSF Detect, NIST SP 800-82, IEC 62443	SOC / OT Operations & Maintenance / OT  Engineering / Cybersecurity	Logs, alerts, investigations

The purpose is not to force every standard into a spreadsheet.

The purpose is to preserve the reason behind each control.

A few months later, management should be able to ask:

Why did we implement this? and receive an answer based on:

• Risk
• Operational consequence
• Requirement
• Ownership
• Evidence

—not merely:

“Because the standard says so”

---

Why Ownership Matters

OT cybersecurity is inherently multidisciplinary.

Typical ownership may include:

• Governance: OT asset owner, OT engineering, cybersecurity, or risk management
• Asset identification: OT Operations & Maintenance, OT engineering
• Network architecture: OT engineering, IT engineering
• Monitoring: Cybersecurity, SOC
• Backup and recovery: OT Operations & Maintenance, OT engineering
• Vendor security: Procurement, OT asset owner, OT engineering, cybersecurity
• Functional safety: Process Safety, OT engineering
• Change management: OT Operations & Maintenance, OT engineering, cybersecurity, safety as applicable

A framework becomes operational only when someone owns the decisions.

---

What This Model Does Not Mean

The layered approach has important limits as follows:

• It does not mean every organization must implement every reference line by line
• It does not mean one framework automatically satisfies another
• It does not mean certification of one component certifies the system
• It does not mean IEC 62443 replaces IEC 61511
• It does not mean cybersecurity replaces process safety
• And it does not mean every facility should use the same architecture

A pipeline compressor station, petrochemical process/facilities, mining conveyor system, manufacturing cell, and power-generation plant may all contain OT.

Their consequences, dependencies, safety functions, technologies, and threat exposure can be very different.

“The framework must follow the system. The system should not be forced to resemble the framework.”

“The framework must follow the system” means we should first understand the actual OT environment—its process, architecture, dependencies, hazards, operational constraints, and risks—and then apply the framework in a way that fits that reality.

“The system should not be forced to resemble the framework” means we should not redesign or classify the plant just so it looks neat according to a reference model.

For example, with IEC 62443, it would be a mistake to say:

“Everything at Purdue Level 2 must be one security zone because the diagram looks cleaner that way.”

Two systems at the same Purdue level may have very different functions, consequences, exposure, or security requirements. One might be a normal process-control system, while another could support a highly critical function. So, the zones should reflect actual risk and common security requirements, not simply copy the Purdue diagram.

The same principle applies more broadly. NIST CSF, NIST SP 800-82, IEC 62443, and IEC 61511 are there to help structure decisions. They are not supposed to make every facility look identical.

A refinery, a pipeline station, a mining conveyor system, and a manufacturing line can all be “OT,” but their architectures, hazards, dependencies, and operating requirements can be completely different.

So, the core idea is:

UNDERSTAND the REAL SYSTEM first → ASSESS the REAL RISK → then USE the FRAMEWORK to structure the response

Not:

Start with the framework → then reshape reality so it fits the framework.

Please be mindful of these terms:

“Framework-driven design instead of risk-driven engineering”

We should use the Risk-Driven Engineering as our OT cybersecurity assurance approach.

---

Key Takeaway

The goal is not to choose a “winning” standard.

NIST CSF 2.0 provides the language for governance, cybersecurity outcomes, and risk communication.

NIST SP 800-82 Rev. 3 provides OT-specific context for applying and tailoring safeguards.

ISA/IEC 62443 provides an IACS-focused structure for risk assessment, architecture, zones, conduits, requirements, responsibilities, and lifecycle activities.

IEC 61511, where Safety Instrumented Systems (SIS) are in scope, connects cybersecurity decisions with the functional-safety lifecycle.

Together, they support a practical model:

• Govern the risk
• Understand the OT context
• Engineer the security requirements
• Connect cybersecurity with functional safety where necessary
• Implement and validate the controls
• Monitor, learn, and improve

Standards should help organizations make better risk decisions. They should not become the risk decision themselves.

A standard should inform and structure the decision, but it should not replace the actual risk assessment.

For example, imagine someone says:

“IEC 62443 recommends this type of control; therefore, we must implement it.”

That is incomplete reasoning.

The better question is:

“What risk are we trying to reduce, what consequence are we preventing, is this control appropriate for this OT environment, and what operational impact could it create?”

So, the standard gives you things like:

• Principles
• Control objectives
• Requirements
• Lifecycle guidance
• Terminology
• Ways to structure the assessment

But the actual decision still depends on the

• Real system
• Process consequence
• Threat exposure
• Safeguards
• Operational constraints
• Residual risk

A simple example:

A standard may support stronger authentication for critical access. But if implementing that authentication creates a dependency that could block operators during an emergency, the organization has to assess that trade-off and design an appropriate solution.

The answer is not simply “the standard says MFA, therefore MFA everywhere.”

The standards should help organizations make better risk decisions and use them as guidance and structure.

They should not become the risk decision themselves, so do not treat “the standard says so” as the entire justification for a control or architecture.

In one sentence:

“COMPLIANCE tells you what a reference expects; RISK MANAGEMENT tells you what your system actually needs.”

This article emphasizes traceability from Objective → Risk → Requirement → Control → Owner → Evidence, rather than stopping at “mapped to a standard.”

---

Next in the Series

A program-level model tells us how the references fit together.

The next question is more practical:

What does this process look like when applied to one real OT risk?

The next article follows a single process scenario—from a cyber event, through process consequence and risk assessment, to security requirements, implementation, and validation.

---

References

• NIST Cybersecurity Framework 2.0
• NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security
• ISA/IEC 62443 Series
• IEC 61511 — Functional Safety: Safety Instrumented Systems for the Process Industry Sector