OT Security Policy Template: Rules for Industrial Systems That Protect Safety and Uptime

Corporate security policies break when they are applied unchanged to industrial control systems, because a forced reboot, an active scan or a locked-out operator account can stop a process or create a safety hazard, so OT needs its own policy that puts safety and availability first and still enforces security. This template is an editable operational technology (OT) security policy covering asset inventory, zones and conduits, remote and third-party access, accounts, change control, patching, removable media, monitoring, backup and incident response, and the interplay with safety systems. It is written for OT security leads, plant and engineering managers, CISOs and process safety owners, and maps to IEC 62443, NIST SP 800-82, ISO/IEC 27001:2022 and NIST CSF 2.0. For how to measure where you are, see the OT Security Maturity Model; for the discipline itself, the OT Security Guide. This page is the policy document.

How to use this template

• Replace placeholders: text in square brackets, such as [Organisation], [Site] and [OT security lead], is yours to set. Bracketed values are suggested defaults, not external requirements.
• Must and should: "must" is mandatory; "should" is recommended, and departures need a documented reason.
• Safety overrides: where a requirement conflicts with a safety instrumented function or a process safety requirement, safety wins and the conflict is recorded as an exception (section 15).
• Site procedures sit underneath: keep this policy short and stable; put zone diagrams, conduit rule sets, approved remote access routes and patch windows in site-level procedures.
• Corporate policy still applies: this policy adds to, and where stated overrides, the corporate information security policy for systems in scope.

1. Purpose

This policy sets the minimum security requirements for [Organisation]'s operational technology so that cyber risk to safety, the environment, production and equipment is identified, reduced and managed, without introducing controls that themselves endanger safe operation. It supports NIST CSF 2.0 outcome GV.PO-01, a policy for managing cybersecurity risk established and enforced.

2. Scope

This policy applies to all [Organisation] sites and to:

• Industrial control systems: PLCs, DCS, SCADA servers, HMIs, engineering workstations, historians, safety instrumented systems (SIS) and their networks.
• Building automation, physical access control, and other systems that monitor or control physical processes.
• Industrial IoT devices, wireless sensors and edge gateways connected to OT networks.
• Networks, firewalls, jump hosts and remote access services between OT and IT or the internet.
• Vendors, integrators and contractors who access, maintain or supply these systems.

3. Principles

1. Safety first: security controls must not degrade safety functions. The SIS must be logically separated from the basic process control system to the extent required by [the process safety standard used on site].
2. Availability and integrity before confidentiality: controls are chosen to protect correct and continuous operation first.
3. Defence in depth: no single control (for example the IT/OT firewall) is relied on alone.
4. Test before change: no security change is made to production OT without testing on a representative system or a vendor-approved procedure.
5. Risk-based: requirements are applied according to the zone's target security level from the OT risk assessment.

4. Roles and responsibilities

5. Asset inventory and risk assessment

1. Each site must maintain an OT asset inventory recording, for each asset: type, vendor, model, firmware and software version, location, zone, network address, owner, criticality, and support status.
2. The inventory must be built using passive discovery or vendor-approved methods. Active scanning of production OT is permitted only under section 10.3.
3. Each site must have an OT risk assessment that partitions the system into zones and conduits and assigns a target security level to each, consistent with IEC 62443-3-2. It must be reviewed at least every [3 years] and after significant change.
4. Cyber scenarios that could cause a hazardous event must be fed into the site's process hazard analysis. See the OT Cyber Physical Risk and Safety Guide.

See the OT Asset Visibility Guide and the IEC 62443-3-2 OT Risk Assessment Guide.

6. Network architecture: zones and conduits

1. OT networks must be separated from corporate IT by an industrial demilitarised zone (DMZ). No traffic may pass directly between IT and control networks; data must be brokered through DMZ services such as a replicated historian or a patch server.
2. Every conduit between zones must be enforced by a firewall or equivalent with a default-deny rule set listing permitted source, destination, protocol and port, each with a documented business reason.
3. Safety instrumented systems must be in their own zone, and engineering access to them must be controlled separately.
4. Direct internet connectivity from control zones is prohibited. Cloud connections must pass through the DMZ via [approved gateways] and be listed as conduits.
5. Firewall rule sets must be reviewed at least [annually] and unused rules removed.
6. Wireless in control zones requires [OT security lead] approval and must use [WPA3-Enterprise or equivalent] with its own zone.

Adapt zone names to your risk assessment. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.

7. Remote and third-party access

1. All remote access to OT must pass through [approved remote access service] in the industrial DMZ. Vendor-installed modems, cellular routers and remote desktop tools that bypass it are prohibited and must be removed when found.
2. Remote access requires an individual named account and phishing-resistant multi-factor authentication. Shared vendor accounts are prohibited.
3. Vendor access must be requested per session, approved by the asset owner, time-limited, and limited to the specific assets needed.
4. Remote sessions that can change control logic, setpoints or safety systems must be supervised or recorded, as defined in site procedures.
5. The site must be able to disconnect all remote access immediately, using a documented and tested method.

Remote services are a common initial access route into OT: MITRE ATT&CK for ICS tracks External Remote Services (T0822) and Remote Services (T0886). See the OT Remote Access Guide and the OT Third-Party and Integrator Access Guide.

8. Accounts and authentication

