GDPR and DNS security requirements intersect more directly than most compliance teams realize. When organizations map out their data protection obligations under the General Data Protection Regulation, DNS infrastructure rarely makes it onto the initial checklist – yet misconfigured DNS records, forgotten subdomains, and dangling CNAME pointers can all create conditions that lead to reportable data breaches.
This article breaks down exactly where GDPR obligations touch DNS security, what specific configurations create compliance risk, and what a realistic remediation approach looks like.
Why DNS Infrastructure Is a GDPR Concern
GDPR Article 32 requires organizations to implement “appropriate technical and organizational measures” to ensure a level of security appropriate to the risk. That language is intentionally broad, but it covers anything that could lead to unauthorized access, accidental disclosure, or loss of availability of personal data.
DNS sits at the foundation of every web application, login portal, API endpoint, and email flow that processes personal data. If an attacker can hijack a subdomain, intercept traffic, or redirect users to a spoofed login page – all of which are possible through DNS misconfigurations – then the organization has failed to implement appropriate technical measures.
The supervisory authorities in Germany, France, and the Netherlands have all referenced DNS-level controls in guidance documents on securing web infrastructure. It is not a theoretical connection.
The Forgotten Subdomain Problem Under GDPR
Here is a scenario that security teams encounter regularly: a company runs a campaign microsite on promo.example.com for three months, then the campaign ends. The hosting account is cancelled, but the CNAME record pointing to a third-party platform is never removed. Six months later, an attacker claims the old hosting account and takes control of that subdomain – serving phishing pages that harvest credentials from users who still trust the parent domain.
Under GDPR, this constitutes a personal data breach if any user data is captured or if the spoofed page tricks users into submitting personal information. The organization is now looking at a 72-hour notification window to their supervisory authority under Article 33, and potential liability under Article 83.
The hidden risks of forgotten subdomains are well documented from a purely technical perspective – but the compliance dimension makes the stakes significantly higher. A stale DNS record is no longer just a sysadmin housekeeping issue; it is a GDPR liability.
Email Authentication and GDPR’s Integrity Requirement
GDPR Article 5(1)(f) requires that personal data be processed in a manner that ensures “appropriate security of the personal data, including protection against unauthorised or unlawful processing.” Email is one of the primary channels through which personal data flows between organizations, processors, and data subjects.
Without proper SPF, DKIM, and DMARC records in place, an attacker can spoof your domain and send fraudulent emails that appear to come from your organization. Those emails may contain or solicit personal data. They may trick recipients into disclosing account credentials. This is a direct failure of the integrity and confidentiality principle.
Preventing email spoofing through correct DNS configuration is therefore not just a deliverability best practice – it is part of fulfilling Article 5(1)(f) obligations. Regulators expect to see these controls in place during audits and incident investigations.
Busting the Myth: “GDPR Is About Data Storage, Not DNS”
A persistent misconception is that GDPR only applies to where and how data is stored – databases, cloud buckets, backups. DNS is “just routing,” so it falls outside the compliance perimeter.
This is incorrect. GDPR applies to the entire processing chain, including the infrastructure that enables access to systems processing personal data. A DNS misconfiguration that allows an attacker to intercept a login session, take over a user-facing subdomain, or redirect email flow is a security failure with direct GDPR implications.
The “appropriate technical measures” standard under Article 32 has been interpreted by data protection authorities to include access controls, encryption in transit, and infrastructure security – all of which DNS directly supports or undermines.
Specific DNS Configurations That Create GDPR Risk
Not every DNS issue carries the same compliance weight. These are the configurations that create the most direct GDPR exposure:
Dangling CNAME records – pointing to deprovisioned third-party services. Enables subdomain takeover. Direct route to phishing and credential harvesting under your domain name.
Missing or broken SPF/DKIM/DMARC – allows domain spoofing in email. Violates the integrity principle and creates liability for any resulting data disclosures.
Unmonitored subdomains processing personal data – login portals, checkout pages, API endpoints that receive personal data but are not part of regular security reviews. If these go down, get hijacked, or start serving unexpected content, you may not know for days.
Stale MX records – pointing to mail servers that are no longer under your control. Incoming email containing personal data may be routed to an unknown destination.
Misconfigured NS delegation – overly broad delegation to third parties without proper contractual controls. Under GDPR, DNS providers that receive queries about personal data processing systems may need to be covered in your data processor agreements.
Building a DNS Security Practice That Satisfies Article 32
Translating this into practical steps:
1. Enumerate your full subdomain inventory. You cannot protect what you cannot see. A complete asset map is the starting point – not just your main domain, but every subdomain that resolves, plus historical records that may have been forgotten.
2. Audit each subdomain for active use and ownership. Any subdomain pointing to a service your organization no longer controls is an immediate risk. Remove or update the DNS record.
3. Verify email authentication records. Confirm SPF, DKIM, and DMARC are in place and correctly configured for every domain used to send mail on behalf of your organization.
4. Implement continuous DNS monitoring. DNS monitoring supports compliance and audit requirements by providing an evidence trail of what changed, when, and whether changes were authorized. This is exactly the kind of documentation that demonstrates Article 32 compliance to a supervisory authority.
5. Define a response procedure for DNS incidents. Know in advance what constitutes a notifiable breach and who is responsible for the 72-hour notification window.
What Auditors Actually Look For
During a GDPR audit or post-breach investigation, data protection authorities and their technical advisors will typically ask:
– What is the organization’s process for identifying and decommissioning subdomains?
– Are email authentication controls documented and tested?
– Is there a change management process for DNS records affecting systems that process personal data?
– Were any DNS changes made in the period preceding the incident?
Organizations that can answer these questions with documented evidence and automated monitoring logs are in a substantially stronger position than those relying on manual records or spreadsheets updated quarterly.
Frequently Asked Questions
Does GDPR explicitly mention DNS security?
No, GDPR does not reference DNS by name. However, the “appropriate technical measures” requirement under Article 32 is broad enough to encompass DNS infrastructure security, and regulators have applied it to cases where DNS misconfigurations contributed to data breaches or unauthorized access.
If a subdomain takeover leads to phishing, who is liable under GDPR?
The organization that owned the domain and failed to maintain control over its DNS records bears primary liability. The attacker’s actions do not transfer responsibility – the failure to implement appropriate security measures to prevent the takeover is the compliance issue.
How often should DNS records be audited for GDPR compliance?
A quarterly manual review is better than nothing, but it is genuinely insufficient for active organizations. DNS changes happen continuously – new subdomains are created, services are deprovisioned, third-party integrations change. Continuous automated monitoring provides the coverage that compliance frameworks expect.
Closing Thoughts
GDPR compliance is not achieved by locking down a database and signing a few processor agreements. The full security perimeter includes the DNS infrastructure that routes users, email, and API traffic to every system processing personal data.
The practical takeaway: treat every unresolved CNAME record, every subdomain without SPF coverage, and every unmonitored API subdomain as a potential Article 32 gap. The remediation steps are not complicated – the bigger challenge is maintaining visibility across an infrastructure that changes constantly. That is where automated, continuous DNS monitoring provides real compliance value.