Safeguard 9.2: Use DNS Filtering Services

To meet the safeguard 9.2: use dns filtering services requirement, you must route organizational DNS queries through a DNS filtering service that blocks known malicious domains and supports monitoring, policy enforcement, and evidence retention. Operationalize it by defining where DNS must be enforced (endpoints, networks, remote users), implementing technical controls, and keeping repeatable proof of coverage and blocks. ¹

Key takeaways:

• DNS filtering must be centrally enforced and hard to bypass, including for remote users.
• Audits fail on evidence gaps: you need logs, policy configuration, and coverage proof on an ongoing basis.
• Treat DNS filtering as a control with owners, scope, and recurring testing, not a one-time IT project.

DNS filtering is a fast, high-impact control because it can stop common intrusion paths before a connection is established. CIS Controls v8 Safeguard 9.2 expects you to use DNS filtering services as a standard defensive layer. ¹

For a Compliance Officer, CCO, or GRC lead, the operational challenge is rarely “do we have a tool?” The hard part is defining enforceable scope (corporate networks, cloud, roaming devices, BYOD boundaries), preventing bypass (hardcoded resolvers, DoH), and producing evidence that the control operates continuously. Examiners also expect you to show how alerts feed incident response, and how exceptions are tracked and approved.

This page translates Safeguard 9.2 into implementable requirements: what systems must be covered, how to deploy DNS filtering without breaking business services, what artifacts to retain, and how to answer the audit questions that commonly stall reviews. References are limited to CIS’s published framework materials. ¹

Regulatory text

Framework requirement: “CIS Controls v8 safeguard 9.2 implementation expectation (Use DNS Filtering Services).” ¹

Operator interpretation (what you must do):
You must implement a DNS filtering capability that:

• Applies organizational policy to DNS lookups (at least for corporate-managed users and systems).
• Blocks or warns on queries to domains associated with malware, phishing, command-and-control, and other known-bad categories.
• Produces logs and reporting that let you prove the control is operating and supports detection and response workflows. ¹

Plain-English interpretation

DNS is the “address book” of the internet. Many attacks require a DNS lookup before the attacker can deliver malware, capture credentials, or establish command-and-control. Safeguard 9.2 expects you to put a control point in front of DNS so users and systems can’t easily resolve and reach known malicious destinations.

From a compliance perspective, the requirement is satisfied only when the control is (1) deployed to the right places, (2) enforced consistently, (3) monitored, and (4) evidenced repeatedly.

Who it applies to

Entities: Enterprises and technology organizations implementing CIS Controls v8. ¹

Operational contexts where auditors will expect this control:

• Corporate networks (HQ, branch, campus Wi‑Fi)
• Remote workforce (laptops off-network)
• Cloud workloads and hosted environments where you manage DNS paths
• High-risk user groups (finance, admins) and high-value assets (identity systems, EDR management servers)

Common scoping boundary (state it explicitly):

• In-scope: corporate-managed endpoints, corporate networks, corporate-controlled resolvers, managed cloud networks.
• Out-of-scope by design (if applicable): unmanaged BYOD devices on guest networks; personal mobile devices; customer networks. Document the rationale and compensating controls.

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

1) Define the control scope and “enforcement points”

Create a short scope statement that answers:

• Which users/devices must use filtered DNS (managed endpoints, servers, privileged accounts).
• Where filtering is enforced: network egress, endpoint agent, roaming client, VPN DNS, or resolver forwarding.
• What “bypass” means in your environment (public resolvers, hardcoded DNS, encrypted DNS).

Artifact: DNS Filtering Control Standard (1–2 pages) with scope, ownership, and exception process.

2) Select the DNS filtering pattern that fits your topology

You can meet the intent with multiple architectures. Pick one primary pattern and document it.

Pattern	Works best for	Audit concern to address
Recursive resolver forwarding to filtering provider	Central networks, data centers	Show all network segments forward DNS through it
Endpoint roaming client/agent	Remote workforce	Prove the agent is installed and healthy
Network firewall DNS enforcement	Branch sites, segmented networks	Prove policy coverage and that clients can’t bypass
Secure web gateway integration	Environments already proxying traffic	Show DNS policy is enforced even off-network

Control design rule: If your workforce is mobile, relying only on on-prem DNS enforcement usually leaves a coverage gap off-network. Your documentation should explain how roaming users are covered.

3) Implement policy: categories, allowlists, blocklists, and logging

At minimum, configure:

• Malicious domain categories (phishing, malware, newly registered domains if supported).
• Logging level that captures: timestamp, client identifier, queried domain, action taken (allowed/blocked), policy applied.
• Allowlist process for business-critical domains that get blocked incorrectly, with approval and review.

Operational note: Overly aggressive blocking that breaks business apps leads to “temporary” bypass rules that never get removed. Put a workflow around allowlisting so exceptions are visible and time-bounded.

4) Prevent bypass (as a stated objective with enforceable controls)

Auditors will probe bypass because DNS filtering is easy to evade if users can set their own resolvers.

Common bypass controls to implement and document:

• Enforce corporate DNS via DHCP/network policies on managed networks.
• Block outbound DNS to unauthorized resolvers at network egress (allow only approved resolvers).
• Address encrypted DNS (DoH/DoT) with an explicit stance: either manage it via enterprise controls or restrict unmanaged DoH from endpoints you control.

Artifact: “DNS Bypass Prevention” section in your standard, plus network rule evidence.

5) Integrate detections with incident response

DNS blocks and “allowed but suspicious” lookups can be early indicators.

Minimum operating model:

• Route DNS filtering logs to a central logging/SIEM platform (or provider reporting).
• Define alert triggers (examples: repeated blocks from a host; high-risk category hits; domains associated with credential theft).
• Create an incident ticketing pathway for investigation and containment.