1. Users must have individual accounts on OT systems wherever the system supports them. Where a system supports only shared accounts, access to the shared credential must be controlled and logged, and the credential changed when people with knowledge of it leave.
2. Default vendor passwords must be changed before commissioning.
3. OT administrative accounts must be separate from corporate accounts, and OT domains must not trust corporate domains.
4. Account lockout must not be enabled on operator HMI accounts where lockout could prevent response to a process upset; compensating monitoring must be used instead.
5. Service accounts, application credentials and certificates used between OT systems must be inventoried with an owner.
6. Access rights must be reviewed at least [every 6 months].

See the OT and ICS Identity and Access Guide and the Identity for OT Environments Guide.

9. Change and configuration management

1. Changes to OT hardware, software, logic, firmware, network configuration and security controls must follow the site management of change (MoC) process, including a cyber security and safety impact review.
2. Emergency changes may be made to restore safe operation and must be reviewed within [2 working days].
3. Known-good configurations and controller logic must be baselined, and deviations detected and investigated.
4. Unused ports, services and software must be disabled or removed where the vendor supports it.

10. Vulnerability and patch management

1. 10.1 Monitoring: the [OT security lead] must review vendor and government ICS advisories against the asset inventory at least [weekly].
2. 10.2 Decisions: each relevant vulnerability must be assessed for exploitability and consequence in the site's architecture, and the decision recorded: patch in the next window, mitigate (for example a conduit rule or disabling a service), or accept with review date.
3. 10.3 Scanning and testing: active scanning or testing of production OT requires a written plan approved by the asset owner, with vendor guidance followed and operations informed. See the Safe Active Scanning and Testing in OT Guide.
4. 10.4 Patching: patches must be vendor-qualified, tested on a representative system where available, and applied in planned maintenance windows, with a backup and rollback plan.
5. 10.5 Unsupported systems: systems past vendor support must be recorded with compensating controls and a replacement plan.

See the OT Patch Management Guide and the ICS Advisory Triage and OT Vulnerability Management Guide.

11. Endpoint protection and removable media

1. OT Windows and Linux hosts must run vendor-approved malware protection or application allowlisting.
2. Removable media must be scanned at a [dedicated scanning kiosk] before use in OT, and only [registered media] may be connected to control systems.
3. Transient devices such as vendor laptops must be scanned and approved before connection, or replaced by [Organisation]-owned maintenance laptops.

See the Removable Media and USB Control Guide.

12. Monitoring, logging and incident response

1. Conduits between IT, DMZ and OT must be monitored, and OT network security monitoring should be deployed passively in control zones of the highest target security level. See the OT Network Security Monitoring Guide.
2. Logs from remote access, firewalls, domain services and engineering workstations must be collected and retained for at least [12 months].
3. Each site must have an OT incident response plan, agreed with operations and process safety, that defines when to isolate OT from IT, who may order a shutdown, and how to operate manually. It must be exercised at least [annually]. See the OT Incident Response Guide.

13. Backup and recovery

1. Controller logic, configurations, HMI projects, historian configuration and golden images must be backed up after every change and at least [quarterly], with one copy offline.
2. Restores must be tested at least [annually] for critical systems.
3. Licence keys, installation media and vendor contact details needed for recovery must be stored with the backups.

See the OT Backup, Recovery and Golden Image Guide.

14. Procurement and suppliers

1. New OT systems and services must include security requirements in the contract, such as support for individual accounts, logging, secure remote access and patch support for the expected life of the system.
2. Product suppliers should demonstrate secure development practices, for example IEC 62443-4-1 or ISASecure certification. See the OT Product Procurement Guide.

15. Exceptions

1. Exceptions must record the requirement, reason (including safety reasons), compensating controls, residual risk and a review date no later than [12 months].
2. Exceptions are approved by the [OT security lead]; exceptions affecting safety systems also need the [process safety owner].

16. Compliance, metrics and review

• Percentage of OT assets in the inventory with current firmware and support status.
• Remote access paths outside the approved service (target zero).
• Conduits with undocumented firewall rules.
• Critical systems with a tested restore in the last [12 months].
• Relevant ICS advisories with a recorded decision within [30 days].

The policy is owned by [OT security lead], approved by [executive sponsor], and reviewed at least [annually] and after any significant OT incident.

Implementation guidance

Rollout

1. Start with visibility and remote access: build the inventory (section 5) and find every remote access path (section 7). Removing unmanaged remote access is usually the largest early risk reduction.
2. Establish the DMZ and conduit rules: run new firewall rule sets in logging mode first, review the traffic with engineers, then enforce default deny in a maintenance window with a rollback rule set ready.
3. Back up before anything else changes: take controller and configuration backups before the first security change at each site.
4. Pilot at one site: apply the full policy at one site, adjust site procedures, then roll out.
5. Size to the organisation: a single small plant can run this policy with one OT security owner and a managed monitoring service; multi-site operators should standardise zone models and remote access centrally.

Framework mapping

Sources

• NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
• ISA: ISA/IEC 62443 Series of Standards
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• MITRE ATT&CK for ICS: T0822 External Remote Services
• MITRE ATT&CK for ICS: T0886 Remote Services

Related NHI Mgmt Group resources: OT Security Guide · OT Security Maturity Model · IEC 62443-2-1 Asset Owner Security Programme Guide · NIST SP 800-82 OT Security Guide · Remote Access Policy Template