For regulated industrial environments, zone and conduit diagrams should be detailed enough to support risk assessment, access control, and change impact analysis, but not so granular that they are impossible to maintain across long equipment lifecycles.
Minimum detail you should always include
At a minimum, each diagram should clearly show:
- Zones with a meaningful grouping logic (e.g., corporate IT, DMZ, site operations, control network, safety systems, lab systems, supplier/remote access).
- Trust level and criticality for each zone (e.g., high criticality / safety-related, regulated data, untrusted external).
- Conduits between zones, including directionality if relevant.
- Key security functions on conduits (firewalls, data diodes, VPN gateways, jump hosts, remote access gateways).
- Protocols or interface types on each conduit at the level of families (e.g., OPC UA, Modbus/TCP, HTTPS, SFTP, vendor remote-support tool).
- Representative systems in each zone (e.g., MES, ERP connector, historian, PLC family, safety PLC, QMS, lab system) rather than every device.
- Ownership and responsibility at zone boundaries (e.g., IT vs OT vs vendor-managed).
When you need more detail
Add more granularity when it is necessary for risk, design, or validation decisions, for example:
- Safety, quality, or batch-release impact: Explicitly show which conduits can influence safety systems, product release decisions, or GxP data.
- Remote access and cloud services: Show specific jump hosts, remote-access platforms, and cloud endpoints, including how identities are authenticated.
- Mixed criticality in one physical network: Where one switch or VLAN carries both safety and non-safety traffic, show the logical segregation and the enforcement points.
- Regulated data flows: Indicate conduits carrying regulated records (e.g., batch records, device history, test results) so you can align controls and evidence collection.
- High-consequence legacy assets: For obsolete or unpatchable equipment, show exactly how it is isolated or monitored.
In these cases, it is often worth diagramming key sub-zones (e.g., safety PLCs vs standard PLCs vs drives) and specific conduits within the control network, while still avoiding a one-box-per-device drawing.
Detail that usually belongs in other artifacts
Zone and conduit diagrams should not try to be physical wiring or detailed network topology diagrams. Typically you should avoid including:
- Every switch, cable, and patch panel.
- Every PLC, HMI, sensor, or workstation as its own icon.
- All IP addresses, VLAN IDs, or routing specifics.
- Detailed firewall rule sets.
These details are usually handled in separate, more technical network diagrams, configuration baselines, or asset inventories. The zone and conduit view should remain stable over time, even as you swap like-for-like devices within a zone.
Balancing detail with maintainability
In brownfield plants with long-lived equipment and mixed vendors, diagrams that are too detailed become obsolete quickly and lose credibility. To keep them usable:
- Abstract within a zone: Show representative assets and types (e.g., “Packaging PLCs”), not every instance.
- Use consistent zone definitions across sites, even if implementations differ. This improves auditability and training.
- Separate logical and physical views: Keep the zone/conduit diagram logical, and link it to physical/network diagrams managed by IT/OT engineering.
- Respect change control: Treat the diagram as a controlled configuration document. Update it under the same change process as firewall changes, new remote-access paths, or new cloud integrations.
Regulated environment and validation considerations
In regulated industries, the diagram detail must support, but cannot replace, your formal risk assessments and validation documents:
- Ensure the diagram is traceable to your risk analysis and security requirements (e.g., IEC 62443 zones and conduits, data integrity requirements, or internal standards).
- Keep diagrams versioned and referenced in change records, design specs, or validation packages when they influence system design.
- Avoid promising that a given diagram “ensures” compliance or safety; its role is to document design decisions and boundaries for later review and verification.
Because full infrastructure replacement is uncommon in these environments, your diagrams should explicitly show coexistence of old and new systems and any compensating controls where ideal segmentation is not yet achieved.
Practical rule of thumb
A useful test is: could a new engineer, cybersecurity specialist, or auditor use only the zone and conduit diagram to:
- Understand which zones are most critical and why.
- See where traffic can cross trust boundaries and what controls exist.
- Identify which conduits matter for a given change request or incident.
If the answer is yes, without needing to parse device-level detail, your diagrams are likely at the right level of detail.
