Risk Assessment for OT Systems: Different Priorities Than in IT

Why IT Risk Methodology Is Not Enough for OT

If you operate an ISMS, you probably have an established risk assessment process. You identify assets, assess threats and vulnerabilities, determine the impact and likelihood, and derive measures. This works well for servers, networks, applications, and data.

But if you try to apply the same process to your production controls, you encounter fundamental problems.

The first problem: The assessment criteria do not fit. In IT, you typically assess impact in the categories of confidentiality, integrity, and availability. A data leak concerns confidentiality. A manipulation concerns integrity. An outage concerns availability. These categories also exist in OT, but their relative importance is completely different.

The second problem: The threat landscape is different. In IT, ransomware, phishing, and data leaks are the dominant threats. In OT, specific threats arise that do not exist in the IT world: process manipulation, safety system bypass, physical destruction through control system interference.

The third problem: The impacts go beyond money and data. In IT, you measure damage in euros, lost data, or reputational harm — the classic risk assessment in an ISMS focuses on these categories. In OT, people can die, environmental damage can occur, or entire production facilities can be physically destroyed.

You therefore do not need a completely new methodology, but you need an adapted methodology that accounts for these differences.

Safety vs. Security: Two Sides of the Same Coin

In the OT world, there is a distinction that does not exist in IT: the distinction between safety and security.

Safety (functional safety) protects people and the environment from the machine. Safety measures ensure that a machine transitions to a safe state in the event of a fault. Examples: Emergency stop systems, safety guard monitoring, pressure relief valves, speed monitoring. Safety has been regulated for decades (Machinery Directive, EN ISO 13849, IEC 62061) and has its own engineering discipline.

Security (cybersecurity) protects the machine (and thereby also people and the environment) from attackers. Security measures prevent an attacker from manipulating controls, stealing data, or disabling systems.

The critical connection: A security incident can become a safety incident. If an attacker manipulates the safety PLC that controls the emergency stop and then drives the machine controller into a dangerous state, the safety barrier fails. The TRITON/TRISIS attack in 2017 attempted exactly that: An attacker compromised the Triconex safety controller of a petrochemical plant to bypass safety functions and then potentially trigger an explosion.

For the risk assessment, this means: Every OT system that controls or influences a safety function has by definition the highest criticality. There is no room for negotiation here.

OT Impact Categories

To meaningfully assess OT risks, you need extended impact categories. The following five categories have proven effective in practice:

1. Personal Injury (Safety Impact)

The safety impact takes precedence over all other categories. A system with Safety Impact 3 is always critical, regardless of its financial value or its importance to production.

2. Environmental Damage

3. Production Downtime

4. Quality Loss

5. Financial Damage

The overall assessment results from the maximum of the individual assessments, with safety impact and environmental damage weighted higher than financial aspects.

OT-Specific Threats

In addition to classic IT threats (malware, phishing, DDoS), there are OT-specific threats that you must consider in your risk assessment:

Process Manipulation

An attacker changes parameters of the controller to sabotage the production process. They alter temperature values, pressure limits, speeds, or mixing ratios. The impacts range from quality problems to equipment damage to personal endangerment.

Specificity: The manipulation can be subtle. A slightly altered mixing ratio may only be noticed when the finished product shows quality problems, days or weeks later. Or the attacker changes the temperature setpoint of a furnace by a few degrees, which drastically shortens the lifespan of the lining and leads to an expensive shutdown months later.

Safety System Bypass

The attacker deactivates or manipulates safety systems (Safety Instrumented Systems, SIS) in order to subsequently create a hazardous condition. This is the most dangerous OT threat because it directly endangers human lives.

Assessment: This threat always has the highest criticality. Every safety system that is reachable via a network must be assessed as the highest risk.

Firmware Tampering

The attacker manipulates the firmware of a PLC or intelligent field device. Unlike a software attack on a Windows PC, a firmware attack survives a reboot and is not detectable with normal IT security tools.

Assessment: Firmware manipulations are difficult to detect and difficult to remediate. Recovery often requires physical access to the device and reprogramming via the engineering workstation.

Denial of Service on Real-Time Systems

In IT, a DDoS attack is annoying. In OT, it can be dangerous. If communication between the PLC and the SCADA system is interrupted, the operator loses their overview of the process. If communication between a safety PLC and sensors is disrupted, the safety function may fail.