Artifact: Runbook page: “DNS Filtering Alerts Triage,” mapping to your incident response process.

6) Establish recurring evidence capture (the part most teams miss)

Safeguard 9.2 is easy to “turn on” and hard to “prove later.” Build a lightweight evidence cadence:

• Export policy configuration snapshots after material changes.
• Retain a sample of logs that shows blocks and enforcement for representative systems.
• Track coverage (what percent of managed endpoints route DNS through the service) as an internal operational metric; keep the report even if you do not publish the number externally.

Daydream (or any GRC system) fits here as the system of record: link the control statement, owner attestations, monthly evidence uploads, and exceptions to Safeguard 9.2 so audits don’t become a log scavenger hunt. ¹

Required evidence and artifacts to retain

Keep evidence that proves design, implementation, and operation:

Design

• DNS Filtering Control Standard (scope, enforcement points, bypass stance, exceptions)
• Architecture diagram showing DNS flows (on-network and off-network)

Implementation

• Configuration screenshots/exports: policies, categories, block/allow lists
• Network rules showing outbound DNS restricted to approved resolvers (where applicable)
• Endpoint management reports showing roaming client deployment (where applicable)

Operation

• Log samples demonstrating blocks (time, client, domain, action)
• Periodic coverage report (endpoints/servers enrolled; network segments covered)
• Triage tickets or incident records tied to DNS events
• Exception register entries (who approved, why, review date)

Common exam/audit questions and hangups

Expect these questions and pre-answer them in your control narrative:

1. “Show me that remote users are covered.”
   Hangup: DNS filtering only enforced on-prem. Fix: roaming client evidence or VPN DNS enforcement proof.

2. “How do you prevent users from changing DNS?”
   Hangup: no egress restrictions; DoH unmanaged. Fix: outbound DNS controls and endpoint configuration posture.

3. “What happens when a business app breaks?”
   Hangup: informal allowlisting in chat. Fix: tracked exception with approvals and periodic review.

4. “Prove it’s working over time.”
   Hangup: only a one-time screenshot. Fix: recurring log samples + coverage reporting.

Frequent implementation mistakes and how to avoid them

• Mistake: Treating DNS filtering as a network-only control.
  Avoidance: document your off-network strategy; test from a laptop on a home network.

• Mistake: Allowlisting without guardrails.
  Avoidance: require ticket + approver + review date; remove allowlists that are no longer needed.

• Mistake: No client identification in logs.
  Avoidance: ensure logs tie queries to a device/user identifier that your SOC can act on.

• Mistake: “Turned on” but not operationalized.
  Avoidance: assign a control owner, define monitoring expectations, and store recurring evidence mapped to Safeguard 9.2. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this safeguard, so this page does not cite enforcement actions.

Risk-wise, DNS filtering is a preventive and detective layer. If it’s missing or easy to bypass, you should expect higher exposure to phishing infrastructure, malware delivery, and command-and-control callbacks. The compliance risk shows up during assessments as an “implemented but not evidenced” finding, especially when you cannot demonstrate coverage for remote users or cannot produce logs that show blocks. ¹

Practical 30/60/90-day execution plan

First 30 days (stand up scope + a defensible baseline)

• Publish the DNS Filtering Control Standard (scope, enforcement points, exceptions, owners).
• Choose your primary enforcement pattern and document DNS flows.
• Enable core malicious domain categories and logging.
• Start an exception workflow (ticket-based) for allowlisting and bypass requests.

By 60 days (close bypass gaps + wire to operations)

• Implement outbound DNS restrictions where feasible (only approved resolvers).
• Address encrypted DNS stance for managed endpoints and document it.
• Send logs to central monitoring or establish a repeatable reporting export.
• Draft the “DNS Filtering Alerts Triage” runbook and test it with a real blocked-event review.

By 90 days (prove coverage + make audits routine)

• Produce a repeatable coverage report (managed endpoints/servers, key networks).
• Store a recurring evidence pack (policy export, log samples, exception register snapshot).
• Run a tabletop: “phishing domain blocked on laptop off-network,” confirm tickets and response steps work.
• In Daydream, map Safeguard 9.2 to the control owner, evidence cadence, and exception register so the next audit pulls from one place. ¹

Frequently Asked Questions

Do we need DNS filtering if we already have a secure web gateway or EDR?

Safeguard 9.2 specifically calls for DNS filtering services, so you should document how DNS lookups are filtered and logged even if other tools also block threats. If your web gateway provides DNS-layer controls, capture evidence that DNS filtering is enabled and enforced. ¹

How do we handle remote laptops that rarely connect to VPN?

Use an endpoint-based roaming DNS filtering client or equivalent enforcement that remains active off-network. Keep endpoint management reports and logs that demonstrate off-network DNS enforcement. ¹

What evidence is most persuasive to an auditor?

A tight control standard plus recurring proof: policy exports, representative log samples showing blocks, and a coverage report that ties devices/networks to the filtered DNS path. One-time screenshots without operational history tend to fail. ¹

Will DNS filtering break business applications?

It can, especially with newly registered domains or content categories. Put allowlisting behind a ticket and approval flow, and review allowlists periodically so exceptions don’t become permanent bypass.

How do we prove users can’t bypass DNS filtering?

Show egress controls that restrict outbound DNS to approved resolvers (where applicable), endpoint configuration controls for managed devices, and a documented position on encrypted DNS. Pair that with testing evidence from a managed endpoint.

Can we scope this to “high-risk users only”?

You can risk-scope, but document the rationale and boundaries clearly. Auditors will still ask how you protect general users and unmanaged devices, so be explicit about what is out of scope and what compensating controls apply.

Footnotes

1. CIS Controls v8; CIS Controls Navigator v8