Join our Newsletter — 33% off our NHI Course
Home› Guides› OT Zones and Conduits Worksheet Template: Assets, Security…
Template OT & IoT Security

OT Zones and Conduits Worksheet Template: Assets, Security Levels and Flows

← All guides
By NHI Mgmt Group, edited by Lalit Choda Updated 14 November 2026 13 min read
On this page

Most sites can draw their OT zones on a whiteboard, but few can show a single record that ties every asset to a zone, every allowed flow to a conduit and every zone to a target security level. This template is that record: an editable worksheet for defining and maintaining the zones and conduits of an industrial automation and control system (IACS), in the terms used by the ISA/IEC 62443 series. It covers scoping the system under consideration, the zone register, a profile for each zone, the conduit register, the flow register that sits under each conduit, a security level summary that compares target and capability levels, and an exceptions log. It is written for OT security architects, control system engineers, integrators and risk owners. IEC 62443 terms are paraphrased here; the standard itself remains the authority. For design principles, see the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide; for the risk assessment that sets target levels, the IEC 62443-3-2 OT Risk Assessment Guide. This page is the working document those guides produce.

How to use this template

  • Replace placeholders: text in square brackets, such as [Organisation], [Site], [Zone owner] and [SUC name], is yours to set. Bracketed numbers are suggested defaults, not requirements taken from any standard.
  • One worksheet per system under consideration (SUC): a SUC is the slice of the plant you are assessing, such as one process unit, one substation or one packaging line. Very large sites keep one worksheet per SUC and a short site index that lists them.
  • Start from the asset register: every row in the zone register points back to assets in the site asset register. If an asset is missing there, add it before you place it in a zone. See the OT Asset Register Template.
  • Design first, then as-built: fill the worksheet as a design record before a build or change, then update it with what passive monitoring and firewall configuration actually show. Mark each row as Design or Verified.
  • Keep it under change control: a new conduit, a new external connection or a zone merge is a change to this document, approved through the site management of change process. See the OT Management of Change for Cyber.
  • Review it with the architecture review: the periodic review checks this worksheet against the live network. See the OT Security Architecture Review Template.

1. Worksheet details and system under consideration

FieldEntry
Organisation and site[Organisation], [Site]
SUC name and identifier[e.g. SUC-03 Water treatment, filtration and dosing]
SUC boundary description[What is inside, what is outside, and the physical and logical edges, e.g. "all assets on VLANs 30 to 39 and the dosing panel in building B"]
Access points into the SUC[Every external connection: enterprise network, vendor remote access, cellular modems, cloud services, removable media stations]
Related worksheets[Other SUCs that share conduits with this one]
Inputs used[Asset register version, network diagram version, risk assessment reference, firewall export date, passive monitoring period]
Worksheet owner[OT security architect]
Contributors[Control system engineer], [Network engineer], [Operations representative], [Process safety owner], [Integrator]
Version and status[v0.1 Draft / Approved / Superseded], [Date]
Next review due[Date, e.g. [12] months or at the next major change]

2. Zoning criteria for this SUC

Record why assets were grouped as they were, so the next engineer can place a new asset without redrawing the design. In IEC 62443 terms a zone groups assets by risk or by shared factors such as criticality, function, location, required access or the organisation responsible for them. Tick the criteria used and add site-specific rules.

CriterionUsed (Y/N)Site rule
Safety function[Y][Safety instrumented systems (SIS) always sit in their own zone, never shared with basic process control]
Process criticality[ ][Assets whose loss stops production or harms the environment are separated from support systems]
Function or Purdue level[ ][Field controllers, supervisory HMIs and historians in separate zones; Purdue level is a starting point, not the rule]
Physical location[ ][Remote sites and outstations are separate zones from the main control room]
Required access[ ][Assets reached by vendors or contractors sit in a zone apart from those only operations staff use]
Responsible organisation[ ][Vendor-managed packages, such as a skid with its own controller, are separate zones]
Technology age and patchability[ ][Unsupported operating systems grouped behind extra controls]
Wireless and mobile[ ][Wireless networks and mobile devices in their own zone, never bridged into a wired control zone]

