What are the SANS ICS Five Critical Controls?
The SANS ICS Five Critical Controls are five security measures that the SANS Institute identified in 2022 as the minimum for an effective cybersecurity programme for industrial control systems (ICS) and OT: an ICS-specific incident response plan, a defensible architecture, ICS network visibility and monitoring, secure remote access and risk-based vulnerability management. The controls were selected by analysing real attacks on industrial companies and describe an outcome to achieve rather than a technical checklist. They do not replace standards such as IEC 62443, but they answer the question many organisations ask first: where do we start?
🕰️ Where do the SANS ICS Five Critical Controls come from?
The controls are set out in the white paper The Five ICS Cybersecurity Critical Controls, written by Robert M. Lee and Tim Conway and dated October 2022. Both teach in the SANS ICS curriculum; Lee is also co-founder and CEO of the OT security company Dragos. They presented the controls in a SANS webcast on 31 October 2022, and the paper was published in early November 2022.
The motivation was practical. According to the authors, established frameworks such as NERC CIP, IEC 62443 and the NIST publications were written when there was little insight into ICS-specific threats, so many of their controls are IT controls that can also be applied to OT. The authors also point to a prevention bias: between 60 and 95% of the guidance in well-known frameworks is preventive, while some organisations spend as little as 5% of their resources on detection, response and recovery. The five controls are meant to restore that balance.
🧠 What do the five controls involve?
| No. | Control | Core idea | OT example |
|---|---|---|---|
| 1 | ICS-specific incident response plan | An operations-informed plan focused on system integrity and recovery, tested through scenario exercises | A tabletop exercise on ransomware in the process network, with operators, engineers and legal counsel in the room |
| 2 | Defensible architecture | A design that supports visibility, log collection, asset identification, segmentation and an industrial DMZ | Network segmentation with only a few crossing points (choke points) between the office and process networks |
| 3 | ICS network visibility and monitoring | Continuous, protocol-aware monitoring of the interaction between systems | A passive sensor on a SPAN port that dissects Modbus and S7 traffic and flags unusual write commands |
| 4 | Secure remote access | Every access path mapped, on-demand access, MFA where possible and a jump host as control point | A vendor connects through a jump server with MFA; the connection is off by default |
| 5 | Risk-based vulnerability management | Judging vulnerabilities by real risk: patch, mitigate or monitor | A vulnerable PLC is only patched at the next planned shutdown and until then is shielded by a firewall rule and monitored |
Control 1 is the starting point. The paper recommends two or three intelligence-driven scenarios from your own sector, such as an attack on a safety system like TRITON, plus one consequence-driven scenario: an outcome operations and management fear, whether or not it has ever happened. An OT incident response plan puts keeping the process running safely first, not merely removing the attacker.
Control 2 starts from the idea that no architecture is secure: only people turn a defensible architecture into a defended one. It includes an inventory of at least the crown jewels, log collection from HMIs and engineering workstations, and the ability to fall back to a “defensible cyber position” during a crisis.
Control 3 makes the first two measurable. Network monitoring with deep packet inspection of industrial protocols supplies the data for the investigations in control 1 and checks that the architecture from control 2 works as intended. The authors advise alerting on attacker techniques that match your scenarios rather than on every anomaly.
Control 4 responds to the surge in remote access since the COVID-19 pandemic of 2020. Attackers no longer need to come in through the IT network; they use the connections of vendors, integrators and OEMs. The paper focuses MFA on connections that cross the internet or a shared network between organisations. Where MFA is not feasible, it lists compensating controls: jump hosts, routing traffic through choke points for closer monitoring and the ability to cut connections when the threat level rises.
Control 5 takes the pressure off patching. According to the paper, only around 4% of ICS vulnerabilities each year require immediate action, because they give an attacker new functionality or are already being exploited. Up to 10% are unusable or incorrectly reported; the rest can be monitored or mitigated.
🎯 Why these five controls?
The controls are intelligence-driven: they were chosen by analysing attacks on industrial companies worldwide. The paper refers to the attacks on the Ukrainian power grid in 2015 and 2016, TRITON/TRISIS at a Saudi petrochemical facility in 2017, the ransomware attack on Colonial Pipeline in 2021 and the PIPEDREAM toolkit disclosed in 2022.
Each incident supports a control. At Colonial Pipeline, the attacker got in through a legacy VPN connection that was no longer in use but had never been decommissioned, a lesson for control 4. With TRITON, configuration changes and deviating communications could have been spotted without any known malware signature, a lesson for control 3. PIPEDREAM abused CODESYS software embedded in hundreds of PLC models, while only a handful of vendors issued an advisory, a lesson for control 5.
Equally important is the insight that most OT attacks do not need a vulnerability at all. An attacker who understands the “system of systems” and the physics of the process uses native functionality, for example changing a controller’s logic through the engineering workstation. That is why the emphasis lies on detection and response rather than on patching alone. The order is deliberate: without visibility of existing connections (control 3), you do not know which remote access you need to secure (control 4).
🔄 How do the controls relate to IEC 62443, NIST SP 800-82 and the Dutch Cybersecurity Act?
The authors advise adopting the five controls first and then mapping them to a common framework, so that you report in a shared language. The mapping below is a practical translation, not an official crosswalk.
| Control | IEC 62443 | NIST SP 800-82 Rev. 3 | Dutch Cybersecurity Act / Cybersecurity Decree |
|---|---|---|---|
| 1 Incident response plan | 62443-2-1:2024, SPE 7 (event and incident management) | Chapter 3 (programme, incident response and recovery), CSF functions Respond and Recover | Decree art. 8 (incident handling) and art. 9 (business continuity and crisis management); reporting duty under the Act |
| 2 Defensible architecture | 62443-3-2 (zones and conduits), 62443-3-3 SR 5.1 (network segmentation) | Chapter 5 (defence in depth, segmentation) | Decree art. 7 (risk management) and art. 16 (up-to-date asset inventory) |
| 3 Visibility and monitoring | 62443-3-3 SR 6.2 (continuous monitoring), 2-1 SPE 7 | CSF function Detect in chapter 6 | Decree art. 8 (detection and logging) |
| 4 Secure remote access | 62443-3-3 SR 1.13 (access via untrusted networks), 2-1 SPE 3 and SPE 6 | Chapter 5 and the OT overlay of SP 800-53 | Act art. 21(3)(j) (MFA), Decree art. 15 (access) and art. 10 (supply chain) |
| 5 Vulnerability management | 62443-2-1 SPE 4 (component security, patch management), IEC TR 62443-2-3 | Chapter 4 (risk management), CSF function Identify | Decree art. 11 (maintenance) and art. 17 (threat intelligence) |
For organisations covered by the Dutch Cybersecurity Act (Cyberbeveiligingswet), in force since 15 August 2026, the five controls are therefore a useful way to prioritise within the duty of care. They do not cover that duty in full: policy, board training, cryptography and personnel security remain mandatory.
🛠️ Step-by-step roadmap for a mid-sized Dutch plant
Take a food manufacturer with 200 employees, two production lines and a small IT department. As a medium-sized industrial food producer, it will typically be an important entity under the Cybersecurity Act. A realistic approach over roughly twelve months:
- Choose scenarios (months 1–2) — select ransomware in the process network, abuse of vendor access and one consequence scenario, such as a manipulated pasteurisation temperature. Run them as a tabletop and record which information was missing.
- Crown jewels and zones (months 2–4) — inventory the PLCs, HMIs, engineering workstations and historian of the critical lines. Place them in zones with a single controlled crossing to the office network.
- Gain visibility (months 3–6) — install a passive monitoring sensor at the IT/OT boundary and next to the crown jewels. Validate the asset inventory and forward critical alerts to the existing (outsourced) SOC.
- Clean up remote access (months 4–6) — map every path, including forgotten 4G routers and remote desktop tools installed by machine builders. Route everything through one jump server with MFA and keep connections off by default.
- Prioritise vulnerabilities (ongoing) — map vulnerabilities to the inventory and give priority to those in the KEV catalogue or relevant to your scenarios. For the rest, choose between mitigating and monitoring.
- Repeat (annually) — rerun the tabletop, record improvements and use the outcome as the effectiveness review required by article 18 of the Decree.
📈 What are the quick wins and maturity stages?
Dragos breaks the five controls down into three stages: implement (putting the controls into practice), operationalise (being able to handle the key scenarios, building sustainable processes and extending the programme to medium-impact sites) and optimise (using a risk management framework to fine-tune investments and improve continuously).
| Control | Quick win (weeks) | Mature state |
|---|---|---|
| 1 | One tabletop with one ransomware scenario | Annual exercises with threat and consequence scenarios, without major gaps |
| 2 | An up-to-date network diagram of the critical line | Complete inventory and segmentation that monitoring validates continuously |
| 3 | A temporary passive capture to learn the traffic | Monitoring at all critical sites, linked to a SIEM and playbooks |
| 4 | Disable unused VPN accounts and remote tools | Access on demand only, with MFA, session recording and as few vendors as possible |
| 5 | Compare the KEV catalogue with the asset list | A repeatable process that assigns each vulnerability to patch, mitigate or monitor |
⚠️ What are the limitations of the Five Critical Controls?
- A minimum, not a full framework — the authors themselves call the controls a minimum. Governance, awareness, cryptography, physical security and supply chain management get little attention, and backups appear only indirectly through recovery.
- Proximity to a vendor — Robert M. Lee runs Dragos, which sells OT monitoring software, and the 4% figure comes from the Dragos Year in Review. That does not make the content wrong, but it pays to read statistics and product advice critically.
- US context — examples and regulation such as NERC CIP come from the United States. European legislation such as NIS2 and the Dutch Cybersecurity Act sets broader requirements.
- No auditable scheme — there is no certification or audit scheme for the five controls. To demonstrate compliance you will still need IEC 62443 or ISO 27001.
- People as a precondition — monitoring and incident response need analysts with OT knowledge. Smaller plants often have to buy this in from an external SOC.
❓ Frequently asked questions
Who wrote the SANS ICS Five Critical Controls?
The SANS ICS Five Critical Controls were written by Robert M. Lee and Tim Conway, both instructors in the SANS Institute’s ICS programme. Their white paper is dated October 2022 and was published in November 2022. Lee is also co-founder and CEO of Dragos.
Do the Five Critical Controls replace IEC 62443?
No, the SANS ICS Five Critical Controls do not replace IEC 62443. They prioritise what to tackle first, whereas IEC 62443 offers a complete and auditable set of requirements. The authors actually recommend mapping the five controls to an existing framework such as IEC 62443 or the NIST Cybersecurity Framework.
Are the Five Critical Controls enough to comply with the Dutch Cybersecurity Act?
Not entirely. The Five Critical Controls cover important parts of the duty of care, such as incident handling, access policy and asset management, but the Cybersecurity Decree also requires policy, cryptography, personnel measures and periodic evaluation. You can, however, use the controls to decide where to start in OT.
In what order should you implement the Five Critical Controls?
The authors recommend implementing the Five Critical Controls in order and in concert. The incident response plan comes first, because the chosen scenarios set the requirements for architecture, monitoring, remote access and vulnerability management. Secure remote access deliberately follows monitoring, because you first need to see which connections exist.
How many ICS vulnerabilities need immediate action according to SANS?
According to the SANS white paper on the Five Critical Controls, only around 4% of ICS vulnerabilities each year require immediate action, based on analyses in the Dragos Year in Review. Up to 10% are unusable or incorrectly reported. Most of the remaining vulnerabilities can be mitigated with network measures or monitored for exploitation.
Why does incident response come first in the Five Critical Controls?
Incident response comes first because the scenarios in the response plan determine what the other four controls must be able to do. Organisations that leave incident response until the end often find that their architecture and monitoring do not deliver the data needed for root cause analysis. The Five Critical Controls therefore treat response as a design requirement, not a final step.
📌 In summary
The SANS ICS Five Critical Controls combine five measures derived from real attacks: an ICS incident response plan, a defensible architecture, network monitoring, secure remote access and risk-based vulnerability management. They give OT teams a starting point and an order of work, but they do not replace a complete framework such as IEC 62443 or the duty of care under the Dutch Cybersecurity Act.