Network Segmentation

To meet the network segmentation requirement, you must define clear boundaries between IT and OT networks and enforce those boundaries with technical controls (for example, firewalls, VLANs, ACLs, or equivalent), with documented rules, approvals, and periodic review evidence. The goal is controlled, provable traffic flow that limits lateral movement and reduces attack surface. ¹

Key takeaways:

• Define IT/OT boundary zones and allowed communications, then enforce them with concrete network controls. ¹
• Operate segmentation like a change-controlled system: rule lifecycle, exception process, and regular reviews. ¹
• Keep auditor-ready evidence: diagrams, rulebases, change tickets, review records, and validation test results that show segmentation works as designed. ¹

“Network segmentation requirement” usually becomes urgent when OT risk rises, remote access expands, or an assessor asks the most basic question: “Show me the boundary between IT and OT, and prove it’s enforced.” In C2M2, the requirement is explicit: IT and OT network boundaries must be defined and enforced through appropriate segmentation. ¹

For a Compliance Officer, CCO, or GRC lead, the work is not selecting a specific technology. The work is making segmentation auditable and durable: clear boundary definitions, a documented architecture, a rule lifecycle, a review cadence, and a controlled exception process that does not become permanent. ¹

This page is written to help you operationalize quickly. It gives you a practical segmentation operating model, a step-by-step implementation sequence, and the evidence set that typically satisfies internal control testing and external diligence. It also flags where teams get stuck: legacy flat networks, “temporary” rules, undocumented vendor tunnels, and diagrams that do not match reality.

Regulatory text

Requirement (C2M2 ARCHITECTURE-1.B, MIL1): “IT and OT network boundaries are defined and enforced through appropriate network segmentation.” ¹

What the operator must do

You need to produce two things and keep them aligned over time:

1. A defined boundary: documented IT/OT zones, conduits (approved paths between zones), and the systems included in scope. Your documentation must be clear enough that another engineer can point to where the boundary exists. ¹

2. An enforced boundary: implemented segmentation controls that restrict traffic to approved communications only, plus operational processes that prevent drift (change control, reviews, and exceptions with an end date or retirement plan). ¹

Plain-English interpretation (what “compliant” looks like)

A compliant program does not rely on tribal knowledge like “OT is on the 10-dot network.” It shows, on paper and in device configuration, that:

• OT is separated from corporate IT and the internet-facing environment.
• Cross-boundary traffic is explicitly allowed for business needs and explicitly blocked for everything else.
• Segmentation rules are managed like controlled infrastructure: requested, approved, implemented, tested, reviewed, and periodically revalidated. ¹

Who it applies to

Entities

This requirement applies to organizations using C2M2 to assess cybersecurity maturity, commonly in energy and other critical infrastructure environments where OT exists. ¹

Operational contexts that trigger real scrutiny

Expect segmentation to be a focal point when you have:

• Industrial control systems, SCADA, DCS, PLC networks, or safety systems connected (directly or indirectly) to corporate IT.
• Remote access for operators, engineers, OEMs, integrators, or other third parties.
• Shared services crossing IT/OT (identity, patching, logging, time sync, backups).
  In each case, the boundary is both a security control and an audit artifact. ¹

What you actually need to do (step-by-step)

Use this sequence to move from “concept” to “auditable control.”

Step 1: Define scope and boundary ownership

• Confirm which sites, OT environments, and supporting IT services are in scope for the C2M2 assessment.
• Assign owners for: OT network architecture, firewall/rule administration, and exception approvals (often OT + InfoSec + Operations).
  Deliverable: a short RACI that ties named roles to boundary decisions.

Step 2: Build the current-state network map (as-is)

Minimum viable mapping:

• OT zones (cell/area zones, control network, safety network if applicable).
• IT zones (corporate LAN, data center, cloud connectivity).
• Boundary enforcement points (firewalls, L3 switches, routers, SD-WAN edges).
• Remote access paths (VPNs, jump hosts, vendor portals).
  Deliverable: an as-is diagram plus an inventory of boundary devices and where their configs are managed.

