Do You Need ICS or SCADA Penetration Testing? A Decision Guide

You need ICS or SCADA penetration testing if your organisation runs equipment that controls a physical process. That could be a production line, a treatment plant or a building management system. The key question is connectivity: is that equipment linked, even indirectly, to your corporate network or the internet? An isolated, genuinely air-gapped system carries far less risk than one with a remote vendor link, a cloud dashboard or a shared network switch.

That single question, whether you have any connectivity into the control environment at all, settles the matter for most organisations faster than any framework or checklist.

What is ICS and SCADA penetration testing, briefly?

It is a controlled, authorised assessment of the systems that monitor and control physical processes. That includes programmable logic controllers (PLCs), remote terminal units (RTUs), human-machine interfaces (HMIs) and the networks connecting them. Industrial control systems (ICS) is the broad term. SCADA describes systems used to supervise equipment spread across a wide area, such as a pipeline or a power network. Testers usually treat the two together as operational technology (OT), distinct from standard IT.

The difference from ordinary IT testing is not the target’s importance. It is the tolerance for disruption. The NCSC’s guidance on operational technology notes that OT prioritises safety, reliability and availability. IT security, by contrast, usually puts confidentiality and integrity first. The reason is simple: a failure here can cause physical harm, not just data loss.

Who actually needs ICS SCADA penetration testing?

A few groups have the clearest case:

• Manufacturers with networked PLCs or an HMI reachable from the office network.
• Utilities and energy operators, particularly those forming part of the UK’s critical national infrastructure.
• Water and wastewater operators running remotely monitored treatment processes.
• Facilities and logistics teams whose building management or warehouse control systems have gained internet or cloud connectivity.
• Any organisation that has recently added remote vendor access, cloud monitoring, or a new link between IT and OT networks. That change is usually where risk actually enters.

Many of these sectors sit inside UK regulatory regimes built around the Network and Information Systems Regulations. So much of the UK’s critical national infrastructure runs on OT that the NCSC has published guidance to help regulators and essential service operators meet those obligations.

What if we don’t operate in a regulated sector?

Regulation is a driver, not the whole picture. A mid-sized manufacturer outside any formal CNI or NIS scope can still have a production line stopped by a compromised remote access point. The cost of that downtime rarely cares whether a regulator was watching. Treat regulatory obligation as one reason to test, not the only one.

How is this different from just running a vulnerability scan?

A vulnerability scan checks a system against a database of known weaknesses and stops there. It does not confirm whether a weakness is actually reachable. On OT equipment, an aggressive scan can itself cause the outage you were trying to avoid, since many PLCs and RTUs were never built to withstand unexpected network traffic. Penetration testing goes further. But it should only be run by testers who understand where that line sits and how to stay on the safe side of it, typically starting with passive observation before any active technique is even considered.

What should a genuine ICS SCADA penetration testing engagement look like?

Expect a process that starts with scoping. Your operations team should be in the room, not just IT or security, and clear stop conditions get agreed before any testing begins. Passive reconnaissance usually comes first. Next comes an architecture and segmentation review, checked against a recognised model such as the zones and conduits approach in the ISA/IEC 62443 series of industrial cybersecurity standards. It applies much the same segmentation logic used in an internal network penetration test, aimed specifically at the IT/OT boundary.

Active exploitation, where it happens at all, tends to be reserved for staging environments or specific, pre-approved low-risk targets rather than live production equipment. NIST’s SP 800-82 guidance on industrial control systems security was written to account for exactly these performance, reliability and safety constraints. It is worth knowing about before a provider tries to sell you a generic infrastructure test with an OT label on it.

How do you tell a genuine OT specialist from a generalist offering the same thing?

Ask direct questions rather than trusting a service page. A provider who has done this work before can describe their stop process without hesitation. They can explain why they favour passive techniques early on, and tell you which framework their report will map findings against. One who cannot is likely to run the same methodology they would use on a corporate network and hope it translates. That is exactly the risk this whole exercise exists to avoid.

General accreditation is a useful, if partial, filter. CREST accreditation requires member firms to demonstrate robust governance, technically competent staff and proven methodologies. It is not an OT-specific credential, but a firm that cannot meet that general bar has no business being trusted with a live industrial network. Public sector and CNI buyers should also know about the NCSC’s CHECK scheme, which accredits providers specifically for testing government and critical infrastructure systems.

Aardwolf Security scopes penetration tests around the environment in front of us, rather than a fixed template, and that scoping conversation costs nothing to start if you want a second opinion on whether your OT connectivity needs testing.

What does a good report actually contain?

A report worth paying for reads differently for different audiences. Engineers and operations staff need to understand the affected zone, the operational risk and a remediation path that respects maintenance windows, not just a severity score. Leadership needs a short summary that explains business impact in plain terms. A weak report skips straight to a generic vulnerability list lifted from a scanner, with no translation into what it actually means for the process the system controls.

The most common findings are rarely exotic. Flat networks with no meaningful separation between IT and OT top the list. Default credentials left over from commissioning are close behind, along with outdated firmware on PLCs and RTUs that has never had a maintenance window for patching. Remote access paths, such as vendor support links or cloud dashboards, quietly undo otherwise sound segmentation more often than not. A good report explains why each of these matters in your specific environment, rather than listing them as if every organisation faces identical risk.

Frequently asked questions

How urgent is ICS SCADA penetration testing if we’ve never done it before?

Urgency tracks connectivity, not company size. If your control network has any link to IT, the internet or a remote vendor, treat a first assessment as a near-term priority. Do not fold it into a routine annual testing cycle and wait your turn. If you want help working out where to start, our team is easy to get in touch with for a no-obligation scoping conversation.

Will testing risk shutting down our production line?

A properly scoped engagement is built specifically to avoid that outcome. It uses passive techniques and staging environments rather than blind active testing against live equipment. The risk comes from skipping that scoping, not from testing itself.

Is a penetration test the same as a compliance audit?

No. An audit checks whether documented controls and processes exist. A penetration test checks whether an attacker could actually get through them in practice. It is a different, complementary question.

What’s the first thing we should commission if budget is limited?

A passive architecture and segmentation review. It identifies the highest-impact structural risks, such as a flat network between IT and OT, without any active testing. It usually shapes what a fuller engagement should focus on afterwards.