What Safeguard 9.2 DNS filtering requires and why it is hard to prove
An assessor will ask one question: does every end-user device resolve names through a DNS filtering service that blocks known malicious domains? Safeguard 9.2 requires exactly that. Every end-user device, whether it sits on the office network or works remotely, must use a filtering DNS service, so that lookups for known malicious domains fail before a connection is made. The Safeguard sits in the Devices asset class and the Protect security function, and CIS assigns it to all three Implementation Groups. That placement makes it part of IG1, the essential cyber hygiene baseline, so an organization cannot treat it as an optional add-on for mature programs.
The usual weak point is the laptop that leaves the building. An on-premises resolver or firewall policy covers devices that route through it, but a roaming laptop on a home or hotel network may use whatever resolver that network hands out. The Safeguard is about the device, not the network, so the compliance lead needs evidence that remote devices are covered too, either through an agent or client that forces filtering or through a secure connection that sends DNS queries through the filter. Confirm with the endpoint team which of these mechanisms applies to each device group before the assessment, and list any device that falls outside both.
The CIS Controls Assessment Specification defines three measures for Safeguard 9.2, combined into one metric called DNS filtering coverage. Its prerequisites are Safeguard 1.1, the enterprise asset inventory, and Safeguard 4.1, the secure configuration process, because the coverage figure is only as complete as the inventory of devices it is measured against. Read the measures directly in the CIS Controls Assessment Specification for Safeguard 9.2 and build the evidence to match each measure, not a general policy statement about DNS. Confirm the exact measure definitions with your assessor, since the auditor's test procedures determine what counts as proof.
Which devices, networks and teams fall inside Safeguard 9.2
Safeguard 9.2 applies to every end-user device, so the scope questions start with where those devices connect and who runs each layer. The cards below cover the decisions that change the work: off-network devices, on-premises endpoints, guest and contractor access, the resolver path, ownership, and the two prerequisites that make coverage measurable.
Laptops and mobile devices off the network
Remote laptops and phones leave the office resolver as soon as they join home or public Wi-Fi, so an office-only DNS filter leaves them unprotected. Confirm which filtering method covers off-network devices, whether that is an agent, a DNS-over-HTTPS endpoint or a secure web gateway profile, and test it from a device that is not on the corporate network. Mobile platforms often limit what a filter can do, so check each operating system separately.
On-premises workstations and servers
Some servers and shared workstations act as end-user devices, such as kiosks, terminal servers and jump hosts used for browsing or email. Decide whether they fall inside the measured population, since a server that performs no browsing may be out of scope while a terminal server serving users is not. Record the decision in the asset inventory so the metric and the audit sample use the same list.
Guest and contractor devices
Guest Wi-Fi and contractor laptops often bypass the managed resolver and are the devices most likely to carry unknown software. Decide whether they must send DNS through the enterprise filter, use a separate filtered guest network, or are excluded and documented as such. Whichever choice you make, state it in writing, because an assessor will ask how unmanaged devices are kept out of the measured population.
The DNS resolver path
Coverage depends on the path DNS queries take. Clients that hard-code a public resolver, use DNS-over-HTTPS in the browser, or reach a resolver through a VPN split tunnel can skip the filter entirely. Map each path from the device to the resolver, check that outbound port 53 and encrypted DNS are blocked or redirected where you require filtering, and confirm that the filter logs the queries it answers.
Ownership of the filter and the device
Two teams usually share this safeguard. The network or security team owns the filtering service, its policy categories and exceptions, while the endpoint or platform team owns the client configuration, resolver settings and agent deployment. Write down who approves a blocked domain, who fixes a device that drops off the filter, and who reports the coverage metric to the risk owner.
Prerequisites from Safeguards 1.1 and 4.1
The CIS Controls Assessment Specification lists the enterprise asset inventory from Safeguard 1.1 and the secure configuration process from Safeguard 4.1 as prerequisites for measuring Safeguard 9.2, because they typically produce the device list and the configuration data the measurement needs. Without a current inventory you cannot prove coverage, and without a documented configuration baseline you cannot show that the resolver setting is enforced on every device.
How an assessor tests DNS filtering coverage
This table sets out how an assessor is likely to approach Safeguard 9.2 under the CIS Controls Assessment Specification, which defines what to measure rather than how. Read each row as a question the assessor will ask, the evidence you should have ready, and where coverage claims usually fail.
| Assessment step | What the assessor looks for | Common finding |
|---|---|---|
| Measures behind the metric | Three measures combined into one DNS filtering coverage metric, so every component must be assessed, not only the main filter | Coverage reported for one measure while the combined metric shows gaps |
| Asset sample from inventory | Devices drawn from the Safeguard 1.1 enterprise asset inventory, including remote and on-premises end-user devices | Inventory omits laptops or home-office devices, so the sample never reaches them |
| Filtering configuration evidence | Exported policy showing the DNS filtering service, the block categories or lists applied, and the assignment to device groups | Policy exists but is not assigned to all device groups or roaming profiles |
| Blocked-domain logs | Logs showing the filter blocking known malicious domains from sampled devices during the review period | No blocked queries in logs, which may mean logging is off or the filter is bypassed |
| Devices outside the filter | Sampled devices resolving DNS through the filter when off network, not only in the office | Remote devices fall back to ISP or public resolvers when the agent is not running |
| Unmanaged resolvers | Endpoints and network segments using only approved resolvers, with direct outbound DNS blocked or monitored | Hard-coded public resolvers, DNS over HTTPS in browsers, or unmanaged IoT devices |
| Block list currency | Evidence of automatic or documented update cadence for threat intelligence and block lists | Lists last updated long before the review, with no record of who owns updates |
| Prerequisite data | Safeguard 4.1 secure configuration process showing how DNS settings are set and enforced on devices | DNS settings changed locally by users with no configuration baseline to compare against |
How to implement DNS filtering on every end-user device
This sequence moves DNS filtering from a policy statement to a verified control: each end-user device, on or off the office network, resolves names through a filtering service, and the coverage is checked against the asset inventory the organization already maintains.
Confirm the end-user device inventory
Start from the enterprise asset inventory that Safeguard 1.1 calls for, and filter it to end-user devices such as laptops, desktops and mobile devices that browse the web. The IT or endpoint team owns this list, and the output is a reconciled register that names each device, its owner and whether it is managed. Devices missing from this register cannot be measured later, so treat any gap as a finding to resolve before configuration begins.
Select a filtering service for off-network devices
Choose a DNS filtering service that still applies policy when a device leaves the office, because an on-premises resolver alone does not cover remote staff. Ask the vendor to confirm in writing how roaming clients or encrypted DNS endpoints are handled, which block categories and threat feeds are included, and where query logs are stored. The output is a documented selection record that names the service, its coverage model and the data it retains.
Configure endpoints and network paths
Deploy the filtering client or point each device at the filtering resolver through your endpoint management tooling, and set the same resolver for office network segments through DHCP or the local resolver. Where the platform supports it, lock these settings so users cannot change them. The output is a configuration baseline that records resolver addresses, client versions and the policy profile assigned to each device group.
Block direct outbound DNS that bypasses the service
Enforce the design at the network edge by blocking outbound DNS (typically UDP and TCP port 53) from end-user segments to any resolver other than the approved one, and review whether encrypted DNS over HTTPS can bypass the control on managed browsers. Firewall rules on a platform such as OPNsense can pass traffic to the approved resolver, block other port 53 destinations and log each match for review. The output is a rule set and a test record showing that a query to an unapproved resolver fails.
Verify coverage against the inventory
Compare the filtering service's active-client or query-source report with the reconciled device register. Each end-user device should appear as a protected asset, and any device that resolves names without passing through the service should be investigated. Confirm that a test domain on the provider's threat list is blocked from both an office device and a device on a home or public network. The output is a coverage report that lists covered, uncovered and excluded devices with the reason for each exclusion.
Set a review cycle and retain evidence
Schedule recurring reviews of the coverage report, the resolver configuration baseline and the bypass rules, and repeat the test queries after any change to network design or endpoint tooling. Record who approves exceptions and how long blocked-query logs are kept, and confirm these retention periods with your compliance function and provider. The output is a review record and an updated evidence folder that an independent assessor can sample, while the organization remains responsible for its own control.
How a DNS filter, network controls and logs fit together
Cloud-delivered DNS filtering sends a device's DNS queries to a provider's resolver, which answers queries for known malicious domains with a block response. It is the most direct way to cover laptops and phones that leave the office network, because the device points at the service wherever it connects. The provider maintains the threat intelligence and resolver infrastructure, so the organization owns configuration, enforcement and evidence.
- Coverage: Confirm the client or profile is installed on every managed end-user device, and decide in writing whether unmanaged or personal devices are in scope.
- Blind spots: A device that uses encrypted DNS to another resolver, or that bypasses the client, can avoid the filter unless outbound DNS is controlled at the network edge.
- Evidence: Policy exports, device enrollment reports that match the asset inventory from Safeguard 1.1, and block logs tied to a user or device identity.
- Cost drivers: Licensing usually recurs per device or per user, and the number of endpoints and the log retention period drive the total.
Ask the provider whether it can report coverage per device, not only per policy, because the assessment measures the share of devices that are protected.
On-premises resolver filtering points office devices at an internal DNS resolver that applies a filtering policy before forwarding or answering queries. Dynamic Host Configuration Protocol (DHCP) scopes or static settings hand out the resolver address, so filtering applies to every device that joins the office network. It works well for fixed locations, but it has no effect once a device leaves that network.
- Coverage: Verify that every office subnet, wireless network and guest network hands out the filtering resolver, and that no device has a hardcoded alternative.
- Blind spots: Remote laptops, devices on home networks and phones on mobile data are outside the filter unless another Safeguard 9.2 control covers them.
- Evidence: Resolver configuration exports, DHCP scope options, and query logs that show blocked lookups for known malicious domains.
- Cost drivers: Hardware or virtual appliances, maintenance, and staff time to tune policy are the main costs, and they recur through licensing or support when the resolver is a commercial product.
Test the setting from a sample of devices in each location, because the configuration on paper may differ from what a device receives.
A self-hosted resolver runs inside the organization's own infrastructure, such as its cloud accounts, data centers or air-gapped network. The organization controls the blocklists it applies, the logs it keeps and the data it retains, and no query leaves the environment for a third-party filter. This option suits organizations with data residency or confidentiality requirements, but it moves the work of list maintenance and availability onto the internal team or its implementation partner.
- Blocklist maintenance: Define who selects, updates and approves blocklist sources, and record each change so the auditor can trace a blocked domain to a decision.
- Availability: A resolver that fails leaves devices unable to resolve names, so plan redundancy and monitoring before go-live.
- Remote devices: Devices outside the network can reach the resolver only through a VPN or another approved path, which must be covered by the remote access controls in Control 12.
- Evidence: Configuration files kept under change control, blocklist update logs, and query logs retained for the period the policy sets.
Confirm with the chosen software vendor which blocklist formats, logging options and security updates it supports, because these vary by product and version.
DNS filtering is one layer of a larger set of controls. Firewall rules govern which destinations and ports devices can reach, network-based URL filtering under Safeguard 9.3 stops connections to malicious or unapproved websites by category or reputation, and browser and extension controls under Safeguard 9.4 limit what runs inside the browser. Each layer catches traffic the others can miss, so none of them satisfies Safeguard 9.2 on its own.
- Egress control: A firewall rule that permits outbound DNS only to approved resolvers closes the path around the filter. In OPNsense, rules pass or block traffic by source, destination, port and protocol, and logging can be enabled for each rule, as described in the OPNsense rules documentation.
- URL filtering: Safeguard 9.3 addresses web destinations by address and content category, which can catch threats that reach a website without a DNS lookup of a listed domain.
- Browser controls: Safeguards 9.1 and 9.4 cover supported browsers and extensions, which affects what a user can install that a DNS filter cannot see.
- Logs: Firewall, DNS and proxy logs must be retained and reviewed under Control 8 to show that blocks occurred and were investigated.
Ask the assessor which combination of these Safeguards it expects for your environment, because each one needs its own evidence.
Evidence that shows every device uses DNS filtering
Safeguard 9.2 is measured as one combined metric, DNS filtering coverage, built from three measures, so the evidence has to show both which devices exist and which of them resolve through a filter. The cards below connect the device inventory, resolver configuration, coverage reporting, block logs and list change records into one body of proof that an assessor can trace from start to finish.
Device inventory cross-referenced to filter enrollment
This is the starting point for the coverage measure: a list of every end-user device, remote or on premises, matched against the devices enrolled in the DNS filtering service. Prerequisite Safeguards 1.1 (enterprise asset inventory) usually supply the device list, so the two records should share identifiers such as hostname, serial number or agent ID. Check that remote laptops and unmanaged devices appear, because a gap between the inventory and enrollment is the first thing an assessor looks for.
Resolver configuration baselines
A baseline records how each device is pointed at the filtering resolver, whether through DHCP options, endpoint agent settings, VPN profiles or managed network policy. It should name the approved resolver addresses or service endpoints and the expected configuration for each device class. Keep the baseline in version control, and confirm that Safeguard 4.1 (secure configuration process) governs changes to it so that a device cannot quietly fall back to an unfiltered resolver.
Coverage report
The coverage report is the artifact that most directly shows the combined metric: the share of inventoried devices that resolve through the filter, with exceptions listed by name. Ask the filtering vendor or your administrator which fields the export contains, such as last-seen time and agent health, since a device that has not checked in recently may not be protected. Retain each report with its generation date so that the coverage figure can be reproduced later.
Samples of blocked-domain logs
Log samples show that filtering is working in practice, not only configured. Collect entries that record a blocked query, including the device, the domain, the category and the timestamp, from a range of device types. Make sure the logs are retained long enough to cover the audit period, and confirm the logging setting is enabled, since a filter that does not record blocks gives an assessor nothing to test. Redact personal data before sharing samples outside the organization.
Block list update records
Records of block list updates show that known malicious domains are refreshed on a defined cycle, not set once and forgotten. Keep the source of each list, the date it was pulled or applied, the person or automated job responsible, and any manual additions or removals with a reason. Where the vendor updates lists automatically, retain the vendor's change history or release notes that show the update cadence.
Scheduled exports and change records
Evidence goes stale quickly, so set recurring exports of the device inventory, coverage report and block list history, for example monthly or on a schedule your audit cycle requires, and store them with fixed naming and retention. Pair them with change tickets for resolver or enrollment changes and exception approvals. Ask the implementation partner or your own team to confirm that each export runs without manual steps, because a record that depends on memory will not hold up at assessment.
What meeting Safeguard 9.2 costs in money and effort
This table breaks down who is paid for each part of meeting Safeguard 9.2, which costs are one-time and which recur, and what moves each one up or down. Use it to structure a quote request and to see where open-source self-hosting removes license spend and where it shifts work to your operations team.
| Cost component | Who is paid or who does the work | One-time or recurring | What drives it up or down |
|---|---|---|---|
| DNS filtering service licenses or hosting | Vendor (subscription) or your team (self-hosted resolver and blocklist feeds) | Recurring | Number of end-user devices and remote share; a self-hosted resolver removes subscription fees but adds hosting and maintenance |
| Endpoint configuration for remote devices | Your IT or endpoint team, or a partner preparing agent or profile deployment | One-time, then recurring for new devices | Mix of managed and unmanaged devices; roaming devices need an agent or encrypted DNS profile that works off the office network |
| Network configuration for on-premises devices | Your network team, possibly a partner configuring resolvers and firewall rules | One-time, then recurring with changes | Number of sites and segments; each segment must send DNS through the filter or be blocked from using outside resolvers |
| Asset inventory reconciliation (Safeguard 1.1) | Your asset management owner, with partner support if the inventory is incomplete | One-time cleanup, then recurring reconciliation | Quality of the existing inventory; the assessment specification lists Safeguard 1.1 as a prerequisite for measuring this Safeguard |
| Secure configuration baseline (Safeguard 4.1) | Your platform or endpoint team, documenting the resolver and client settings | One-time documentation, recurring review | How many device types and operating systems you run; each needs its own documented DNS setting |
| Coverage monitoring and evidence upkeep | Your security operations or compliance staff, or a partner preparing reports | Recurring | Frequency of coverage checks, how many devices fall out of scope each month, and how much manual reconciliation is needed |
| Exception and bypass handling | Your security operations team | Recurring | Number of business-justified exceptions and how quickly unauthorized resolver use is detected and closed |
| Independent review or auditor sampling | Independent auditor or assessor, if your program is examined under a framework that maps to Safeguard 9.2 | Recurring per assessment cycle | Scope size, number of device samples requested and whether evidence is organized before the assessor arrives |
Where OPNsense and Coraza fit, and where they do not
OPNsense is an open-source firewall platform (BSD-2-Clause) built on a stateful packet filter. Its rules pass, block or reject traffic by source, destination, port and protocol. That makes it useful for a supporting control: an organization can require that end-user devices reach DNS only through the approved filtering resolver and block outbound DNS from anywhere else. Traffic that tries to bypass the filter, such as a device hard-coded to a public resolver on port 53, can then be dropped at the network edge. OPNsense does not itself filter DNS queries against malicious domain lists, so it is not a DNS filtering service and does not satisfy Safeguard 9.2 by itself.
- Enforce the approved resolver: Rules can pass DNS only to the filtering resolver's address and block other outbound port 53 and port 853 traffic. Confirm how your devices reach DNS over encrypted transports before relying on port rules alone.
- Use aliases for maintainability: Aliases group the resolver addresses, the in-scope subnets and any exceptions, so one change updates every rule that refers to them.
- Log rule matches: Enabling logging on blocking rules and reviewing the live log view gives evidence that bypass attempts were stopped.
- Cover remote devices: A perimeter firewall does not see traffic from laptops on home networks. Remote devices need a client-side or cloud-delivered DNS control, which OPNsense cannot provide.
- Confirm the configuration: Keep exported rule sets and change records as evidence.
Before you rely on this design, check the OPNsense documentation for the current rule options and confirm with your own network team which traffic paths reach the firewall at all.
Coraza is an open-source web application firewall (Apache-2.0) compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set. It inspects HTTP traffic for attacks such as SQL injection, cross-site scripting and code injection, and integrates with proxies such as Caddy, HAProxy, Traefik and Nginx. Its purpose is to protect web applications from malicious requests. It does not resolve, inspect or block DNS queries, so it has no role in filtering the domains that end-user devices look up. An assessor who sees Coraza listed as the evidence for Safeguard 9.2 will not accept it, because the Safeguard concerns the device's name resolution rather than application input.
- Different traffic path: Coraza sits in front of applications and examines request content. DNS queries never pass through it.
- Different protected asset: It protects the applications you host. Safeguard 9.2 protects end-user devices browsing the internet.
- Useful elsewhere: Coraza may support application security or web defense controls that belong to other parts of your program, which should be documented separately.
- Do not reuse the evidence: A Coraza rule set or log export should not appear in the Safeguard 9.2 evidence package.
- Ask the right question: When a vendor or open-source project is proposed for this Safeguard, ask what names it resolves and what block lists it applies.
Review your evidence index and remove any Coraza references from the Safeguard 9.2 entry if they were added in error.
Safeguard 9.2 asks for a DNS filtering service that blocks known malicious domains on every end-user device, remote or on premises. Packet filtering and web application firewalls can contribute, but the core control is a resolver or filtering layer that evaluates each domain lookup against block lists and reports the result. The CIS Controls Assessment Specification measures this through coverage, combined into one metric for DNS filtering coverage. That means the evidence must show which devices use the filter, not only that a filter exists somewhere in the network.
- Filtering function: A resolver or filtering service must check domains against malicious-domain lists and return a block response.
- Device coverage: Devices on remote networks must use the same filter, which typically requires a roaming client or a cloud-delivered resolver.
- Inventory dependency: The coverage measure depends on the asset inventory from Safeguard 1.1 and the secure configuration process from Safeguard 4.1.
- Bypass control: Firewall rules that block alternative resolvers protect the coverage figure.
- Retained logs: Query logs and block events must be retained so the metric can be recalculated for an assessor.
Safeguard 9.2 cannot be met by firewall rules alone, so plan the filtering layer before choosing how to enforce it.
This page does not name the open-source DNS resolver or filter you should run, because the right choice depends on your architecture, your block list sources and the devices you must cover. Several open-source resolvers can apply block lists, but their list handling, reporting and remote device support differ, so confirm each capability in your own environment before committing. An implementation partner can prepare the test plan, but the organization owns the decision and the evidence.
- Block list capabilities: Ask which list formats the resolver accepts, how often lists update and whether you can audit the active entries.
- Remote device coverage: Confirm how roaming devices are directed to the filter and what happens when they are off the corporate network.
- Reporting: Check that query and block events can be exported with timestamps and device identifiers.
- Failure behavior: Decide what happens if the filter is unavailable and whether devices fail open or closed.
- Test before audit: Run a controlled lookup of a known test domain from several device types and record the results.
Document your chosen resolver, its configuration and your test results, then map them to the coverage measure in the assessment specification.
Who owns DNS filtering: your team, a partner and the assessor
Safeguard 9.2 is the organization's control, so the organization decides device scope and owns the result. An implementation partner can design the resolver setup, configure endpoints and assemble evidence, while an independent assessor tests the control and reaches its own conclusions. The cards below separate those roles so each one is clear before work starts.
The organization owns scope and accountability
Your organization decides which end-user devices fall under Safeguard 9.2, including remote laptops, on-premises workstations and any shared or contractor-managed endpoints. Scope depends on an accurate asset inventory, which is why Safeguard 1.1 is a prerequisite for measuring this control. Ask internally who signs off on the scope statement and who answers for a device that is missing from the filter.
The partner designs the resolver architecture
An implementation partner can propose how DNS queries from remote and on-premises devices reach a filtering service, including resolver placement, failover and how off-network devices are covered. The design should match your network and the self-hosted platforms you run. Ask for the architecture in writing and confirm which components are yours to operate after handover.
The partner configures endpoints and rules
Configuration work covers pointing endpoints and firewall rules at the approved resolvers, blocking direct outbound DNS that bypasses them, and documenting the secure configuration process that Safeguard 4.1 expects. Filtering rules in a firewall can pass, block or reject traffic by source, destination, port and protocol. Confirm who holds administrative credentials once the work is complete.
The partner builds the coverage report
The measurement for Safeguard 9.2 combines three measures into one coverage metric. A partner can build the report that counts covered devices against the asset inventory and lists exceptions with reasons. Ask for the query logic, the data sources and how the report is refreshed, so your team can rerun it without the partner.
The partner prepares evidence, not conclusions
Evidence for the assessor usually includes the scope statement, resolver configuration exports, the coverage report and records of exceptions and their approvals. The partner assembles and explains these artifacts. It does not decide whether the control is effective, and it should not write the assessor's findings or wording of the conclusion.
The assessor tests and concludes
An independent assessor samples devices, checks the coverage report against the inventory and tests whether unfiltered paths are blocked. Only the assessor issues conclusions, and an assessment performed by the people who built the control cannot serve as independent testing. Confirm the assessor's independence rules in writing before engaging a partner for the same scope.
Safeguard 9.2 questions buyers ask before hiring help
What drives the cost of meeting Safeguard 9.2 with outside help?
The cost depends mostly on how many end-user devices must be covered, how many locations and remote populations they span, and how much of the DNS filtering stack already exists. Cost falls into two groups. One-time work covers discovery, choosing or confirming the filtering service, configuring endpoints and resolvers, testing blocking behavior and writing the evidence pack. Recurring costs cover the filtering subscription or hosting, log review, and periodic checks that new devices are enrolled. The CIS Controls do not set a price, so ask any partner for a quote built from a written scope that lists device counts, sites, identity sources and the DNS services in use. Keep license fees separate from services fees so you can compare options fairly.
How long does it take to scope a DNS filtering project?
Scoping usually takes less time than the build itself, and its length depends on the state of your asset inventory and device management. The CIS Controls Assessment Specification lists Safeguards 1.1 (enterprise asset inventory) and 4.1 (secure configuration process) as prerequisites for measuring Safeguard 9.2, so a team with a current inventory and documented build process can scope faster. If device lists are incomplete, expect discovery to take the first part of the engagement. No duration figure is supplied for this work, so ask a prospective partner to state the phases, the dependencies they assume and the decision points that would change the timeline.
What does the internal team need to provide for DNS filtering work?
The internal team owns the device estate, the identity sources and the change approvals, so it must supply them. Expect to provide:
- A current list of managed and unmanaged end-user devices, including remote laptops and mobile devices in scope
- Access to the existing resolvers, DHCP settings, VPN or zero trust access paths and endpoint management tooling
- A named owner who can approve DNS changes and accept the risk of blocking false positives
- Access to logs or SIEM feeds so blocked-request evidence can be retained
Without these, a partner can design the filter but cannot prove that every device uses it.
Can a small IT team implement DNS filtering on its own?
A small team can often implement DNS filtering alone when it has a manageable device count, one identity source and a single endpoint management platform. The hard part is coverage, not configuration: remote devices that leave the office network must still resolve through the filter, and that usually requires an agent, a managed DNS profile or a VPN that forces resolution. Small teams should confirm how each device class is enrolled and how they will prove coverage at audit time. If the work involves custom resolvers, self-hosted open-source components or evidence packaging for an assessment, an outside partner can take on those parts under a fixed scope.
How does Safeguard 9.2 differ from Safeguard 9.3 URL filtering?
Safeguard 9.2 applies DNS filtering to every end-user device so that known malicious domains fail at name resolution. Safeguard 9.3 covers network-based URL filters that stop connections to malicious or unapproved websites by category, reputation or block list. The two overlap in purpose but differ in position and coverage. DNS filtering works at the resolver layer and is typically used for all devices, while URL filtering inspects web destinations through a proxy or gateway. Plan them together so that a device off the corporate network still has protection and so that blocked events from both controls feed the same review process.
What does the CIS Controls Assessment Specification measure for Safeguard 9.2?
The CIS Controls Assessment Specification defines three measures for Safeguard 9.2, which are combined into one metric called DNS filtering coverage. The specification describes what to measure, including the inputs, operations and metrics used to verify implementation, but it does not prescribe the tools or the method you use to collect the data. In practice, an assessor will ask for the device population, the proportion of devices resolving through the filter, and evidence that known malicious domains are blocked. Confirm the exact measure wording against the specification before you design your evidence set.
Does DeployOpen certify that Safeguard 9.2 is met?
No. DeployOpen plans, implements, configures and documents self-hosted open-source platforms in your own infrastructure, and it prepares systems and evidence for assessment. Only an independent auditor or assessor issues reports or certifications. The organization owns its controls and decides which Safeguards it claims. Fixed-scope engagements agree deliverables, scope and timelines in writing before work starts, so you can see what evidence will be handed over and what remains with your internal team or an external assessor.
What should a DNS filtering quote include?
A useful quote lists the scope in concrete terms, not just the Safeguard number. Ask for:
- Device counts by type, location and remote population, with the enrollment method for each
- The filtering components to be configured, hosted or integrated, and which parts you already license
- The measurement approach for the DNS filtering coverage metric and the evidence format
- Recurring tasks such as log review, list updates and onboarding of new devices
- Assumptions about your inventory and configuration baseline, and what happens if they are wrong
A quote that states these items lets you compare proposals on equal terms.
How DeployOpen scopes DNS filtering for an audit
DeployOpen agrees the scope of DNS filtering work in writing before any system is touched. The written scope names the end-user device population that Safeguard 9.2 reaches, covering remote laptops, on-premises workstations and any mobile or virtual endpoints the organization treats as in scope. It also records which DNS filtering service is being configured, where its policy is managed, and which deliverables the client receives, such as configuration exports, deployment records and coverage reports. DeployOpen prepares these systems, configuration and evidence. The organization still owns the control, and only an independent auditor or assessor can test it and issue any report.
Because the CIS Controls Assessment Specification measures this Safeguard through three measures combined into one DNS filtering coverage metric, the scope should state how each measure will be produced. The reader should confirm with the assessor which population the coverage percentage is calculated against, and whether the denominator comes from the asset inventory. Safeguards 1.1 (enterprise asset inventory) and 4.1 (secure configuration process) are prerequisites for that measurement, so the written scope should say whether DeployOpen will rely on the client's existing inventory and hardening records or will also prepare them. Gaps in either change the effort, so they belong in the scope before work begins.
A scope should also state what is out of bounds. Typical exclusions include devices the client does not manage, third-party networks where the client has no control, and the policy decisions about which categories or domains are blocked, which remain the client's to approve. Ask for a written scope that lists the assumptions, the client responsibilities such as providing administrator access and change windows, and the acceptance criteria for each deliverable. Ask the independent assessor to review the draft scope before signing, so the evidence collected matches what the audit will test.
How DeployOpen implements and evidences Safeguard 9.2
DeployOpen plans, builds and documents DNS filtering for Safeguard 9.2 inside your own infrastructure, using self-hosted open-source platforms. Your organization owns the control; DeployOpen prepares the systems and evidence, and an independent assessor decides what they prove.
How we scope
- We confirm which end-user devices, on premises and remote, must use the DNS filtering service.
- We agree how Safeguard 9.2 coverage will be measured, drawing on the asset inventory and secure configuration process.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we build
- We deploy a self-hosted DNS filtering service in your cloud accounts, data centers or air-gapped network.
- We configure policies to block known malicious domains and document which device groups they cover.
- We test coverage on representative devices, both on the corporate network and off it, and record the results.
How we hand over
- We deliver configuration records, coverage reports and runbooks that map each measure to the systems that produce it.
- We document how device coverage is checked and how exceptions are approved and reviewed.
- We walk your team through the evidence so your own staff can reproduce it for an independent assessor.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- We can review blocklist updates and coverage gaps as your device estate changes.
- Confirm with us during scoping which assessor evidence requests your engagement will need to answer.
