OT Security Assessment vs Penetration Test: Which One Does Your Plant Need First?

If you run a cement, mining or aggregates plant and someone has asked for "a security test", the first decision is not which firm to hire. It is which of two different things you are buying. An OT security assessment documents what is on the control network, how it connects, and where it falls short of a target architecture. A penetration test tries to get in and reports what worked on the day it ran. One is a map of the plant. The other is a single trip across it.

On how often: neither ISA/IEC 62443 nor NIST SP 800-82 fixes a calendar interval for assessing an industrial control system. Both expect the picture to be redone when the system changes in a meaningful way, and reviewed on a schedule the asset owner sets and writes down. In practice that means a full topology assessment once per plant to establish the baseline, a refresh after any project that adds or moves equipment, and a lighter review at a fixed interval between those events. A penetration test, where it belongs in OT at all, comes after the assessment and only against the parts of the network the assessment showed can take it.

What an OT security assessment produces

An assessment is a documentation exercise with an engineering standard behind it. The output is an asset inventory of every controller, HMI, historian, server and switch on the OT network, with a photograph of where each one sits. It includes drawings of the network as it is actually built, by production area, next to a drawing of where it should be. Each gap between the two becomes a finding with a severity, mapped to Purdue Model levels and ISA/IEC 62443 zones, and each finding links to a recommendation on a roadmap.

The method matters as much as the output. A proper OT assessment is passive first. Engineers observe traffic on a monitoring port, read configuration exports that your own staff run, and walk every electrical room and cabinet with a plant escort. Nothing is configured, nothing is injected, and control logic is never opened. The walkdown is what gets the serial links, fieldbus segments and standalone machines into the inventory. A scan from a laptop in the control room only documents the devices that answer on IP.

What a penetration test produces

A penetration test is an attempt to reach something you did not intend to be reachable, under written rules of engagement, inside an agreed window. The report lists the paths the tester took, what they reached, and what stopped them. Its value is that it proves a specific control fails, with evidence, rather than arguing that it might.

In OT the limits are real. Active traffic can upset the controllers it reaches, so a responsible test keeps Level 0 and Level 1 out of scope and treats anything in the control layer as read-only at most. The result is a snapshot: it tells you what was exploitable that week, with those credentials, from that starting point. And on a flat plant network the findings tend to repeat what a topology review already shows. The tester lands on the office side, finds a route straight to an HMI, and writes "segment the network". You paid for a sentence that the assessment would have given you with the drawing to act on.

Why the order matters

A penetration test on an undocumented network answers a question you already know the answer to. If the plant historian, the batch controller and the file server share one network, there is no mystery about whether an attacker could move between them. The useful question is which boundaries should exist, where, and what it takes to build them without stopping production. That is what the assessment answers, and it is the input every later decision depends on, including whether to test at all.

The order also matters for the people who review your program. Audit and insurance questionnaires tend to ask whether segmentation is documented and verified, and who owns the drawings. A penetration test report on its own does not answer that. An assessment report with rated findings and evidence does.

When a penetration test is the right call

There are good reasons to commission one, and they all come after the baseline exists:

• A remediation phase has finished and you want independent proof that the industrial DMZ, the remote access path or the firewall rules do what the drawings say.
• A new remote access service for OEM vendors is going live and you want it tried before the vendors use it.
• A customer contract, insurer or regulator asks for one by name.

In every case the scope should be written against the assessment: which zones are in, which are out, which accounts the tester holds, and who at the plant can stop the work. Safety systems stay out of scope without exception.

How often, in practice

A workable cadence for a multi-plant operator looks like this. Establish the baseline once per plant with a full assessment. Refresh the drawings and the inventory after every project that touches the network, which means tying the refresh to change control so a project cannot close with the documentation still showing the old state. Review the whole picture at a fixed interval the OT owner writes into the plan, and use that review to decide whether a penetration test of a specific boundary is worth running that year.

What breaks this cadence is not the interval. It is the assumption that the drawings are still right because nobody changed them on purpose. Plants that grew by acquisition and integrator projects rarely have a single owner of the topology, so each refresh starts from scratch. Our earlier post on the Purdue Model in practice walks through what that drift looks like level by level.

Where to start

If you have neither, start with the assessment. Pick the plant where the next capital project is planned, document it before the project starts, and let the findings set the scope for everything that follows. The Topology Assessment page describes what we deliver and what access we need on site.