Most OT security programmes look sound on paper, yet an auditor walking a plant floor often finds an unlisted engineering laptop, a vendor modem nobody remembers approving and a backup of a controller project file that has never been restored. This checklist is the field document for an operational OT security audit at one site or one production area: it records what was checked, how it was checked and what evidence was seen for asset inventory, internet exposure, remote access, accounts, segmentation, monitoring and recovery. It is written for OT security leads, site engineering managers, internal auditors and the integrators who support them. It is deliberately narrower than the programme view in the OT Security Programme Health Check and does not restate the rules in the OT Security Policy Template: it tests whether those rules are true on the ground today.
How to use this template
- Copy the checklist for each site or production area. Replace text in square brackets, such as [Organisation], [Site] and [90 days], with your own values. Bracketed numbers are suggested defaults, not external requirements.
- Mark each check Pass, Fail, Partial or Not tested in the Result and evidence column, and record where the evidence is kept (photo, configuration export, ticket number, log extract). A check without evidence is recorded as Not tested, never Pass.
- Prefer observation over interview. "The engineer said the modem is unplugged" is weaker evidence than a photo of the unplugged modem and a firewall log showing no sessions.
- Agree a safety brief with operations before any active check. Passive observation, configuration review and document inspection come first; any scanning of live control networks needs written operations approval, a named engineer present and a stop condition. The OT Security Assessment Guide covers assessment method in depth.
- Run sections 1 to 8 for a full audit. For a focused check (for example after a remote access change) run section 1, the relevant section and section 9.
1. Audit record
| Field | Entry |
|---|
| Audit ID, dates and site | [OTA-2026-04] [Dates] [Site, production area] |
| Process and safety context | [Process type, safety instrumented systems present yes/no, hazardous areas] |
| Scope boundary | [Purdue levels or IEC 62443 zones in scope, for example Level 1 to Level 3.5, excluding the safety system] |
| Reference documents | [OT security policy version, zone and conduit drawing version, asset register export date] |
| Auditor, site sponsor and operations contact | [Names and roles; operations contact with authority to stop the audit] |
| Active testing approved | [None / Listed checks only, approval reference] |
| Overall result | [Satisfactory / Satisfactory with findings / Unsatisfactory] |
2. Asset inventory
The joint CISA and partner guidance Foundations for OT Cybersecurity: Asset Inventory Guidance (August 2025) sets out five steps: define scope and objectives, identify assets and collect attributes, create a taxonomy, manage and collect data, and implement life cycle management. It lists high-priority attributes including protocols, criticality, asset number, role, hostname, IP and MAC address, logging, manufacturer, model, operating system, physical location, ports and services, and user accounts. These checks test whether the register meets that bar. The OT Asset Register Template gives a register layout and the OT Asset Visibility Guide covers discovery methods.
| # | Check | How to verify | Result and evidence |
|---|
| 2.1 | A register exists for the site, has a named owner and was updated within [90 days] | Export with date; owner named in register or RACI | [ ] |
| 2.2 | Sample reconciliation: [10] devices picked on the floor are all in the register with correct location, model and firmware | Walk-down photos of nameplates against register rows | [ ] |
| 2.3 | Reverse sample: [10] register rows picked at random exist and are where the register says | Walk-down record | [ ] |
| 2.4 | Passive network data (monitoring sensor or switch tables) shows no unlisted IP or MAC addresses in scope | Comparison report; list of unknowns with disposition | [ ] |
| 2.5 | Each asset carries a criticality rating and is assigned to a zone | Register fields populated for all rows in scope | [ ] |
| 2.6 | Transient assets (engineering laptops, USB programming cables with adapters, vendor test kit) are listed with custodian | Transient asset log; physical check of the engineering cabinet | [ ] |
| 2.7 | Accounts and remote access paths are recorded per asset (local users, vendor accounts, modems, cellular routers) | Register fields; cross-check with section 4 | [ ] |
| 2.8 | Changes in the last [6 months], including emergency changes, are reflected in the register | Pick [3] closed change records and confirm register updates | [ ] |
| 2.9 | End of support status is recorded and each unsupported asset has a compensating control or replacement date | Register field; risk register entries | [ ] |
3. Internet exposure and boundary
CISA, FBI, EPA and DOE list removing OT connections to the public internet as the first of their primary mitigations for OT. This section confirms nothing in scope is reachable from the internet and that the IT to OT boundary is what the drawings show.
| # | Check | How to verify | Result and evidence |
|---|
| 3.1 | No OT asset or OT management interface answers from the public internet | External attack surface report for all site public IP ranges and cellular router addresses, dated within [30 days] | [ ] |
| 3.2 | No undeclared cellular or broadband routers in control panels | Panel walk-down; photo log; spectrum or carrier account review where available | [ ] |
| 3.3 | All IT to OT traffic passes through a demilitarised zone (DMZ); no direct routes from enterprise to Level 2 or below | Firewall rule export reviewed against the conduit drawing | [ ] |
| 3.4 | Boundary firewall rules have owner, business reason and review date; no "any" source or destination | Rule export; sample [10] rules; see the Firewall Rule Review Checklist | [ ] |
| 3.5 | Boundary device firmware is current against vendor advisories and its management interface is reachable only from a management zone | Version against vendor advisory page; access list | [ ] |
| 3.6 | Data leaving OT (historian replication, cloud telemetry) flows outbound only, through a declared conduit | Rule direction and session logs; see the OT Process Historian Security Guide | [ ] |
4. Remote and third-party access
The same CISA mitigation set asks operators to secure remote access: prefer a private IP connection, and where remote access is needed use a VPN with strong passwords and phishing-resistant multifactor authentication, apply least privilege and disable dormant accounts. The NCSC-led Secure connectivity principles for OT add centralising and standardising connections and logging all connectivity. Design detail is in the OT Remote Access Guide; use the OT remote access and historian health check for deeper periodic review.
| # | Check | How to verify | Result and evidence |
|---|
| 4.1 | Every remote access path in scope is listed, and there is one approved route (or a small, documented set) | Path list against section 2.7 and 3.2 findings | [ ] |
| 4.2 | Remote sessions require phishing-resistant MFA | Gateway policy export; test login observed with a named user | [ ] |
| 4.3 | Remote sessions terminate in the DMZ or a jump host, never directly on a controller or HMI | Session path in gateway logs; conduit drawing | [ ] |
| 4.4 | Vendor access is off by default and enabled per job with a ticket and an expiry | [5] recent vendor sessions matched to approved requests; see the OT Remote Access Request Form Template | [ ] |
| 4.5 | Sessions that can change process logic are recorded or supervised by site staff | Recording sample; supervision log | [ ] |
| 4.6 | No remote account has been unused for more than [90 days] without being disabled | Last-login report from the gateway | [ ] |
| 4.7 | Each integrator or vendor with access has a current contract clause covering security obligations and notification | Contract register; see the OT Supplier Remote Access Assessment Template | [ ] |
5. Accounts, credentials and machine identities
OT accounts include far more than named operators: shared HMI logins, engineering workstation accounts, service accounts used by historians and OPC servers, controller passwords and the keys or certificates on gateways. These are non-human identities in practice and are often the least reviewed. The OT and ICS Identity and Access Guide covers the model.
| # | Check | How to verify | Result and evidence |
|---|
| 5.1 | No device in scope uses a manufacturer default password | Sample [10] devices across types; credential vault entries; vendor default lists checked | [ ] |
| 5.2 | Shared accounts are listed with the people who know the password, and the password changes when someone leaves | Shared account list; last change date against leaver records | [ ] |
| 5.3 | Service accounts (historian, OPC, backup, antivirus update) have an owner, minimum rights and no interactive logon | Account properties export | [ ] |
| 5.4 | OT administrative accounts are separate from enterprise accounts, or enterprise trust into OT is documented and limited | Domain trust configuration; admin group membership | [ ] |
| 5.5 | Controller and safety system passwords or key switches are in a controlled state (run mode, key removed and stored) | Photo of key position; key log | [ ] |
| 5.6 | Certificates and keys on gateways and remote access devices have known expiry dates and an owner | Certificate list with expiry | [ ] |
6. Segmentation and zones
Zones and conduits come from IEC 62443 and are covered in the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide. The audit question here is narrower: does traffic actually match the drawing?
| # | Check | How to verify | Result and evidence |
|---|
| 6.1 | A current zone and conduit drawing exists and is dated after the last architecture change | Drawing version; change log; the OT Zones and Conduits Worksheet Template if used | [ ] |
| 6.2 | Observed flows between zones match permitted conduits | Flow summary from monitoring sensor or firewall logs over [7 days]; list of unexpected flows | [ ] |
| 6.3 | Safety instrumented systems sit in their own zone with only declared connections | Drawing and switch or firewall configuration | [ ] |
| 6.4 | No dual-homed hosts bridge zones outside a controlled conduit | Interface lists on HMIs, historians and engineering stations | [ ] |
| 6.5 | Unused switch ports in control cabinets are disabled or physically locked | Switch configuration; sample cabinet inspection | [ ] |
| 6.6 | Wireless in scope (process wireless, maintenance Wi-Fi) is listed, segmented and uses current encryption | Controller configuration; site survey record | [ ] |
7. Monitoring, logging and change detection
| # | Check | How to verify | Result and evidence |
|---|
| 7.1 | Boundary firewall, remote access gateway and jump host logs are collected centrally and retained for [12 months] | Log source list; oldest retained event | [ ] |
| 7.2 | Passive network monitoring covers the conduits in scope | Sensor placement against the drawing; see the OT Network Security Monitoring Guide | [ ] |
| 7.3 | Alerts exist for controller program download, mode change and firmware change, and someone reviews them | Alert rule list; [3] recent alerts with disposition | [ ] |
| 7.4 | A test event (for example a planned remote login out of hours) produced an alert that reached the on-call responder | Test record with timestamps | [ ] |
| 7.5 | ICS advisories and the CISA Known Exploited Vulnerabilities catalogue are triaged against the register | Triage log; see the ICS Advisory Triage and OT Vulnerability Management Guide | [ ] |
| 7.6 | Removable media entering the site is scanned at a kiosk or controlled station | Kiosk log sample; observation | [ ] |
8. Backup, recovery and manual operation
The CISA, FBI, EPA and DOE mitigations end with practising the ability to operate manually and routinely testing continuity plans, fail-safes, backups and standby systems. A controller backup that has never been restored to a spare is an assumption. See the OT Backup, Recovery and Golden Image Guide for design.
| # | Check | How to verify | Result and evidence |
|---|
| 8.1 | Current backups exist for controller programs, HMI projects, historian configuration and engineering workstations | Backup list with dates against register criticality | [ ] |
| 8.2 | Backups match running versions (no drift) | Comparison for [3] controllers: running program against stored copy | [ ] |
| 8.3 | At least one copy is offline or immutable and stored away from the OT network | Storage location; access list | [ ] |
| 8.4 | A restore to spare hardware or a test bench was completed within [12 months] and timed | Restore test record with measured time | [ ] |
| 8.5 | Installation media, licences and licence dongles needed for rebuild are available offline | Physical check of recovery kit | [ ] |
| 8.6 | Manual or degraded operation was exercised within [12 months] and operators know the procedure | Exercise report; operator interview | [ ] |
| 8.7 | An isolation plan exists: who can disconnect the site from IT and external networks, and what keeps running | Plan document; named decision makers; see the OT Incident Response Guide | [ ] |
| Finding ID | Check reference | Description | Risk rating | Owner | Due date | Status |
|---|
| [F-01] | [3.2] | [Undeclared cellular router in Panel 4] | [High] | [Name] | [Date] | [Open] |
| [F-02] | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] |
- Rating rule: any Fail on 3.1, 4.2, 4.3, 5.1 or 8.7 is rated High by default and reported to [OT security lead] within [5 working days].
- Sign-off: auditor [Name, date], site sponsor [Name, date], operations [Name, date].
- Next audit: [Date, normally 12 months, or sooner after major change].
Implementation guidance
- Start with paper and passive data. Collect the register, drawings, firewall exports and gateway logs before visiting the site, so the walk-down tests specific claims.
- Pilot at one site. Run the full checklist at one site, time each section and remove checks that cannot produce evidence there; keep the removed check list so the gap is visible.
- Map to your frameworks once. The table below gives the main crosswalk. Store the mapping with the template so audit evidence can be reused for regulator or certification requests.
- Feed findings into change management. Remediation in OT usually needs an outage window; raise changes through the process in the OT Management of Change for Cyber guide rather than fixing on the day.
- Roll back safely. If any check disturbs the process, stop, record the event, restore the previous state with operations and continue only by passive means.
- Trend the results. Count Fail and Not tested per section across sites each year; a rising Not tested count usually means evidence is not being kept.
| Section | NIST SP 800-53 Rev. 5 | Primary guidance |
|---|
| 2. Asset inventory | CM-8 System Component Inventory | CISA and partners, OT asset inventory guidance (2025) |
| 3. Exposure and boundary | SC-7 Boundary Protection | CISA primary mitigations; NCSC secure connectivity principles |
| 4. Remote access | AC-17 Remote Access | CISA primary mitigations; NCSC secure connectivity principles |
| 5. Accounts | IA-2 Identification and Authentication | NIST SP 800-82 Rev. 3 |
| 6. Segmentation | SC-7 Boundary Protection | IEC 62443 zones and conduits; NIST SP 800-82 Rev. 3 |
| 7. Monitoring | SI-4 System Monitoring; AU-6 Audit Record Review | NCSC principle: log and monitor all connectivity |
| 8. Recovery | CP-9 System Backup; CP-4 Contingency Plan Testing | CISA primary mitigations (manual operation and testing) |
NIST SP 800-82 Rev. 3, the Guide to Operational Technology (OT) Security, was finalised on 28 September 2023; an initial public draft of Revision 4 was open for comment until 30 November 2026 when this page was checked, so confirm the current revision before citing it in audit reports.
Standards and references
This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: OT Security Guide · Top 10 OT Security Risks · OT Security Assessment Guide · OT Security Policy Template