Most OT networks have a segmentation diagram that nobody has tested against the traffic actually crossing the boundaries, so the review that signs off the architecture is often reviewing a drawing rather than the plant. This template is an editable worksheet for reviewing the security architecture of an industrial control system (ICS) site or system, and for validating that zones, conduits and boundary controls behave as designed. It covers scoping, evidence to collect, zone and conduit review, boundary and remote access checks, a segmentation validation test plan with safe test methods, identity and monitoring checks, and how to rate and report findings. It is written for OT security architects, assessors, plant engineering leads and the integrators who support them, and maps to IEC 62443-3-2 and 62443-3-3, NIST SP 800-82 Rev. 3 and the CISA Cross-Sector Cybersecurity Performance Goals. For assessment types and running an assessment safely, see the OT Security Assessment Guide; for design principles, the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide. This page is the review worksheet.
How to use this template
- Replace placeholders: text in square brackets, such as [Organisation], [Site], [System under review] and [Lead reviewer], is yours to set. Bracketed numbers are suggested defaults, not external requirements.
- One worksheet per system under consideration: run the review per site or per IEC 62443 "system under consideration", not for the whole enterprise at once. Large sites can split by process area.
- Answer each check with evidence: every check takes a result (Met, Partly met, Not met, Not applicable) and an evidence reference. A result with no evidence is recorded as Not met.
- Passive first: sections 1 to 6 are document, configuration and passive traffic review. Section 7 contains active validation tests, which run only with operations approval, in agreed windows, and never against safety instrumented systems (SIS) without the process safety owner's sign-off.
- Feed the results onward: findings go into the site risk register and the zone and conduit worksheet. See the OT Zones and Conduits Worksheet Template.
1. Review details and scope
| Field | Entry |
|---|---|
| Organisation and site | [Organisation], [Site] |
| System under review | [e.g. DCS for Unit 2, water treatment SCADA, packaging line] |
| Review trigger | [Periodic every [24] months / major change / new connection / incident / acquisition] |
| Review type | [Design review (pre-build) / As-built review / Post-change review] |
| In scope | [Zones, conduits, levels and sites included] |
| Out of scope and why | [e.g. SIS logic, vendor cloud platform] |
| Review team | [Lead reviewer], [OT engineer], [Network engineer], [Operations representative], [Process safety owner for section 7] |
| Approvals for active testing | [Name, role, date, test window] |
| Target security levels | [SL-T per zone from the IEC 62443-3-2 risk assessment, or "not yet set"] |
IEC 62443 uses three security level types: SL-T (target, from the risk assessment), SL-C (what a component can provide when properly configured) and SL-A (what is actually achieved in operation), as summarised in the ISA Global Cybersecurity Alliance quick start guide. An architecture review measures evidence towards SL-A. If no SL-T exists, record that as a finding and see the IEC 62443-3-2 OT Risk Assessment Guide.
2. Evidence to collect before the review
| # | Evidence | Source | Received |
|---|---|---|---|
| 2.1 | Current network diagrams (logical and physical), dated and version controlled | [Network engineering] | [Y/N] |
| 2.2 | Asset inventory with IP addresses, firmware, owner and zone | [Asset register or OT monitoring platform] | [Y/N] |
| 2.3 | Zone and conduit register with SL-T per zone | [Risk assessment] | [Y/N] |
| 2.4 | Firewall, router ACL and switch configurations for every boundary | [Exported configs, read only] | [Y/N] |
| 2.5 | Remote access architecture, accounts and session records for [90] days | [Remote access platform] | [Y/N] |
| 2.6 | Passive traffic capture or flow data from each boundary for at least [7] days | [SPAN or TAP, OT monitoring tool] | [Y/N] |
| 2.7 | List of external connections: vendors, cloud services, other sites, corporate IT | [OT lead] | [Y/N] |
| 2.8 | Previous review findings and their status | [Risk register] | [Y/N] |
CISA's Cross-Sector Cybersecurity Performance Goals expect an IT and OT asset inventory with IP addresses that is updated at least monthly (goal 1.A). An inventory older than that is itself a finding. See the OT Asset Register Template.
3. Zone review
For each zone in the register, complete one row. A zone, as defined in IEC 62443, groups assets by risk or by criteria such as criticality, function, location, required access or responsible organisation.
| # | Check | Result | Evidence |
|---|---|---|---|
| 3.1 | Every asset in the inventory is assigned to exactly one zone; no "unknown" assets remain in a control zone | ||
| 3.2 | Each zone has a named owner and a documented SL-T | ||
| 3.3 | Safety instrumented systems sit in their own zone, separate from the basic process control system | ||
| 3.4 | Assets of mixed criticality in one zone are justified, or the zone takes the highest SL-T of its members | ||
| 3.5 | Wireless networks, engineering laptops and portable media stations are placed in defined zones, not left implicit | ||
| 3.6 | Obsolete or unpatchable assets are identified and placed behind additional compensating controls | ||
| 3.7 | The diagram matches what passive monitoring observed (no unexplained hosts or subnets) |
4. Conduit and boundary review
A conduit groups the communication channels between zones that share security requirements. Review every conduit, then every rule on its enforcing device.
| # | Check | Result | Evidence |
|---|---|---|---|
| 4.1 | Every conduit has a documented purpose, source zone, destination zone, protocols, ports and owner | ||
| 4.2 | Boundary devices deny by default and allow by exception (NIST SP 800-53 SC-7(5)); no "any any" rules | ||
| 4.3 | IT to OT traffic passes through an industrial DMZ or monitored intermediary, with no direct routes from corporate IT to control zones (CPG 2.F) | ||
| 4.4 | No OT asset is reachable from the public internet unless there is a documented, approved exception with added protections (CPG 2.X) | ||
| 4.5 | Each rule maps to a conduit entry and has a named requester and review date; rules unused for [180] days are flagged | ||
| 4.6 | Where data only needs to leave OT (historian replication, reporting), one-way transfer or outbound-only rules are used | ||
| 4.7 | Industrial protocols crossing a boundary are restricted to required function codes where the enforcing device supports it | ||
| 4.8 | Management interfaces of boundary devices are reachable only from a management zone, with authenticated, logged access | ||
| 4.9 | Firewall change records exist for every rule change since the last review |
For function code filtering and protocol specifics, see the Industrial Protocol Security Guide.
5. Remote and third-party access review
| # | Check | Result | Evidence |
|---|---|---|---|
| 5.1 | All remote access enters through one approved path that terminates in the DMZ, not on a control zone asset | ||
| 5.2 | Remote users authenticate with phishing-resistant MFA and individual named accounts | ||
| 5.3 | Vendor access is enabled per session with operations approval, then disabled; dormant accounts are removed | ||
| 5.4 | No unmanaged remote access tools, cellular modems or vendor-installed gateways were found in passive monitoring or site walkdown | ||
| 5.5 | Sessions to control zones are recorded and retained for [90] days |
CISA's primary mitigations for OT call for removing OT connections to the public internet, securing remote access with phishing-resistant MFA and least privilege, disabling dormant accounts and segmenting IT from OT through a DMZ. Use the OT Supplier Remote Access Assessment Template for a deeper review of each supplier route.
6. Identity, monitoring and recovery checks
| # | Check | Result | Evidence |
|---|---|---|---|
| 6.1 | OT domains or local account stores are separate from corporate Active Directory, or trust is one way and documented | ||
| 6.2 | Default passwords on boundary devices, HMIs and controllers have been changed | ||
| 6.3 | Service and interface accounts crossing conduits (historian replication, OPC, backup) are inventoried, individually owned and rotated | ||
| 6.4 | Boundary devices send logs to central storage with restricted access (CPG 2.T and 2.U) | ||
| 6.5 | Passive network monitoring covers each conduit and alerts on new flows between zones | ||
| 6.6 | Backups of controller logic and configurations are held offline and restore has been tested in the last [12] months | ||
| 6.7 | Manual operation procedures exist and were exercised in the last [12] months |
Shared and machine accounts that span zones quietly undo segmentation, because one credential opens every conduit it is used on. See the OT and ICS Identity and Access Guide.
7. Segmentation validation test plan
Design checks prove intent; validation proves behaviour. Run these tests in order, stopping at the first level operations will accept. Record each test in the table below.
- Configuration analysis (no traffic): compare every boundary rule set against the conduit register. Any allowed flow with no conduit entry is a finding.
- Passive flow comparison: compare observed flows from at least [7] days of capture with the conduit register. Flag flows that cross a zone boundary without a conduit, and conduits with no observed traffic (candidates for removal).
- Path analysis: trace routes from corporate IT, the remote access entry point and any internet-facing service to each control zone using configuration data. Every path must traverse an enforcing boundary.
- Controlled reachability tests: with approval and in a window, test from a designated test host in each source zone that only allowed services in the destination zone respond. Start with IT and DMZ to Level 3; test into Levels 1 and 2 only on spare, offline or simulated equipment, or with the vendor present.
- Negative tests from untrusted locations: confirm from an external vantage point and from the corporate network that no OT service is reachable that is not listed in the conduit register.
- Rollback and stop rules: any unexpected process alarm, controller fault or operator concern stops testing immediately. Have the operations representative present and a restore plan for any device touched.
| Test ID | Source zone | Destination zone | Method | Expected | Observed | Pass or fail |
|---|---|---|---|---|---|---|
| V-01 | [Corporate IT] | [Level 3 operations] | [Config analysis] | [Only via DMZ] | ||
| V-02 | [DMZ] | [Level 2 supervisory] | [Passive flow comparison] | [Historian replication only] | ||
| V-03 | [Remote access entry] | [Level 2 engineering] | [Path analysis] | [Jump host only, MFA] | ||
| V-04 | [Internet] | [All OT] | [External negative test] | [No response] | ||
| V-05 | [BPCS zone] | [SIS zone] | [Config analysis only] | [No routable path or documented read only link] |
Active scanning in control zones is an operational decision, not a security one. For safe testing practice, see the OT Penetration Testing Guide.
8. Threat paths to test the architecture against
Review the architecture against the initial access routes most often seen in OT. Each row needs a named control and the check that evidences it.
| ATT&CK for ICS technique | What the architecture must stop | Worksheet checks |
|---|---|---|
| T0883 Internet Accessible Device | OT devices exposed directly to the internet | 4.4, V-04 |
| T0822 External Remote Services | Abuse of VPN, remote desktop or vendor portals into OT | 5.1 to 5.5, V-03 |
| T0886 Remote Services | Lateral movement between zones using legitimate remote services | 4.2, 4.5, 6.3 |
| T0866 Exploitation of Remote Services | Exploitation of exposed services on unpatchable assets | 3.6, 4.7, 6.5 |
9. Findings, rating and sign-off
| Rating | Definition | Default response time |
|---|---|---|
| Critical | Direct path from internet or corporate IT to a control or safety zone, or internet-exposed OT asset | [Mitigate within 7 days] |
| High | Conduit rule broader than its documented purpose into Level 2 or below, or unmanaged remote access | [30 days] |
| Medium | Documentation gaps, stale rules, missing logs on a boundary | [90 days] |
| Low | Hygiene items with compensating controls in place | [Next review cycle] |
Findings log: [ID], [Check reference], [Rating], [Description], [Owner], [Due date], [Status]. Sign-off: [Lead reviewer], [OT asset owner], [Site manager], [Date]. Next review due: [Date].
Implementation guidance
Rollout
- Pilot on one system: run the worksheet on one well-understood system to calibrate checks and the time needed (typically [3 to 5] days of effort for a mid-size site).
- Agree active testing rules: settle with operations which section 7 tests are allowed and where, before the first full review, and write that into the site testing procedure.
- Tie to change control: make a post-change review mandatory for new conduits, new external connections and boundary device replacements. See the OT Management of Change for Cyber guide.
- Track over time: keep previous worksheets and compare results review to review.
Metrics
- Percentage of boundary rules that map to a conduit entry (target [100%]).
- Number of observed cross-zone flows with no conduit entry, per review.
- Internet-exposed OT assets found (target zero).
- Remote access paths not through the approved route.
- Critical and high findings closed within their response time.
Framework mapping
| Framework | Reference | Worksheet sections |
|---|---|---|
| IEC 62443-3-2 | Zones, conduits and SL-T from security risk assessment for system design | 1, 3, 4 |
| IEC 62443-3-3 | FR 5 Restricted Data Flow; FR 1 Identification and Authentication Control; FR 6 Timely Response to Events | 4, 6, 7 |
| NIST SP 800-53 Rev. 5 | SC-7 Boundary Protection, SC-7(5), AC-4 Information Flow Enforcement, CM-2 Baseline Configuration, CA-8 Penetration Testing | 4, 7 |
| NIST CSF 2.0 | ID.AM-03 network data flows, PR.IR-01 protection from unauthorised logical access, DE.CM-01 network monitoring | 2, 4, 6 |
| CISA CPGs | 1.A Asset Inventory, 2.F Network Segmentation, 2.X Limit OT Connections to Public Internet, 2.T Log Collection | 2, 4, 6 |
| ISO/IEC 27001:2022 | Annex A 8.20 Networks security, 8.22 Segregation of networks | 3, 4 |
The NCSC and partner agencies published secure connectivity principles for OT in January 2026, covering balancing risk before connecting, limiting exposure, hardening boundaries and logging and monitoring among eight principles. They are a useful lens when section 4 finds a new external connection being proposed.
Sources
- ISA: ISA/IEC 62443 Series of Standards
- ISA Global Cybersecurity Alliance: Quick Start Guide, An Overview of the ISA/IEC 62443 Standards
- NIST: SP 800-82 Rev. 3 Guide to Operational Technology (OT) Security
- CISA: Cross-Sector Cybersecurity Performance Goals
- CISA: Primary Mitigations to Reduce Cyber Threats to Operational Technology
- CISA: Foundations for OT Cybersecurity, Asset Inventory Guidance for Owners and Operators
- NCSC: Designing safer links, secure connectivity for operational technology
- MITRE ATT&CK for ICS: Internet Accessible Device
Related NHI Mgmt Group resources: OT Security Assessment Guide, OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide, OT Supplier Remote Access Assessment Template, OT Security Policy Template.