Insider Threats

In the OT world, machine operators, maintenance staff, and maintenance service providers often have direct physical access to control systems. A disgruntled employee or a careless service provider can cause significant damage without needing sophisticated hacking tools.

Supply Chain Attacks

Compromised software updates from the machine manufacturer, manipulated spare parts with embedded malware, or compromised maintenance tools from a service provider: Supply chain attacks on OT systems are particularly insidious because the attack vector comes through trusted channels.

The Risk Assessment Process for OT

Step 1: Zone Formation and Conduit Identification

Before you assess individual systems, divide your OT environment into zones (based on the Purdue Model or IEC 62443-3-2). Each zone contains systems with similar security requirements. The connections between zones are conduits.

For each zone, you define a Security Level (SL) according to IEC 62443:

For most mid-market companies, SL 2 or SL 3 is appropriate. SL 4 is only relevant for critical infrastructure such as nuclear power plants or energy grids.

Step 2: Asset Inventory and Criticality Assessment

As part of the protection requirements analysis, you assess the criticality of each OT asset in each zone based on the five impact categories (safety, environment, production, quality, finances). The overall criticality of the asset results from the maximum.

Particularly important: Document the dependencies between assets. If PLC A fails and thereby stops the entire production line B, then the effective criticality of PLC A is at least as high as that of the entire line B.

Step 3: Threat Analysis

For the most critical assets (and for each conduit between zones), you identify the relevant threats. Use the OT-specific threats described above as a checklist and supplement them with industry-specific threats.

For each threat, you assess:

• Likelihood: How likely is it that this threat will materialize? Consider the exposure of the system (reachable from the internet? From the office network? Only locally?), the existing protective measures, and the current threat landscape (are there known campaigns targeting your industry or technology?).

• Impact: What happens if the threat materializes? Use the five impact categories.

Step 4: Risk Evaluation and Prioritization

The risk results from the combination of likelihood and impact. Use a risk matrix that reflects the OT specifics:

For risks with safety impact, the acceptance threshold should be significantly lower than for purely financial risks. A "medium" risk with potential personal injury requires treatment, while a "medium" risk with purely financial damage may be acceptable.

Step 5: Measure Planning

For each unacceptable risk, you define measures. The measures follow the hierarchy:

1. Avoid the risk: Remove the system or connection (e.g., disconnect an unnecessary network connection of a PLC)
2. Reduce the risk: Implement technical and organizational measures (segmentation, access control, monitoring)
3. Transfer the risk: Insurance, maintenance contract with SLA
4. Accept the risk: Conscious decision, documented and approved by executive management

For OT systems in particular: Measures must not impair availability and safety. A security measure that increases the risk of production downtime is counterproductive. Every measure must therefore also be evaluated for its impact on operations.

The EU Machinery Regulation and Risk Assessment

The EU Machinery Regulation 2023/1230 requires from 2027 that manufacturers include cybersecurity risks in their risk assessment. For machine operators, this has indirect implications:

New machines come with a manufacturer's cybersecurity risk assessment. This assessment gives you valuable information: What threats has the manufacturer identified? What measures has the manufacturer integrated into the machine? What residual risks remain? What recommendations does the manufacturer give for operator-side protection?

You must incorporate the manufacturer's information into your operator risk assessment. If the manufacturer recommends operating the machine in a segmented network and you ignore this recommendation, you bear the residual risk. The manufacturer's information thus becomes an input for your OT risk assessment.

Existing equipment without a cybersecurity assessment requires more effort on your part. For machines put into service before 2027, no manufacturer cybersecurity risk assessment exists. You must perform the assessment yourself, which means higher effort.

Documenting the OT Risk Assessment

The documentation of the OT risk assessment must simultaneously fulfill several requirements: It must be traceable for auditors, comprehensible for executive management, and actionable for the operational team. A proven structure:

The OT Risk Register

For each identified risk, you document:

Risk ID and title: A unique identifier and a short, comprehensible title. Not "R-OT-014," but "R-OT-014: Ransomware infection of the SCADA server in Hall 2."

Affected asset: Which OT system is affected? With reference to the asset register.

Threat scenario: What exactly could happen? Describe the scenario concretely enough that someone unfamiliar with the facility understands the situation.

