How to buy an OT/ICS pentest: scope, safety and what the proposal must say

Why buying an OT/ICS pentest differs from buying an IT test

An IT penetration test and an OT/ICS pentest share a methodology at their core, but the procurement process for the two is not the same. The systems being tested in an OT engagement control physical processes: a valve, a conveyor, a power relay, a pump. A misconfigured test against a corporate web server may cause a service outage lasting minutes. The same error against a PLC managing a cooling circuit carries consequences that an IT team cannot resolve by restarting a service.

The tester's qualifications, the scope definition, the safety constraints and the report format all need to be evaluated differently. A vendor who performs well on infrastructure penetration testing may have no exposure to industrial protocols such as Modbus or DNP3, and that gap is not always visible in a generic proposal. This guide covers what to ask for, what to exclude from scope and how to read a proposal for genuine OT competence.

The procurement difference is not bureaucratic. In an OT environment, an error is measured in operational disruption, not service recovery time. Understand that before you choose a vendor.

Defining scope: what to test and what to protect

OT environments contain several distinct layers: field devices such as PLCs and RTUs, the control layer of HMIs and engineering workstations, the supervisory layer of SCADA systems and historians, and the connections between those layers and the corporate IT network. A single engagement rarely covers all of them, and trying to do so increases both cost and operational risk without proportionate return. Start by identifying where you want assurance, not by listing everything that exists.

The IT-OT boundary is almost always worth testing. The path from a domain-compromised workstation into the control network, the kind of chain described in engineering workstation to PLC: how control logic tampering happens, can often be assessed through passive traffic analysis and credential testing without interacting with live control devices. That scope stays within safe operating bounds and produces findings that operations staff can act on.

Define exclusions with the same precision as inclusions. Sending write commands to PLCs, modifying controller setpoints and testing during production hours should be explicitly excluded unless you have isolated test hardware or a confirmed maintenance window. A vendor who treats these exclusions as negotiating positions is not a vendor to shortlist. The exclusions protect your operation and are not obstacles to a thorough assessment.

Scope creep is a risk in OT engagements in both directions. A scope that expands during the engagement to include live device testing not agreed in advance creates operational risk. A scope that shrinks because the vendor is uncomfortable with the OT environment produces findings that do not reflect the real attack surface. Agree the scope in writing, have it signed by both sides and hold to it.

Safety protocols the engagement must follow

Every OT/ICS pentest must have a written safety plan before any testing begins. The plan names the systems in scope, the actions that are explicitly prohibited, the conditions under which testing will be paused or stopped, and the person authorised to call a halt. This document is part of the authorisation, not an appendix to be reviewed after the engagement starts.

Passive reconnaissance, capturing and analysing network traffic without sending any commands, carries far lower operational risk than active interaction. It can reveal unencrypted Modbus sessions, unauthenticated HMI connections and protocol anomalies without putting any device at risk. Active testing against PLCs or RTUs, if it is required at all, should be conducted against isolated or decommissioned hardware, or reserved for a maintenance window with operations staff present.

Operations staff, the engineers who run the control system daily, must be involved in safety planning and must sign off on the plan before work begins. They will know which devices are running near capacity, which maintenance windows are genuinely available and which constraints the IT team may not know about. Their sign-off is part of the authorisation document, not a courtesy notification.

What a credible OT/ICS pentest proposal must contain

A proposal that lists tools, hours and a standard CVSS finding format is not sufficient for an OT/ICS engagement. The document must show that the vendor understands the technical requirements and the operational constraints of the environment. The table below shows the elements a credible proposal must contain, what to look for in each and what signals a firm is not equipped for this work.

The methodology section should reference the MITRE ATT&CK for ICS matrix and NIST SP 800-115 or equivalent technical testing guidance. Those references tell you the vendor maps findings to a recognised framework, so you can track the same attack categories across engagements and compare results year on year. A vendor who produces a bespoke finding taxonomy with no external anchor makes that comparison impossible.

The deliverable section is where proposals most often disappoint. Ask whether remediation guidance will be written for an OT context: a high-severity finding against a 15-year-old PLC that cannot be patched requires a network segmentation or monitoring recommendation, not a patch deadline that cannot be met. Reviewing what your OT monitoring should catch during an ICS pentest alongside the proposal gives you a baseline for the detection coverage a good engagement should address.

Evaluating whether a vendor is qualified for this work

OT security is a narrow specialism. Ask the vendor directly to name the industrial protocols they test against: Modbus, DNP3, EtherNet/IP, Profinet, IEC 61850 and BACnet are the common ones across industrial and building management contexts. A firm with a red team background and no OT work is not qualified for this engagement regardless of their IT record. Purple teaming may help assess detection coverage in a later exercise, but the initial pentest requires domain knowledge that general IT methodology does not provide.

Request a sanitised sample report from a comparable OT engagement before the shortlisting stage. A strong OT report contains network topology diagrams of the control network, protocol-level findings with traffic captures where relevant, and remediation advice that distinguishes patchable vulnerabilities from those requiring compensating controls. A report that reads as a standard web application assessment with OT terminology inserted shows the firm has not adapted its practice to industrial environments.

References to the NIST Cybersecurity Framework in a proposal are reasonable as a structural anchor, but confirm that OT-specific controls accompany them. A vendor whose methodology describes identify, protect and detect in IT terms but has no position on zone and conduit architecture, unidirectional gateways or Purdue model segmentation has not built an OT practice. Ask specifically about those topics during the evaluation call and note whether the answers come from experience or from a framework document.

OT and ICS security testing in the UAE

The UAE hosts oil and gas processing, electricity generation, water treatment, transport management and port logistics systems, many of which depend on industrial control networks in Dubai and Abu Dhabi. Federal entities and their suppliers operating supervisory systems fall under the UAE Information Assurance Regulation published by TDRA, which sets minimum security controls across information and operational technology alike.

DESC governs Dubai government entities and the suppliers who deliver technology services to them. An organisation providing operational support to a Dubai government entity is subject to DESC requirements that may include security testing of the operational systems in scope. In Abu Dhabi, entities in the healthcare sector are bound by ADHICS, and organisations in the energy and utilities sector work under the requirements of their licensing authority. CBUAE requirements apply to financial institutions, including those running operational technology for payment infrastructure.

Organisations procuring an OT/ICS pentest in either emirate should prepare a written authorisation naming the systems under test, the testing window, the methods permitted and the operational contact for the systems in scope. UAE regulators expect documented authorisation for security testing that affects operational systems. A verbal agreement or a general penetration testing mandate does not satisfy that requirement. The IT team and the operations staff who run the systems being tested should both review the authorisation letter, and a copy should be retained for any regulatory review.

Frequently asked questions