3. Zone register

One row per zone. The SL-T column comes from the risk assessment; leave it as "pending" until that assessment is approved, rather than guessing.

Zone IDZone namePurposeAsset countHighest consequenceSL-TZone ownerStatus
Z-01[Enterprise interface DMZ][Historian replica, patch staging, remote access jump hosts][ ][Business disruption][2][ ][Design / Verified]
Z-02[Supervisory control][SCADA servers, HMIs, engineering workstations][ ][Loss of view and control][ ][ ][ ]
Z-03[Basic process control][PLCs, remote I/O, drives][ ][Process upset, equipment damage][ ][ ][ ]
Z-04[Safety instrumented system][SIS logic solvers and their engineering station][ ][Harm to people or environment][ ][Process safety owner][ ]
Z-05[Vendor package][ ][ ][ ][ ][ ][ ]

Rules for the register: every asset in the SUC belongs to exactly one zone; an asset that must sit in two zones (for example a dual-homed server) is recorded in section 8 as an exception; and a zone with no named owner is not approved.

4. Zone profile (one per zone)

Copy this block for each zone. It holds the detail that does not fit in the register and is what an assessor reads first.

FieldEntry
Zone ID and name[Z-03 Basic process control]
Logical boundary[VLANs, subnets, address ranges]
Physical boundary[Cabinets, rooms, buildings; who holds the keys]
Asset list reference[Filter or tag in the asset register, e.g. zone = Z-03]
Asset types present[Controllers, I/O, HMIs, servers, network devices, safety devices, wireless]
Consequence if compromised[Safety, environmental, production, regulatory, financial]
Threats considered[e.g. insider misuse, malware from removable media, lateral movement from Z-02 using legitimate remote services (ATT&CK for ICS T0886)]
SL-T and source[Level, plus the risk assessment reference that set it]
Lowest SL-C among components[Level and the component that limits it]
Compensating controls[Where SL-C is below SL-T: what is added at the zone or conduit, see section 7]
Accounts and identities in the zone[Human roles, shared accounts, service accounts, controller and device credentials]
Allowed entry routes[Conduit IDs only; anything else is unauthorised]
Monitoring[Sensor or log source covering this zone]
Owner and approver[Name, role, date]

5. Conduit register

A conduit groups the communication channels between zones that share the same security requirements. Record each conduit once, with the zones it joins and the device that enforces it. A cross-zone flow that does not belong to a conduit in this table is not authorised.

Conduit IDZones joinedPurposeEnforcing deviceDefault actionMediaSL-TOwnerStatus
C-01[Enterprise to Z-01][Historian replication, patch download, remote access entry][Firewall FW-IT-01][Deny][Wired][ ][ ][Design / Verified]
C-02[Z-01 to Z-02][Jump host sessions, data collection][Firewall FW-OT-01][Deny][ ][ ][ ][ ]
C-03[Z-02 to Z-03][Supervisory reads and writes, controller programming][ ][Deny][ ][ ][ ][ ]
C-04[Z-03 to Z-04][Status read from SIS to BPCS only][ ][Deny][ ][ ][ ][ ]
C-05[Vendor to Z-05][Vendor support][ ][Deny, enabled on request][ ][ ][ ][ ]

