
An ICS security assessment is a structured evaluation of an industrial control system, the PLCs, HMIs, SCADA servers, engineering workstations and networks that run a physical process, to find the weaknesses an attacker could use to disrupt, damage or take control of that process. It differs from an IT assessment because the thing at risk is not only data but uptime, equipment and safety. This guide covers the frameworks behind a sound assessment (NIST SP 800-82 Rev. 3, ISA/IEC 62443 and the Purdue model), ICS risk management, where penetration testing fits, ICS security monitoring, and a checklist to prepare with.
An ICS security assessment is a systematic review of the people, processes and technology that operate an industrial control system, measured against a recognized framework, to identify vulnerabilities, rate the risk they pose to the physical process, and prioritize the controls that reduce it. A good assessment produces three things: an accurate asset inventory, a ranked list of risks tied to real consequences, and a remediation plan the operations team can carry out without breaking production. Telling a plant to patch every controller this quarter is not a plan; ICS assessments have to respect maintenance windows, vendor support and safety systems that cannot be touched without a management-of-change process. For the general version, see our overview of cybersecurity assessment types.
In cyber security, ICS (industrial control systems) means the programmable devices and software that monitor and control physical processes in sectors such as energy, manufacturing, water, oil and gas, and transportation. NIST groups ICS under the broader term operational technology (OT), which it describes as programmable systems and devices that interact with the physical environment and detect or cause a direct change through the monitoring or control of devices, processes and events.
In practice that means SCADA, distributed control systems (DCS), PLCs, remote terminal units (RTUs), safety instrumented systems (SIS) and HMIs. Most were built for reliability and long service life, not hostile networks, which is why they are assessed differently from servers and laptops. Our glossary entry on ICS security defines the terms.
Industrial organizations need an ICS cyber security assessment because the consequences of a control-system compromise are physical, and because most ICS environments have never been tested against the way attackers actually reach them. Two documented incidents show both halves.
In 2017, malware known as TRITON (also called TRISIS and HatMan) was used against the safety controllers of a Middle East petrochemical facility. According to the FBI, it targeted Schneider Electric Triconex safety instrumented systems, the equipment that initiates a safe shutdown in an emergency, and could have caused significant physical damage and loss of life. It failed because the plant's automatic shutdown and malware detection triggered, not because the safety layer was built to resist it.
In May 2021, Colonial Pipeline shut down its pipeline system in response to a DarkSide ransomware attack on its networks and did not restart full delivery until May 13, according to the U.S. Department of Energy. The ransomware hit IT systems; the pipeline stopped anyway, because the operator could not be confident the OT side was isolated. That assumption is exactly what an assessment exists to test. Our post on energy sector cybersecurity challenges covers the sector where this gap is most visible.
The three ICS security frameworks most assessments are built on are NIST SP 800-82 Rev. 3, the ISA/IEC 62443 series, and the Purdue model. SP 800-82 tells you how to secure OT, ISA/IEC 62443 tells you what requirements to meet and how to grade them, and the Purdue model gives you a shared map of the network you are securing.

NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security, published in September 2023, is the U.S. reference for OT security. It covers OT threats, vulnerabilities and countermeasures, and how to apply the NIST Risk Management Framework to OT. Its architecture guidance is direct: separate corporate and OT networks with stateful firewalls or unidirectional gateways, use a DMZ so traffic never passes directly between the two, and layer the OT network so the most critical communications sit in the most protected layer. It uses the Purdue model as its segmentation example.
The ISA/IEC 62443 series defines requirements and processes for implementing and maintaining electronically secure industrial automation and control systems (IACS). Part 2 covers security programs (62443-2-1 for asset owners), Part 3 covers systems (3-2 for security risk assessment during system design, 3-3 for system security requirements and security levels), and Part 4 covers product development (4-1) and components (4-2).
Two ideas from 62443 drive most assessments. Zones and conduits: a zone is a group of assets with common security requirements, and a conduit is the logical grouping of communication channels between zones. Security levels SL 1 through SL 4 grade how capable an adversary a zone must resist, from casual or coincidental events at SL 1 to sophisticated, well-resourced and highly motivated attackers at SL 4. An assessment against 62443 asks whether each zone actually achieves its target level.
The Purdue model (the Purdue Enterprise Reference Architecture) is a layered reference model that separates a plant into functional levels, from the physical process and field devices at the bottom, through controllers and supervisory systems, up to manufacturing operations, business logistics and enterprise IT. ISA-95 builds its enterprise-control hierarchy on it, and NIST SP 800-82 uses it to illustrate segmentation. For an assessor it is a checklist of boundaries: every place traffic crosses a level is a place to test whether the control there enforces anything.
MITRE ATT&CK for ICS catalogs adversary tactics and techniques against control systems, including ICS-specific tactics such as Inhibit Response Function and Impair Process Control, and is the right vocabulary for threat modeling and monitoring. In the electric sector, NERC's Critical Infrastructure Protection (CIP) standards, approved by FERC as mandatory reliability standards, add obligations an assessment should map to.
ICS risk management is the ongoing process of framing, assessing, responding to and monitoring the risks that cyber threats pose to an industrial process, so that control decisions are based on consequence rather than on the length of a vulnerability list. The four components come from NIST SP 800-39, and NIST SP 800-82 Rev. 3 applies the same Risk Management Framework to OT. An ICS security risk assessment is the second step of that cycle, not the whole of it.