Practical note: auditors tend to compare diagrams to configs. If your diagram says “all OT traffic funnels through Firewall A,” but Firewall B has an unmanaged tunnel, you will spend the whole exam explaining the mismatch.

Step 3: Define the target segmentation policy (to-be)

Write a “segmentation standard” that answers:

• What constitutes IT, OT, and any intermediate zone (often a DMZ or industrial DMZ concept).
• Default posture: deny by default across IT/OT boundary unless explicitly approved.
• Approved conduits (for example: historian replication, patch management relay, identity proxy, secure remote access via jump host).
• Logging expectations at boundary points.
  Deliverable: a signed standard (or architecture decision record) that becomes the basis for rule reviews and exceptions. ¹

Step 4: Rationalize allowed traffic (the rulebook)

Create an “allowed communications matrix” that lists:

• Source zone / source system
• Destination zone / destination system
• Protocol/port
• Business justification
• Data directionality
• Owner and approver
  Deliverable: a matrix that maps directly to firewall rules and ACL entries.

This is where compliance value is created: you turn “OT talks to IT sometimes” into a bounded, reviewable list.

Step 5: Implement (or tighten) enforcement controls

Pick controls appropriate to your environment; C2M2 does not mandate a product. Common patterns include:

• Firewalls between IT and OT zones (physical or virtual).
• VLANs and ACLs for intra-site segmentation.
• Dedicated industrial DMZ for cross-boundary services and remote access termination.
• Jump hosts/bastions for administrative access into OT.
  Deliverable: change tickets, approved rule changes, and config snapshots showing enforcement exists. ¹

Step 6: Put segmentation under change control

Operationalize a rule lifecycle:

• Intake (request form tied to the communications matrix)
• Risk review (OT security + owner approval)
• Implementation (network team)
• Validation (test plan + results)
• Documentation update (diagram + matrix)
• Sunset/recertification (exception retirement path)
  Deliverable: a documented lifecycle and evidence that you followed it for recent changes. ¹

Step 7: Validate segmentation works (not just configured)

Validation options you can defend:

• Rule recertification with owners signing off on need.
• Targeted network path testing (from IT to OT and vice versa) against the matrix.
• Confirmation that “deny” rules are effective (blocked traffic attempts show up in logs).
  Deliverable: validation results tied to specific boundary controls and rules, stored with the review package. ¹

Step 8: Monitor for segmentation drift

Drift happens through emergency changes, vendor access, and “temporary” routes. Set expectations for:

• Logging at boundary points (accept/deny events, admin changes).
• Periodic review of rules and exceptions.
• Alerts for new subnets, routes, or tunnels that bypass boundary controls.
  Deliverable: recurring review records and a drift-detection procedure that is actually used. ¹

Required evidence and artifacts to retain

Auditor-ready packet (store in your GRC system, with timestamps and approvers):

1. Network segmentation architecture (to-be) and as-is diagrams showing IT/OT boundaries and enforcement points. ¹
2. Communications matrix mapping business requirements to specific allowed flows.
3. Firewall/ACL rule review records (who reviewed, what changed, what was removed). ¹
4. Change approvals for segmentation changes, including emergency changes with follow-up review. ¹
5. Exception register: purpose, compensating controls, approver, and retirement criteria. ¹
6. Validation evidence: test plans/results, screenshots or exported reports showing enforcement. ¹

If you manage this in Daydream, structure the evidence by “boundary” (site or environment), then attach rules, reviews, and tests to that boundary so you can answer scope questions fast.

Common exam/audit questions and hangups

Questions you should be ready to answer

• “Show the IT/OT boundary on a diagram, and show the device configs that enforce it.” ¹
• “Which OT systems can initiate connections to IT? Which IT systems can initiate to OT?”
• “How do you approve new ports/protocols across the boundary?” ¹
• “How do you detect a new tunnel, route, or vendor connection that bypasses the boundary?”
• “Show the last rule review and evidence of cleanup.” ¹