Two rules worth writing into the site standard: there is no conduit straight from the enterprise network to a control zone (traffic passes through the DMZ, which matches CISA's segmentation goal and its primary mitigations for OT); and every conduit that crosses to the internet or to a third party is listed with its business justification, because CISA's performance goals expect any internet exposure of OT to be justified, documented and given extra protection.

6. Flow register (channels within each conduit)

This is the part most worksheets skip, and the part that makes firewall rules reviewable. One row per allowed communication channel. Each boundary rule should map to exactly one row here.

Flow IDConduitSource (asset or group)DestinationProtocol and portDirection and initiatorFunctionRead or writeRule referenceJustification and owner
F-001C-01[Z-01 historian replica][Enterprise historian][e.g. vendor replication port][Outbound, initiated from Z-01][Process data to business][Read only][FW-IT-01 rule 12][ ]
F-002C-02[Jump host][Engineering workstation][e.g. TCP 3389][Inbound to Z-02, session brokered][Remote engineering][Interactive][ ][ ]
F-003C-03[SCADA servers][PLC group A][e.g. Modbus TCP 502, EtherNet/IP 44818][Server initiates][Polling and setpoint writes][Read and write][ ][ ]
F-004C-04[SIS][BPCS gateway][ ][SIS initiates][Trip status][Read only][ ][ ]
  • Be specific: name hosts or small groups, not whole subnets, and list ports, not "any". Where a protocol firewall or deep packet inspection is used, record the allowed function codes or services (for example read-only on a monitoring flow).
  • Record the initiator: outbound-only flows from a higher-trust zone are easier to defend than inbound ones. Note where a flow was redesigned to reverse its direction.
  • Write flows need a reason: any flow that can change a controller, setpoint or program needs a named owner and, where practical, time-bound enablement.
  • Verify against reality: compare the register with passive monitoring for a full operating cycle, including batch changes and shutdowns. Flows seen but not listed are findings; flows listed but never seen are candidates for removal.

7. Security level summary and gaps

In IEC 62443 terms, the target level (SL-T) is what the risk assessment says a zone or conduit needs, the capability level (SL-C) is what its components can reach when properly configured without extra countermeasures, and the achieved level (SL-A) is what is measured once the system is commissioned and running. Levels 1 to 4 describe rising attacker capability, from casual or accidental violation at level 1 to sophisticated, well-resourced and highly motivated attackers with IACS-specific skills at level 4. The series breaks requirements into seven foundational requirements (FR 1 to FR 7), so record levels per FR where you have the data.

Zone or conduitFRSL-TSL-C (limiting component)SL-A (evidence)GapCompensating controlRisk owner decision
[Z-03]FR 1 Identification and authentication control[ ][ ][ ][ ][e.g. authentication enforced at jump host for all access into the zone][Accept / Treat / Date]
[Z-03]FR 2 Use control[ ][ ][ ][ ][ ][ ]
[Z-03]FR 3 System integrity[ ][ ][ ][ ][ ][ ]
[Z-03]FR 4 Data confidentiality[ ][ ][ ][ ][ ][ ]
[C-03]FR 5 Restricted data flow[ ][ ][ ][ ][e.g. protocol-aware firewall limiting writes to listed engineering hosts][ ]
[Z-03]FR 6 Timely response to events[ ][ ][ ][ ][ ][ ]
[Z-03]FR 7 Resource availability[ ][ ][ ][ ][ ][ ]

Leave SL-A blank until there is evidence from testing or assessment; a design value written into that column hides real gaps. For how target and capability levels are set and compared in detail, see the IEC 62443-3-3 and 4-2 Security Levels Guide.

8. Exceptions and compensating controls log

Exception IDDescriptionZone or conduitReasonCompensating controlsRisk ownerExpiry or review date
E-01[Dual-homed historian spanning Z-01 and Z-02][ ][Vendor support constraint until upgrade][Host firewall, IP forwarding disabled, monitored][ ][ ]
E-02[Cellular modem on remote outstation][ ][ ][ ][ ][ ]

Every exception has an expiry date. An exception past its date without renewal is escalated to the risk owner, not silently carried forward.

9. Identities crossing conduits

Conduits carry identities as well as packets. List the accounts and credentials each conduit relies on, because a well-drawn boundary is bypassed by a shared engineering password or a vendor account that never expires.

ConduitIdentityTypeAuthentication methodWhere the credential is storedOwnerLast reviewed
[C-02][Jump host operator accounts][Human, named][Phishing-resistant MFA][Directory][ ][ ]
[C-01][Historian replication account][Service account][ ][ ][ ][ ]
[C-05][Vendor support accounts][Third party][ ][ ][ ][ ]

Service and device credentials are the ones most often left unrotated. See NHIs in OT and the OT Remote Access Guide.

10. Approval

RoleNameDecisionDate
Worksheet owner[ ][Prepared][ ]
Operations or plant manager[ ][Approved / Returned][ ]
Process safety owner (for SIS zones and conduits)[ ][ ][ ]
Risk owner (accepts section 7 and 8 residual risk)[ ][ ][ ]

Implementation guidance

Rollout

  1. Pick one SUC: start with a well-documented system and a cooperative owner. Fill sections 1 to 3 from existing drawings in a workshop of [half a day].
  2. Collect evidence passively: export firewall rules and gather passive traffic captures or monitoring data for a representative operating period. See the OT Network Security Monitoring Guide.
  3. Build the flow register: reconcile rules and observed traffic into section 6. Expect the first pass to find rules with no owner and flows with no rule.
  4. Set target levels: run or reuse the risk assessment to fill SL-T, then record capability levels from vendor documentation for section 7.
  5. Plan changes, not big bangs: new boundaries are introduced in monitor or log-only mode first where the enforcing device supports it, then enforced in an agreed outage window with a tested rollback (the previous rule set saved and restorable).
  6. Approve and baseline: sign off section 10 and keep the approved version as the baseline for future change requests.

Metrics

  • Percentage of SUC assets assigned to exactly one zone (target [100%]).
  • Percentage of boundary rules that map to a flow register entry (target [100%]).
  • Observed cross-zone flows with no register entry, per review period.
  • Zones and conduits with SL-T set and approved.
  • Exceptions past their expiry date (target zero).

Common failure patterns

  • Zones copied from Purdue levels alone: a single "level 2" zone spanning several process units lets one compromised HMI reach everything. Use the criteria in section 2.
  • Conduits with "any" services: a conduit with no flow register is a hole with a name. Section 6 exists to stop this.
  • SIS sharing a zone with basic control: the safety system then inherits every weakness of the control network.
  • Forgotten paths: cellular modems, vendor laptops and remote access tools that bypass the DMZ, which ATT&CK for ICS tracks as External Remote Services (T0822) and Internet Accessible Device (T0883).
  • A worksheet nobody updates: without a change control hook the document drifts from the plant within months.

Framework mapping

FrameworkReferenceWorksheet sections
ISA/IEC 62443-3-2Security risk assessment for system design: identifying the SUC, partitioning into zones and conduits, setting SL-T1, 2, 3, 5, 7
ISA/IEC 62443-3-3System security requirements and security levels; FR 5 restricted data flow6, 7
NIST SP 800-82 Rev. 3OT security architecture and network segmentation guidance2 to 6
NIST SP 800-53 Rev. 5SC-7 Boundary Protection, AC-4 Information Flow Enforcement, CM-2 Baseline Configuration5, 6, 10
NIST CSF 2.0ID.AM-03 network communication and data flows maintained; PR.IR-01 protection from unauthorised logical access5, 6
CISA CPGs1.A Asset Inventory, 2.F Network Segmentation, 2.P Document Network Topology, 2.X Limit OT Connections to Public Internet3, 5, 6

NIST has published an initial public draft of SP 800-82 Rev. 4, with comments due by 30 November 2026; Rev. 3 remains the final version, so check for changes before mapping to the new revision.

Sources

Related NHI Mgmt Group resources: OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide, IEC 62443-3-2 OT Risk Assessment Guide, OT Security Architecture Review Template, OT Asset Register Template, IEC 62443 Guide.

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 14 November 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security. nhimg.org