Cybersecurity Architecture Design

Cybersecurity Architecture Design (C2M2 v2.1 ARCHITECTURE-1.A) requires you to establish and maintain a documented cybersecurity architecture for in-scope IT and OT assets, with defined security zones and network segmentation that are kept current as systems change. Operationally, you need authoritative diagrams, segmentation standards, a change/update workflow, and review evidence that the architecture reflects reality. ¹

Key takeaways:

• Define security zones and segmentation rules for both IT and OT, then document them in diagrams and standards. ¹
• Make architecture maintenance part of change management so diagrams and zone inventories stay current after installs, removals, and exceptions. ¹
• Retain evidence: approved architecture artifacts, change records, exception approvals, and periodic review/reconciliation proof. ¹

A maturity assessment fails fast when your “architecture” exists only as tribal knowledge, outdated Visio files, or a single network diagram that ignores OT realities. C2M2’s Cybersecurity Architecture Design requirement focuses on a simple operator outcome: you can show how in-scope IT and OT assets are structured, how they are segmented into security zones, and how that structure is maintained over time. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest way to operationalize this requirement is to treat architecture as controlled documentation with a clear owner, a defined minimum content standard, and a maintenance trigger tied to real operational events (new connections, firewall rule changes, remote access enablement, new OT cells, cloud network changes). Your goal is exam-ready evidence that the architecture is (1) established, (2) used to drive segmentation decisions, and (3) maintained so it matches the environment. ¹

This page gives you requirement-level implementation guidance: scope, concrete steps, evidence to retain, audit questions to prepare for, common mistakes, and an execution plan you can run without waiting for a perfect enterprise re-architecture.

Regulatory text

Requirement (C2M2 v2.1 ARCHITECTURE-1.A, MIL1): “Cybersecurity architecture of IT and OT assets is established and maintained, including network segmentation and security zones.” ¹

Operator interpretation: you must be able to produce a current, approved architecture that covers the IT/OT environment in scope and shows:

• Security zones (how you group systems by function and risk)
• Network segmentation between zones (how you limit communications and contain compromise)
• Ongoing maintenance (how updates happen when the environment changes)

What “maintained” means in practice: architecture artifacts are updated through a defined workflow when changes occur (installations, removals, new connections, exceptions) and reviewed periodically with evidence. ¹

Plain-English interpretation (what the requirement is really asking)

A regulator, assessor, or customer auditor wants to see that you have an intentional design for how systems connect, especially where IT and OT meet, and that the design is kept current. If you cannot show your zones, boundaries, and allowed pathways, you cannot credibly claim you control lateral movement risk, remote access exposure, or blast radius in OT. ¹

Who it applies to

Entity types: energy sector organizations and other critical infrastructure operators using C2M2 to assess cybersecurity capability. ¹

Operational context (scope matters):

• Applies to the defined C2M2 assessment scope (a business unit, function, site, or OT environment). ¹
• Covers both IT assets (enterprise networks, identity, cloud workloads that support operations) and OT assets (control systems, SCADA components, historian, engineering workstations, cell/area networks). ¹

Third-party touchpoints: if third parties can access your environment (managed service providers, OEMs, integrators), your architecture must represent their access paths and the segmentation controls governing them.

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

Use this as a build checklist. Don’t wait for perfect tooling.

Step 1: Define “architecture minimum requirements” for your scope

Create a short standard that defines what an acceptable architecture package includes for your environment:

• Zone taxonomy (examples: enterprise IT, DMZ, OT DMZ, control zone, safety zone, vendor remote access zone)
• Required diagrams (logical zone diagram minimum; physical/site diagram where relevant)
• Required metadata (asset/system names, owners, connectivity types, trust boundaries)
• Required control statements (e.g., “zone-to-zone traffic must be explicitly authorized and logged”)

Keep it implementable: the point is consistency and maintainability, not art.

Step 2: Establish security zones and document trust boundaries

Deliverable: a zone model that names each zone, its purpose, and its risk assumptions. For each zone, record:

• Typical assets in the zone
• Allowed inbound/outbound communications at a high level
• Authentication expectations (human, service, vendor)
• Monitoring/logging expectations

This becomes your control narrative: segmentation isn’t “we have firewalls,” it’s “we have defined zones with documented allowed pathways.”

Step 3: Document segmentation and allowed pathways

Deliverable: a segmentation rule set that connects directly to implementation artifacts:

• For each zone-to-zone connection, state the business purpose
• Identify the enforcing control points (firewall, ACL, gateway, jump host, remote access broker)
• Tie pathways to approvals (who can authorize new flows or changes)

Aim for “auditor-traceable”: someone can pick a pathway on the diagram and find the rule, owner, and approval.

Step 4: Make maintenance non-optional by tying it to change management

This is where most programs fail. Add explicit architecture update triggers to change workflows:

• New system installed or removed
• New VLAN/VRF/subnet created
• Firewall rule changes that cross zone boundaries
• Remote access enabled/modified
• New third-party connection
• Exceptions granted (temporary flat network, emergency access)

Your change record should require: “Which architecture artifact was updated? Link to the new version.”

The C2M2 best-practice expectation aligns to this: define how cybersecurity architecture design is updated during changes, installations, removals, or exceptions. ¹

Step 5: Reconcile “paper vs. reality” on a recurring basis

Pick a practical reconciliation method that fits OT constraints:

• Compare diagrams to firewall configs/rulebases for zone-crossing rules
• Compare network segmentation inventory to switch/router configs (VLANs, VRFs)
• Validate remote access paths match documented broker/jump architecture
• Spot-check a sample of assets per zone for correct placement

