SCADA and ICS: The Difference and How They Fit Together

SCADA and ICS are not two names for the same thing. ICS (Industrial Control System) is the category. SCADA (Supervisory Control and Data Acquisition) is one type of system inside that category. Every SCADA system is an ICS. Not every ICS is a SCADA system.

That’s the whole answer in three sentences. The rest of this article explains why the confusion exists, where the line actually sits between SCADA and the other ICS types, and how the newer term OT fits over both. The definitions here come from NIST SP 800-82 Rev. 3, the reference document most engineers and security teams use when these terms need to be exact.

The hierarchy: OT contains ICS, ICS contains SCADA

Picture three boxes, one inside the other.

OT (Operational Technology) is the outer box. It covers every programmable system that interacts with the physical world — anything that detects or causes a physical change by monitoring or controlling devices, processes, and events. That includes industrial control systems, but also building automation, physical access control, transportation systems, and environmental monitoring. Your plant’s badge reader system is OT. It is not an ICS.

ICS (Industrial Control System) is the middle box. It covers the control systems used in industrial processes: manufacturing, power generation and transmission, water treatment, oil and gas, chemicals. If the system controls an industrial process, it’s an ICS.

SCADA, DCS, and PLC-based systems are the inner boxes. These are the three classic ICS architectures. They differ mainly in geography and control philosophy, which we’ll get to.

So when someone says “SCADA and ICS security,” they’re technically saying “one type of control system, and the category it belongs to.” It’s like saying “sedans and cars.” Harmless in conversation, but if you’re writing a security policy, a tender document, or a network architecture, the distinction matters. A requirement written for “SCADA” that was meant to cover the whole plant may legally or contractually exclude your DCS.

What SCADA actually is

SCADA exists to solve one problem: controlling assets that are spread out over distance, where collecting the data centrally matters as much as the control itself.

Think electrical transmission and distribution, gas and oil pipelines, water distribution, wastewater collection, rail networks. The assets are kilometers or hundreds of kilometers apart. Nobody stands next to them. So you need three things:

1. Field devices — RTUs, PLCs, or IEDs at the remote sites, controlling the local process and reading the sensors.
2. A communication layer — radio, fiber, cellular, satellite, leased lines — moving data between the field and the center.
3. A control center — the SCADA server (master station), HMIs, engineering workstations, and a historian, where operators watch the whole system and send commands.

The defining trait is loose coupling over wide areas. The control center polls field devices at intervals — every few seconds, sometimes longer — and issues supervisory commands like new setpoints. The fast, hard-real-time control loop runs locally at the field site, in the RTU or PLC. If the communication link drops, the field device keeps its process running on its own logic. The SCADA layer supervises; it doesn’t close the millisecond loops.

That word “supervisory” is doing real work in the acronym. It tells you where SCADA sits in the control hierarchy: above the local control layer, not inside it.

A note from practice: in substation and power-plant projects, the platform doing this job (MicroSCADA X, Zenon, and similar) is often installed inside one site rather than across a region. The architecture is still SCADA — a supervisory layer acquiring data from IEDs and protection relays and presenting it centrally — even when the “wide area” is one switchyard. The vendor category and the control philosophy define it, not the distance alone.

The components you’ll find in a SCADA system

Since SCADA is the ICS type people name most, it’s worth being precise about what’s inside one. These are also the components a security assessment has to inventory.

Control server (master station, MTU). The software heart of the system. It polls field devices, stores and processes their inputs and outputs, runs the alarm logic, and serves data to the HMIs. Large systems with hundreds of RTUs add sub-control servers to spread the polling load. In practice this is a redundant server pair, sometimes with a full backup control center on a separate site connected over the WAN.

HMI (Human-Machine Interface). The operator’s window: single-line diagrams, process graphics, alarm lists, trend displays. Operators monitor state, acknowledge alarms, and change setpoints here. The HMI reads from and writes through the control server — it doesn’t usually talk to field devices directly.

Data historian. Time-series storage for process values, alarms, and events. Feeds reporting, trending, and post-incident analysis. Historians tend to straddle the IT/OT boundary because business users want the data, which makes them a classic conduit — and a classic weak point if placed carelessly.

Engineering workstation. Where the configuration lives: database edits, display building, RTU and PLC programming. From an attacker’s perspective this is the highest-value host in the system, because it holds write access to everything below it.

RTU (Remote Terminal Unit). The field workhorse at remote sites. Reads sensors, drives actuators, executes local logic, and reports to the control server over the telemetry link. Built for wide-area comms and rough environments.

PLC (Programmable Logic Controller). Functionally overlaps the RTU and increasingly replaces it — modern PLCs speak WAN protocols and cost less. Inside a SCADA system a PLC plays the RTU role; inside a DCS it’s a local controller; on its own it’s a PLC-based system.

IED (Intelligent Electronic Device). Field devices with their own brains — protective relays being the prime example in power systems. An IED may be polled directly by the control server or aggregated through a local RTU, and critically, it acts on its own protection logic without waiting for instructions from the center. Protection can’t afford a round trip to the control room.