Impact: Assessed across the five impact categories (safety, environment, production, quality, finances). With justification for each assessment.

Likelihood: Assessed on a defined scale, with justification (what vulnerabilities exist, what protective measures are in place, how exposed is the system).

Risk rating: Result from impact and likelihood.

Existing measures: What protective measures are already implemented?

Planned measures: What additional measures will be implemented?

Risk acceptance: Is the residual risk (after implementing planned measures) acceptable? Who made this decision?

Review date: When will this risk be reassessed?

Integration into the ISMS

The OT risk assessment should not be a separate document that exists alongside the IT risk register. Ideally, you integrate it into a unified risk register that contains both IT and OT risks. In ISMS Lite, IT and OT risks can be maintained in a unified register, with OT-specific impact categories (safety, environment) available as separate assessment fields, 500 Euro pro Jahr for the complete feature set. This has several advantages:

Executive management sees all risks in one place and can compare. An OT risk with Safety Impact 3 is not overlooked because it sits in a separate document that is not presented during the management review.

Relationships between IT and OT risks become visible. The risk "Ransomware infection of Active Directory" has direct implications for OT systems that authenticate via Active Directory. When both risks are in the same register, this connection becomes apparent.

The risk assessment methodology is consistent. You do not have to explain why the IT risk register uses a three-level scale and the OT register uses a five-level scale. A consistent methodology with OT-specific extensions (safety category, environmental category) is the better approach.

Common Weaknesses in OT Risk Assessments

In practice, I consistently observe the same mistakes in OT risk assessments:

Risks formulated too abstractly. "Cyberattack on production" is not a risk — it is a category. A risk must describe a concrete scenario: "An attacker compromises the SCADA server through the machine manufacturer's unsecured remote maintenance access and encrypts the hard drive. Operators lose process visibility for Line 1 and Line 2. Estimated production outage: 48 hours."

Underestimating likelihood. Many OT managers argue: "Our production has never been the target of an attack, so the probability is low." This is a fallacy. First, it is possible that attacks have already occurred but were not detected (because no monitoring exists). Second, the threat landscape changes: What was unlikely yesterday may become reality tomorrow.

Ignoring cascade effects. You assess the impact of a PLC failure in isolation (one machine is down). But in reality, downstream processes depend on this machine, and the actual damage is many times greater than the isolated failure.

Not linking safety and security. The safety risk assessment exists (from the machine manufacturer), the security risk assessment exists (in the ISMS), but nobody has checked whether a security incident can impair a safety function. This link is essential.

Not documenting compensating controls as residual risk. You have an unpatched system and deploy a firewall rule as a compensating control. But you do not document that a residual risk remains (the firewall rule can be bypassed, and the system remains vulnerable). Compensating controls reduce risk but rarely eliminate it completely.

Practical Tips for OT Risk Assessment

Start with the most critical systems. You do not need to assess all OT assets simultaneously. Begin with the systems that have the highest criticality (safety systems, central SCADA servers, controllers for the main production line). Then expand gradually.

Involve production engineering. You cannot perform the risk assessment for OT systems from an IT perspective alone. You need the knowledge of machine operators, maintenance staff, and production technicians. They know the facilities, the dependencies, and the real impacts of a failure.

Use existing safety assessments. For many OT systems, safety risk assessments already exist (per EN ISO 12100, HAZOP, FMEA). These assessments contain valuable information about criticality and the impacts of a failure. Use them as input for your cybersecurity risk assessment.

Document dependencies explicitly. In OT, cascade effects are the rule, not the exception. If you do not document the dependencies, you systematically underestimate the impact of an incident. A network switch connecting three production lines has a different criticality than a switch connecting only one machine. This dependency must be visible in the risk assessment.

Review regularly. OT environments change more slowly than IT environments, but they do change. New machines, new network connections, new software versions, new threats: Review your OT risk assessment at least annually and after every significant change.

Further Reading

• OT Security in SMEs: Why Production Control Belongs in Your ISMS
• IT/OT Convergence: Risks at the Interface Between Office and Production
• Securing SCADA and PLC Systems: Practical Measures Without Production Downtime
• Purdue Model Explained: Network Zones in Manufacturing
• EU Machinery Regulation 2023/1230: Cybersecurity Requirements from 2027