Safeguard 12.3: Securely Manage Network Infrastructure

Safeguard 12.3 requires you to securely manage network infrastructure by putting formal control around how network devices are configured, changed, accessed, and monitored so they stay in a hardened, approved state. To operationalize it fast, define “network infrastructure” in scope, standardize secure baselines, tightly control admin access and changes, and retain recurring evidence that proves the process runs. ¹

Key takeaways:

• Define and inventory in-scope network infrastructure, then bind it to secure configuration baselines. ¹
• Control the two highest-risk failure modes: privileged access to devices and untracked configuration change. ¹
• Treat evidence as a deliverable: capture configs, change records, approvals, and review logs on a recurring cadence. ¹

The “safeguard 12.3: securely manage network infrastructure requirement” is a practical operator mandate: keep routers, switches, firewalls, wireless controllers, load balancers, SD-WAN components, and cloud networking controls in a known-good, approved state, and prove it. CIS Controls v8 frames this as an implementation expectation, so assessors will look for operational discipline more than perfect tooling. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to translate the safeguard into four auditable movements: (1) clearly define what infrastructure is in scope and who owns it, (2) establish secure configuration standards and an exception process, (3) enforce access and change controls that prevent drift and unauthorized changes, and (4) generate repeatable evidence that ties device state back to approvals and monitoring. ¹

This page is written to help you implement with minimal ambiguity: what to do, in what order, what artifacts to keep, what auditors ask, and where teams commonly fail. It also calls out how to keep the control running when operations are distributed across Network Engineering, Cloud Platform, Security, and third parties that manage parts of your environment. ¹

Regulatory text

Excerpt (provided): “CIS Controls v8 safeguard 12.3 implementation expectation (Securely Manage Network Infrastructure).” ¹

Operator interpretation of the text: You must run a managed program for network infrastructure so device configuration and administration are controlled, secure by default, and verifiable. A reasonable implementation has documented standards, controlled access, controlled change, and monitoring with evidence that those practices occur consistently. ¹

Plain-English interpretation (what this really means)

Your network infrastructure is security-critical shared plumbing. If a firewall rule changes without review, if a switch config drifts, or if a third party has standing admin access, you can lose segmentation, logging, and traffic control quickly. Safeguard 12.3 expects you to treat network infrastructure like production code: hardened baselines, approved changes, restricted admin access, and continuous visibility. ¹

The control is also about auditability. Many organizations “do the right things” informally but cannot prove it during an assessment. CIS explicitly flags missing implementation evidence as a risk factor for 12.3. ¹

Who it applies to

Entity types: Enterprises and technology organizations implementing CIS Controls v8. ¹

Operational context (where this shows up):

• Network Engineering teams managing on-prem routers/switches/firewalls.
• Cloud/Platform teams managing cloud networking (for example, security groups, route tables, virtual firewalls) when those controls function as “network infrastructure” in your environment.
• Security teams that own standards, segmentation requirements, logging requirements, and privileged access governance.
• Third parties that design, operate, or administer network infrastructure (managed network services, MSPs, colo providers, incident response firms with emergency access). Use the same control expectations and evidence requirements for them. ¹

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

Use this sequence to get to an implementable, testable control quickly.

1) Define scope and ownership (make it auditable)

• Write a one-page Network Infrastructure Scope Statement: device types included, environments (prod/non-prod), and whether cloud networking constructs are included.
• Name control owners: one accountable owner (often Head of Network or Infrastructure), plus GRC owner for evidence and testing coordination.
• Define “managed” vs “unmanaged” network devices, and state that unmanaged devices are not permitted or must be remediated via an exception. ¹

Deliverable: RACI + scope statement signed (or otherwise approved) by accountable leadership.

2) Establish secure configuration baselines (standard + exceptions)

• Create a Network Device Hardening Standard. Minimum content:
  • Allowed management protocols (disable insecure management where feasible).
  • Logging requirements (what must be logged and where it must be sent).
  • Time sync requirements.
  • AAA requirements (centralized auth, role-based admin where feasible).
  • Secure configuration expectations for key device families (firewalls, switches, wireless).
• Create an Exception Process: request, risk acceptance, compensating controls, expiration date, and review cadence.
• Tie the baseline to templates or configuration snippets your team can actually apply. Keep it “implementable,” not aspirational. ¹

Practical note: Auditors accept exceptions when they are controlled, time-bound, and reviewed. They reject “we plan to fix it later” with no documented risk acceptance.

3) Control privileged access to network infrastructure (stop silent admin paths)

• Define who can administer network devices and through what paths (jump host, VPN, management network).
• Require unique admin identities. If shared accounts exist, document them as exceptions with a retirement plan and compensating controls.
• Require documented onboarding/offboarding for administrators, including third-party admins.
• Require periodic review of admin access lists against current job role and tickets. ¹

Evidence angle: Access is where many teams fail audits because they cannot show who had access at a point in time.

4) Control configuration change (make drift and “cowboy changes” hard)

• Put network configuration changes under a change management workflow:
  • Request ticket with scope, risk, and rollback plan.
  • Approval (technical + security when the change affects segmentation, exposure, or logging).
  • Implementation record (who, when, what changed).
  • Post-change validation (basic connectivity + security checks relevant to the change).
• For emergency changes, require retroactive approval and documentation within your defined policy window.
• Capture configuration backups so you can prove state and support rollback. ¹

5) Monitor, review, and prove operation (recurring evidence capture)

This is the part that turns a written control into a defensible one.

• Run scheduled checks that validate network infrastructure remains aligned to baseline.
• Review for unauthorized changes and anomalous admin activity.
• Track remediation and exceptions to closure.

