What Web Filtering Compliance Requirements Actually Mean: CMMC, HIPAA, CIPA & PCI DSS Mapped

CMMC wants boundary protection and network monitoring. HIPAA cares about protecting electronic health data. CIPA calls for a technology protection measure. PCI DSS divides its requirements into network security, malware defense, logging, and intrusion detection. In short, web filtering compliance requirements are scattered.

IT and security teams are left translating four different rulebooks into real-world safeguards, then working out where filtering, DNS controls, and logging support each one. That means hunting down the relevant clauses, interpreting what they require, and then determining whether their current filtering solution delivers both the protection and the proof needed for compliance.

Is DNS filtering required for compliance?

CIPA explicitly requires a technology protection measure that blocks or filters certain content, while CMMC, HIPAA, and PCI DSS describe broader requirements for boundary protection, malware prevention, monitoring, logging, and access control.

Important to note:

DNS filtering helps with compliance, but no product makes you compliant on its own. Real compliance comes down to how you scope, configure, operate, and document your environment.

The quick-reference table below maps how DNS and web filtering align with the main compliance requirements.

Where each compliance framework touches filtering

CMMC: DNS filtering and boundary protection

CMMC Level 2 currently uses the 110 security requirements in NIST SP 800-171 Revision 2. Three of those requirements are especially relevant when evaluating DNS filtering and protective DNS controls.

Which CMMC controls apply?

3.13.1: Monitor, control, and protect communications at external and key internal boundaries

This control requires organizations to protect communications crossing defined system boundaries. DNS filtering can support it by evaluating outbound DNS requests and preventing connections to destinations identified as malicious, suspicious, or prohibited by policy.

Since DNS requests often occur before a user or device connects to an online resource, filtering at this layer can stop a risky connection before a malicious payload is downloaded.

However, DNS filtering is only one component of boundary protection. Firewalls, gateways, network architecture, access restrictions, and other controls may still be needed to satisfy the requirement across the full environment.

3.13.6: Deny network communications by default and allow them by exception

A DNS filtering policy can contribute to a deny-by-default approach when configured in allow-list-only mode, so DNS requests are denied unless the destination is explicitly permitted.

The control applies to network communications more broadly, though. A filtering policy that denies certain DNS resolutions does not prove that every form of network communication is denied by default. Organizations should therefore describe DNS filtering as one enforcing control within a wider permit-by-exception architecture, not as complete evidence for 3.13.6 by itself.

3.14.6: Monitor systems and inbound and outbound communications

DNS query data can help security teams identify attempted connections to phishing infrastructure, malware-hosting domains, command-and-control services, and other suspicious destinations. This provides useful evidence that outbound activity is being monitored and investigated.

What do CMMC assessors look for?

CMMC assessments are evidence-based. Assessors may examine policies, architecture diagrams, configuration settings, filtering rules, system logs, alerts, test results, and records showing that the control operates as described.

For DNS filtering, useful evidence may include:

• The networks, users, devices, and locations covered
• Policies defining blocked and permitted destinations
• Logs showing blocked and allowed DNS requests
• Records of policy changes and administrative activity
• SIEM exports or alerts generated from DNS activity
• Tests demonstrating that prohibited destinations cannot be resolved
• Procedures for reviewing alerts and investigating exceptions

You must demonstrate that the filtering product purchased is deployed within the assessed environment, configured to support the relevant control, and consistently operated.

See how DNS controls map to NIST requirements.

HIPAA: technical safeguards and the proposed Security Rule update

What does 45 CFR 164.312 require?

The HIPAA Security Rule does not explicitly require DNS filtering. Instead, its technical safeguards require regulated organizations to protect electronic protected health information through controls covering access, auditability, integrity, authentication, and secure transmission.

The audit-controls standard requires mechanisms that record and examine activity in information systems containing or using electronic protected health information. DNS query logs can contribute valuable context by showing which destinations a device or user attempted to reach, whether the connection was blocked, and when the activity occurred.

That evidence can help with threat investigations and risk analysis. It does not replace audit logs from clinical applications, identity systems, endpoints, databases, or other systems handling protected information.

DNS filtering can also reduce the likelihood that users or connected medical devices communicate with malicious infrastructure. This is particularly useful for unmanaged and IoT devices that cannot run conventional endpoint agents.

