What Safeguard 4.9 asks for and why assessors measure coverage
If you are preparing for a CIS-aligned review, the question to answer is whether every network-attached asset resolves names through DNS servers you trust. Safeguard 4.9 asks that network infrastructure be configured to use trusted DNS servers, either enterprise-controlled servers or reputable externally accessible ones. The risk behind it is hijacked or poisoned resolution: if an endpoint or appliance is pointed at an untrusted resolver, an attacker who controls that resolver can send users to malicious addresses without any other compromise. CIS places the Safeguard in the Devices asset class and the Protect security function, and assigns it to Implementation Groups 2 and 3, so it is not part of the IG1 baseline. Expect an assessor to ask for the DNS configuration of your assets, not for a policy statement alone.
The Controls Assessment Specification measures Safeguard 4.9 as one coverage metric built from four measures. In plain terms, coverage asks what share of in-scope assets use approved resolvers. Before you can compute it, you need a current list of assets, which is why the specification lists Safeguards 1.1 and 4.1 as prerequisites: the asset inventory defines the denominator, and the secure configuration process defines what an approved DNS setting is. Confirm with your assessor exactly how they will count assets that are offline, virtual or managed by a third party, since those choices change the result.
Coverage is hard to produce because DNS settings are spread across several places. Resolver addresses may come from DHCP scopes, static settings on servers, operating system profiles on endpoints, mobile device management policies, and the configuration of firewalls, routers and wireless controllers. A change in one location can be overridden in another, and a device that was never inventoried will not appear in any report. Start by exporting resolver settings from each source and matching them to the asset inventory, then record the exceptions. The gaps you find in that reconciliation are usually the findings an assessor would raise.
Which assets and DNS paths fall inside Safeguard 4.9
Safeguard 4.9 applies wherever a device or service resolves names, so the scope is set by what resolves names, not by what sits in a single network. The cards below walk through the asset classes and DNS paths an assessor will expect you to account for, and the inventory from Safeguard 1.1 is the starting point for all of them.
Endpoints and end-user devices
Laptops, desktops and mobile devices resolve names constantly, and each one receives its resolver from a network configuration or a management profile. Check which resolver each device actually uses on the wired network, on Wi-Fi and when it is off the corporate network, because remote devices often fall back to a resolver the organization never selected. Confirm that the endpoint management tool can report the configured DNS servers for each device, since coverage is measured per asset.
Servers and virtual workloads
Application, database and infrastructure servers often have static resolver settings set during build, and those settings can drift from the approved list over time. Images, templates and autoscaling groups can carry old resolver addresses that quietly reappear in new instances. Sample the configuration from golden images as well as running hosts so that the coverage figure reflects what gets deployed.
Network devices and wireless controllers
Routers, switches, firewalls, access points and wireless controllers often resolve names for management, logging and updates, so their resolver settings belong in scope. These devices are frequently configured by hand or through vendor tools, which makes them easy to overlook in an inventory. Include the management plane as well as the data plane, and confirm which resolver each device uses for its own administrative traffic.
Cloud workloads and private resolvers
Cloud instances, containers and managed services may use the cloud provider's resolver, a private resolver inside a virtual network, or a resolver you operate yourself. Each option needs a decision about whether it counts as trusted under your own policy, and that decision should be written down. Ask the cloud platform team which resolver each account, virtual network and cluster uses, and record any exceptions with an owner.
DHCP scopes that hand out resolvers
A DHCP scope can push a resolver address to every client that leases an address, so one scope setting can change the coverage of hundreds of assets at once. Review each scope's DNS option, including scopes on guest, lab and industrial networks that are easy to forget. An assessor will test whether a client that receives an address from a scope actually gets an approved resolver, so compare scope settings with a sample of leased clients.
Split-horizon internal zones
Split-horizon DNS returns different answers for the same name depending on whether the query comes from inside or outside the network. Internal zones may be served only by enterprise resolvers, while external queries go to public resolvers, so a single trust decision can be wrong for one of the two views. Document which zones are internal, which resolver is authoritative for each, and what happens when an internal name is queried from a remote device.
How an assessor tests trusted DNS configuration
This table maps each part of the assessor's approach to Safeguard 4.9 against what the assessor examines, the evidence expected and where coverage typically breaks down. Read it as a checklist of what to prepare before an assessment, since the measure is coverage and coverage is only provable when the inventory is complete.
| Assessment step | What the assessor checks | Evidence to prepare | Where it usually fails |
|---|---|---|---|
| Asset inventory sample | Whether the asset population used for the coverage calculation is complete and current, drawn from the Safeguard 1.1 inventory | Current asset inventory export with device type, location and owner fields, plus the sampling basis | Inventory omits laptops, cloud workloads or network devices, so the denominator cannot be trusted |
| Resolver settings on sampled endpoints | Whether sampled devices resolve names through enterprise-controlled or reputable external DNS servers | Exported resolver configuration or osquery and management tool output for each sampled device | Devices fall back to ISP or default resolvers, often on home networks, travel laptops or guest Wi-Fi |
| Network infrastructure settings | Whether routers, switches, firewalls and wireless controllers point at trusted resolvers | Device configuration backups or screenshots showing DNS server entries and management interface settings | Appliances keep factory DNS settings or DHCP scopes hand out a public resolver that nobody reviewed |
| Secure configuration process | Whether the documented process from Safeguard 4.1 defines approved resolvers and how they are applied | Approved DNS server list, the 4.1 process document and evidence of its annual review | The process names no approved resolvers, or the list is out of date with what is deployed |
| Exception review | Whether each device or segment not using a trusted resolver has a recorded, approved reason and an end date | Exception register with owner, justification, approver and review history | Exceptions exist only as informal knowledge, so unapproved resolvers look identical to approved ones |
| Coverage calculation | Whether the share of in-scope assets configured correctly reconciles to the sampled results | Coverage worksheet tied to the inventory and sampling records | Coverage cannot be reproduced because the inventory and sample were not retained at the same point in time |
How to bring trusted DNS coverage to 100 percent of in-scope assets
This sequence turns Safeguard 4.9 from a policy statement into a measured result: every in-scope asset points at approved resolvers, and the coverage figure can be reproduced by an assessor. It runs from the asset inventory through a written trust standard, configuration, verification, exception handling and a final coverage report.
Confirm the asset inventory baseline
Start from the detailed enterprise asset inventory that Safeguard 1.1 requires, because the Safeguard 4.9 measurement needs a denominator. Filter the inventory to network-connected devices in the Devices asset class that can perform DNS resolution, such as end-user devices, servers, network infrastructure and mobile or IoT assets where your environment supports it. The output is a frozen list of in-scope assets with an owner and an asset class for each, plus a documented rule for what is excluded and why. If the inventory is incomplete, coverage will look higher than it is, so ask the assessor how they will test completeness.
Define approved resolvers and trust criteria
Write the resolver standard that the organization owns: the approved DNS servers, whether they are enterprise-controlled or reputable externally accessible resolvers, the criteria that make a resolver trusted, and who approves additions. Criteria typically cover who operates the service, where queries are logged, whether encrypted transport is used, and how the operator handles security filtering and change notices. The output is an approved resolver register with addresses, operator, approval date and reviewer. Confirm the criteria with your security and network teams before they are applied to any asset.
Link the process to the secure configuration baseline
Connect the resolver standard to the secure configuration process that Safeguard 4.1 describes, so the approved DNS settings sit inside the documented baseline for end-user, server, mobile and IoT assets and for network infrastructure under Safeguard 4.2. This step adds the DNS settings as baseline items with an owner and a review cycle. The output is a baseline entry for each asset class that names the approved resolvers and the configuration source. Without this link, the DNS setting has no documented owner and cannot be reviewed as part of the regular baseline cycle.
Set resolver configuration through DHCP and configuration management
Apply the approved resolvers centrally. For assets that obtain addresses dynamically, set the DNS server options in the DHCP scope. For managed servers, network devices and workstations, set the resolver in the configuration management or endpoint management tooling so the value is version-controlled and reapplied when drift occurs. Static exceptions should be rare and recorded. The output is a change record for each scope and policy group that shows the approved resolver values, the approver and the deployment date. Ask your team which configuration source is authoritative for each asset class so that two tools do not set conflicting values.
Verify resolver settings on each asset class
Check the configured resolver on a sample and on the full population for each asset class, using the endpoint or configuration management reports, DHCP lease data, or a query tool such as osquery where it is deployed. Fleet policies can answer a yes or no question per device, and Wazuh configuration assessment can check configuration files against policy, though you should confirm which checks each platform supports in your environment. The output is a per-asset result showing the resolver in use and a pass or fail status. Keep the raw query output, because it becomes the measurement evidence that an assessor will sample.
Track and approve exceptions
Record every asset that does not use an approved resolver, with the reason, a compensating control, the owner and an review date. Exceptions can include devices that cannot accept centrally assigned settings or isolated systems with a documented need for a different resolver. Each exception needs approval from the same authority that approved the resolver register. The output is an exception register that feeds the coverage calculation, so each non-compliant asset is either fixed, approved with a reason or flagged as a gap. An assessor will test whether exceptions are real and reviewed, not just listed.
Produce the coverage report
Calculate coverage as the number of in-scope assets using an approved resolver, divided by the number of in-scope assets, with approved exceptions shown separately. Keep the report tied to the frozen inventory from the first step and the verification data from the fifth step. The output is a dated coverage report with the method, the population, the exception list, the approver and the query evidence. Ask the independent assessor which measures they expect to see, since the Safeguard 4.9 assessment specification defines the measures and metric that the report should follow. Re-run the report on a regular cycle so that drift is caught after the initial result.
Where open-source tooling fits by environment
On endpoints and servers, the resolver setting usually lives in the operating system, in network interface configuration, or in a DHCP-assigned value that the device accepts. Safeguard 4.9 asks whether these devices point at the DNS servers your organization has approved. A configuration check can read that setting and report whether it matches an expected value. Wazuh's Security Configuration Assessment and Fleet policies can both be used to check and report on these settings, but neither decides which resolvers are trusted. That decision belongs to your resolver standard.
- Wazuh configuration assessment: YAML policies scan monitored endpoints for misconfigurations, checking files and running processes, and can be extended with custom policies that test for your approved resolver addresses.
- Fleet policies: Each policy is a yes or no osquery question asked of devices, such as whether the device resolves through an approved server, and the policies page shows which devices pass or fail.
- Coverage gaps: A check only covers devices that report to the tool, so the asset inventory from Safeguard 1.1 must be used to confirm the population.
- Limits of a pass: A passing result shows the setting at the time of the scan. It does not show that the resolver is responding correctly or that traffic actually follows that path.
- Vendor defaults: Some platforms ship with resolver values that you did not choose, so the custom policy must test for your list, not a generic one.
Confirm with your own resolver standard which addresses are approved, and check that the scan population matches your current asset inventory.
Network infrastructure such as routers, switches and wireless controllers often holds its own DNS server settings, and these are typically managed centrally. Safeguard 4.9 applies to these devices as well, so the configured resolvers should be recorded and checked against the approved list. Where the firewall sits between internal clients and the internet, it can also constrain which DNS servers those clients are allowed to reach, which makes its rules part of the evidence.
- OPNsense rules: The stateful packet filter passes, blocks or rejects traffic by source, destination, port and protocol, so rules can allow DNS only to approved resolvers and block other outbound DNS.
- Aliases for resolver lists: OPNsense aliases group approved DNS server addresses, which keeps the rule set readable and makes the approved list a single place to review.
- Rule match logging: Logging rule matches lets reviewers see whether DNS queries were passed to approved servers or blocked, using the live log view.
- Device configuration: The device's own resolver setting still needs to be recorded, because a firewall rule does not change what a router is configured to use.
- Scope of proof: Firewall rules show what traffic is permitted, not that every device uses a trusted resolver. Both the rule and the device setting are needed.
Confirm that your network devices expose their resolver settings for review, and that firewall aliases match the approved resolver list in your standard.
In cloud environments, resolver settings are often inherited from the provider's virtual network, a DHCP option set, or a managed DNS service, and they can change when a workload is rebuilt. Safeguard 4.9 still applies to these workloads, so the configuration that defines their resolvers should be treated as the evidence. Infrastructure as code that declares the network and instance settings is usually the most reliable place to check, and a runtime check on the instance confirms what is actually in effect.
- Declared configuration: Infrastructure as code templates that set DNS options can be version controlled and reviewed, which gives a record of what was approved and when it changed.
- Runtime checks: A scan on the running instance, such as a Wazuh policy or a Fleet query, confirms the resolver the workload actually uses.
- Provider-managed resolvers: When the provider's resolver is used, confirm with the provider and your standard whether it counts as a reputable, approved option for your environment.
- Ephemeral workloads: Short-lived instances need checks that run at build time or on a schedule, because they may not persist long enough for periodic scans.
- Egress controls: Cloud firewalls or network appliances that restrict outbound DNS produce separate evidence that should be kept with the workload records.
Confirm which resolver each cloud network and workload class is meant to use, and whether your checks cover both declared and running configuration.
Evidence that passes a coverage measure for Safeguard 4.9
An assessor measuring Safeguard 4.9 needs to see which resolvers are approved, which assets use them, and how exceptions are handled. The five artifacts below connect those answers, and each one depends on the asset inventory and secure configuration process that feed the measurement.
Approved trusted resolver list
This is the written list of DNS resolvers the organization has decided to trust, whether enterprise-controlled servers or reputable externally accessible ones. Each entry should record the address, who operates it, the segments or asset classes it serves, and a short rationale for trusting it. Review the list on a set schedule and whenever a resolver changes ownership or policy. Ask whether the rationale covers filtering and logging, since those are what make a resolver trustworthy in practice.
Asset inventory extract
The measurement depends on knowing which assets should be configured. Pull an extract from the asset inventory maintained under Safeguard 1.1, filtered to the enterprise assets in scope for Safeguard 4.9, such as servers, end-user devices and network infrastructure. Each row should show the asset identifier, class and owner. An extract that is older than the inventory it came from will understate the denominator, so regenerate it before each review.
Configuration check output
This artifact shows the resolver settings actually present on each asset. Collect output from a configuration check tool, or from a scripted query of the operating system or device management platform, listing the configured DNS servers per asset. Compare each result against the approved list. Output with no timestamp or no asset identifier cannot be tied to the measurement, so confirm both fields are present before accepting it as evidence.
Exception records with approvals
Some assets will not use an approved resolver, for example isolated network segments or devices that cannot accept a managed DNS setting. Each exception should name the asset, the resolver in use, the business reason, a compensating control, the approver and an expiry date. Exceptions without approval or without an end date are the most common finding in this area. Reconcile the exception register against the configuration check output so that every non-compliant asset either appears in the register or is fixed.
Periodic coverage reports
A coverage report converts the inventory, configuration output and exceptions into the percentage of in-scope assets that meet the requirement, which is the metric Safeguard 4.9 uses. Produce the report on a recurring cycle and keep the prior versions so trends are visible. The report should show the numerator, the denominator and the exception count. Ask the team which person signs off each report and whether the same person owns the underlying data, because assessors look for separation between producing and reviewing the figure.
What meeting Safeguard 4.9 costs in money and effort
This table lists the cost components of meeting Safeguard 4.9, who is paid for each, whether it is one-time or recurring, and what moves it up or down. No fee figures are given here because none are supplied for this Safeguard, so use the list of drivers to frame a request for a written, scoped quote.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Resolver decision and documentation | Internal architects, with an implementation partner if requested | One-time, revisited on change | Number of resolver policies per segment and whether internal or external resolvers are chosen |
| Configuration of DHCP and device settings | Platform or endpoint engineering team | One-time, then recurring with new builds | Number of asset types, from servers and laptops to network devices and mobile devices |
| Asset inventory prerequisite (Safeguards 1.1 and 4.1) | Asset management and IT operations | Recurring, as assets change | Inventory quality; gaps mean manual checks on unknown devices |
| Self-hosted configuration checks (for example, Wazuh or Fleet) | Internal operations, with open-source licenses carrying no license fee | Recurring operating time for tuning, patching and reviewing results | Number of endpoints monitored and how many custom policies the team writes |
| Evidence upkeep | Compliance or security team, sometimes with a partner | Recurring, usually tied to review cycles | How often DNS settings change and whether results export to a central record |
| External review | Independent reviewer or assessor, engaged by the organization | Recurring at each assessment cycle | Scope size, documentation quality and how many findings need rework |
| Auditor sampling | Independent auditor, paid by the organization under its engagement | Recurring at each audit | Number of asset classes and locations an auditor samples, and the consistency of configuration across them |
| Remediation of drift | Operations teams and, where needed, an implementation partner | Recurring, unpredictable | How many systems drift from approved resolvers and how quickly alerts reach the owner |
Questions buyers ask about Safeguard 4.9
Can an in-house team meet Safeguard 4.9 without outside help?
Yes, an in-house team can meet Safeguard 4.9 if it has the skills and time to configure DNS settings on every in-scope device and to keep a record of them. The work is mostly configuration and verification, not new technology. Whether to bring in help depends on how many network infrastructure assets you run, how current your asset inventory is, and whether your staff already maintain a secure configuration process under Safeguard 4.1. Outside help is usually most useful for the inventory and the configuration baseline, which the measurement depends on. Confirm internal capacity against the Safeguard's scope before deciding.
How long does Safeguard 4.9 take to implement?
The duration depends mainly on the quality of your asset inventory and on how many network devices use DNS settings you do not control. If Safeguard 1.1 already produces a complete inventory of network infrastructure, the configuration work is largely a matter of pointing each device at approved resolvers and checking the result. If the inventory is incomplete, the first phase is discovery, which often takes longer than the configuration itself. No duration figure is supplied for this work, so ask any provider to estimate it from a written scope that lists the assets, the number of DNS settings to change and the verification method.
Are external DNS resolvers acceptable under Safeguard 4.9?
Yes, the Safeguard allows either enterprise-controlled DNS servers or reputable, externally accessible DNS servers, so an external resolver can satisfy it if it is a trusted choice. Your documented process should state which resolvers are approved, why they are considered trustworthy, and what happens when a resolver changes or fails. Consider whether the resolver's logging, privacy terms and jurisdiction match your data handling rules, because those points affect your other Control 3 and Control 8 obligations. Confirm the choice with your security and legal teams before you rely on it.
What does the team need to supply before an engagement starts?
The team needs to supply a current asset inventory, the approved list of DNS resolvers, the network infrastructure devices that will be in scope, and the configuration processes that already govern them. Access to the devices or their management platforms is also required, along with a named owner who can approve the resolver list. Under the Assessment Specification, Safeguards 1.1 and 4.1 are prerequisites because they produce the data the measurement needs, so missing either one usually delays the work. Agree these inputs in writing as part of the fixed scope.
What will an assessor ask for to verify Safeguard 4.9?
An assessor will typically ask to see which network infrastructure assets are in scope, the DNS settings configured on each one, and the evidence that those settings point at trusted servers. They will check that the measure is applied across the inventory, because the Assessment Specification combines four measures into one coverage metric. Expect requests for the approved resolver list, the configuration baseline, and sample exports showing the current DNS settings. Note that the Specification says what to measure but not how, so agree the method and evidence format with your assessor before testing begins. Only an independent assessor or certification body can issue a conclusion.
How do I show coverage for Safeguard 4.9 with open-source tools?
You can collect coverage evidence with self-hosted tools that report configuration state across your estate. Wazuh's Security Configuration Assessment checks monitored endpoints against YAML policies and can be extended with custom checks, so a custom policy can verify the DNS settings on managed hosts. Fleet policies are yes or no osquery questions, and its policies page shows which devices pass or fail each one, which suits a coverage view. For network devices, OPNsense's rules and aliases document what traffic is permitted, which supports the approved resolver list. Confirm that each tool can read the specific settings on your device types before you commit to it.
Does Safeguard 4.9 map to any other frameworks?
CIS maps Safeguard 4.9 to NIST SP 800-53 Rev. 5 controls SC-20, SC-21 and SC-22 in the CIS Controls Navigator for v8.1. That mapping helps you reuse the same DNS evidence for a NIST-aligned assessment, but it does not make the two frameworks equivalent, and each assessor decides how far the evidence reaches. Check the Navigator directly for other frameworks you are subject to, because the mappings are CIS's, not ours. Ask your assessor to confirm how they will accept shared evidence.
Who owns trusted DNS, who prepares evidence and who assesses it
The organization decides which DNS resolvers its enterprise assets may use, who approves exceptions and how those decisions are recorded. Safeguard 4.9 asks that network infrastructure use trusted DNS servers, either enterprise-controlled servers or reputable externally accessible ones, so the trust decision is a policy choice that belongs to the people accountable for the risk. No outside party can accept that risk on the organization's behalf.
- Approved resolver list: Name the internal and external resolvers that count as trusted, with the reason each was chosen.
- Exception process: Define who can approve a device that uses a different resolver, for how long and under what compensating control.
- Ownership of the asset inventory: Assign the team that keeps the Safeguard 1.1 inventory current, since coverage cannot be measured without it.
- Review cadence: Set how often the resolver list and exceptions are reviewed and who signs off.
Check that the written policy names an accountable owner and that exceptions are approved by someone other than the engineer who requested them.
An implementation partner can configure resolver settings across endpoints, servers and network devices, build the checks that show which assets use approved resolvers, and assemble the evidence an assessor will request. This work is usually scoped in writing before it starts, and the organization keeps ownership of the resulting policy and records. The partner prepares the material; it does not decide whether the organization meets the Safeguard.
- Configuration changes: Set resolver settings through the organization's existing management tooling, such as directory policy, configuration management or network device templates.
- Coverage checks: Build queries or scans that report, per asset, which resolver is configured, as in illustrative osquery or Wazuh checks.
- Exception records: Export the list of approved exceptions and match each one to a named owner and approval.
- Evidence packaging: Organize screenshots, configuration exports and check outputs by asset class so the assessor can trace each measure.
Ask the partner to state in the statement of work which artifacts they will hand over and who keeps them after the engagement ends.
An independent auditor, assessor or certification body tests the implementation against the requirement and issues findings or a report. The auditor selects samples, reviews the evidence, may re-perform checks and decides whether the result is adequate. This independence is what gives a report its weight with customers and regulators, so the auditor must not design the controls it later tests.
- Sampling: The auditor chooses which assets and network segments to examine, rather than accepting the organization's list alone.
- Re-performance: The auditor may run its own resolver checks against sampled devices to confirm the results.
- Findings: Gaps are recorded as findings the organization must respond to, not silently corrected by the partner during the test.
- Scope limits: The line falls where advising becomes deciding: a partner may explain a requirement, but the auditor determines conformance.
Confirm with the auditor, before work starts, which evidence they accept and whether they require a particular assessment method for this Safeguard.
Outsourcing is useful for building and running the configuration and evidence, but it must not blur who owns the decision or who issues the verdict. The same firm that configures resolvers should not also certify that its own work meets the Safeguard if an external report is expected. Each role should be written into contracts and engagement letters so that the boundary is visible to the auditor from the start.
- Usually outsourced: Resolver configuration, coverage scripting, evidence packaging and remediation of failed devices.
- Usually kept in-house: Trust decisions, exception approvals, the asset inventory owner and periodic policy review.
- Never combined: Designing the control and independently assessing it in the same report.
- Documented handover: Record which party produced each artifact and who approved it.
Before signing, ask each party to describe in writing which of these roles it holds and which it does not.
Where organizations fall short on trusted DNS
Safeguard 4.9 is easy to state and hard to prove. The gaps below share one root cause: the organization cannot say, for every device, which resolver it uses and why that resolver is trusted. Each card names a gap and the check that closes it.
Unmanaged resolvers on remote and BYOD endpoints
Laptops that leave the office often keep whatever resolver the home router or public Wi-Fi hands out, and personal devices may point at a resolver the organization has never reviewed. A device that resolves names through an unknown server fails the coverage measure even when the office network is clean. Check whether managed endpoints receive DNS settings from policy, and whether unmanaged devices can reach enterprise resources at all. Confirm the answer for each device group rather than assuming the office configuration applies everywhere.
Appliances with hard-coded resolvers
Firewalls, printers, cameras, network devices and some appliances ship with a fixed DNS server in firmware or a default template. These settings rarely appear in the endpoint policy that an administrator reviews, so a device can keep querying a resolver that was never approved. Check the configuration of each appliance class directly, and record the resolver the vendor set so it can be compared with the approved list. Where a device cannot be changed, document the exception and the compensating control.
No defined trust criteria
Safeguard 4.9 allows either enterprise-controlled DNS servers or reputable, externally accessible ones, but it does not define reputable. Without written criteria, teams choose resolvers by habit, and the measured coverage depends on who answered the question. Write down what makes a resolver approved, such as who operates it, where it is hosted, whether it supports the logging the security team needs and who approves changes. Review the list on a set schedule and record each decision.
No reconciliation between DHCP and inventory
DHCP scopes hand out DNS server addresses automatically, so a single scope change can alter the resolver for hundreds of devices. If the asset inventory is not compared with DHCP leases and scope options, the team cannot show which devices receive which resolver. Safeguards 1.1 and 4.1 supply the inventory and the secure configuration process that this measurement relies on. Check that each DHCP scope option matches the approved list, and that devices missing from the inventory are flagged rather than silently counted.
How DeployOpen prepares trusted DNS evidence in your environment
DeployOpen scopes the Safeguard 4.9 work in writing before any change is made to your network. The scope names which resolvers, DHCP scopes, server and endpoint groups, network devices and mobile fleets are in play, which DNS upstreams are approved (enterprise-controlled resolvers, or reputable externally accessible ones you have chosen), and which assets are excluded and why. Deliverables and timelines are agreed in the same document. Because the CIS Assessment Specification treats the asset inventory (Safeguard 1.1) and the secure configuration process (Safeguard 4.1) as prerequisites for measuring this Safeguard, the scope should also state where those two inputs come from in your environment and whether they are current enough to count the assets being measured.
DeployOpen then implements and hardens the configuration inside your own infrastructure, whether that is your cloud accounts, data centers or air-gapped network. Work typically covers the resolver settings on DHCP servers and operating systems, the DNS settings on network devices, and a repeatable check that flags any enterprise asset pointing at an unapproved resolver. Where an open-source platform such as Wazuh or Fleet is used to run the check, the rule logic, the list of approved servers and the remediation steps are written into the delivered configuration so your team can run and adjust them later. Ask any partner to show you exactly which configuration keys, policies or query results will be produced for each asset class in scope.
DeployOpen prepares evidence for your assessment but does not issue audit reports or certifications. The deliverables are the scoping record, the configuration baseline, the coverage results for the four measures in the Assessment Specification, exception records with owners and dates, and a runbook describing how the results are reproduced. Independent auditors or certification bodies decide whether that evidence is sufficient. Your organization owns its controls, its risk acceptance decisions and its approved DNS list. Confirm with your assessor which evidence format they accept before work starts.
How DeployOpen scopes and implements Safeguard 4.9
DeployOpen approaches Safeguard 4.9 as a fixed-scope engagement that starts with the network infrastructure and DNS resolvers your organization already runs. We prepare the configuration, the measurement data and the evidence your team and an independent assessor need, while your organization keeps ownership of the control.
How we scope
- Agree in writing which network devices, endpoints and resolver paths fall under Safeguard 4.9 and which are excluded.
- Confirm the enterprise asset inventory and secure configuration process from Safeguards 1.1 and 4.1 that the measurement depends on.
- Record the approved trusted DNS servers, whether enterprise-controlled or reputable external resolvers, and who approves changes to them.
How we build
- Configure in-scope network infrastructure to use the approved trusted DNS servers, applied through your change management process.
- Set up configuration coverage reporting so each asset's DNS setting can be checked against the approved list.
- Test resolution from representative devices and segments before rollout, and record the results for the change record.
How we hand over
- Document the approved DNS server list, configuration baseline, coverage measurement method and the owner of each measure.
- Provide the evidence an assessor would request for Safeguard 4.9, such as configuration exports and coverage reports, mapped to the four measures in the assessment specification.
- Walk your operations and audit teams through the runbook so they can reproduce the coverage check without DeployOpen.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer if your organization wants help keeping coverage current.
- Review coverage reports when new network segments, devices or resolver changes are introduced.
- Confirm with your independent auditor or assessor which evidence they accept, since DeployOpen prepares evidence but does not issue assessment results.