Communications infrastructure. Everything between center and field: radio, microwave, cellular, satellite, fiber, leased lines, plus the modems, routers, and communication processors on both ends. Topologies range from point-to-point (simple, expensive per channel) through series and multi-drop arrangements that share channels at the cost of complexity. This layer is what makes SCADA SCADA — and it’s the layer with no equivalent in a DCS or a standalone PLC line.

What the other ICS types are

To place SCADA properly, you need to see what it’s being contrasted with.

DCS — Distributed Control System

A DCS controls a production process inside one geographic location: a refinery, a power generation plant, a chemical complex, a water treatment plant. The controllers are distributed across the facility — that’s the “distributed” — but everything sits on one site, on a fast local control network.

The control philosophy is different from SCADA. A DCS runs a supervisory control loop that actively coordinates a group of local controllers executing the process together, with tight coupling and short time constants. Feedback loops hold process variables at setpoint continuously. The DCS is the process control, not just a window onto it.

Rule of thumb: SCADA supervises things that are far apart and mostly autonomous. A DCS orchestrates things that are close together and interdependent.

The two also work side by side. A power generation plant runs on a DCS; the transmission grid it feeds runs on SCADA; the DCS talks to the SCADA system so generation output can follow transmission demand. Same enterprise, two ICS types, one interface between them.

PLC-based systems

PLCs show up inside both SCADA (as field controllers, doing RTU-like work) and DCS (as local controllers under the supervisory loop). But a PLC-based topology is also its own ICS type: smaller installations where one or a few PLCs control a discrete process — an assembly line, a packaging machine, a pumping skid — often with a local HMI and no central control server at all. Closed-loop control, minimal human involvement, no supervisory layer worth the name.

If your whole system is a PLC, an HMI panel, and a fieldbus, it’s an ICS. It’s not SCADA, and calling it SCADA in documentation invites scoping errors later.

SCADA vs DCS vs PLC-based at a glance

	SCADA	DCS	PLC-based
Geography	Wide area, dispersed sites	Single site or plant	Single machine or line
Primary goal	Centralized data acquisition + supervisory control	Continuous coordinated process control	Local discrete/logic control
Control loop location	Local (RTU/PLC); center supervises	Distributed controllers under a supervisory loop	In the PLC itself
Coupling	Loose, tolerant of comms loss	Tight, short time constants	Self-contained
Typical comms	Radio, cellular, satellite, leased lines, WAN	Plant control network, fieldbus	Fieldbus, local LAN
Typical sectors	Power T&D, pipelines, water networks, rail	Refineries, generation, chemicals, pharma	Manufacturing lines, packaging, machines
Typical protocols	DNP3, IEC 60870-5-104, Modbus, IEC 61850 (substations)	Fieldbus families, Modbus, proprietary	Modbus, PROFINET, EtherNet/IP

Real installations blur these lines constantly. A modern pipeline SCADA with fast IP links behaves partly like a distributed DCS. A large DCS spanning two plants starts to look like SCADA. The categories describe design intent, not rigid classes — which is exactly why the umbrella term ICS is useful.

Where the confusion comes from

Three reasons the terms get mixed up.

Historical shorthand. In critical infrastructure sectors — power especially — SCADA was for decades the only ICS most people touched. So “SCADA security” became the phrase for what is really ICS security, and it stuck. A lot of what gets published under “SCADA security” today applies to every ICS type and to plenty of systems with no SCADA component at all.

Vendor and media usage. Marketing material and news coverage use SCADA as a catch-all because it’s the recognizable term. When an incident hits a water utility’s PLCs, headlines say “SCADA attack” whether or not a SCADA system was involved.

Standards use different umbrella terms. This is the sneaky one. The three main reference frameworks each picked a different word for roughly the same scope:

Standard	Umbrella term	What it covers
NIST SP 800-82 Rev. 3	OT (Operational Technology)	ICS plus building automation, physical access control, transport, monitoring systems. Earlier revisions used “ICS” — the retitle to OT happened in Rev. 3 (2023).
IEC 62443	IACS (Industrial Automation and Control Systems)	Control systems plus the associated personnel, software, and networks that affect safe and reliable operation. Explicitly includes SCADA, DCS, PLCs, RTUs, IEDs, and safety systems.
IEC 62264	Enterprise-control system hierarchy	The functional levels from process (Level 0) to enterprise (Level 4) — the model the other two build on.

So a security engineer reads NIST and says OT, reads IEC 62443 and says IACS, reads older material and says ICS or SCADA — and all four can mean the same set of equipment. If you’re writing requirements, pick one term, define it once, and hold it through the document.

The level model: where SCADA and ICS sit in the stack

The cleanest way to see the relationship is the functional hierarchy from IEC 62264-1, which both NIST SP 800-82 and IEC 62443 adopt as their reference model:

• Level 4 — Enterprise. Business planning and logistics. ERP, scheduling, procurement. IT territory.
• Level 3 — Operations management. Production workflow, detailed scheduling, historians at the site level, MES.
• Level 2 — Supervisory control. Operator HMIs, alarms, supervisory functions, process history collection. This is where the SCADA server and DCS supervisory layer live.
• Level 1 — Basic control. PLCs, RTUs, DCS controllers, protection devices. The devices that actually close control loops. Safety and protection systems sit here too, logically or physically separated.
• Level 0 — The process. Sensors, actuators, the physical equipment itself.