What is changing under the proposed HIPAA Security Rule?

In December 2024, the US Department of Health and Human Services (HHS) proposed a major update to the HIPAA Security Rule. Proposed changes include:

• Removing the distinction between “required” and “addressable” implementation specifications
• Requiring more detailed written policies and documentation
• Requiring technology asset inventories and network maps
• Strengthening requirements for audit reviews and compliance assessments
• Requiring multi-factor authentication in most circumstances
• Requiring anti-malware protection and network segmentation
• Requiring vulnerability scanning and penetration testing

As of September 30, 2026, these changes remain proposed. HHS has not yet issued the final rule or its final compliance date, and the existing HIPAA Security Rule remains in effect. Organizations should prepare for the direction of the proposed changes without presenting them as current legal requirements.

For healthcare teams, the practical message is clear: filtering, malware protection, asset visibility, audit logging, and documented evidence are becoming harder to treat as informal or isolated controls.

Explore DNS-layer protection for healthcare organizations.

CIPA: the framework that explicitly requires filtering

CIPA is different from the other frameworks mentioned because it expressly requires a filtering technology.

Schools and libraries receiving certain E-Rate discounts must implement an internet safety policy that includes a technology protection measure. That measure must block or filter internet access to visual depictions that are obscene, constitute CSAM, or are harmful to minors in the circumstances defined by the law.

For schools, CIPA also requires monitoring of minors’ online activities and education on appropriate online behavior. Before adopting the required policy, the organization must provide reasonable public notice and hold at least one public hearing or meeting.

DNS-based content filtering can help schools and libraries:

• Block prohibited and inappropriate content categories
• Apply different policies to networks, groups, users, or devices
• Protect school-managed devices when students leave the campus
• Record blocked and permitted requests
• Produce reports showing that filtering was active
• Document policy settings and administrative changes

For audit purposes, the organization should be able to produce its internet safety policy, public-hearing records, details of the filtering technology, and evidence that the technology protection measure was operating.

The filtering technology is required, but policy adoption, monitoring, education, documentation, and certification obligations remain the responsibility of the school or library.

Explore DNSFilter’s education filtering capabilities.

PCI DSS: filtering as malware and network protection

PCI DSS v4.0.1 organizes its security expectations across multiple requirements. There is no single “web filtering requirement,” but DNS filtering can support several controls within a cardholder data environment.

Requirement 1: Install and maintain network security controls

Requirement 1 governs the network security controls used to restrict traffic to and from the cardholder data environment.

DNS policies can prevent systems from resolving known malicious or prohibited domains. They can also provide an additional enforcement point for outbound connections. DNS filtering does not replace firewalls, network security control rulesets, or segmentation between the cardholder data environment and other systems.

Requirement 5: Protect systems and networks from malicious software

Requirement 5 requires organizations to protect systems and networks from malware. DNS filtering can stop users or devices from connecting to known malware-hosting, phishing, botnet, or command-and-control domains.

This reduces the opportunity for malicious software to reach the environment, retrieve additional payloads, or communicate with external infrastructure. It remains a preventive layer, not a substitute for anti-malware technology, where PCI DSS requires it.

Requirements 10 and 11.5: logging and intrusion monitoring

Requirement 10 covers logging and monitoring access to system components and cardholder data. DNS logs can add network-level evidence to investigations by showing attempted destinations, timestamps, devices, users, and enforcement actions.

Requirement 11.5 requires intrusion detection or intrusion prevention techniques to monitor traffic at the perimeter and at critical points within the cardholder data environment. An additional requirement, 11.5.1.1, applies to service providers and covers detecting and addressing covert malware communication channels.

DNS tunneling is one technique attackers may use to establish a covert communication channel. DNS telemetry may help identify unusual query volumes, encoded subdomains, unexpected destinations, or other anomalous behavior. However, PCI DSS does not name DNS tunneling in Requirement 11.5, and DNS filtering should not be presented as a replacement for the required IDS/IPS capabilities.

Filtering also does not independently reduce PCI DSS scope. Proper segmentation may reduce scope, but DNS filtering alone does not establish segmentation or remove systems from the cardholder data environment.

Where CIS Controls, ISO 27001, NIST, and SOC 2 fit

CMMC, HIPAA, CIPA, and PCI DSS are not the only compliance frameworks DNS security can enhance.

