How DNS Filtering Supports SOC 2 Compliance
See which SOC 2 compliance criteria DNS filtering supports, and the exact evidence to hand to your auditor for each.
You are going through SOC 2, you already use DNS filtering or you are thinking about it, and you want to know if it counts in the audit.
Short answer: yes.
DNS filtering supports several SOC 2 requirements, primarily in the areas of security and monitoring. It helps, but it won't make you compliant on its own.
SOC 2, short for System and Organization Controls, is a compliance framework developed by the AICPA to check how well a company protects customer data.
This guide shows which parts of SOC 2 DNS filtering supports, and the exact evidence you hand to your auditor for each one.
Which SOC 2 Criteria DNS Filtering Supports
SOC 2 is built on five Trust Services Criteria:
- Security
- Availability
- Processing Integrity
- Confidentiality
- Privacy
Every SOC 2 report covers Security. The other four are added only if they apply to you. DNS filtering lines up most closely with the security controls under the Security criterion.
| Criterion | What it asks for | How DNS filtering helps | Evidence you produce |
|---|---|---|---|
| CC6.1 | Access controls that limit what systems and users can reach | Enforces which destinations resolve and which are blocked at the resolver | Policy configuration export and block logs |
| CC6.6 | Protection against threats from outside the system boundary | Blocks malicious domains, phishing, command-and-control, and DNS tunneling before a connection is made | Threat-block logs and category policy configuration |
| CC7.1 | Detection of configuration problems and drift from a baseline | Keeps a filtering-policy baseline and a change trail on rules | Policy change history or configuration audit log |
| CC7.2 | Monitoring for anomalies and security events | Records DNS queries as a running view of internet activity | Query-log samples exported to your SIEM, kept across the audit window |
| CC7.3 and CC7.4 | Evaluating and responding to events | Feeds DNS detections into your incident response process | Records of reviewed DNS alerts with the action taken |
If Availability is in your scope, DNS filtering helps a little there too. Blocking malicious traffic cuts the incidents that threaten uptime and informs disaster recovery planning. The core mapping still sits under Security.
Three of these rows do the heavy lifting:
Monitoring (CC7.2)
This is the one auditors flag most. They want proof you watch activity across your environment, and DNS traffic is a big part of it. Query logs give you a running record of what was reached, when, and from which device.
Without them, you have a gap you cannot backfill.
Boundary protection (CC6.6)
Blocking malicious domains, phishing, and command-and-control traffic at the DNS level stops threats before a connection opens. The block logs prove the control is live and catching real traffic, which is more convincing than a policy document on its own.
It also cuts the risk of data breaches, which often start with a single bad click and can expose sensitive information.
Response (CC7.3 and CC7.4)
Detecting something is only half the job. Auditors want to see that a detection went somewhere: someone reviewed it, decided what it was, and logged what they did. Thousands of blocked events with no sign of review tells the wrong story.
Having the Control Is Not the Same As Proving It
Here is where teams slip up. Once DNS filtering is running, it is easy to assume the evidence takes care of itself. It does not.
An auditor will not accept a running tool as proof. They are checking the operational integrity of the control: that it is set up correctly and actually runs day-to-day. They want to see two things:
- The control is designed: A configuration export shows what your policy blocks, what it allows, and how it is set up.
- The control operates: A documented review shows someone checked the policy and logs, confirmed it still works, and signed off with their name, the specific date, and what they found.
You need both. A config export with no review looks like a control nobody watches. A review with no export has nothing behind it.
Two more things people miss:
- Retention: A SOC 2 Type II report covers a set observation window, so your logs have to cover that whole window with room to spare. A short rolling history means you can reach audit time with a working control and no way to prove it worked months ago. Set retention against the window and confirm the exact period with your auditor.
- Review cadence: Auditors want a steady rhythm, not a scramble the week before fieldwork. Quarterly is common. Record who reviewed, when, and what they found, even if nothing changed.
This is what separates a control's design from its operational effectiveness, and it is why SOC 2 Type II is an ongoing commitment rather than a one-time check. Treating your DNS reviews as regular management processes keeps your internal controls audit-ready.
What DNS Filtering Does Not Cover
DNS filtering is a supporting control, not a full compliance program. It closes a specific gap and leaves plenty for other tools. It does not handle:
- Access management
- Endpoint protection and intrusion detection systems
- Change management
- Your wider logging and SIEM setup
Treat it as one layer that produces clean evidence for its slice of the work.
It also has a real technical limit. DNS filtering works at the point where a domain is resolved, so anything that skips your resolver skips the filter. A device using encrypted DNS pointed at another resolver, or an app connecting straight to an IP address, can get past it.
That is why auditors look for layered security controls instead of a single line of defense, and why endpoint tools still matter alongside DNS filtering.
Calling it one layer among several is more accurate and easier to defend in an audit than claiming it protects all your sensitive data on its own.
What To Look For In a DNS Filtering Tool For SOC 2
The tool you pick decides whether the evidence comes out clean or whether you rebuild it by hand at audit time. Look for:
- Retention that covers your audit window: Logs only count as evidence if they still exist when the auditor asks. Some tools keep a short history, and some put longer retention or log export behind a higher tier, so check it is included on your plan.
- Clean export: SIEM streaming or API access, so logs and config can leave the dashboard and land in your evidence store without manual work.
- An admin action trail: A record of your policy baseline and any changes to it over time.
- Coverage on every device: Distributed teams create blind spots when a tool covers only some platforms, or drops off once a laptop leaves the office. Full coverage keeps your evidence complete and your client data protected wherever people work.
Good data management here means the logs that prove your controls are easy to find, export, and keep for as long as the audit needs. Those are the criteria worth checking in any DNS tool.
Here is how Control D measures up:
- Control D retains up to 1 month of raw query logs and 1 year of analytics for every plan, so your monitoring record covers a standard audit window without a paid add-on
- SIEM streaming and full API access are included on every plan, so logs and config can flow into your SIEM or wherever you store audit evidence without manual collection
- Control D's Admin Logs feature records every configuration change, policy update, and permission change, along with which user made it, so you can show your policy baseline and its full change history without piecing it together after the fact
- Control D runs on macOS, Windows, Linux, all major browsers, iOS, and Android, so no device slips through, and your DNS evidence stays complete across the team
- Control D is also SOC 2 Type II compliant and holds ISO 27001 and ISO 27701 certification
Final Thoughts
DNS filtering earns its place in a SOC 2 audit when you treat it as a source of evidence. Running the tool is the easy part. The value is in the logs and reviews that prove the control actually works, and in being clear about the gaps it leaves for other controls to cover.
Get retention, export, and change history right from the start, and most of that evidence produces itself by the time the auditor asks. Start a free trial or see plans and pricing.
Frequently Asked Questions (FAQs)
Does SOC 2 require DNS filtering specifically?
No. SOC 2 sets outcomes, not tools, and it never names a product. DNS filtering is one practical way to meet the monitoring and boundary-protection criteria, but the auditor only cares that the outcome is met. You can reach it however works for your setup.
How long should DNS logs be retained for a SOC 2 audit?
Long enough to cover your full Type II observation window, with a buffer, so your logs span that period and are still available when the auditor asks. Confirm the exact window with your auditor, since it depends on your scope.
Can encrypted DNS get past filtering?
It can. A device using encrypted DNS pointed at another resolver, or an app connecting straight to an IP, can skip a resolver-level filter. This is why layered data security matters. Pair DNS filtering with endpoint tools so a bypass does not leave a hole in your evidence.
Is a DNS provider's own SOC 2 report enough for my audit?
No. Their report covers their controls, not yours. It helps with vendor due diligence, but it does not replace the evidence your own audit needs. You still produce your own config exports, logs, and review records for the DNS controls you run.
Does SOC 2 cover data protection laws like HIPAA or GDPR?
Not directly. SOC 2 is a voluntary compliance framework, separate from data protection laws and other regulatory compliance regimes. Strong SOC 2 controls often support them, though. If you handle protected health information or other sensitive data, DNS filtering and logging can feed that evidence too.