Retain evidence of reconciliations and periodic reviews so you can show the architecture is maintained, not merely drafted. ¹

Step 6: Operationalize exception handling

You will have exceptions (legacy flat networks, vendor constraints, outage windows). Create a simple exception record:

• What segmentation requirement is not met
• Compensating controls (monitoring, access restrictions, temporary controls)
• Expiration/review date
• Risk acceptance owner sign-off

Exceptions are not a failure if controlled and documented; unmanaged exceptions are.

Required evidence and artifacts to retain (exam-ready)

Maintain an “architecture evidence pack” for the in-scope environment:

Core artifacts

• Approved cybersecurity architecture standard (minimum requirements, zone definitions)
• Current logical zone diagram(s) covering IT and OT scope
• Network segmentation/security zones inventory (zones, subnets/VLANs/segments, owners)
• Allowed pathways register (zone-to-zone traffic purposes, enforcing controls)

Operational evidence

• Change tickets showing architecture updates tied to installs/removals/changes/exceptions ¹
• Version history or repository logs for diagrams/architecture documents
• Periodic review and reconciliation records (meeting notes, attestations, diff reports) ¹
• Exception register with approvals and compensating controls
• Samples of firewall rule reviews tied back to documented pathways (sample-based evidence is fine if scoped)

If you run Daydream for GRC, store these artifacts as a single requirement evidence collection with mapped controls and a standing request list for OT/network teams. That reduces scramble work during assessments and keeps “maintained” true by construction.

Common exam/audit questions and hangups

Assessors tend to probe four friction points:

1. Scope clarity: “Which sites/networks are included, and where do IT/OT boundaries exist?”
2. Zone definition quality: “Are zones named and justified, or are they just network labels?”
3. Traceability: “Show me one connection from the diagram to the actual enforcing control and its approval.”
4. Maintenance proof: “How do you know this diagram is current? Show changes and reviews.” ¹

Hangup: teams present a single enterprise network diagram that omits OT cells, remote access, or third-party pathways. For C2M2, OT architecture representation is explicitly in scope. ¹

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
Diagrams exist but no zone definitions	You can’t show intent or control objectives	Write a short zone model with purpose, assets, allowed flows
Architecture updates rely on “someone remembering”	“Maintained” becomes unprovable	Add architecture update tasks to change tickets 1
Segmentation described at a high level only	Auditors want traceability to controls	Maintain an allowed pathways register tied to enforcing points
OT ignored or oversimplified	Requirement explicitly covers IT and OT	Build at least one OT logical zone diagram per site/cell structure 1
Exceptions handled informally	Hidden flat networks and vendor access	Use an exception register with approvals and compensating controls

Risk implications (why operators get burned)

If architecture artifacts are inaccurate or outdated, environments drift from approved baselines and security decisions get made on incomplete information during internal control testing, audits, customer diligence, or regulator review. ¹

In OT, that drift often shows up as undocumented conduits, “temporary” vendor connections that become permanent, and firewall rules that effectively collapse zones. Architecture maintenance is how you prevent those from becoming normal.

Practical 30/60/90-day execution plan

First 30 days (stabilize and prove “established”)

• Confirm C2M2 assessment scope (sites, networks, OT domains). ¹
• Assign an architecture owner and approver (often OT security architect + network lead + GRC).
• Publish architecture minimum requirements and a zone taxonomy.
• Produce a baseline logical zone diagram for the scoped environment, including IT/OT boundary and remote access.

Next 60 days (make it operable and defensible)

• Build the segmentation inventory and allowed pathways register.
• Integrate architecture updates into change management (required field + link to updated artifact). ¹
• Stand up an exception process with a register and approvals.
• Run a first reconciliation (diagram vs. firewall rules / network config) and capture evidence. ¹

By 90 days (make it repeatable and audit-ready)

• Run a second architecture review cycle with documented outcomes (changes, accepted risk, remediations). ¹
• Build a small audit evidence package: baseline artifacts + change samples + reconciliation samples.
• If third-party access exists, validate paths are documented, zoned, and governed by the same change/exception process.

(If you need a system to keep these artifacts, owners, reviews, and evidence in one place, Daydream can house the requirement, map the controls, and generate an assessor-ready evidence view without rebuilding spreadsheets each cycle.)

Frequently Asked Questions

Do we need perfect network segmentation to meet this requirement?

You need a defined architecture with security zones and segmentation, plus proof it is maintained. If segmentation is imperfect due to legacy constraints, document exceptions with compensating controls and approvals, and show a maintenance process. ¹

What counts as “maintained” evidence for architecture?

Change records that trigger architecture updates, version history of diagrams/standards, and periodic review or reconciliation records. Keep samples that show updates after installations, removals, or exceptions. ¹

Can we satisfy this with a single Visio diagram?

A diagram helps, but assessors usually need zone definitions, allowed pathways, and traceability to enforcement points. One file can work only if it includes the required context and is kept current through a controlled process. ¹

How do we handle vendor remote access in the architecture?

Treat vendor access as a defined pathway across zones with explicit control points (jump host/broker), approvals, and logging expectations. Document it on the diagram and in the allowed pathways register, and manage changes through the same workflow.

Who should own cybersecurity architecture in an IT/OT environment?

Ownership typically sits with an OT security architect or network/security engineering lead, with GRC enforcing documentation, review cadence, and evidence retention. The key is a single accountable owner with cross-functional approvers.

What if our asset inventory is incomplete?

Start with the architecture scope and zones, then iteratively reconcile what you discover during network reviews and change activity. Retain reconciliation evidence that shows the architecture and inventories are being corrected over time. ¹

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