CIS Controls, a set of 18 prioritized cybersecurity best practices developed by the Center for Internet Security (CIS), includes safeguards relating to web-browser and email protections, network monitoring, access control, and defense against malware. DNS filtering can provide a centrally enforced control for blocking known threats and prohibited destinations.

ISO 27001, a standard published by the International Organization for Standardization (ISO), takes a risk-based approach. Organizations select and operate controls based on their information-security risks, scope, and Statement of Applicability. DNS filtering may support controls relating to network security, logging, monitoring, web access, and malware protection. For a more detailed mapping, read What the ISO 27001 Regulation Means for DNS Security in 2025.

The National Institute of Standards and Technology (NIST) covers a broader family of standards and guidance. Relevant requirements depend on whether the organization is using the Cybersecurity Framework, NIST SP 800-171, NIST SP 800-53, or another publication.

System and Organization Controls (SOC 2) is an assurance framework rather than a prescriptive list of mandatory technologies. DNS filtering can support controls and evidence connected to security monitoring, access restrictions, incident detection, and change management, depending on the organization’s system description and control design.

In every case, the same principle applies: map the filtering control to a defined risk or requirement, document how it works, and retain evidence that it continues to operate.

What to check when evaluating a filtering vendor

Compliance-driven buyers should look beyond whether a vendor lists CMMC, HIPAA, CIPA, or PCI DSS on its website and question whether the platform can provide the control coverage and evidence needed for your environment.

Evaluate whether the product provides:

1. Clear policy granularity: Can you control categories, applications, domains, top-level domains, users, devices, networks, and exceptions?

2. Coverage beyond the office network: Do the same policies protect remote and roaming users, or does coverage disappear when a device leaves the network?

3. Searchable DNS query logs: Can investigators identify the user, device, request, policy decision, and time associated with an event?

4. Export and SIEM integration: Can DNS data be exported into your existing monitoring and evidence-retention workflows? DNSFilter, for example, can send query data to SIEM platforms through HTTP Event Collector or Amazon S3 integrations.

5. Suitable retention and reporting: Does the platform retain enough information for investigations and audits, or allow your organization to retain it in another approved system?

6. An administrative audit trail: Can you show who changed a policy, what changed, when it changed, and whether an exception was approved?

7. Reliable deployment against your deadline: Can the platform be deployed across the in-scope environment without adding a long infrastructure project?

8. Evidence that can be tested: Can your team demonstrate that prohibited destinations are blocked, logs are generated, exports are functioning, and policies apply to the intended users and devices?

DNSFilter provides AI-powered content and threat filtering at the DNS layer, with granular policies, deployment options for networks and roaming devices, searchable reporting, and data export for wider security workflows. We help organizations enforce defined policies and produce useful audit evidence without replacing the wider technical and administrative safeguards each framework requires.

Turn compliance requirements into practical controls

See how MSPs and IT teams can translate changing security and compliance demands into an actionable program.

FAQs

Is DNS filtering required for HIPAA compliance?

No. HIPAA does not explicitly require DNS filtering, but it can support HIPAA risk management by blocking malicious destinations and providing network-level activity logs. It does not replace the access controls, audit controls, authentication, integrity protections, transmission safeguards, or wider risk-management processes required under the HIPAA Security Rule.

Does CIPA require web filtering or just a policy?

CIPA requires both an internet safety policy and a technology protection measure that blocks or filters specified visual material. Schools must also monitor minors’ online activities, educate students about appropriate online behavior, and complete the relevant public-notice and certification processes.

What PCI DSS requirement covers malware and malicious domains?

PCI DSS Requirement 5 covers protection against malware, while Requirements 1, 10, and 11.5 address network controls, logging, and intrusion monitoring.

The standard does not specifically require DNS filtering. DNS filtering can supplement these controls by blocking known malicious destinations and providing DNS telemetry for monitoring and investigations.

Is DNS filtering a NIST or CMMC requirement?

DNS filtering is not explicitly named as a mandatory technology in the relevant CMMC requirements.

It can support NIST SP 800-171 requirements for boundary protection and system monitoring, particularly 3.13.1 and 3.14.6. It may also contribute to a deny-by-default architecture under 3.13.6, but it does not, by itself, satisfy that broader network requirement.