The ICS spans Levels 0 through 3 (with 3 shared between the control and business worlds, which is why the IT/OT boundary and the DMZ conversation always lands there). SCADA, as a system, stretches from its Level 2 control center down through the communication layer to Level 1 field devices — but the term names the supervisory architecture, and the acronym points straight at Level 2.

When someone asks “is the PLC part of the SCADA system?”, the honest answer is: the PLC is a Level 1 ICS component that the SCADA system acquires data from and supervises. In loose usage it’s “part of the SCADA”; in an asset inventory or a security zone model, classify it at Level 1 and be precise.

What makes ICS different from IT systems

The SCADA/ICS/OT vocabulary exists because these systems can’t be treated like IT, and the differences are operational, not cosmetic. If you’ve worked plant-side, none of this will surprise you — but it’s the list that decides which IT security practices transfer and which ones break things.

Time behavior. ICS are time-critical. Some loops need deterministic response in milliseconds; jitter matters more than throughput. IT systems want throughput and tolerate delay. A security control that adds unpredictable latency is fine on a file server and disqualifying inside a control loop.

Availability. Industrial processes run continuously. Outages get planned weeks ahead. “Reboot it and see” — the default IT troubleshooting move — is not available when the component is holding a process at setpoint. That’s why redundant controllers running in parallel are standard where IT would settle for a restore-from-backup plan.

Consequence of failure. IT failures cost data and money. ICS failures can cost equipment, environmental damage, and lives. This is why every serious framework repeats the same rule: any security measure that impairs safety is unacceptable, full stop.

Patching reality. IT patches roll out automatically on a schedule. ICS patches wait for vendor validation, end-user testing, a planned outage window, and sometimes system revalidation — and a fair share of the installed base runs operating system versions the vendor stopped patching years ago. “Just patch it” is not a strategy at Level 1 and 2; compensating controls and segmentation are.

Resource constraints. Field devices run real-time operating systems with no spare capacity for agents, encryption, or logging. Plenty of deployed devices can’t do password protection properly. Security has to be built around them, at the network and architecture level, because it can’t be installed on them.

Support model. IT tolerates mixed vendors and third-party tools. ICS support often comes from a single vendor whose license terms void support if you install third-party software. Your endpoint security choices may be made for you by a service agreement.

Priority order. The standard framing: IT ranks confidentiality first, then integrity, then availability. ICS inverts it — availability first, integrity second, confidentiality last, because raw process values are near-worthless out of context, while a stopped process is expensive immediately. Individual zones can deviate (a safety system may put integrity on top), but the inversion is the reliable default and the reason IT security teams and control engineers talk past each other until someone writes it down.

Why the distinction matters for security

This is where sloppy terminology costs real money and real risk.

Scope definition. IEC 62443 asks you to partition your systems into zones and conduits and assign target security levels per zone. You can’t do that if “SCADA” in your documentation sometimes means the Level 2 servers, sometimes the whole plant, and sometimes the remote sites. A zone model built on fuzzy terms produces fuzzy boundaries, and fuzzy boundaries are where attacks live.

Different architectures, different threat surfaces. SCADA’s defining feature — wide-area communication over radio, cellular, satellite, and leased lines — is also its defining exposure. Field sites are physically remote, often unmanned, sometimes reachable by legacy dial-up or poorly segmented WAN links. A DCS has almost none of that; its exposure concentrates on the IT/OT boundary at Level 3, the engineering workstations, and vendor remote access. A PLC line’s exposure is often a technician’s laptop and a USB port. One security checklist written for “SCADA/ICS” without distinguishing these will over-protect some surfaces and miss others.

Security priorities are inverted from IT, but differently per type. Across all ICS, availability and integrity outrank confidentiality — the reverse of typical IT systems, where confidentiality leads. But within that: a transmission SCADA outage means loss of visibility over a grid; a DCS outage means a running chemical process loses its coordinating brain. The consequence models differ, so the countermeasure trade-offs differ. Latency added by a security control that’s invisible on a SCADA polling cycle can be unacceptable inside a DCS loop.

Procurement and compliance language. Regulations and standards apply per system type in some sectors. If a compliance obligation targets “SCADA systems” and your site runs a DCS, you need to know — precisely — whether you’re in scope. Engineers who treat the words as interchangeable can’t answer that question.

Quick decision guide: which term to use

• Talking about the whole discipline of securing industrial systems? Say OT security (current NIST usage) or ICS security (still widely understood). Both beat “SCADA security” unless SCADA is literally the system in question.
• Writing under IEC 62443? Use IACS, because that’s the defined term the requirements attach to.
• Describing a wide-area supervisory system with a control center and remote sites? That’s SCADA. Say SCADA.
• Describing plant-wide continuous process control on one site? That’s a DCS. Don’t call it SCADA.
• One controller running one machine or line? PLC-based system. Also not SCADA.
• Unsure, or covering several types at once? ICS is the safe umbrella.

FAQ