DNS Filtering for HIPAA Compliance
How DNS filtering supports HIPAA, maps to the Security Rule, what to require from a provider, and the log risk to watch for.
The Health Insurance Portability and Accountability Act (HIPAA) never names DNS filtering specifically.
The Security Rule is risk-based, so it sets goals and lets you pick the security measures that meet them.
But DNS filtering is one of those measures. It supports several HIPAA requirements, so it is a safeguard you can stand up fast and document clearly.
If your framework or your auditor keeps pointing at web controls, this guide shows where DNS filtering operates and fits, what it does and does not do for HIPAA, and what to look for in a provider.
TL;DR
- HIPAA is risk-based, so DNS filtering counts as a supporting safeguard and does not by itself make you compliant.
- It supports real technical safeguards, including access control, audit controls, transmission security, and stopping incidents early.
- Your DNS query logs can hold personal health information, so how you log matters as much as whether you log.
- A HIPAA-ready DNS filtering service needs a signed business associate agreement, encrypted queries, DNSSEC, access control, and control over where logs live.
- The proposed 2025 Security Rule update would make encryption and MFA mandatory, though it is not final yet.
Is DNS Filtering Required for HIPAA Compliance
Short answer: no. HIPAA does not require any specific product, and no DNS filtering service is "HIPAA certified." What it does do is help satisfy several Security Rule requirements, which is why it earns a place in your program.
The Security Rule applies to covered entities (hospitals, clinics, and health insurance companies) and to the business associates that handle their data. It is risk-based, so you assess your own risks and apply reasonable safeguards rather than working from a fixed product list.
DNS filtering fits because most attacks start with a single DNS query. For example:
- A user clicks a link to one of many phishing websites.
- Their device asks the domain name system to look up that domain.
- DNS filtering checks the domain against known potential threats and can block access to malicious domains before any connection happens.
That is a preventive control you can show an auditor. If you want the full guide on what DNS filtering is and how it works, start there. The rest of this guide stays on HIPAA.
How DNS Filtering Supports HIPAA Technical Safeguards
DNS filtering supports these parts of the Security Rule. It helps meet them, but it does not meet the Rule alone.
| Security Rule requirement | What DNS filtering does |
|---|---|
| Risk analysis and activity review (§164.308(a)(1)) | Logs give you a record of internet access to review for anomalies |
| Access control (§164.312(a)) | Policies decide which domains each user or device can reach |
| Audit controls (§164.312(b)) | Query logging creates the activity trail auditors ask for |
| Integrity (§164.312(c)) | DNSSEC validation confirms responses were not tampered with |
| Authentication (§164.312(d)) | SSO and enforced MFA control who can change policy |
| Transmission security (§164.312(e)) | Encrypted DNS keeps queries private on the wire |
| Incident procedures (§164.308(a)(6)) | Blocking phishing sites and malware domains stops incidents early |
Four of these carry most of the weight.
1. Audit controls
DNS sits in front of nearly all internet access, so its logs are a clean activity record. Control D keeps raw query logs for up to 1 month and can stream them to your SIEM.
For what to capture and how long to keep it, see DNS logging best practices.
2. Transmission security & Integrity
Encrypted DNS stops queries being read in transit, and DNSSEC validation blocks spoofed answers that would send users to fake IP addresses.
Control D validates DNSSEC by default and supports DoH, DoH3, DoT, and DoQ. You can disable DNSSEC per Profile if a domain is misconfigured. Legacy UDP on port 53 works too, but it is not encrypted.
3. Incident prevention
Most attacks begin with a lookup to a malicious domain, so blocking it at the resolver, or redirecting users to a safe block page, stops phishing attacks before they land.
DNS security also works outbound: the same chokepoint blocks queries to exfiltration and command-and-control domains, cutting off a common route for data leakage before ePHI leaves the network.
4. Access control
Not every user or device needs to reach the whole internet. DNS filtering lets you set policies per user or group, so a front-desk machine, a clinical workstation, and an admin laptop can each resolve a different set of domains.
That maps to the access control safeguard by limiting what each role can reach at the network layer, and it pairs with the SSO and enforced MFA that govern who can change those policies in the first place.
The remaining rows lean on these same two capabilities:
- Risk analysis and activity review draw on the same query logs as audit controls
- Authentication here means controlling admin access to the filtering console rather than logging users into your ePHI systems, so it is a partial contribution rather than a full answer.
Can DNS Query Logs Contain Personal Health Information
Yes, they can. On its own, no single field in a DNS log is medical information since there is no diagnosis or treatment record in there. But combined, the fields can tie an identifiable person to their use of a health service, and where that happens, the log can fall within HIPAA's scope.
Whether a given log crosses that line depends on the circumstances, so the safe move is to treat DNS logs as potentially sensitive and handle them accordingly.
A single DNS query log can hold:
- The domain or hostname requested
- The device or endpoint name
- A timestamp
- Source and destination IP addresses
Here is what that can look like: a personal phone on the staff Wi-Fi resolving a named addiction-recovery service at 9:14 on a Tuesday. No diagnosis appears anywhere, yet the record links an identifiable person to their care.
So treat DNS logs as sensitive information you have to protect, and make it part of your data protection plan.
Apply the minimum necessary rule (§164.502(b)) to what you log and how long you keep it, choose a data storage region that meets your data residency requirements, and put any provider that receives it under a business associate agreement.
Here is how that works with Control D:
- Query logging runs only when Full Analytics is on, and you can switch it off completely.
- Raw logs are deleted after 1 month. Only aggregated analytics, without raw queries, are kept for up to a year.
- You pick the storage region (US, EU, or AU), and logs never leave it.
- Logs are encrypted at rest.
One honest limit: Control D retention for raw logs can be set to 1, 3, or 7 days, or 1 month, but not longer, and there is no field-level redaction. You minimize data by turning off Full Analytics, not by editing single fields.
What to Look for in a HIPAA-Compliant DNS Filtering Service
Take this checklist into any vendor conversation. No DNS filtering service is "HIPAA certified," so check the safeguards, confirm the BAA scope, and configure it correctly on your side.
- A signed business associate agreement covering the DNS services you use. Without it, no data that could touch ePHI should reach the provider.
- Control over log content, retention, and location, so you can meet minimum necessary and keep data in-region.
- Encrypted DNS (DoH, DoT, or DoQ) so queries stay private.
- DNSSEC validation to block spoofed responses.
- Access control: SSO, MFA you can enforce, and roles that limit who can change policy.
- Independent proof such as SOC 2 Type II and ISO 27001 for your vendor review.
- Encryption of stored logs.
Here is how Control D measures up, as an example:
- BAA: yes. Control D signs one for organization accounts.
- Encryption and DNSSEC: DoH, DoH3, DoT, and DoQ, with DNSSEC on by default.
- Logs: you choose the region, logs stay there, raw logs are kept for up to 1 month, and everything is encrypted at rest. More on the DNS logging page.
- Access: SSO over OIDC with Okta and Entra ID, admin-enforced MFA, and Owner, Admin, and Viewer roles. All of it is on every organization account, with no tier gating.
- Attestations: SOC 2 Type II and ISO 27001 & ISO 27701. Find more info in the Security & Trust Center.
How to Deploy DNS Filtering in a Healthcare Network
Deployment comes down to two steps:
- Filter at the network level. Point your network's resolver at the DNS filtering service. Every device that connects is covered right away, with nothing to install.
- Add a roaming client. Put a lightweight client on devices that leave the network, so laptops and phones keep the same protection off-site.
That covers most of a normal office. Healthcare is harder in three specific ways worth planning for.
- Old medical devices. Imaging machines and infusion pumps often cannot run software agents. Luckily, they do not need one, because DNS filtering can operate at the network resolver so they're covered the moment they connect.
- Guest and patient Wi-Fi. Open networks are an easy way in for malware. A separate network and web filtering policy can handle that traffic. Because DNS filtering runs at the network resolver, every device on the guest Wi-Fi is covered automatically. It also restricts access to malicious sites without impacting the network your clinical and staff devices rely on.
- Browser DoH bypass. Browsers can activate their own encrypted DNS (DoH), letting them bypass your designated resolver and undermining DNS-based filtering. This issue affects all DNS filtering solutions, so it's best addressed by enforcing managed browser policies that disable DoH and by blocking known public DoH resolver domains on your network.
Control D runs on exactly this model, so one deployment covers the first two cleanly: agentless network filtering for the devices you cannot install on, native clients across Mac, Windows, Linux, iOS, and Android for anything that roams, and per-profile filtering to keep guest traffic off the clinical network.
DoH is the exception: Control D can block public DoH resolvers at the DNS layer, but the only reliable fix is a managed browser policy that disables DoH.
What the Proposed 2025 HIPAA Security Rule Update Changes
In January 2025, HHS proposed an update to the Security Rule. As of mid-2026 it is still a proposal, not law, with final action now estimated for July 2027 at the earliest. Until then, the current rule applies.
If it passes as written, several safeguards that are optional today would become mandatory:
- Encryption of ePHI in transit and at rest
- Multi-factor authentication
- Network segmentation
- Regular security testing
- Annual business associate certification
If you already run DNS filtering, you are part of the way there. Encrypted DNS and admin MFA line up with two of those requirements, and Control D supports both today. The rest sit at the program level and are handled alongside your other controls.
Final Thoughts
DNS filtering will not make you HIPAA compliant on its own, and it was never meant to. What it does is support specific Security Rule requirements, from access control and audit logging to transmission security, while closing off one of the most common ways attacks begin. That makes it one of the easier safeguards to stand up and to prove to an auditor.
Two things decide whether it helps or complicates your compliance: how you handle the logs, and whether your provider will sign a BAA. Get those right, and DNS filtering earns its place in your wider HIPAA program.
If you want to see how this fits your own setup, try Control D for free (no credit card required).
Frequently Asked Questions (FAQs)
Is DNS filtering required for HIPAA?
No. HIPAA names no specific technology. DNS filtering is a recognized safeguard that supports several Security Rule requirements, but it does not make you compliant on its own.
Does Control D sign a business associate agreement?
Yes, for organization accounts. Start on the compliance page.
Can DNS query logs contain PHI?
Yes. Hostnames, device names, and IP addresses can link a person to a health service. Apply minimum necessary, keep logs in a region you control, and put the provider under a BAA.
Is any DNS filtering service "HIPAA certified"?
No. There is no government HIPAA certification for products. What matters is the safeguards a provider supports, the BAA, and your own setup.
Does DNS filtering replace a firewall?
No. It is one layer that stops threats before a connection is made. It works alongside your firewall and endpoint tools.
