Introduction
A cybersecurity risk assessment for operational technology environments is fundamentally different from an IT risk assessment. In IT, risk is primarily measured in terms of data confidentiality, financial loss, and service availability. In OT, risk must account for physical safety, environmental impact, production loss, equipment damage, and regulatory consequences.
This guide provides a structured methodology for conducting OT cybersecurity risk assessments based on IEC 62443-3-2 and adapted from real-world industrial implementations. It is designed for OT security practitioners, risk managers, and CISOs responsible for understanding and managing cyber risk in industrial operations.
Why OT Risk Assessment Is Different
Consequence Severity
IT risk assessments typically measure consequences in financial terms: cost of data breach, regulatory fines, revenue loss from downtime. OT risk consequences include dimensions that cannot be easily monetized:
- Safety: Could this scenario injure or kill a worker or member of the public?
- Environmental: Could this scenario cause a chemical release, oil spill, or emissions violation?
- Equipment: Could this scenario cause physical damage to equipment with long replacement lead times?
- Production: What is the hourly, daily, or weekly cost of a production shutdown?
- Regulatory: Could this scenario trigger regulatory action, license revocation, or criminal liability?
A comprehensive OT risk assessment must evaluate all five dimensions for every identified risk scenario.
Threat Actor Capabilities
OT environments face a distinct threat landscape. The IEC 62443 Security Level framework defines four levels of attacker sophistication:
| Security Level | Threat Actor Profile | Example |
|---|---|---|
| SL 1 | Casual or coincidental violation | Malware infection via USB drive |
| SL 2 | Intentional attack using simple means | Disgruntled employee with process knowledge |
| SL 3 | Sophisticated attack using moderate resources | Organized cybercrime targeting OT for ransom |
| SL 4 | State-sponsored attack with OT-specific capabilities | TRITON, Industroyer, PIPEDREAM |
The target Security Level for each zone determines the risk threshold and the strength of required controls.
Operational Context
OT risk cannot be assessed in a vacuum. The same vulnerability may represent high risk in one operational context and low risk in another:
- A PLC vulnerability in a safety-critical reactor control system versus the same vulnerability in a non-critical utility monitoring system
- An unpatched HMI on an air-gapped network versus the same HMI on a network connected to the enterprise
- A remote access vulnerability at a continuously operated refinery versus the same vulnerability at a batch manufacturing facility with regular shutdowns
Phase 1: Scope Definition and Asset Identification
Defining the Assessment Boundary
Begin by defining clear boundaries for the risk assessment:
- Physical scope: Which facilities, units, or process areas are included?
- System scope: Which control systems, networks, and supporting infrastructure are in scope?
- Organizational scope: Which teams, vendors, and third parties interact with in-scope systems?
Document the boundary explicitly. Systems outside the boundary should be identified as external dependencies and their interfaces documented as conduits.
Asset Inventory
A risk assessment is only as good as its asset inventory. Before risk scenarios can be identified, you must know what exists:
- All communicating devices: PLCs, RTUs, HMIs, servers, switches, firewalls, engineering workstations
- Software and firmware versions on every device
- Network architecture: subnets, VLANs, routing, firewall rules
- Communication flows: which devices talk to which, using what protocols
- Remote access pathways: VPN, jump servers, vendor connections, cellular modems
- Physical access points: USB ports, console connections, maintenance laptops
Use passive network discovery tools to supplement manual inventory. Most assessments discover 30-50% more devices than the facility knew existed.
Zone and Conduit Definition
Based on the asset inventory and network architecture, define security zones and conduits per IEC 62443-3-2:
- Group assets into zones based on common security requirements, operational function, and trust level
- Identify every conduit connecting zones
- Document the data flows, protocols, and access requirements for each conduit
- Assign a target Security Level (SL-T) to each zone based on the criticality of the controlled process and the organization's risk tolerance
Phase 2: Threat Identification and Scenario Development
Threat Source Identification
Identify the threat sources relevant to each zone:
- External adversaries: Nation-states, organized crime, hacktivists, competitors
- Internal threats: Disgruntled employees, negligent users, compromised accounts
- Supply chain: Compromised vendor updates, infected maintenance laptops, backdoored components
- Environmental: Power failures, natural disasters, equipment failures that create cyber-physical cascading effects
Attack Scenario Development
For each zone, develop specific attack scenarios that describe:
- Threat source: Who is attacking?
- Entry vector: How do they gain initial access?
- Attack path: How do they move from initial access to the target system?
- Target: Which specific asset or process is the ultimate target?
- Action on objective: What does the attacker do when they reach the target?
- Consequence: What is the physical, operational, or safety impact?
Example scenario:
An attacker compromises an engineering workstation through a spear-phishing email containing a weaponized project file. Using stolen credentials, they access the PLC programming environment and modify the control logic governing reactor temperature limits. The modified logic allows the reactor to exceed safe temperature thresholds, potentially causing a thermal runaway event.
Develop 5-15 scenarios per zone, prioritizing those with the highest potential consequences.
MITRE ATT&CK for ICS Mapping
Map each scenario to the MITRE ATT&CK for ICS framework to ensure comprehensive threat coverage:
- Initial Access (T0817-T0866)
- Execution (T0807-T0873)
- Persistence (T0839-T0889)
- Lateral Movement (T0812-T0886)
- Collection (T0802-T0868)
- Impact (T0826-T0882)
This mapping helps identify scenarios that may have been overlooked and provides a common language for communicating threats.
Phase 3: Consequence Analysis
For each scenario, assess the consequences across all five dimensions using a standardized severity scale:
Consequence Rating Scale
| Rating | Safety | Environmental | Production | Equipment | Regulatory |
|---|---|---|---|---|---|
| 1 - Negligible | No injury | No release | < 1 hour downtime | No damage | No impact |
| 2 - Minor | First aid treatment | Minor contained release | 1-8 hours downtime | Minor repair | Reporting required |
| 3 - Moderate | Medical treatment | Reportable release | 1-7 days downtime | Significant repair | Investigation triggered |
| 4 - Major | Serious injury | Major release, offsite impact | 1-4 weeks downtime | Major equipment replacement | Enforcement action |
| 5 - Catastrophic | Fatality | Catastrophic release | > 1 month downtime | Facility-level damage | Criminal prosecution |
The overall consequence score for each scenario is determined by the highest rating across all dimensions. A scenario with minor production impact but major safety consequences is rated as Major (4).
Phase 4: Likelihood Estimation
Estimate the likelihood of each scenario based on:
- Vulnerability presence: Are the technical vulnerabilities required for this scenario present?
- Exposure: Is the target system accessible from the attacker's starting position?
- Existing controls: What controls are already in place that would prevent or detect this attack?
- Threat actor motivation: How motivated is the threat source to target this specific facility?
- Attack complexity: How much specialized knowledge and tooling does this attack require?
Likelihood Rating Scale
| Rating | Description | Approximate Frequency |
|---|---|---|
| 1 - Rare | Requires multiple unlikely conditions | Less than once per decade |
| 2 - Unlikely | Possible but would require specific effort | Once per 5-10 years |
| 3 - Possible | Could reasonably occur | Once per 1-5 years |
| 4 - Likely | Expected to occur | Once per year |
| 5 - Almost Certain | Currently exploitable with known tools | Multiple times per year |
Phase 5: Risk Scoring and Prioritization
Risk Matrix
Combine consequence and likelihood scores using a risk matrix:
| Negligible (1) | Minor (2) | Moderate (3) | Major (4) | Catastrophic (5) | |
|---|---|---|---|---|---|
| Almost Certain (5) | Medium | High | Critical | Critical | Critical |
| Likely (4) | Low | Medium | High | Critical | Critical |
| Possible (3) | Low | Medium | High | High | Critical |
| Unlikely (2) | Low | Low | Medium | High | High |
| Rare (1) | Low | Low | Low | Medium | High |
Risk Prioritization
Rank all scenarios by risk score and group them:
- Critical: Requires immediate action. Compensating controls must be implemented within days while permanent remediation is planned.
- High: Requires action within the current planning cycle. Include in the next maintenance window or budget cycle.
- Medium: Should be addressed but can be scheduled over 6-12 months.
- Low: Accept, monitor, or address opportunistically.
Phase 6: Risk Treatment Planning
For each risk above the organization's risk acceptance threshold, define a treatment plan:
Treatment Options
- Mitigate: Implement controls to reduce likelihood or consequence
- Transfer: Shift risk through insurance or contractual arrangements
- Avoid: Eliminate the risk by removing the vulnerable system or connection
- Accept: Formally acknowledge and accept the residual risk with documented justification
Practical Treatment Planning
For each risk being mitigated, the treatment plan must include:
- Specific controls: What exactly will be implemented (not generic recommendations)
- Responsible owner: Who is accountable for implementation
- Timeline: When will the control be implemented, including interim compensating controls
- Validation method: How will the control's effectiveness be verified
- Residual risk: What is the expected risk level after the control is implemented
The most common failure in OT risk treatment planning is recommending controls that operations teams cannot or will not implement. Every recommended control must be validated against operational constraints:
- Can this control be deployed without a process shutdown?
- Does this control affect system response time or availability?
- Is the control compatible with vendor support agreements?
- Does the operations team have the skills and tools to maintain this control?
- What happens to the process if this control fails?
Reporting and Communication
Executive Risk Summary
For leadership and board reporting, present:
- Total number of scenarios assessed and risk distribution (Critical/High/Medium/Low)
- Top 5-10 risks by score with plain-language descriptions of potential consequences
- Risk trend over time (if this is a recurring assessment)
- Treatment plan status and resource requirements
- Comparison against peer organizations or industry benchmarks where available
Technical Risk Register
For the security and operations teams, maintain a detailed risk register containing:
- Every assessed scenario with full documentation
- Current risk score with supporting rationale
- Assigned treatment plan with owner and timeline
- Compensating controls currently in place
- Links to relevant vulnerability data, threat intelligence, and asset records
Maintaining the Risk Assessment
A risk assessment is a living document, not a one-time exercise:
- Annual reassessment of all scenarios with updated threat intelligence and vulnerability data
- Triggered reassessment when significant changes occur: new system installations, network architecture changes, new threat intelligence, or incidents
- Continuous monitoring of risk indicators through the OT security monitoring program
- Treatment plan tracking with regular progress reviews and escalation for overdue items
Conclusion
OT cybersecurity risk assessment is the foundation of every effective industrial security program. It provides the evidence base for investment decisions, the prioritization framework for security improvements, and the common language for communicating cyber risk to operations, engineering, and executive stakeholders. Done well, it transforms OT security from a technical concern into a managed business risk.
Beacon Security conducts OT cybersecurity risk assessments for industrial facilities across oil and gas, energy, manufacturing, chemical, and automotive sectors. Contact us to discuss your risk assessment requirements.