CIS guidance in your data emphasizes mapping 12.3 to documented control operation and recurring evidence capture. Treat that as the minimum bar for an assessment-ready program. ¹

Where Daydream fits naturally: Daydream can hold the requirement-to-control mapping for safeguard 12.3, assign owners, schedule recurring evidence requests, and keep an audit-ready thread that ties baselines, change records, and reviews to the safeguard language. This directly addresses the stated risk factor of missing implementation evidence. ¹

Required evidence and artifacts to retain

Keep artifacts that prove (a) the standard exists, (b) access is controlled, (c) changes are approved and traceable, and (d) reviews happen.

Core artifacts (minimum set):

• Network Infrastructure Scope Statement + RACI/ownership.
• Network Device Hardening Standard (current version + version history).
• Configuration baseline templates (or approved reference configs) by device class.
• Inventory of in-scope network infrastructure (export or report).
• Privileged access roster for network administration (including third parties) and access review records.
• Change tickets for a sample of network changes, including approvals, implementation notes, and validation evidence.
• Configuration backup records (or repository history) showing changes over time.
• Exception register with approvals, compensating controls, and expiry/review evidence.
• Monitoring/review outputs for unauthorized changes and admin activity, plus remediation tracking. ¹

Retention tip: Store point-in-time exports (PDF/CSV snapshots) for access rosters and device configs during each review cycle. Systems change; auditors ask what was true then.

Common exam/audit questions and hangups

Assessors typically probe the following:

1. “What is network infrastructure in your environment?”
   Hangup: teams answer verbally but cannot show a scoped list tied to ownership.

2. “Show your baseline and prove devices comply.”
   Hangup: baseline exists, but no recurring check or no evidence that checks were reviewed.

3. “Who has admin access, including third parties, and how do you review it?”
   Hangup: access is split across platforms (AAA, local accounts, cloud IAM), and nobody can produce a single reconciled view.

4. “Pick a recent firewall/switch change and walk me through the approval and validation.”
   Hangup: emergency changes stay undocumented; tickets lack rollback/validation detail.

5. “How do you handle exceptions and configuration drift?”
   Hangup: exception process exists but exceptions never expire or get re-approved. ¹

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	What to do instead
Treating 12.3 as “a network team thing” only	Gaps form at cloud edges and between teams	Define scope across on-prem + cloud networking and assign shared ownership
Writing a hardening standard nobody can apply	Auditors see shelfware; ops ignores it	Use implementable baselines and templates; document exceptions
No proof of recurring operation	CIS flags missing evidence as a risk factor	Schedule evidence capture: access reviews, config reviews, change samples 1
Third-party admin access unmanaged	Creates untraceable changes and accountability gaps	Put third-party access under the same provisioning, review, and logging expectations
Change management exists but excludes network devices	Network changes become “special” and escape controls	Put network config changes under the same ticket/approval discipline

Risk implications (why operators care)

Network infrastructure weaknesses tend to cascade: a single misconfiguration can expose services, disable segmentation, or break centralized logging. For compliance, the most common failure is not a missing tool; it is the inability to show consistent control operation across teams and environments. CIS highlights this explicitly by calling out missing implementation evidence as a risk factor for 12.3. ¹

Practical 30/60/90-day execution plan

No sourced timelines are provided, so treat these as execution phases you can adapt.

First 30 days (stabilize scope + minimum control)

• Publish scope statement and ownership (RACI).
• Inventory in-scope devices and management planes.
• Draft hardening baseline for the highest-risk devices (typically firewalls and remote access paths).
• Implement a single intake path for network changes (ticket requirement) and start capturing approvals and post-change validation.

Days 31–60 (make it enforceable + measurable)

• Roll out privileged access controls: named admins, documented third-party access, and an access roster you can export.
• Stand up configuration backup/versioning for in-scope devices.
• Start baseline compliance checks (even if initially manual sampling) and document findings and remediation.

Days 61–90 (prove repeatability + audit readiness)

• Formalize recurring reviews: access review, config drift review, exception review.
• Run an internal “audit packet” test: pick multiple device changes and produce end-to-end evidence (request → approval → change → validation → config record).
• Centralize evidence in a system of record (for example, Daydream) so the mapping to safeguard 12.3 and the recurring evidence trail is easy to produce. ¹

Frequently Asked Questions

Does safeguard 12.3 include cloud networking (security groups, route tables, virtual firewalls)?

If those controls function as your network infrastructure, include them in scope and manage them with the same baseline, access, and change controls. Write the scope decision down so an auditor does not have to infer it. ¹

What’s the minimum evidence an auditor will accept for “securely managed” network infrastructure?

A documented baseline, proof of controlled admin access, and a set of change records that tie configuration changes to approvals and validation. Add recurring reviews and you move from “point-in-time” to “operating control.” ¹

Our network team makes emergency firewall changes. How do we stay compliant?

Allow emergency changes, but require a defined retroactive documentation and approval path and keep the before/after configuration evidence. Track emergency changes as exceptions if they repeatedly bypass standard process. ¹

How do we handle network devices managed by a third party?

Put third-party administration under your access governance and change management expectations, and require evidence delivery (access lists, change tickets, config snapshots). If they cannot provide it, document a risk decision and compensating controls. ¹

We have a baseline, but devices drift. Is that automatically a failure?

Drift is common; the failure is unmanaged drift. Track drift findings, document remediation or approved exceptions, and retain review evidence that shows you detected and handled it. ¹

How do we map safeguard 12.3 into a control library without overcomplicating it?

Create one parent control (“Securely manage network infrastructure”) with sub-controls for baseline, privileged access, change management, and recurring review/evidence capture. Daydream is useful here because it keeps the mapping and recurring evidence requests in one place. ¹

Footnotes

1. CIS Controls v8; CIS Controls Navigator v8