Hangups that slow audits down

• Diagrams not updated after changes.
• Rule reviews that exist as meetings but have no outputs (no list of rules reviewed, no actions).
• Exceptions with no end state, so “temporary” becomes permanent. ¹

Frequent implementation mistakes and how to avoid them

1. Flat OT networks with a single “edge firewall” and many internal trust paths.
   Fix: define internal OT zones (at least by function or criticality) and segment high-impact systems first.

2. Allow rules justified by “it breaks otherwise.”
   Fix: require a business owner, a protocol, and a testable justification in the communications matrix.

3. Remote access terminating directly into OT.
   Fix: terminate remote access into a controlled intermediate zone with a jump host and explicit conduits into OT.

4. No rule lifecycle.
   Fix: treat segmentation like code: documented request, review, implement, validate, and recertify. ¹

5. Evidence scattered across network tools and inboxes.
   Fix: centralize artifacts in your GRC repository (for example, Daydream) with a consistent naming convention and review cadence. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific C2M2 requirement. The operational risk is still direct: weak or eroded segmentation increases the chance that an IT compromise can move into OT, and it makes controlled-traffic claims hard to prove during audits and customer diligence. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize and document)

• Confirm scope and name boundary owners.
• Produce as-is diagrams and a boundary device inventory.
• Stand up a basic exception register for any known bypasses or “temporary” rules.
• Start capturing configs/exports for boundary enforcement points as baseline evidence.

Days 31–60 (standardize and control change)

• Publish the segmentation standard (zones, default-deny posture across IT/OT, approved conduits). ¹
• Build the communications matrix for the highest-risk cross-boundary flows first (remote access, identity, patching, historian).
• Implement a rule request + approval workflow and require it for all boundary changes.

Days 61–90 (validate and make it repeatable)

• Run a formal rule review and remove or time-bound unnecessary rules. ¹
• Execute validation testing against the communications matrix and store results with the review package.
• Add drift monitoring: alerting for config changes and periodic recertification of exceptions.

Frequently Asked Questions

Do we need a dedicated industrial DMZ to satisfy the network segmentation requirement?

C2M2 requires defined and enforced IT/OT boundaries, not a specific architecture pattern. If you can show enforced controls and controlled conduits without an industrial DMZ, document that design and keep validation evidence. ¹

What’s the minimum evidence an auditor will accept for “enforced boundaries”?

Provide diagrams plus device-level proof: firewall/ACL configurations, approved change records, and validation test results tied to the stated boundary. Keep rule review records to show the control stays effective over time. ¹

How do we handle third-party remote access into OT without failing segmentation expectations?

Terminate third-party access in a controlled zone (often an intermediate zone) and require explicit, documented conduits into OT. Track each third party connection as an exception or approved conduit with an owner, justification, and periodic review evidence. ¹

Our OT environment is old and can’t tolerate changes. Can we document-only for now?

Documentation alone won’t meet “defined and enforced.” If you need a phased approach, document the current enforcement points, implement compensating controls where possible, and create a plan with change control and validation steps as you improve segmentation. ¹

How often should we review segmentation rules and exceptions?

C2M2 requires that boundaries are enforced; it does not prescribe a frequency. Set a cadence you can execute consistently, and retain rule review outputs and exception recertifications as evidence. ¹

What’s the fastest way to make this auditable in a GRC program?

Treat each IT/OT boundary as a control object with a single evidence packet: diagrams, communications matrix, ruleset exports, approvals, review minutes, and validation results. A GRC workflow tool like Daydream helps keep approvals and artifacts linked so you can answer scope and “show me” questions quickly. ¹

What you actually need to do

Use the cited implementation guidance when translating the requirement into day-to-day operating steps. ²

Footnotes

1. Cybersecurity Capability Maturity Model v2.1

2. DOE C2M2 program