This is a ready-to-use policy. A policy states what the organization requires and who owns it; the site-specific network diagrams and firewall rule sets underneath it state how the design is built. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, and route it through your normal document control, review, and approval. A worked filled specimen follows the template so you can see how a completed version reads. This content is educational and general; adapt it to your own quality and IT security systems and verify each cited reference against the current source.
Document control header
| Field | Entry |
|---|---|
| Document title | OT Network Segmentation and Access Control for Control Systems |
| Document number | <<FILL: POL-ID, e.g. POL-OT-002>> |
| Version | <<FILL: version, e.g. 1.0>> |
| Effective date | <<FILL: effective date>> |
| Supersedes | <<FILL: prior version or "New">> |
| Policy owner | <<FILL: role, e.g. Head of Automation Engineering / OT Security sponsor>> |
| Applies to | <<FILL: sites, process areas, and control systems in scope>> |
| Review cycle | <<FILL: e.g. every 2 years, or on any new conduit or zone change>> |
1. Purpose
This policy sets how <<FILL: COMPANY NAME>> separates process control networks (the operational technology, or OT, environment that runs PLCs, SCADA, and DCS) from the general business IT network, and how access into that environment is granted, limited, and monitored. The goal is to keep an incident on the business network, a compromised laptop, a phishing email, a ransomware infection, from ever reaching a controller that runs a validated GxP process. A network architecture is a data integrity control: if an unauthorized path to a controller’s programming port exists, the validated state behind that controller can no longer be trusted.
2. Policy statement
<<FILL: COMPANY NAME>> requires that every control system supporting a GxP process is placed in a defined network zone appropriate to its criticality, that every data path between zones (a conduit) is identified, authorized, and technically controlled, and that access to any zone is granted by role on a least-privilege basis, never by convenience. This policy is binding on employees, contractors, system integrators, and vendors who design, operate, maintain, or remotely support control systems on the company’s behalf.
3. Scope
This policy applies to the network infrastructure, switches, firewalls, remote access gateways, and wireless access points, that carries traffic for PLCs, SCADA servers and clients, DCS controllers and workstations, process historians, and the engineering workstations and software used to program them. It covers the conduit between the OT environment and the MES, LIMS, ERP, and general business network, and it covers vendor and third-party remote access into any of these systems.
It does not define the engineering content of any one firewall rule set or network diagram; those are held as controlled engineering records referenced in section 12. It does not replace the broader CSV cybersecurity and access control program, which this policy’s OT-specific requirements sit inside.
4. Definitions
- Zone: a grouping of systems that share a common trust level and security requirement, sized so that every system in it can be protected to the same standard.
- Conduit: a defined, controlled data path between two zones. A conduit is not “the network cable”; it is the specific, documented, access-controlled channel a given data flow is permitted to use.
- Demilitarized zone (DMZ): an intermediate zone that holds the servers (such as a historian mirror or a patch repository) that both OT and business-IT sides need to reach, so neither side connects directly into the other.
- Purdue-style reference model: the common layered architecture that lines up with the ISA-95 hierarchy, with Level 0-2 control and supervisory systems on the OT side, Level 3 manufacturing operations (MES, historian) as the controlled boundary layer, and Level 4-5 business systems on the IT side.
- Least privilege: a user, account, or system is granted only the access needed for its function, no more, and that access is time-limited where the function itself is time-limited (for example a vendor support session).
- Jump host (bastion): a single, hardened, monitored point through which administrative or engineering access into a zone must pass, rather than allowing direct connections from end-user devices.
5. Network zone model
Zones are set by ISA-95 level and GMP criticality, not by convenience of the existing network layout. Record the actual zone assignment for every system in the system inventory maintained per <<FILL: SOP-ID for the automation system inventory>>.
| Zone | ISA-95 level | Example systems | Trust boundary |
|---|---|---|---|
| Process control zone | 0-1 | PLCs, DCS controllers, field instruments | Highest protection; no direct inbound path from outside the zone except through a defined conduit |
| Supervisory zone | 2 | SCADA servers and clients, HMIs, local historian cache | Segmented from the process control zone by a managed switch or firewall; engineering access logged |
| Site operations DMZ | 2-3 boundary | Historian replication server, patch repository, antivirus definition server | The only systems with a path to both the OT side and the business side; neither side connects through it directly to the other |
| Manufacturing operations zone | 3 | MES, EBR, LIMS interfaces | Controlled conduit to Level 2 for process data; controlled conduit to Level 4 for business data |
| Business zone | 4-5 | ERP, email, general office network | Standard corporate IT controls; never a direct path into Levels 0-2 |
6. Conduits and data flow control
- Every data path between zones is documented as a named conduit with its source, destination, protocol, direction, and business justification, held in the conduit register per
<<FILL: reference for the conduit register>>. - No conduit connects the business zone directly to the process control or supervisory zones. Any data that must cross does so through the site operations DMZ, in the direction and format the DMZ is designed to carry.
- Conduits are filtered to the specific protocol and port the data flow requires; a firewall rule that allows “any” traffic between zones is treated as an undocumented conduit and is closed or replaced with a scoped rule.
- Conduit traffic is logged, and an unexpected new connection attempt across a zone boundary raises an alert per security event logging and monitoring.
- A new conduit, or a change to an existing one, goes through change control before it is implemented, with the same rigor as a change to the control system itself.
7. Access control by zone and role
| Role | Process control zone | Supervisory zone | Site DMZ | Manufacturing operations zone |
|---|---|---|---|---|
| Automation / controls engineer | Programming access, logged, from a managed engineering workstation only | Full configuration access | No standing access | Read access to interface status |
| Operator | No direct access | Operate (HMI) access only, no configuration rights | No access | No access |
| IT / infrastructure administrator | No access without a documented, time-limited exception | Administrative access to server and OS layer, not to process logic | Full administrative access | Administrative access to interface servers |
| Quality Assurance | No access | Read-only, for audit trail and alarm review | No access | Read-only |
| Vendor / integrator (remote support) | No standing access; time-limited, supervised session only, per section 9 | Same as process control zone | No access | Not applicable unless scoped to a specific interface issue |
8. Engineering and maintenance access controls
- Programming and engineering software (ladder logic editors, SCADA configuration tools, DCS engineering stations) runs only on managed, company-controlled workstations, never on a personal or unmanaged device.
- Controllers and engineering workstations do not expose open USB ports or unused network ports in a way that allows an unmanaged device to connect; unused physical ports are disabled or secured.
- Default vendor passwords on every control system component are changed before the system enters service, and the change is recorded as part of commissioning.
- Engineering and administrative accounts on control systems are individual, not shared, so a programming change can always be attributed to a person, consistent with the audit trail expectations in automation systems validation.
9. Remote vendor and third-party access
- Remote access by a vendor or integrator into any zone is granted only for a specific, time-limited support session, never as a standing open connection or permanently installed remote-access client.
- Every remote session requires multi-factor authentication, is routed through the company’s jump host, and is supervised by company personnel for the duration of the session.
- The session is logged (who, when, what was accessed, what was changed), and any configuration change made during the session goes through change control after the fact if it was not pre-approved.
- Standing VPN tunnels, dial-up modems, or vendor-installed remote-access software that bypasses the jump host are prohibited and are treated as a finding when discovered during periodic review.
10. Roles and accountability
| Role | Accountability under this policy |
|---|---|
| Policy owner / OT security sponsor | Owns this policy, the zone model, and the conduit register; confirms periodic review happens on schedule. |
| Automation / controls engineering | Implements the network design, maintains the conduit register, and executes approved programming changes. |
| IT / infrastructure security | Operates the firewalls and jump host, monitors conduit traffic, and investigates alerts. |
| Quality Assurance | Approves this policy, reviews periodic review findings, and confirms the access-control matrix is followed in practice. |
| System owner | Confirms the systems under their ownership are correctly zoned and that access lists stay current. |
| Vendor / integrator | Follows the remote access requirements in section 9 as a condition of the support agreement. |
11. Acceptance criteria
This policy is being met when all of the following are true:
- Every GMP-impacted control system appears in the system inventory with an assigned zone, and the assignment matches the actual network configuration.
- Every data path between zones is a documented, justified conduit in the conduit register, with no open “any-any” rule between the business zone and Levels 0-2.
- The access-control matrix in section 7 is reflected in the actual accounts and permissions on each system, verified at periodic review.
- No standing vendor remote-access path exists outside the supervised, time-limited process in section 9.
- Conduit traffic monitoring is active and alerts route to a defined responder.
12. References
IEC 62443 series, Security for industrial automation and control systems (zones, conduits, and security levels). EU GMP Annex 11, Computerised systems (current version; a draft revision issued for public consultation in July 2025, not yet final, signals explicit cybersecurity expectations for computerized systems). 21 CFR 211.68, Automatic, mechanical, and electronic equipment. ISPE GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems, Second Edition (2022). NIST Special Publication 800-82, Guide to Operational Technology (OT) Security, where adopted as a supporting reference.
Confirm the current version and clause numbers of each reference before issue.
13. Supporting records
| Record | Reference |
|---|---|
| Automation system inventory with zone assignment | <<FILL: reference>> |
| Conduit register | <<FILL: reference>> |
| Firewall rule set / network diagrams | <<FILL: reference, controlled engineering document>> |
| Vendor remote access log | <<FILL: reference>> |
| Periodic review of access and zoning | <<FILL: SOP-ID>> |
14. Revision history
| Version | Date | Author | Summary of change |
|---|---|---|---|
<<FILL: 1.0>> | <<FILL: date>> | <<FILL: author>> | Initial issue. |
15. Approvals
| Role | Name | Signature | Date |
|---|---|---|---|
| Author | <<FILL>> | ||
| Reviewer (IT / OT security) | <<FILL>> | ||
| Reviewer (QA) | <<FILL>> | ||
| Approver (Engineering / Quality Head) | <<FILL>> |
Filled specimen
The following shows the zone assignment and a conduit register entry completed for an illustrative fill and finish line, so you can see the level of detail an inspector expects. The company, systems, and settings are illustrative; replace them with your own.
| Field | Entry |
|---|---|
| Document title | OT Network Segmentation and Access Control for Control Systems |
| Document number | POL-OT-002 |
| Version | 1.0 |
| Effective date | 01 September 2026 |
| Policy owner | Head of Automation Engineering |
| Applies to | Fill and finish building, Lines 1-3, all PLC, SCADA, and historian systems |
Specimen zone assignment:
| System | Assigned zone | Basis |
|---|---|---|
| Line 3 filler PLC | Process control zone | Executes fill-weight control and reject logic, GMP-critical |
| Line 3 SCADA server | Supervisory zone | Operator HMI, alarm management, local historian cache |
| Site historian replication server | Site operations DMZ | Only system with a path to both OT and the MES on the business side |
| MES interface server | Manufacturing operations zone | Receives batch data from the historian DMZ server, feeds the EBR |
Specimen conduit register entry:
| Field | Entry |
|---|---|
| Conduit ID | CND-014 |
| Source / destination | Line 3 SCADA server to site operations DMZ historian |
| Protocol / port | Historian replication protocol, TCP 443, one direction (OT to DMZ) |
| Business justification | Batch data must reach the MES for the electronic batch record |
| Control | Firewall rule scoped to the single protocol and the two named hosts; no other traffic permitted |
| Last reviewed | 14 August 2026, no change |
A vendor remote-support session on the same line, logged under section 9, ran on 20 August 2026 for 90 minutes, routed through the company jump host with multi-factor authentication, supervised by the site automation engineer, to troubleshoot a communication fault between the filler PLC and the SCADA server. No configuration change was made; the session log was closed with that note and filed against the conduit it touched.
Common inspection findings this policy prevents
- A single flat network with no segmentation between the business LAN and the controllers running GMP processes.
- A firewall rule allowing “any” traffic between the MES and the PLC network, documented as a conduit in name only.
- A standing VPN connection from a vendor’s office into a controller’s programming port, left open since commissioning.
- Shared engineering accounts on SCADA or DCS engineering stations, so a programming change cannot be attributed to a person.
- No record of which systems sit in which zone, so a network diagram exists but nobody can say what it is protecting against.
How to adapt this policy
- Set your document number, owner, and review cycle in the header.
- Map your actual systems to the zone model in section 5; a site with a simpler or more complex architecture may need more or fewer zones, but keep the principle that nothing jumps directly from business IT to a controller.
- Build the conduit register from your real network diagrams, not from memory; every existing firewall rule between zones should appear as a named, justified conduit or be closed.
- Confirm the access-control matrix in section 7 against your actual account lists at your next periodic review, not just against intent.
- Confirm every reference in section 12 against the current published version before issue.