Every device on your network makes DNS requests hundreds of times a day. Every time a user opens a browser, checks email, or launches an application, a DNS query goes out: quietly, automatically, invisibly. It's the most fundamental layer of network communication, and it's one of the most exploited vectors for malware, phishing, and data exfiltration.
Yet DNS is one of the most overlooked layers in compliance programs. Organizations invest heavily in endpoint protection, access controls, and log management, then leave DNS unmonitored and unfiltered, creating a gap that attackers know how to find.
DNS filtering closes that gap. And it does something else that's valuable from a compliance perspective: it maps to requirements across multiple frameworks simultaneously. A single DNS filtering deployment generates audit-ready logs, enforces acceptable use policies, blocks malware at the network layer, and provides real-time threat detection. It satisfies controls under HIPAA, CMMC, ISO 27001, SOC 2, NIST, and CIS Controls at the same time.
Understanding where DNS filtering fits in your compliance program, and how to document it for auditors, is what this article covers. Because the consequences of non-compliance, from regulatory fines to reputational damage, make it essential to close every defensible gap you can.
Healthcare organizations, covered entities, and business associates operate under one of the most demanding compliance regimes in any industry. The HIPAA Security Rule (45 CFR Part 164) requires specific technical safeguards to protect electronic protected health information (ePHI), and DNS filtering directly supports several of them.
The Security Rule establishes national standards for protecting ePHI created, received, used, or maintained by covered entities. It is organized around administrative, physical, and technical safeguards. The technical safeguards under §164.312 are most directly relevant to DNS filtering, covering access controls, audit controls, integrity controls, and transmission security. Together these requirements demand that organizations not only restrict access to ePHI but also actively monitor and log activity and protect against threats that could compromise data in transit or at rest.
The Security Rule requires covered entities to protect against "reasonably anticipated" threats to the security of ePHI. Malware, including ransomware that has devastated healthcare organizations, relies almost universally on DNS to reach command-and-control infrastructure, download payloads, and exfiltrate data. DNS filtering blocks these connections at the network layer before any payload executes, satisfying the spirit and letter of §164.306(a)(1). Critically, this protection applies to every device on the network, including medical devices and IoT equipment that cannot run traditional endpoint security software.
HIPAA requires covered entities to implement technical policies and procedures that allow only authorized persons to access ePHI. DNS filtering enforces acceptable use policies at the network layer, restricting access to file-sharing services, uncategorized domains, and newly registered domains commonly used in phishing campaigns. This supports the broader access control requirements under §164.312(a)(1) by ensuring that even if a user attempts to reach an unauthorized destination, the network itself enforces the boundary.
HIPAA requires covered entities to implement hardware, software, and procedural mechanisms to record and examine activity in systems that contain ePHI. DNS query logs provide a continuous, timestamped record of all outbound network activity, covering every domain queried, every connection attempted, and every block triggered. This log data is directly usable in breach investigations and compliance audits, providing evidence that controls were active and functioning during the audit period.
DNS tunneling is a technique where attackers encode stolen data inside DNS queries to external servers, and it is a known vector for ePHI exfiltration. DNS filtering platforms that detect tunneling patterns can block these attempts before data leaves the network, directly supporting the transmission security requirements under §164.312(e)(1).
For more on HIPAA, see our HIPAA compliance glossary.
Defense contractors and suppliers in the Defense Industrial Base (DIB) who handle Federal Contract Information (FCI) or Controlled Unclassified Information (CUI) must comply with the Cybersecurity Maturity Model Certification (CMMC) 2.0 framework. CMMC 2.0 is the DoD's mechanism for ensuring that sensitive defense information is protected across the supply chain, and non-compliance can mean loss of contract eligibility.
CMMC 2.0 consolidated the original five levels into three. Level 1 (Foundational) covers basic cyber hygiene and applies to organizations handling FCI only. Level 2 (Advanced) applies to organizations handling CUI and requires implementation of all 110 practices from NIST SP 800-171 Rev 3. This is where most defense contractors operate. Level 3 (Expert) adds practices from NIST SP 800-172 and applies to the highest-priority CUI programs. DNS filtering is most directly relevant at Level 2, where the controls are most demanding and the assessment requirements are most rigorous.
CMMC Level 2 requires organizations to monitor, control, and protect communications at external boundaries and key internal boundaries. DNS filtering acts as an enforcement point at that boundary, blocking outbound connections to known-malicious domains, preventing DNS tunneling, and ensuring only authorized resolution paths are used. Every DNS query that leaves the network passes through the filter, making it a comprehensive boundary protection control that satisfies the SC domain requirements.
DNS telemetry is one of the fastest and most reliable early indicators of compromise. When a device begins querying unusual domains, newly registered hostnames, or known malicious infrastructure, it often signals the early stages of a breach or malware infection, frequently before any other security tool has generated an alert. DNS filtering platforms that surface these alerts in real time support the incident detection and reporting requirements under the CMMC IR domain, enabling faster response and containment.
NIST SP 800-171 Rev 3, which underpins CMMC Level 2, includes System and Communications Protection controls that DNS filtering directly satisfies. Boundary protection, network monitoring, and secure name resolution are all addressed through DNS filtering deployment. Rev 3 also introduced organization-defined parameters (ODPs), which require organizations to document specific implementation decisions. DNS filtering policies, block categories, and exception handling processes all serve as that documentation.
CMMC Level 2 assessments require documented evidence of control implementation. DNS filtering provides two forms of evidence that assessors expect to see: policy documentation (what is blocked and why, how exceptions are requested and approved, how policies are reviewed) and log data (proof that the controls are active and functioning during the assessment period). Both are essential. A DNS filtering deployment without policy documentation is difficult to defend in an assessment; log data without a policy to reference it against is equally problematic.
Learn more about CMMC 2.0 from our CMMC compliance glossary.
ISO/IEC 27001:2022 is the international standard for information security management systems (ISMS) and one of the most widely adopted compliance frameworks across industries and geographies. Unlike prescriptive regulatory regimes, ISO 27001 takes a risk-based approach where organizations identify their specific risks and implement controls from Annex A proportionally. This flexibility makes it applicable to any industry, and its international recognition makes it valuable for organizations operating across borders.
The 2022 revision of ISO 27001 significantly restructured Annex A, moving from 114 controls across 14 clauses in the 2013 version to 93 controls organized across four themes: Organizational, People, Physical, and Technological. Organizations still referencing 2013 control numbering should note this change, as several DNS-relevant controls exist in the Technological theme (Annex A.8) that have no direct equivalent in the older structure. For certification purposes, the 2022 version is now the operative standard.
Annex A.8.7 requires that protection against malware be implemented and supported by user awareness. DNS filtering is a documented, auditable technical control that directly satisfies this requirement, blocking malicious domains before malware can download or execute across every device on the network regardless of operating system or endpoint protection status. The network-level enforcement is particularly valuable because it cannot be disabled by end users, providing a consistent baseline that complements endpoint security tools.
A.8.20 requires that networks are managed and controlled to protect information in systems and applications. A.8.21 extends this to the security of network services, including authentication mechanisms, access restrictions, and connection management. DNS filtering enforces network security policy at the resolution layer, ensuring devices cannot reach unauthorized or malicious destinations regardless of application-layer controls. This makes it a strong evidence point for both controls during ISO 27001 certification audits.
ISO 27001:2022 explicitly includes web filtering as a Technological control under A.8.23. This is one of the clearest and most direct mappings in any major compliance framework. DNS-based web filtering is a recognized implementation approach for A.8.23, and having it deployed is direct evidence of control implementation. Organizations pursuing ISO 27001 certification should ensure their DNS filtering policy is documented and that logs are retained in a format that can be presented to auditors.
ISO 27001 certification requires evidence of ongoing monitoring and measurement of controls. DNS query logs, block event records, and policy change histories provide continuous, timestamped evidence that is directly usable in internal audits and Stage 2 certification reviews. Ensure log retention periods align with your ISMS documentation requirements and that policy changes are logged with timestamps and approvals.
Learn more about DNS security requirements under ISO 27001:2022 in our ISO 27001 DNS security guide.
SOC 2 is an auditing standard developed by the AICPA for service organizations, including SaaS companies, managed service providers, and any organization that stores, processes, or transmits customer data. It evaluates controls against five Trust Services Criteria (TSC): Security, Availability, Confidentiality, Processing Integrity, and Privacy. Most organizations pursue a Security-focused Type II report, which covers a defined period of time (typically 6 to 12 months), making consistent, ongoing control operation essential.
For a foundational overview of SOC 2, see our SOC 2 overview.
The Security criterion, also called the Common Criteria, is the foundation of every SOC 2 report. It covers logical and physical access controls, system operations, change management, and risk mitigation. DNS filtering contributes to multiple Common Criteria categories, making it a meaningful control in any SOC 2 program.
CC6.6 requires that the organization implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software. DNS filtering operates at the network layer to prevent devices from reaching malicious infrastructure, blocking phishing domains, malware download sites, and command-and-control servers before any connection is established. This is a clear, auditable implementation of CC6.6 that complements endpoint-layer controls.
CC7.1 requires that the organization detects and monitors for new vulnerabilities and uses threat intelligence as part of its security operations. DNS filtering platforms that incorporate threat intelligence feeds, identifying newly registered domains, categorized malware infrastructure, botnet C2 servers, and domain generation algorithm (DGA) patterns, directly operationalize that intelligence at the DNS layer. Every query is evaluated against current threat data in real time, satisfying the spirit of CC7.1's continuous monitoring requirement.
CC7.2 requires that the organization implements detection measures to identify anomalies that may indicate a security event. DNS telemetry provides behavioral signals that are difficult to replicate at other layers, including unusual query volumes, queries to newly registered or uncategorized domains, DNS tunneling patterns, and sudden spikes in NXDOMAIN responses. These signals surface anomalies for security operations teams and provide the detection capability CC7.2 requires.
SOC 2 Type II auditors will sample your DNS filtering logs over the audit period, review your DNS security policy, and examine change management records to verify that policy changes were approved and documented. Practical requirements to have in place before your audit window opens include log retention covering the full audit period, a written DNS filtering policy that defines categories, exceptions, and review frequency, and a change log showing that policy updates went through an approval process.
For more on why SOC 2 compliance matters when evaluating vendors, read our guide on SOC 2 and vendor trust.
The National Institute of Standards and Technology (NIST) publishes the cybersecurity frameworks and special publications that underpin U.S. federal compliance requirements and that are widely adopted by private organizations as a security foundation. Three publications are most directly relevant to DNS filtering: the Cybersecurity Framework (CSF) 2.0, SP 800-53, and SP 800-171.
NIST released CSF 2.0 in February 2024, and the most significant change is one that many organizations are still incorporating: the addition of a sixth function, Govern (GV). The original five functions (Identify, Protect, Detect, Respond, Recover) described what organizations should do technically. Govern sits above all of them and addresses how organizations should make cybersecurity decisions, defining organizational context, establishing risk management strategy, clarifying roles and responsibilities, and managing supply chain risk.
This is a meaningful shift for DNS filtering. Under CSF 2.0, DNS filtering policies covering what is blocked, why, how exceptions are handled, and how policies are reviewed are no longer just technical documentation. They are governance artifacts that feed the GV.OC (Organizational Context) and GV.RM (Risk Management Strategy) subcategories. A DNS filtering deployment that is well-documented and policy-governed satisfies the Govern function; one deployed without documentation does not.
DNS filtering touches every function in the CSF 2.0 framework:
Govern (GV): DNS filtering policies and change logs serve as governance documentation under GV.OC and GV.RM, connecting network-level controls to the organization's risk management strategy.
Identify (ID): DNS query logs surface the full picture of what domains, services, and applications are in active use across the network, supporting asset inventory and risk assessment functions.
Protect (PR): DNS filtering enforces access controls at the network layer (PR.AC) and implements data security policies by blocking unauthorized or malicious destinations (PR.DS).
Detect (DE): Real-time DNS threat detection, flagging queries to malicious, newly registered, or suspicious domains, directly supports anomaly detection (DE.AE) and continuous monitoring (DE.CM).
Respond (RS): During an incident, DNS sinkholing redirects malicious traffic for analysis without fully blocking it, enabling investigation while limiting damage.
Recover (RC): Post-incident, DNS filtering policies can be rapidly updated to block domains associated with the attack, preventing recurrence and supporting recovery planning.
SP 800-53 Rev 5 includes three controls specifically dedicated to DNS security under the System and Communications Protection (SC) family:
DNS filtering directly satisfies SC-21 by ensuring only trusted, validated resolution paths are used and blocking queries to known-malicious domains. It supports SC-22 by adding a security layer to the resolution architecture.
SP 800-171 Rev 3 (published May 2024) governs the protection of Controlled Unclassified Information (CUI) in non-federal systems and underpins CMMC Level 2. Rev 3 expanded the control set and introduced organization-defined parameters (ODPs), which are specific values and decisions that each organization must document for how they implement each control. This means DNS filtering deployment alone is not sufficient. Organizations must document their specific implementation choices, block categories, exception processes, and review cadence as part of their CUI protection documentation. DNS filtering supports the SC family controls in SP 800-171 Rev 3, particularly around boundary protection, network monitoring, and secure communications.
In March 2026, NIST published SP 1308: "NIST CSF 2.0: Cybersecurity, Enterprise Risk Management, and Workforce Management Quick-Start Guide." This publication formalizes the connection between CSF 2.0's Govern function and an organization's broader enterprise risk management (ERM) and workforce management practices.
For organizations using DNS filtering, SP 1308 matters because it establishes exactly where DNS policy documentation belongs in the governance structure. The GV.OC subcategory (Organizational Context) requires that legal, regulatory, and contractual requirements surrounding cybersecurity decisions are understood and documented. DNS filtering policies are part of that context. The GV.RM subcategory (Risk Management Strategy) requires that risk tolerance and priorities are established and communicated. DNS block policies are an expression of those risk decisions. SP 1308 gives organizations a framework for connecting their DNS filtering program to enterprise-level risk governance, strengthening both the compliance posture and the internal case for the investment.
NIST has also released SP 1347, a "CSF 2.0 Informative References Quick-Start Guide," for public comment as of March 2026. This forthcoming publication will help organizations map CSF 2.0 outcomes to informative references across other frameworks, which is directly relevant to the cross-framework compliance strategy this article describes. Monitor nist.gov for its final release.
DNS filtering plays an active role in incident response through a technique called DNS sinkholing, which redirects queries to known-malicious domains to a controlled server for analysis rather than blocking them outright. This allows security teams to identify infected devices, understand the scope of an infection, and gather intelligence about the attack while limiting ongoing damage. Post-incident, DNS filtering policies can be updated in minutes to block infrastructure associated with the attack, supporting both the Respond and Recover functions of the CSF.
For a brief overview of NIST frameworks and their role in cybersecurity compliance, see our NIST compliance glossary.
The CIS Controls (v8) are a prioritized set of 18 safeguards developed by the Center for Internet Security. Unlike broad risk frameworks, CIS Controls are prescriptive and implementation-focused, making them a popular starting point for organizations building or maturing security programs, particularly those without large dedicated security teams. They are organized into Implementation Groups (IG1, IG2, IG3) that scale with organizational size and risk profile, making them one of the most accessible frameworks for small and mid-size organizations.
Implementation Group 1 (IG1) represents basic cyber hygiene and covers the minimum controls every organization should have regardless of size or industry. IG2 applies to organizations with dedicated IT staff handling sensitive data. IG3 applies to organizations facing sophisticated, targeted threats. DNS filtering appears explicitly in IG1, meaning it is considered a baseline expectation even for organizations just beginning their security program.
Safeguard 9.2 specifically requires the use of DNS filtering services on all enterprise assets. This is one of the most direct and unambiguous mappings in any major compliance framework. CIS explicitly names DNS filtering as a required control, not just as an implied best practice. For IG1 organizations, this means DNS filtering is not optional; it is a documented requirement of the baseline control set. For IG2 and IG3 organizations, the requirement extends to more granular policy enforcement and threat intelligence integration.
Safeguard 13.3 requires deploying a solution to detect and alert on network traffic anomalies. DNS telemetry is a primary data source for this requirement. DNS-based anomaly detection identifies command-and-control communication, DNS tunneling, and domain generation algorithm (DGA) activity that other controls miss entirely. Because DNS is used by nearly every type of malware, monitoring it provides coverage that complements and often exceeds what endpoint-only monitoring can detect.
CIS Control 2 requires maintaining an inventory of authorized software. DNS query logs reveal shadow IT, including services, applications, and cloud platforms that are in active use across the network but have not been formally inventoried or approved. This visibility supports Control 2 requirements and gives IT and security teams an accurate picture of what is actually running in the environment, rather than relying solely on endpoint-reported data.
One of the practical advantages of CIS Controls is the Implementation Group structure. IG1 organizations can deploy DNS filtering with basic category blocking and minimal configuration; the primary requirement is that it is present and active. IG2 organizations should add threat intelligence integration, policy documentation, and alerting on anomalous activity. IG3 organizations should layer in advanced detection capabilities, integrate DNS telemetry with SIEM/SOAR platforms, and implement formal DNS security policies reviewed on a defined cadence.
For more on the CIS Controls framework and where DNS fits within it, see our CIS Controls overview.
What the sections above illustrate is that DNS filtering is not a point solution built for one framework. It is a horizontal control that satisfies requirements across all six simultaneously. The same deployment that generates HIPAA audit logs also satisfies NIST SC-21, supports ISO 27001 A.8.23, provides evidence for SOC 2 CC7.2, meets CMMC SC domain requirements, and fulfills the CIS Controls 9.2 safeguard.
This matters for compliance programs because it means DNS filtering delivers compounding return. Organizations subject to multiple frameworks, such as a healthcare SaaS company that must satisfy both HIPAA and SOC 2 or a defense contractor pursuing both CMMC Level 2 and ISO 27001, get coverage across all of them from a single control.
DNSFilter is a SOC 2 compliant platform that adds a critical layer to your organization's security strategy, protecting against threats at the DNS level, reinforcing NIST-aligned frameworks, and generating the audit-ready evidence that compliance programs require, without adding complexity to your infrastructure.
See how DNSFilter supports your compliance requirements →
Ready to see it in action? Book a demo and we'll show you exactly how DNSFilter maps to your compliance requirements.