What an OT/ICS pentest report must contain

The executive summary and its distribution obligations

The executive summary is the page a board member reads and the section a regulator opens first. It states what was tested, the overall risk posture across the tested zones, and the three to five findings with the highest operational consequence. Write it to one page. Every other decision about depth, format, and sequencing follows from whether this page is clear.

Before any finding is listed, the summary must carry the report classification level and its distribution list. A typical OT/ICS pentest report is marked CONFIDENTIAL and distributed to the asset owner, the OT team lead, the CISO, and any regulator named in the engagement letter. In the UAE, DESC and NESA expect evidence packs with defined recipient sets when a submission accompanies an assurance review. Listing the distribution on the first page is not a formality: it sets the legal and regulatory status of the document from the moment it leaves the engagement team.

Where the engagement covers infrastructure under a national critical information infrastructure protection regime, the summary should confirm whether a regulatory submission is planned, who will carry it, and which evidence appendices support it. The CISO reading this section needs to know whether the document in their hands is the evidence pack they file with a regulator or the working document they hand to the remediation team. Both are legitimate purposes; they require different handling.

Scope, zones, and the testing constraints the report inherits

The scope section records what was tested and, equally, what was not. List every asset by tag and IP address, the network zone it belongs to, the protocols in scope, and the safety constraints applied during the engagement. An OT test almost always excludes write operations to certain registers, specific times of day, and PLCs that have no warm standby. Those exclusions belong here, stated precisely, so a reader who later finds an untested path cannot assume it was within scope.

The methodology block names the standard the work was conducted against. NIST SP 800-82 is the primary guide for industrial control system security assessment; state the revision in use. Agreeing depth, protocol coverage, and zone access before day one is the subject of how to buy an OT/ICS pentest; what this section records must match what the proposal agreed. A discrepancy between contracted scope and reported scope is a gap a technical auditor will note.

State the testing window with its rationale. An engagement run during a scheduled maintenance window with production halted carries a different risk profile than one run against live equipment with a safety observer on standby. State which it was, who the named safety contacts were, and what the emergency stop procedure was. The operations team inheriting this report needs to understand how the test was conducted before they can plan a remediation sequence.

Vulnerability findings and the IEC 62443 classification

Each finding must stand alone. A finding that requires the reader to cross-reference three other sections to understand what it means will not be acted on. State the affected asset, the vulnerability class, the attack path, the potential consequence in operational terms (loss of view, loss of control, unsafe state), and the evidence. A file name is not evidence. The capture itself, the reproduction steps, and the affected register or function code are evidence.

Map every finding to an IEC 62443 zone and conduit. IEC 62443 organises an industrial control system into zones of differing trust, connected by conduits, and assigns a security level target to each zone based on the consequence of a compromise. A finding in Zone 2 (a process cell) that crosses the conduit to Zone 3 (the SCADA network) has a different remediation scope and regulatory weight than one contained within a single zone. Without this mapping the operations team cannot identify which compensating controls apply, and the remediation owner cannot scope the fix without re-reading the appendices. The table below shows a structured finding format using the IEC 62443 zone model.

CVSS scoring applies to OT findings, but the base score alone is not sufficient. An unauthenticated write to an output register may score 9.1 under the FIRST CVSS framework, but the operational consequence depends on whether the process is safety-critical. Annotate each finding with the operational consequence class: loss of view, loss of control, loss of safety, or manipulation of view. MITRE ATT&CK for ICS provides the tactic and technique classification that makes this annotation systematic. The Modbus/TCP unauthenticated command injection article shows how a technique-level description changes the priority a finding receives in a real OT environment.

The risk and remediation matrix

A remediation matrix gives the operations team a decision tool, not a to-do list. Plot findings on two axes: operational risk (what breaks if exploited, and at what speed) and remediation effort (calendar time to deploy a confirmed fix, not engineer hours). A finding with a patch available and a deployment path through the next maintenance window sits in a different cell than one requiring a firewall policy change agreed across three operational and network teams. The matrix makes that distinction visible before any work is scheduled, and it is the section an operations manager and a CISO will look at before any other.

