How to Scope IT-OT Penetration Testing Safely

Scoping a penetration test in an IT environment is a problem of boundary definition. Scoping one in an operational technology (OT) environment is a problem of consequence management. The question is not just what to test, but what happens if something goes wrong during testing. 

On a factory floor, the answer to that question can involve production shutdowns, safety incidents and equipment damage. Getting scope right is not a formality. It is the difference between a useful engagement and a crisis. The stakes are not theoretical: in Fortinet’s 2025 State of Operational Technology and Cybersecurity Report, 50% of organizations surveyed reported one or more cybersecurity incidents in the past year.

The Core Tension You Have to Resolve First

OT environments run on availability. A historian server, a distributed control system (DCS) controller or a human-machine interface (HMI) going offline for ten minutes during testing can stop a production line, trigger alarms across a plant or, in the worst case, affect safety instrumented systems. Security testing that causes that outcome is not a success, regardless of what it finds. The risk is documented, not hypothetical. NIST records a natural gas utility whose pen testers, hired to test the corporate IT network, strayed into a segment connected to the supervisory control and data acquisition (SCADA) system. The test locked up SCADA and stopped gas delivery to customers for four hours. NIST also records a ping sweep that hung a control system in a chip plant and destroyed $50,000 worth of wafers.

At the same time, testing that excludes everything sensitive produces a false picture of your security posture. The systems that are hardest to test are often the ones most likely to be targeted. Resolving this tension requires a scoping methodology that is honest about what can be tested safely and what requires a different approach.

Building the Scope From Your Asset Inventory

You cannot scope what you cannot see. The starting point for any IT-OT pen test scope is a current, accurate asset inventory. That means every device on the OT network, not just what appears in a configuration management database (CMDB) or network diagram that was last updated two years ago. Passive discovery techniques, such as traffic mirroring and protocol analysis, can build that inventory without sending a single packet to a live device. The visibility gap is the norm, not the exception: Dragos found that 80% of its 2022 service engagements had a lack of visibility across OT networks. 

Once you have the inventory, categorize assets by criticality and testability. Safety instrumented systems are excluded without exception. Any system with a direct connection to physical process control requires a specific justification for active testing, documented approval from operations leadership and a rollback plan. Engineering workstations and historian servers that sit at the IT-OT boundary are typically testable with appropriate controls in place.

Passive First, Active Only Where It Is Safe

The safest and most informative starting point in any OT environment is passive reconnaissance. Monitoring network traffic at a span port or tap reveals what is communicating, what protocols are in use, what credentials are passing in cleartext and what the real network topology looks like versus the documented one. This produces actionable findings with no risk to production systems.

Active testing should follow only where it has been explicitly approved, the blast radius of a failure is contained, and the operations team has been briefed. That means testing in maintenance windows where possible, with operations staff available to respond, and with a clear abort condition defined in advance. The rules of engagement for an OT pen test are not a legal formality. They are an operational safety document.

What the Scope Document Must Include

A well-constructed IT-OT pen test scope document covers more ground than its IT equivalent. Beyond the standard system list and IP ranges, it needs to define the testing methodology per zone, the conditions under which active testing is permitted, the change control requirements before the engagement starts and the communication chain if something unexpected occurs during testing. This zone-based structure follows IEC 62443 from the International Electrotechnical Commission, and Special Publication 800-82 from the National Institute of Standards and Technology (NIST) gives matching guidance for testing operational technology.

Both the security team and operations leadership should review and sign off on the scope document. Security teams sometimes scope engagements without fully consulting the people who run the plant. That leads to surprises during the engagement that damage trust between security and operations and make future testing harder to approve. 

Validating Your Scope Before the Engagement Starts

Even experienced teams miss things in OT scope reviews. Vendor remote access paths that are not in the asset register. Wireless access points installed for temporary maintenance that were never removed. Cloud connections from process historians that were set up by the OT vendor and are not documented anywhere in the security team's records.

A structured scope review process that specifically looks for these categories of missing scope reduces the risk of an engagement that either causes an incident or produces an incomplete picture. The goal is to go into the engagement knowing what you are testing, what you are deliberately excluding and why. Expect the review to find something: in the same Dragos engagement data, 53% of engagements included a finding of external connections into the OT network from equipment makers, IT networks or the internet.

Scope is where an OT engagement succeeds or fails. Book a scoping workshop and walk into your next test with the asset inventory, zone map and test boundaries settled before anyone sends a packet.