Framing sets the strategy: what must keep running, what safety limits apply, what the organization can tolerate and who decides. Assessing identifies threats, vulnerabilities, the harm that could follow and its likelihood; in ICS, harm means lost production, damaged equipment, environmental release and injury, which is why process engineers must take part. Responding chooses countermeasures within the system's constraints: segmentation, hardening, compensating controls where patching is impossible. Monitoring verifies the responses are in place and still work. Our guide to cybersecurity risk assessment steps covers the generic method.
An ICS vulnerability assessment identifies known weaknesses in controllers, HMIs, engineering workstations, network equipment and remote-access paths; ICS vulnerability management is the program that tracks and closes them over time. Active scanning can be unsafe on some OT devices, so assessors lean on passive network capture, configuration review and vendor advisories, and confine active checks to test systems or agreed maintenance windows. CISA's ICS advisories and its Cyber Security Evaluation Tool (CSET), a guided standards-based self-assessment, are useful starting points. Where a scan cannot run, a manual review must.
Penetration testing fits into an ICS security assessment as the proof step: the assessment says a boundary or control should hold, and the penetration test finds out whether it does. A control that exists on paper has not been secured; it has been described. Findings that only testing surfaces include firewalls that allow everything, engineering workstations reachable from the corporate LAN, shared remote-access credentials and HMIs that accept unauthenticated writes.
ICS penetration testing is scoped differently from IT testing. Rules of engagement define which zones are in bounds, which devices are never touched, what time windows apply and who in operations can halt the test. Live controllers are rarely exploited; testers demonstrate reachability and validate on spare hardware. Our guide to ICS and OT penetration testing covers the method, and the CBTC penetration test case study shows an engagement on a safety-relevant control system.

ICS security monitoring is the continuous collection and review of network traffic, device logs, configuration state and process anomalies so that an intrusion is detected before it affects the physical process. It closes the loop on the monitoring step of risk management: an assessment tells you where you were vulnerable on one day, and monitoring tells you whether you still are.
Because many OT devices cannot run agents, ICS monitoring is mostly passive: mirrored traffic at the Purdue boundaries, protocol-aware analysis, and alerts on new devices, new conversations between zones, configuration downloads to controllers and remote-access sessions outside change windows. ISA/IEC 62443 covers this under its foundational requirement for timely response to events, and ATT&CK for ICS gives detection engineers concrete techniques to write detections against. Logs from the DMZ, jump hosts and engineering workstations should feed the same place IT alerts go, with a playbook that includes operations. See our post on continuous security monitoring for the program side.
ICS/OT security assessment services should include asset discovery that does not disturb production, a gap review against ISA/IEC 62443 or NIST SP 800-82, a consequence-driven risk assessment done with your process engineers, an authorized penetration test of the IT/OT boundary and key zones, a monitoring recommendation, and a remediation roadmap sequenced around your outage schedule. If a proposal is a network scan with a compliance spreadsheet attached, it is a scan and should be priced like one. Ask how the provider protects live controllers, whether findings are ranked by process consequence rather than CVSS alone, and whether a retest is included. Most plants also run IoT and IIoT devices; our overview of IoT and embedded device penetration testing explains what that adds.
An ICS security assessment is the broad review: inventory, architecture, gap analysis against a framework and a risk register. An ICS penetration test is a controlled attack on specific boundaries and systems to prove which gaps are exploitable. The assessment tells you what should be fixed; the test tells you what an attacker could do today.
No single interval is mandated across all sectors, so the practical answer is at least annually, after any significant change to the network or process, and after any security incident. Sector rules such as NERC CIP set their own obligations. Between assessments, continuous monitoring is the control that catches drift.
Not always. Some controllers and legacy devices can fault or reboot on unexpected traffic, so assessors default to passive capture and configuration review and run active checks only with written authorization, in agreed windows, and where possible on spare hardware. A provider that plans to run a standard vulnerability scanner across the control network without discussing this is a warning sign.
From a security firm that has tested operational technology, follows ISA/IEC 62443 and NIST SP 800-82 in its method, and can show engagements on comparable systems. Ask for the approach in writing, including how live equipment is protected, before signing. ioSENTRIX delivers ICS and OT assessments and penetration tests.
ioSENTRIX is a CREST-accredited penetration testing firm, ISO/IEC 27001 certified and SOC 2 Type 2 attested. Our ICS, IoT and IIoT penetration testing service combines a framework-based ICS security assessment with authorized testing of the IT/OT boundary and the zones that matter most, using passive discovery and test hardware to keep production out of harm's way. Findings are ranked by consequence to the process, every fix is retested, and the report is written for engineers and auditors alike. We do not report that a firewall exists; we report what it stopped.
If you are not sure your OT network is as isolated as the diagram says, talk to us about scoping an ICS security assessment.