Label each finding's remediation category explicitly: patch available, configuration change, compensating control, or architecture change. Each category has a different owner and a different approval path inside an OT environment. A configuration change to a PLC parameter is an engineering change request with its own safety review. A compensating control that adds a firewall rule between zones is a network change requiring network team sign-off. An architecture change that reroutes a conduit is a project with a capital budget and a shutdown window. These ownership boundaries must be visible in the report, because an OT change cycle runs to weeks or months, not the hours of a server patch.

Verifying fixes on live OT equipment

The retest section of an OT report carries different weight than its equivalent in an IT assessment. Confirming that a PLC firmware update was applied, that a firewall rule is in place between zones, or that an authentication requirement is enforced cannot be done on an ad hoc basis. Every fix must be verified inside a scheduled maintenance window, with the safety interlock state documented before and after the change. The verification record is not optional: it is the evidence that a finding is closed.

For each finding, the report must specify the verification procedure. A finding patched at firmware level is verified by reading the version string and confirming the vulnerable function code is no longer reachable. A finding addressed by a firewall rule is verified by replaying the same traffic and confirming the rule drops it. A compensating control limiting register access is verified by confirming which function codes are refused. Vague retest records stating confirmed fixed without supporting evidence do not satisfy a technical reviewer. The article on engineering workstation to PLC logic tampering illustrates why verification at the PLC level requires equipment-specific procedures.

Where a fix cannot be tested on live equipment before the next major maintenance window, state that explicitly in the report. Record the expected verification date and note which compensating controls are in place in the interim. An open finding with a verified compensating control and a committed verification date is a managed risk. An open finding with no stated path to verification is not. CISA guidance on industrial control system security describes the interim-control expectation in the context of critical infrastructure protection, and it aligns with what NESA and DESC reviewers look for when they open an evidence pack.

Technical appendices and evidence packaging

The appendices are the raw evidence that makes every finding reproducible. A finding that cannot be reproduced is not a finding. Each appendix should be indexed by finding number and contain the original network capture or screenshot, the commands run and their output, the firmware version string confirming the affected build, and the timestamp of the test. Where a tester used a constructed environment to demonstrate a risk, label it. Where the finding was demonstrated on live equipment, state the safety precautions taken during that demonstration.

Package the appendices with the same classification as the report body. A full packet capture of a process network is sensitive data: it reveals asset inventory, protocol configuration, and register maps that are directly useful to an attacker with network access to the environment. In an infrastructure pentest context an appendix is typically shared with the operations team and deleted after remediation; in an OT report the retention and destruction schedule belongs in the document itself. State it on the cover page and confirm it in the engagement letter. What your team can observe during a test, as detailed in what your OT monitoring should catch during an ICS pentest, is only actionable if the evidence the appendix preserves is complete.

OT/ICS pentest reports in the UAE regulatory context

In the UAE, the obligations attached to an OT/ICS pentest report depend on which sector the asset owner operates in. NESA governs critical information infrastructure and publishes the UAE Information Assurance Regulation, which requires operators to conduct and document security assessments. NESA's Critical Information Infrastructure Protection (CIIP) framework specifically addresses OT and SCADA environments, and a pentest report submitted as assurance evidence must be structured to support an Information Assurance Report. Without a classification level, a distribution list, and a finding-level evidence pack, the document does not satisfy what NESA expects from a CIIP submission.

Dubai entities that supply services to government or manage critical systems fall under DESC, the Dubai Electronic Security Centre, which issues its own information assurance standards. DESC expects structured security testing evidence, and a report that names findings without supporting evidence appendices does not meet the submission bar. Abu Dhabi healthcare operators are bound by ADHICS, administered by the Department of Health, which requires documented security testing of connected operational systems. The Central Bank of the UAE framework applies to financial institutions operating OT-adjacent infrastructure, such as payment processing systems with physical control components.

For an OT pentest engagement covering infrastructure with cross-emirate reach, the report may need to satisfy both Abu Dhabi and Dubai regulatory submissions simultaneously. The classification and distribution structure agreed at the start of the engagement, and documented in the executive summary, is what makes that possible. A single well-structured report can serve as both the CISO's working document and the regulator's evidence pack. The federal baseline is the UAE Information Assurance Regulation, available from the TDRA, which both emirate-level frameworks build on.

Frequently asked questions