Forgotten subdomains: the regulatory and breach exposure your DNS records are already creating
Sienna VanceApril 29, 2026
Key takeaways
A subdomain takeover does not require a breach of your own systems to trigger GDPR Article 33 notification obligations. If an attacker hijacks a subdomain on your domain and uses it to collect personal data through phishing, that is a personal data breach under the regulation -- and the 72-hour notification clock starts.
In Vulnox assessments, forgotten subdomains remain exposed for an average of 14 months before detection. The exposure period is not a technical failure. It is a process failure: no one owns DNS record decommissioning as a defined responsibility.
Certificate transparency logs are append-only and public. Every SSL certificate ever issued for your domain, including subdomains from campaigns that ended three years ago, is permanently recorded and queryable by anyone in under 60 seconds.
Large enterprises are disproportionately exposed because subdomain creation is decentralized -- marketing, DevOps, product, and vendors all create DNS records -- while DNS cleanup has no equivalent ownership structure.
Vendor security questionnaires increasingly ask about external attack surface management practices. An organization that cannot demonstrate DNS record lifecycle controls is giving a credible answer to a question its clients are asking.
TL;DR
Forgotten subdomains are not just a security gap. They are a documented regulatory exposure. A dangling DNS record pointing at a cloud resource you no longer control can be claimed by an attacker in minutes, turned into a phishing page under your domain, and used to collect personal data from your customers. Under GDPR, Thailand PDPA, and most equivalent frameworks, that is a breach you are responsible for notifying -- regardless of whether your own systems were ever touched.
The subdomain that was not in scope
A mid-size SaaS company in the EU received an inquiry from a customer who had received a phishing email appearing to come from a legitimate-looking subdomain of the SaaS company's domain. The email collected login credentials. The subdomain was one that had been used for a partner integration two years earlier. The integration ended, the integration platform contract was cancelled, and the CNAME record pointing to it was never removed. An attacker registered a new account with the integration platform, claimed the cloud resource the CNAME pointed to, and had a functional phishing page under the SaaS company's own domain within hours. The SaaS company's internal systems were never touched. Their penetration test from six months earlier had not covered this subdomain. It was not in the asset register.
The question their DPO faced was not whether a breach had occurred. Under GDPR Article 4(12), unauthorized disclosure of personal data by any means is a personal data breach. The question was whether the organization had taken reasonable technical and organizational measures to prevent it -- and whether the failure to monitor DNS records for dangling entries constituted a gap in those measures. The supervisory authority's answer to that question carries real weight.
How subdomain takeovers work and why they are a regulatory problem, not just a technical one
The technical mechanism is straightforward. An organization creates a DNS CNAME record pointing a subdomain at a cloud service -- an S3 bucket, a GitHub Pages deployment, a Heroku app, an Azure storage endpoint. The project ends. The cloud resource gets decommissioned or the account lapses. The DNS record stays. The CNAME now points at a resource name that no one owns.
Cloud providers assign resource names on a first-come basis. An attacker monitoring certificate transparency logs and subdomain enumeration outputs identifies the dangling record, registers a new account with the same provider, claims the resource name the CNAME points to, and the subdomain now serves attacker-controlled content. This takes minutes once the dangling record is identified. The attacker does not need credentials, network access, or any contact with the organization's infrastructure.
The regulatory dimension is where most organizations underestimate the exposure. Data protection frameworks define a personal data breach as any breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data. A phishing page hosted on your subdomain that collects credentials or personal information from your customers fits that definition. The fact that the data was collected on infrastructure you did not know you had handed to an attacker is not a defense. It is the problem.
Example
Under GDPR Article 33, a personal data breach must be notified to the supervisory authority within 72 hours of the controller becoming aware of it, unless it is unlikely to result in a risk to the rights and freedoms of individuals. A phishing page collecting credentials from your customers, served under your domain, is not a low-risk event. The 72-hour clock starts when you become aware. Organizations that discover a subdomain takeover weeks after it occurred face a situation where the clock may have started running when the first customer reported the phishing email, not when the security team confirmed the mechanism.
CNAME records pointing to cloud services are the primary vector, but not the only one. NS record delegation to defunct DNS providers creates equivalent exposure. If an organization delegated DNS for a subdomain to a third-party provider whose account was later cancelled, an attacker can register with the same provider and claim the DNS zone. The subdomain then resolves to whatever records the attacker creates. This variant is less commonly checked because most subdomain takeover tooling focuses on CNAME records.
What subdomain assessments find across real environments
Assessment base: Vulnox digital footprint assessments, 2023-2024, cross-sector
Average exposure window before detection: 14 months
Across Vulnox digital footprint assessments, forgotten subdomains vulnerable to takeover had been in that state for an average of 14 months before the assessment identified them. In no case had the organization's internal monitoring flagged the dangling record. The exposure period is consistent across organization sizes. The variable is not size -- it is whether DNS record lifecycle is a defined process with an owner.
Fourteen months is a long time under GDPR's accountability principle. Article 5(2) requires controllers to demonstrate compliance. An organization that cannot show it has a process for DNS record decommissioning, and whose assessment reveals a 14-month-old dangling CNAME, is not well-positioned to demonstrate that its technical and organizational measures were appropriate.
Large organizations have disproportionately more vulnerable subdomains, not fewer
Organizations with more than 5,000 employees were three times more likely to have five or more vulnerable forgotten subdomains than smaller organizations, based on Vulnox assessment data. The reason is structural: large organizations have more teams with the ability to create DNS records -- marketing, DevOps, product, regional offices, vendor integrations -- and no equivalent distribution of responsibility for decommissioning. DNS creation is self-service. DNS cleanup is no one's job.
This pattern appears consistently enough that it is worth naming as a governance finding, not just a technical one. An organization with 50 people has one team managing infrastructure. An organization with 5,000 people has dozens of teams creating it. Without a cross-functional DNS lifecycle policy, the attack surface grows proportionally to headcount.
Registrar monitoring does not cover takeover risk
Most organizations believe their domain registrar provides sufficient monitoring for subdomain security. Registrars monitor uptime, DNS resolution, and renewal. They do not monitor whether CNAME targets are still owned by the registrant, whether NS delegation zones are still controlled by the organization, or whether the resources pointed to by DNS records have lapsed. These are application-layer and account-level questions that registrars have no visibility into.
The gap between what organizations believe registrar monitoring covers and what it actually covers is where takeover vulnerability lives. This is not a criticism of registrars -- it is not their function. It is a documentation gap in how organizations communicate their monitoring architecture to compliance auditors and clients.
The compliance finding that surprises legal teams: you can be liable for a breach on infrastructure you forgot you had
Common belief
Most DPOs and legal teams operate on the assumption that breach notification obligations attach to incidents involving systems the organization controls and operates. If the organization's servers were not compromised, the argument goes, there is no breach to notify.
What we found
In post-assessment conversations with legal and compliance teams, the most common response to the regulatory dimension of subdomain takeover risk is that they had never considered DNS records to be within the scope of their data protection impact assessments or their technical and organizational measures documentation. The gap is not deliberate -- it is a category error. DNS infrastructure is managed by IT. Data protection measures are documented by compliance. The two teams rarely review the same asset inventory.
GDPR's definition of a personal data breach does not require that the organization's own systems be directly compromised. It requires that personal data was exposed through a breach of security. If an attacker uses a subdomain on your domain -- a subdomain that exists because you created a DNS record and did not remove it -- to collect personal data from people who believed they were interacting with you, the question of whether your servers were touched is secondary to the question of whether personal data was exposed through a failure of your security measures.
The specific failure -- not removing a DNS record after decommissioning the underlying resource -- is a technical and organizational measure that the accountability principle requires you to have implemented. If you did not implement it, and the gap was exploited, the supervisory authority's analysis does not begin with your server logs. It begins with your DNS record management policy.
This interpretation is not settled law across all EU member states. There is genuine legal debate about the outer bounds of controller liability for subdomain takeover scenarios. But the regulatory exposure is real enough that organizations should not assume the answer runs in their favor.
The subdomain exposure categories most DNS audits miss
NS record delegation to decommissioned DNS providers
Organizations sometimes delegate DNS for a subdomain to a third-party DNS provider for a specific project -- a managed campaign microsite, a partner portal, a regional deployment. When the project ends and the provider account lapses, the NS delegation record remains. An attacker who registers with the same provider and claims the zone can create arbitrary DNS records for the subdomain, including MX records enabling email spoofing and A records for phishing pages. Standard subdomain takeover tooling checks CNAME targets; it does not always check NS delegation validity.
Acquired organization subdomains never migrated
Post-acquisition DNS integration is rarely complete. The acquired organization's domain may be redirected at the top level, but individual subdomains -- particularly those used for legacy customer portals, partner integrations, or internal tools -- often remain pointing at the acquired organization's original infrastructure. When that infrastructure is eventually decommissioned as part of IT consolidation, the DNS records are left behind. No one in the acquiring organization has a clear view of the acquired DNS landscape.
Vendor-created subdomains in scoped deployments
Vendors deploying software-as-a-service integrations, content delivery configurations, or marketing platforms frequently create DNS records in the client's zone as part of their onboarding process. When the vendor relationship ends, the vendor deprovisions their infrastructure but has no ability to remove DNS records in the client's zone -- that requires the client to act. The client, having cancelled the vendor contract, does not necessarily have a workflow that connects 'cancel vendor contract' to 'audit DNS records for this vendor's integration.'
Historical subdomains visible only in certificate transparency logs
Certificate transparency logs record every SSL certificate ever issued for a domain. They are append-only, public, and permanent. Subdomains that were used briefly, never added to any internal asset register, and long since removed from DNS still appear in certificate transparency history. An attacker querying crt.sh for an organization's domain gets a historical inventory of every subdomain that ever had HTTPS enabled -- including ones the organization has no record of and may still have dangling DNS records for.
How an external assessment maps forgotten subdomain exposure
- Step 1
Certificate transparency log review
Output:Complete historical subdomain list including subdomains removed from DNS, sorted by certificate issuance date to identify which were most recently active.
Purpose:Retrieve the full historical subdomain list from crt.sh and equivalent CT log aggregators. This is the starting point because it is comprehensive, passive, and returns subdomains that no longer exist in DNS but may still have infrastructure running.
- Step 2
DNS resolution against historical subdomain list
Output:Three-way categorization: actively resolving, NXDOMAIN, and resolving-but-target-unverified -- the last category being the primary area of interest for takeover risk.
Purpose:Resolve every subdomain from the CT log against current DNS to identify which still have active records, which return NXDOMAIN, and which resolve but to a resource that may not be owned by the organization.
- Step 3
CNAME and NS target validation
Output:List of dangling records: CNAME targets that are unclaimed or claimable, NS delegations to zones not controlled by the organization.
Purpose:For every subdomain with a CNAME or NS record, verify that the target resource is currently registered to and controlled by the organization. Cloud provider resources, third-party DNS zones, and hosting platform accounts all have mechanisms for this verification.
- Step 4
Active service fingerprinting on resolving subdomains
Output:List of undocumented but actively serving subdomains, categorized by service type and authentication requirement.
Purpose:For subdomains that resolve and return HTTP responses, determine what the service is, whether it requires authentication, and whether it is documented in the organization's asset register.
- Step 5
Cross-reference against internal asset register
Output:Delta report: subdomains present in external enumeration not present in internal documentation, and vice versa.
Purpose:Compare the full subdomain inventory against whatever internal asset documentation the organization maintains. The gap between the two lists is the primary finding.
Where forgotten subdomain risk is heading from a regulatory standpoint
Within three years, at least one publicly reported GDPR enforcement action will cite failure to manage DNS record lifecycle as a specific gap in technical and organizational measures, following a subdomain takeover that resulted in personal data exposure. This finding does not yet have a named precedent. The structural conditions for it are present in the majority of mid-to-large organizations assessed.
Supervisory authorities are increasing technical sophistication in their enforcement investigations. External attack surface analysis is now a standard component of post-breach regulatory inquiry in several EU member states. The connection between dangling DNS records, subdomain takeover, and personal data breach is technically straightforward once an investigator runs enumeration against the organization's domain. The only missing element is a case where this chain is the primary cited failure. That case is structurally likely.
Confidence: mediumIf, by 2028, no GDPR enforcement action publicly cites DNS record lifecycle management as a gap in technical and organizational measures, this prediction is wrong.Vendor security questionnaires from enterprise buyers will include specific questions about DNS record decommissioning processes within two years. Currently, vendor questionnaires ask about asset inventory and attack surface management in general terms. The specificity of the subdomain takeover risk is becoming well enough understood that procurement teams will add targeted questions.
Enterprise procurement security reviews have progressively added more specific technical questions as understanding of attack surface management has matured. The same progression happened with questions about cloud storage configuration, third-party JavaScript, and API security. DNS record lifecycle is at the same stage of awareness now that those topics were three to four years ago.
Confidence: highIf major enterprise vendor questionnaire frameworks (CAIQ, SIG, VSQ) do not include DNS record decommissioning as a specific control question by 2027, this prediction is wrong.
Why this belongs in data protection documentation, not just the security team's remit
DNS record lifecycle management is treated as an IT operations task in most organizations. It sits in runbooks, not in data protection impact assessments. The compliance team documents technical and organizational measures for their GDPR records of processing activity without knowing that a decommissioned marketing subdomain from 18 months ago is one unclaimed S3 bucket name away from becoming a personal data breach.
This is a governance gap, not a knowledge gap. Security engineers understand subdomain takeover. DPOs understand breach notification. Neither team is systematically reviewing the overlap. The result is that an organization can have a mature GDPR compliance program and simultaneously have no process that connects infrastructure decommissioning to data protection obligations.
I think DNS record lifecycle should appear explicitly in technical and organizational measures documentation, reviewed annually alongside the records of processing activity. Not as a lengthy control framework -- as a single process requirement: when infrastructure is decommissioned, DNS records pointing to it are removed within a defined window, and that removal is documented. The documentation serves both the security function and the accountability principle.
Counterargument
The counterargument is that DNS record management is too technical to belong in data protection documentation, and that forcing compliance teams to own infrastructure lifecycle decisions creates process overhead without proportionate risk reduction. That is a reasonable position for organizations with mature, well-integrated security and compliance functions where the gap is already covered. Most organizations do not have that integration. For them, putting DNS record lifecycle in neither function's documentation means it is in no one's documentation.
One thing to do this week
Query crt.sh for your organization's primary domain. The URL format is https://crt.sh/?q=%.yourdomain.com. Review the results and identify every subdomain that appears in the certificate history. Cross-reference against your current DNS zone. Any subdomain in the CT log that is not in your DNS records -- or that is in DNS but points to a cloud resource you cannot immediately verify you still control -- is a potential takeover target. Take that list to whoever owns your DNS zone and confirm that each entry either has a current owner who can verify the resource is still under organizational control, or has a removal ticket open. That process takes a few hours. The regulatory exposure of not doing it is open-ended.
Further Reading
Digital Footprint
digital footprint analysisVulnerability Assessment
vulnerability assessment servicesExternal Attack Surface Management Recorded Future
external attack surface managementSubdomains Enumeration The Hacker Recipes
subdomain enumeration techniquesNIST Vulnerability Assessment Definition
NIST vulnerability assessment definition
Frequently Asked Questions
Can a subdomain takeover trigger GDPR breach notification obligations?
Yes. GDPR defines a personal data breach as any breach of security leading to unauthorized disclosure of or access to personal data. If an attacker claims a forgotten subdomain on your domain and uses it to collect personal data through phishing, that meets the definition -- even if your own systems were never directly compromised. The failure to remove a dangling DNS record after decommissioning the underlying resource is a gap in technical and organizational measures that Article 5(2) requires you to demonstrate you had in place.
How long do forgotten subdomains typically remain exposed before detection?
In Vulnox digital footprint assessments, forgotten subdomains vulnerable to takeover had been in that state for an average of 14 months before detection. In no assessed case had internal monitoring flagged the dangling record. The exposure window is consistent across organization sizes. The determining factor is whether DNS record decommissioning is a defined process with an owner -- not the size or maturity of the security team.
What is a dangling CNAME record and why does it enable subdomain takeover?
A dangling CNAME record is a DNS entry pointing a subdomain at a cloud resource -- an S3 bucket, GitHub Pages deployment, Heroku app, Azure storage endpoint -- that no longer exists or whose account has lapsed. Cloud providers assign resource names on a first-come basis. An attacker who identifies a dangling CNAME can register a new account with the same provider, claim the resource name the CNAME points to, and immediately serve attacker-controlled content under the organization's subdomain. No credentials or network access to the organization are required.
Why are large organizations more exposed to forgotten subdomain risk than smaller ones?
Subdomain creation in large organizations is decentralized -- marketing, DevOps, product, regional offices, and vendors all create DNS records. Subdomain decommissioning has no equivalent distributed ownership. DNS cleanup is no one's formal job. Vulnox assessments found that organizations with more than 5,000 employees were three times more likely to have five or more vulnerable forgotten subdomains than smaller organizations, because the volume of record creation outpaces any manual cleanup process.
Does monitoring through a domain registrar protect against subdomain takeover?
No. Registrars monitor uptime, DNS resolution, and renewal. They do not monitor whether CNAME targets are still owned by the registrant, whether NS delegation zones are still controlled by the organization, or whether cloud resources pointed to by DNS records have lapsed. The takeover risk exists at the application and account layer, not the DNS resolution layer -- which is outside registrar visibility.
What should be included in technical and organizational measures documentation to cover subdomain takeover risk?
DNS record lifecycle management should appear explicitly in technical and organizational measures documentation reviewed alongside records of processing activity. At minimum: a defined process for removing DNS records when infrastructure is decommissioned, a defined window for completion, and documentation of each removal. This process should be triggered by infrastructure decommissioning workflows in IaC pipelines, project closeout checklists, and vendor offboarding procedures. The documentation serves both the security function and GDPR's accountability principle under Article 5(2).
How does certificate transparency log history create ongoing subdomain exposure risk?
Certificate transparency logs are append-only and permanent. Every SSL certificate ever issued for a domain is recorded, including subdomains from campaigns and integrations that ended years ago. An attacker querying crt.sh for an organization's domain gets a complete historical subdomain inventory, including entries the organization has no current record of and may still have dangling DNS records for. The log cannot be edited or expunged -- the historical record is permanent regardless of whether the subdomain is still in use.
Related Articles
Basic digital footprint check: what free tools find and what they miss
A basic digital footprint check using free tools takes less than an hour and reliably surfaces subdomains, certificate history, and indexed content. What it misses — assets with no DNS record, credential material in archived repositories, and vendor-created infrastructure — is where the regulatory exposure lives.
SaaS digital footprint: what customer-facing infrastructure exposes before anyone attacks
In Vulnox assessments, the average SaaS company has 11 externally reachable assets its own team cannot name. That gap between what you think you expose and what is actually visible is where most breaches begin.
Digital footprint exposure and data protection risk: what regulators find that internal teams miss
Forgotten subdomains, undocumented SaaS integrations, and exposed API keys are data protection violations waiting to be discovered -- by a regulator, not your internal team. Vulnox assessments found at least one forgotten subdomain in 71% of environments reviewed. Here is what that exposure looks like through a regulatory lens.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.