What Safeguard 4.2 asks for and why a written process comes first
Safeguard 4.2 asks your organization to establish and maintain a written process for configuring network infrastructure securely, and to review that process once a year or after significant enterprise changes. If you must show an assessor that this Safeguard is met, the document itself is the first artifact they will request, because CIS measures it as a failure whenever no such process exists or the last review and update is more than 12 months old. The Safeguard covers the devices that move and filter traffic, including switches, routers, firewalls and wireless access points, and it asks for the process to be written down, owned and kept current rather than held in the heads of the engineers who happen to configure them.
In v8.1, CIS places Safeguard 4.2 in the Documentation asset class and the Govern security function, and assigns it to all three Implementation Groups. That means it is part of IG1, the essential cyber hygiene baseline every enterprise is expected to meet. The Govern placement matters for planning: the process is a management artifact with an owner, a review cycle and a sign-off, not only a technical setting. Before drafting, confirm who in your organization owns network configuration standards, where the current device baselines live today, and whether a change after a firewall rule set or a switch template update triggers a review of the document.
The process also does more work than its own score. The CIS Controls Assessment Specification lists Safeguard 2.1, the software inventory, as a prerequisite for measuring Safeguard 4.2, and seven other Safeguards, including 1.5, 2.6, 12.3 and 12.6, list 4.2 as a prerequisite. In practice, a written standard gives later measurements something to compare against: you cannot report configuration coverage for a switch fleet if no defined standard says what correct looks like. Treat the process as the reference point for everything that follows, and check the specification's own wording for the exact inputs before you rely on it for evidence.
Which network devices and teams fall under the process
Safeguard 4.2 applies to the network infrastructure the enterprise actually runs, so the first task is an accurate list of device classes and the teams that change them. Each card below is a scoping decision that determines what the written process must cover and what evidence the assessment specification will look for.
Firewalls and routers
Perimeter firewalls, internal segmentation firewalls and routers are the devices the Safeguard most often brings to mind, and they usually have the most rules and the highest change rate. Confirm that the process names each model family, its management method and its owner, and that the review date covers the rule base as well as the platform. Ask whether any firewall is managed by a vendor portal outside your own change records, because those changes still belong in scope.
Switches and wireless controllers
Access and core switches, wireless controllers and access points are often configured by a different team from the firewalls, so they drift unless the process names them. Include management interfaces, SNMP settings, VLAN definitions and wireless security profiles. Check that access points deployed by facilities or branch staff appear in the inventory the process relies on.
VPN gateways and remote access
VPN concentrators and remote access gateways sit on the boundary between untrusted networks and internal systems, so their cipher suites, authentication settings and split tunneling options carry real risk. Confirm the process covers both on-premises appliances and any gateway a cloud provider runs for you. Ask who approves a change to authentication settings and whether that approval is recorded.
Cloud virtual network appliances
Virtual firewalls, virtual routers and cloud security groups in public cloud accounts are network devices even though no rack exists. Many enterprises manage them through infrastructure as code, so the configuration process should state whether the repository or the running cloud state is authoritative. Confirm that accounts created by application teams are covered, since they are a common source of untracked network rules.
Owning teams and their handoffs
Network, security, cloud platform and application teams each change parts of the network configuration, and the process should assign a named owner for every device class and every handoff between them. Document who may approve a change, who implements it and who verifies it. Unclear handoffs are a frequent reason a written process exists but cannot show that it was followed.
Third-party managed network services
When a managed service provider configures or operates your network devices, the Safeguard still applies to the enterprise. Confirm in the contract which configuration standards the provider follows, how it reports changes to you, and how you receive evidence of its annual review. If the provider keeps configuration backups outside your environment, confirm where they are stored and who can access them.
How the CIS assessment specification scores Safeguard 4.2
The first question the specification asks is whether a secure configuration process for network infrastructure exists at all. If no such process is in place, the Safeguard fails regardless of how well the devices are actually configured. The process is a written, approved document that describes how network devices such as firewalls, switches, routers and wireless access points are built, changed and retired in a secure state. An assessor looks for a process that a named owner maintains and that staff can follow, not a generic statement of intent.
- Written scope: The document names the device classes it covers, including firewalls, switches, routers and wireless controllers.
- Defined steps: It describes how a standard build is set, how deviations are approved and how changes are recorded.
- Named ownership: A role or team is accountable for keeping the process current.
- Link to the inventory: The process refers to the software and device records that Safeguard 2.1 and Control 1 produce, so the scope is traceable.
- Approval record: The version carries an approval date and approver.
Before an assessment, confirm that the document exists in a controlled location, that every network device class in your environment is named in it, and that the owner can explain the steps without reading them aloud.
The specification also fails the Safeguard when the process was last reviewed and updated more than 12 months before the assessment. Safeguard 4.2 itself asks for review once a year or after significant changes to the enterprise, so the 12-month threshold in the assessment is the point at which an existing process stops counting as current. A process that was written well but not revisited will fail this test on its own.
- Dated revision history: Each version shows the date it was reviewed and the date it was updated, which are the values an assessor will check.
- Trigger-based reviews: Significant network changes, such as a new site, a new firewall platform or a merger, should prompt a review that resets the date.
- Review record: Minutes, sign-off or a change ticket show that someone actually read and approved the document.
- Calendar control: A recurring task or document management reminder prevents the date from quietly aging out.
- Version control: Storing the document in a repository with commit history gives a tamper-evident trail of changes.
Before an assessment, check the most recent review date against the assessment date, and confirm that a change to the network since then has been reflected in a dated update.
The metric for Safeguard 4.2 is standard configuration coverage, meaning the share of network infrastructure that is actually built and maintained to the documented standard. A process that exists and is current can still fail in practice if many devices were configured by hand and never brought into line. The coverage measure asks the organization to show which devices follow the standard and which do not, and to account for the exceptions.
- Device population: The count of network devices in scope comes from an inventory, so the denominator is defensible.
- Compliant devices: Devices are checked against the standard configuration by configuration management tooling or periodic configuration exports.
- Exception register: Devices that deviate are listed with the reason, the approver and a remediation date.
- Trend over time: Repeated measurements show whether coverage is improving rather than a single snapshot.
- Software dependency: Accurate coverage depends on knowing which network software and firmware versions are running, which links back to Safeguard 2.1.
Before an assessment, ask your team to produce the current coverage figure and its source, and to list every exception with its approval. The CAS covers what to measure, not how, so the method you choose must be documented and repeatable.
Building the network configuration process step by step
This sequence turns Safeguard 4.2 from a single written sentence into a working process: known devices, agreed baselines, named owners, scheduled reviews and recorded approval, each leaving a document or record an assessor can inspect.
Inventory network devices from the Safeguard 2.1 output
Start from the software inventory produced under Safeguard 2.1, which the CIS Controls Assessment Specification lists as a prerequisite for measuring Safeguard 4.2. Extend it to cover network devices such as routers, switches, firewalls, access points and load balancers, recording make, model, firmware or operating system version, location and the owner responsible for each. Done means every network device in scope has a row in the inventory and every row has a named owner. The assessor will ask to see this inventory and check it against the network diagrams.
Define baseline configuration standards per device type
For each device type in the inventory, write a baseline that states the approved configuration: management access restricted to administrative networks, secure management protocols only, default credentials removed, unneeded services disabled, logging sent to a central collector, and firmware kept on a supported version. Where a published hardening guide exists for the vendor or platform, reference it as the starting point and record any deviations with a reason. Done means each device type has a signed baseline. The assessor will ask for these baselines and for evidence that they match the devices in service.
Write the process with owners and change triggers
Draft the written process itself. It should state its purpose and scope, name the role that owns it, describe how a device is configured, how deviations are approved, and how configuration is verified after installation. List the change triggers that force an out-of-cycle review, such as a new device type, a major firmware upgrade, a merger, or a change to the network architecture. Done means the document is versioned, names its owner and lists its triggers. The assessor will check that the document exists, is current, and is the document staff actually follow.
Verify devices against the baseline
Compare running configurations with the approved baseline using either a configuration management tool, scripted export and diff, or a vendor management platform. Record every deviation, decide whether it is accepted or must be corrected, and track corrections to closure. Measurement under the Assessment Specification uses standard configuration coverage, so the question is how many in-scope devices match an approved baseline. Done means a coverage report exists for the current inventory. The assessor will ask to see that report and the deviation log behind it.
Set the annual review and post-change review
Schedule the annual review of the process and the baselines, and define the post-change review that follows each significant enterprise change. The CIS Controls Assessment Specification fails the Safeguard when the process has not been reviewed and updated in the last 12 months, so the calendar entry and the review record must both exist. Done means a dated review schedule is in place and the last review was recorded with its outcome. The assessor will check the review date against the version history of the document.
Record approval and retain the evidence
Obtain formal sign-off on the process and baselines from the accountable executive or a delegate who has authority over network operations, and record the approver, date and version. Store the approved documents, inventory, coverage report and change records in a location that keeps version history. Done means each artifact has an approval record and is retrievable without reconstruction. The assessor will ask for the signed version and confirm that the approved version is the one in use.
Evidence that passes a Safeguard 4.2 review
Safeguard 4.2 is judged on documents that exist and on records that show the process is followed over time. The cards below cover the written process itself, the review trail that proves it stays current, and the configuration and change evidence that shows it is applied to network devices.
Approved written process
The core artifact is a written process for configuring network devices securely, approved by a named owner and stored where auditors can retrieve it. It should name the device types in scope, such as routers, switches, firewalls and wireless controllers, and state who builds, approves and checks configurations. Confirm the document covers the full device lifecycle, from initial build through change and retirement, and that it refers to the baseline and change records described below. An approved, scoped document is the first thing an assessor checks.
Revision history and last review date
The assessment specification fails Safeguard 4.2 when the process was last reviewed and updated more than 12 months ago, so the last review date is measured directly. Keep a version table in the document with the author, approver, date and summary of each change. Keep the document in version control so that the history can be produced without reconstruction. Confirm that the revision history matches what the team says it does.
Annual review record
Safeguard 4.2 calls for review once a year or after significant changes to the enterprise, so the review itself needs its own record. A review record should show the date, the reviewers, the scope examined, the findings and the decisions taken, including decisions to make no change. Record reviews triggered by significant enterprise changes as well as scheduled ones. Keep the record linked to the revision history so that an assessor can follow a review to its outcome.
Device configuration baseline
A baseline records the approved secure settings for each network device type, such as management access, logging, time sources, unused ports, password handling and permitted protocols. Compare the baseline against the actual configuration of devices, and keep the comparison results. Where the organization uses a published benchmark as its starting point, note which one and which version was adopted and why. Confirm that each baseline is owned and that exceptions to it are documented and approved.
Change records showing the process applied
Evidence that the process is used appears in change tickets. Each change to a network device should reference the baseline, show the configuration reviewed before and after the change, and record who approved it. Sample several changes across the period under review, including emergency changes, because those are where undocumented configuration tends to appear. Confirm that changes made outside the process are detected and reconciled rather than left unexplained.
Configuration coverage reports
The measure for Safeguard 4.2 is standard configuration coverage, so the organization should be able to show what share of in-scope network devices match the baseline. A coverage report lists each device, its assigned baseline, its compliance state and the date of the last check. Gaps should lead to tickets with owners and dates. Ask whether the report is generated from a tool or assembled by hand, and confirm that the device list it uses matches the asset inventory maintained under Safeguard 1.1 and the software inventory maintained under Safeguard 2.1.
What meeting Safeguard 4.2 costs in money and effort
This table breaks down the cost components of meeting Safeguard 4.2, showing who is paid for each item, whether it is one-time or recurring, and what moves it up or down. No fee figures are supplied for this Safeguard, so use the table to build the scope questions you put to any quote, including the option of self-hosted open-source tooling that can remove license spend.
| Cost component | Who is paid or who spends time | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Writing the network device configuration process | Internal network and security staff, possibly an outside consultant if internal capacity is short | One-time to create, then recurring review | Number of device types, vendors and admin models; reuse of an existing server or endpoint process as a template |
| Approving the process | Senior management or the designated owner who signs off the document | One-time per version | How many approval layers exist and whether the process is kept in a single controlled document |
| Network device inventory | Network operations staff, and an implementation partner if discovery tooling is deployed | One-time build, recurring upkeep | Count of switches, routers, firewalls and access points; whether an existing asset inventory (Safeguard 1.1 and 2.1 data) can be reused |
| Baseline definition and hardening standards | Network engineers, with security review of each baseline | One-time per device family, updated on change | Number of distinct firmware versions and vendors; availability of vendor or CIS Benchmark content to start from |
| Configuration assessment tooling | Licensing to a vendor, or staff and partner time to deploy open-source tools such as OPNsense or Wazuh configuration checks | Licenses or subscriptions recur; open-source tools carry setup and maintenance effort instead | Choice between commercial and self-hosted tooling; number of devices scanned; reporting needs |
| Annual review and change-driven updates | Network and security staff, plus approvers | Recurring, at least annually and after significant enterprise changes | Frequency of network changes, mergers, new sites or cloud network build-outs |
| Evidence collection for assessors | Internal staff preparing samples, with auditor or assessor time billed separately | Recurring at each assessment cycle | Number of samples the assessor selects, how well evidence is indexed, and whether configuration reports are exportable |
| Remediation of configuration gaps | Network engineers, change board, and possibly the device vendor | One-time for initial gaps, recurring as drift appears | Age of current device configurations and how many devices fall outside the approved baseline |
| Quote and scope agreement | The organization and any implementation partner, agreed in writing before work begins | One-time | Clarity of device list, sites in scope and which items are owned internally versus outsourced |
Who writes, implements and attests to the process
The organization owns the process. Safeguard 4.2 asks for a written process for configuring network infrastructure securely, and that document only has value if the organization's own people approve it, follow it and sign off on its annual review. Ownership sits with the function that runs the network, usually with security sign-off on the standard configuration.
- Approval: A named executive or governance body approves the written process and records the approval date.
- Operation: The network team applies the process to firewalls, switches, routers and wireless controllers, and records deviations.
- Annual review: An accountable owner reviews and signs the process at least once a year and after significant enterprise changes.
- Exceptions: Someone in the organization approves and tracks each exception to the standard configuration.
- Ongoing evidence: Change records, configuration baselines and review sign-offs are kept by the organization, not by the partner.
Confirm internally who holds each of these roles before any outside party starts work, because the assessor will test whether the organization actually runs the process.
An implementation partner helps the organization put the process into practice. DeployOpen, for example, plans, implements, configures and documents self-hosted open-source platforms inside the client's own infrastructure. For this Safeguard, a partner can draft the configuration standard, set up tooling that checks devices against it and assemble the evidence pack. The partner does not decide the organization's risk appetite and does not approve the standard on the organization's behalf.
- Documentation drafts: The partner drafts the configuration process and baseline for the organization to review and adopt.
- Tooling setup: The partner configures policy checks and firewall rule management, for example with OPNsense or Wazuh, against the agreed baseline.
- Evidence preparation: The partner collects configuration exports, check results, review records and change history into an organized pack.
- Gap reports: The partner documents where devices deviate from the baseline and what remediation is planned.
- Handover: The partner transfers ownership of the documents, tooling and runbooks to the organization's staff.
When you ask for a scope, confirm that deliverables are written, that the organization retains ownership of approvals and that the partner will not sign any attestation.
An independent auditor, assessor or certification body tests whether the process exists and works, then issues any report or certificate. CIS itself does not certify organizations against the Controls, and the Controls' Assessment Specification defines what to measure, not who measures it. The assessor must be independent of the organization and of the partner that helped build the controls, because an assessor who designed the evidence cannot also test it objectively.
- Independence: The assessor should not have designed the configuration process or the tooling it reviews.
- Testing: The assessor samples devices, checks the review date and compares configurations against the documented baseline.
- Reporting: Only the assessor issues the report, attestation or certificate that the organization shares with customers or regulators.
- Scope agreement: The assessor confirms which network devices and environments are in scope before testing.
- Accreditation: Ask whether the assessor holds a relevant accreditation or recognition for the work, since accreditation programs differ by framework.
Before you hire anyone, confirm with your customer or regulator which assessor type they accept, and get that requirement in writing.
Where organizations fail Safeguard 4.2 and how to close it
Most organizations that struggle with Safeguard 4.2 already configure their network devices. The gap is usually that the process is not written down, not kept current, or not connected to the systems that show whether it works. The cards below cover the failure points an assessor is most likely to find and the action that closes each one.
Process exists only as practice
Engineers configure switches, routers and firewalls by habit, using knowledge held by a few people and never written into a single document. Safeguard 4.2 asks for a written process, so an assessor who asks for it will receive nothing to measure against. Close the gap by writing the steps down: the approved baseline, who may change a device, how builds are verified and where the standard lives. Then confirm the document describes what engineers actually do.
Reviews lapse past 12 months
The assessment specification fails Safeguard 4.2 when the process was last reviewed and updated more than 12 months ago, so a document approved once and forgotten fails quietly. Assign a named owner, put the review on a recurring calendar, and record the date and reviewer on the document itself. Review also after significant enterprise changes, such as a new site, a vendor swap or a cloud migration, because the Safeguard asks for that trigger too.
No link to change management
A secure baseline that changes outside the change process drifts within weeks. Requests to open a port, add a rule or replace a firmware image should pass through the same approval steps that the configuration process defines. Check that change tickets reference the baseline, that emergency changes are reviewed afterwards, and that the firewall rule history matches the approved change log. Without this link, the process describes a network that no longer exists.
Device classes missing from scope
Organizations usually cover core routers and firewalls but omit out-of-band management controllers, load balancers, VPN concentrators, branch routers and lab equipment. The process should list every network device class, the baseline for each and the owner responsible. Use the software and asset inventories from Safeguards 1.1 and 2.1 to reconcile the device list, and treat any class without a baseline as an open finding.
Wireless and cloud devices omitted
Access points, wireless controllers and cloud network constructs such as virtual firewalls, security groups and virtual routing tables often sit outside the network team's usual review. Safeguard 4.2 covers network infrastructure, so these belong in the process with their own baselines. Confirm that wireless settings such as encryption, management access and rogue controls are included, and that cloud network configuration is governed by the same written process as physical equipment.
No measurable coverage
Without a count of compliant devices, the process cannot show whether it works, and the assessment specification measures standard configuration coverage. Track how many in-scope devices run the approved baseline and how many drift from it. Automated compliance checks, such as Wazuh policies for supported platforms or manual comparisons against exported configurations, can produce that number. Set a target, report it to the owner each review cycle and keep the reports as evidence.
Questions buyers ask about Safeguard 4.2
Can our own team write the network secure configuration process without an outside firm?
Yes. Safeguard 4.2 asks the organization to establish and maintain the process, so the document must be owned internally and reflect how your network devices are actually built and changed. Your network, security and operations staff write the process, approve it and keep it current. An implementation partner can draft a template, map it to your device families and help set up the review cycle, but it cannot own the process or attest that it is followed. Ask any partner to show which parts of the document it drafted and which parts your staff must approve before they are treated as final.
What does the work require from our staff?
The work needs people who know your network estate well enough to describe it. Typically this means network engineers who can state the secure baseline for each device type, security staff who can define the review criteria, and an approver with authority over network change. Ask for time from these roles in the planning phase, because the process cannot be written from a generic template alone. Named owners for the document and for each review are the evidence an assessor looks for first.
How long does the annual review take in terms of our own steps?
The review is a set of steps you control: confirm the document still matches current device types, check the configuration baseline against recent changes, record the reviewer and date, and update the document where needed. The Safeguard measurement fails if the process was last reviewed and updated more than 12 months ago, so schedule the review well inside that window and repeat it after significant enterprise changes. Ask any partner for its estimated effort for the first review and for later reviews as a separate line in the written scope.
Must Safeguard 4.1 be finished before we start Safeguard 4.2?
Not strictly, but the two are closely linked. Safeguard 4.1 covers the secure configuration process for end-user, mobile, IoT and server assets and for operating systems and applications, while Safeguard 4.2 covers network infrastructure. Both are Govern-function Safeguards with their own review cycle. Many organizations draft them together because they share a change process, approvers and templates. The CIS assessment specification also lists Safeguard 2.1, the software inventory, as a prerequisite for measuring 4.2, so an accurate inventory of network devices and software should exist before you claim coverage.
What will the assessor request as evidence for Safeguard 4.2?
Expect a request for the written process itself, its version history, the date of the last review and update, and the approval record. The assessment specification measures whether a process exists and was reviewed within 12 months, and it uses standard configuration coverage as its metric, so the assessor will also want to see the baseline configurations and a sample showing that network devices follow them. Confirm the exact evidence list with your independent auditor, since assessors set their own sampling and evidence requirements.
What drives the cost of meeting Safeguard 4.2 up?
The main driver is the number and variety of network devices and the number of distinct baselines you must document, such as routers, switches, firewalls and wireless controllers across several sites or clouds. Cost also rises when the current configuration is undocumented, when change control is informal, or when several teams own different devices. Costs fall when inventory is accurate and baselines already exist. The one-time costs are drafting the process and building baselines. The recurring costs are the annual review, the update after significant changes and staff time. Ask for a quote that separates these items and names who performs each one.
Which open-source tools help produce the configuration evidence for network devices?
OPNsense (BSD-2-Clause) provides a stateful packet filter whose rules pass, block or reject traffic by source, destination, port and protocol, and it can log each rule match for review. Its aliases help group address ranges so rules stay readable under review. Wazuh (GPL-2.0-only) Security Configuration Assessment checks monitored endpoints against YAML policies, mostly based on CIS benchmarks, and recommends remediation. Confirm which device types each tool supports in your environment before you rely on it for evidence, since coverage for switches and wireless hardware varies by platform.
How DeployOpen prepares network configuration evidence
DeployOpen's work on Safeguard 4.2 starts with a written scope agreed before any configuration changes. That scope names the network devices in play, such as firewalls, routers, switches and wireless controllers, and the self-hosted platforms that will hold the configuration baselines. DeployOpen then drafts the network secure configuration process document, which the client owns and approves. The document should state who approves a standard configuration, how deviations are recorded, and what triggers a review. The CIS assessment specification fails the Safeguard when the process is missing or was last reviewed more than 12 months ago, so the document needs a dated approval record and a named owner from the first day.
DeployOpen configures the tooling that produces evidence inside the client's own cloud accounts, data centers or air-gapped networks. For firewall rules, that typically means OPNsense, whose rules, aliases and per-rule logging can be exported and reviewed. For endpoint and server checks, Wazuh Security Configuration Assessment and Fleet policies can show which assets pass or fail a baseline. Before these systems are trusted, the client should confirm each device type is supported, that scan results are retained, and that the owner of each exception is identified. The software inventory from Safeguard 2.1 should be checked for accuracy, because the assessment specification lists it as a prerequisite for measuring Safeguard 4.2.
DeployOpen assembles an evidence pack for the independent assessor or auditor the client has chosen. The pack typically includes the approved process document, its review history, baseline configuration exports, scan outputs, exception records and change records that link to the process. DeployOpen does not issue reports, attestations or certificates. Only the independent assessor or certification body does that, and the client owns its controls. Because configuration drifts after the first review, ongoing review support is available as a separate retainer, scoped in writing, so that the annual review and post-change updates stay current.
