Dangling DNS Governance for NIS2, DORA and GDPR

The CISO gets the message at 07:12 on a Monday.

A security researcher has found promo.company.com pointing to an abandoned cloud app. The DNS record is still live. The cloud resource is gone. The SaaS tenant that once served the campaign was deleted six months ago, shortly after Marketing moved to another platform. Nobody removed the CNAME.

By 08:30, the question is no longer, “Can someone take over the subdomain?” It is, “Why did nobody know this asset existed?”

By 09:15, Legal is involved because the subdomain once collected email addresses for a product waitlist. Procurement is involved because the campaign platform was managed by an agency. Compliance is involved because the company is preparing for ISO/IEC 27001:2022 surveillance, NIS2 readiness and customer assurance questionnaires. The DPO asks whether the exposure could become a personal data breach under GDPR if the subdomain is weaponized. The CFO asks whether the same weakness could affect a payments portal within the group’s regulated financial services environment.

The technical fix may take minutes. The governance problem can take months to unwind if the organization cannot prove that every internet-facing asset is known, owned, reviewed, monitored and retired through a controlled process.

That is why dangling DNS and subdomain takeover prevention cannot be treated as a narrow DNS cleanup task. A stale DNS record is often a visible symptom of deeper control failures: incomplete asset inventory, weak ownership, missing decommissioning evidence, poor change control, inadequate supplier exit management, insufficient external attack surface monitoring and unclear incident classification.

For Clarysec clients, dangling DNS is a management system test. It shows whether policies, controls, registers, evidence and accountability actually work when a forgotten cloud dependency becomes an attacker’s opportunity.

What dangling DNS really means

A subdomain takeover becomes possible when a DNS record, often a CNAME, points to a resource that no longer exists or is no longer controlled by the organization. If an attacker can claim or recreate the target resource on the cloud or SaaS platform, they may be able to serve content under the organization’s trusted subdomain.

Common examples include:

• A CNAME pointing to an unclaimed cloud app service.
• A vanity SaaS hostname left in DNS after the subscription was cancelled.
• A CDN distribution removed from the provider console but still referenced in public DNS.
• A marketing microsite decommissioned by an agency without DNS removal.
• A storage endpoint or static website mapping that can be re-registered.
• A development subdomain exposed through a forgotten platform-as-a-service project.

The business impact can be severe. Attackers may host phishing pages, capture credentials, distribute malware, abuse domain reputation, intercept session data or damage brand trust. Where the subdomain previously processed personal data, even a short-lived takeover can trigger GDPR breach analysis. Where the affected service supports regulated financial operations, the incident may also need assessment under DORA or internal ICT risk frameworks.

Auditors increasingly see dangling DNS as evidence of control maturity. A single stale record can indicate that the organization does not know what it owns, who owns it, how changes are reviewed, how cloud services are exited or how externally facing assets are monitored.

That is why Clarysec maps this issue across ISO/IEC 27001:2022 ISO/IEC 27001:2022, ISO/IEC 27002:2022 ISO/IEC 27002:2022, NIS2, DORA, GDPR, NIST CSF 2.0 and COBIT 2019 audit expectations.

Why ISO 27001:2022 is the practical backbone

The strongest way to govern dangling DNS is not to create separate programs for NIS2, DORA and GDPR. It is to use ISO/IEC 27001:2022 as the management system backbone and generate evidence once for many assurance needs.

The relevant requirements begin before Annex A. Clauses 4.1 to 4.4 require the organization to understand its context, interested-party requirements, ISMS scope and dependencies with other organizations. For dangling DNS governance, the scope should include external DNS, domains, registrars, cloud services, SaaS platforms, agencies, managed hosting, CDNs and any third party that can create or retire internet-facing services.

Clauses 5.1 to 5.3 make this a leadership and accountability issue. Management must align the ISMS with business direction, provide resources, communicate the importance of information security and assign responsibilities. If Marketing can launch a microsite, Engineering can create cloud endpoints and Procurement can terminate SaaS contracts, the organization needs a governance model that assigns clear DNS and service ownership across all of them.

Clauses 6.1.1 to 6.1.3 provide the risk assessment, risk treatment and Statement of Applicability logic. Dangling DNS should be recorded as a realistic risk scenario, not just a scanner output. It affects confidentiality, integrity and availability, and often maps to legal, regulatory and contractual obligations.

Clauses 7.5, 8.1, 8.2 and 8.3 turn governance into evidence. They require controlled documented information, planned and controlled operational processes, consideration of unintended changes, control of externally provided processes, periodic risk assessments and documented treatment outcomes.

Annex A then gives the control catalogue. In Clarysec projects, the core ISO/IEC 27002:2022 relationships usually look like this:

The point is simple. ISO/IEC 27001:2022 does not ask for a heroic one-time cleanup. It asks for a controlled operating model that prevents recurrence.

The Zenith Controls view: one risk, three control anchors

In Zenith Controls: The Cross-Compliance Guide Zenith Controls, Clarysec uses relevant ISO/IEC 27002:2022 controls as cross-compliance anchors. For dangling DNS and subdomain takeover governance, three controls are central.

Control 5.9, Inventory of information and other associated assets, is classified as preventive, supports confidentiality, integrity and availability, aligns to the Identify cybersecurity concept, and sits under asset management as the operational capability with governance, ecosystem and protection as security domains.

Control 5.23, Information security for use of cloud services, is classified as preventive, supports confidentiality, integrity and availability, aligns to Protect, and sits under supplier relationships security as the operational capability with governance, ecosystem and protection as security domains.

Control 8.8, Management of technical vulnerabilities, is classified as preventive, supports confidentiality, integrity and availability, aligns to Identify and Protect, and sits under threat and vulnerability management as the operational capability with governance, ecosystem, protection and defense as security domains.

This matters because dangling DNS is not only an asset control failure, not only a cloud control failure and not only a vulnerability. It is all three. The organization must show that asset inventory, cloud usage governance and vulnerability management reinforce each other.

Clarysec often adds supporting practices around these anchors: ISO/IEC 27005 for risk assessment and treatment discipline, ISO/IEC 27017 for cloud service security governance, ISO/IEC 27018 where cloud services process PII, ISO/IEC 27701 for privacy information management, and ISO 22301 where continuity and crisis response are relevant.

The policy evidence that already requires DNS lifecycle control

Many organizations already have policies that, if implemented properly, would prevent dangling DNS. The gap is that DNS lifecycle control is not explicitly connected to those policies.

Clarysec’s Asset Management Policy-sme Asset Management Policy-sme - SME, Policy Implementation Requirements, clause 6.6.1 states:

Cloud-based assets (e.g., storage accounts, SaaS platforms, web domains) must also be included in the inventory.

The same policy adds in clause 6.6.2:

Ownership, purpose, access privileges, and renewal timelines must be documented.

For dangling DNS governance, this means every production subdomain and material non-production subdomain should have a named owner, business purpose, linked service, access model and review date.

Most importantly, clause 6.6.3 states:

Expired or unused services must be deactivated and removed from the inventory.

For DNS, this must be interpreted carefully. Removing the service from the inventory is not enough. The DNS record, cloud binding, SaaS custom domain claim, certificate, WAF rule, CDN configuration and monitoring entry must also be reviewed.

The enterprise version reinforces this wider asset concept. Clarysec’s Asset Management Policy Asset Management Policy, Scope, clause 2.2.5 states:

Logical assets: domain names, licenses, user accounts, configuration baselines

Domain names and configurations are not administrative trivia. They are trust-bearing assets that can become attack paths.

The change control linkage is equally important. Clarysec’s Change Management Policy Change Management Policy, Purpose, clause 1.1 states:

This policy establishes a formal framework for initiating, assessing, approving, implementing, and reviewing changes to the organization’s information systems, infrastructure, applications, and related processes.

A DNS removal, SaaS termination, cloud app deletion, CDN migration or marketing microsite retirement should therefore generate change evidence. The absence of a change ticket is often the first audit red flag.

Cloud governance must also be connected. Clarysec’s Cloud Usage Policy Cloud Usage Policy, Governance Requirements, clause 5.5 states:

The Information Security Team must routinely assess network traffic, DNS activity, and logs to detect unauthorized cloud use (shadow IT). Detected violations must be investigated promptly.

For subdomain takeover prevention, DNS activity monitoring is not only about shadow IT. It is also about stale IT, meaning assets that were once authorized but are no longer controlled.

A practical Clarysec workflow for dangling DNS governance

A strong dangling DNS program is not complicated. It is disciplined, repeatable and connected to the ISMS, vulnerability management, change management and supplier lifecycle.

For SMEs, this may begin as a lightweight register. For enterprises, it usually integrates DNS exports, external attack surface management, cloud asset inventories, CMDB records, vulnerability scanners, SIEM alerts and ticketing systems.

The governance question remains the same: can you prove that every externally reachable subdomain is known, owned, monitored and removable through a controlled process?

The abandoned campaign subdomain, handled the right way

Return to the Monday incident. promo.company.com points to an abandoned SaaS campaign site.

First, the security lead creates a vulnerability record because the asset is externally facing. Clarysec’s Vulnerability and Patch Management Policy Vulnerability and Patch Management Policy, Policy Implementation Requirements, clause 6.1.1 states:

All systems must be scanned at least monthly; high-risk or externally exposed assets must be scanned weekly.

For SMEs, the equivalent policy sharpens prioritization. The Vulnerability and Patch Management Policy-sme Vulnerability and Patch Management Policy-sme - SME, Policy Implementation Requirements, clause 6.5.1 states:

Systems that process personal data, provide remote access, or are externally facing must be prioritized for scanning and updates

Second, the owner is identified through the asset register. If the owner is unknown, that becomes a control failure against asset governance. The register is updated to include DNS name, target provider, original business owner, data classification, supplier and status.

Third, IT checks the cloud or SaaS platform. If the cloud account was deleted, Clarysec’s Cloud Usage Policy-sme Cloud Usage Policy-sme - SME, Policy Implementation Requirements, clause 6.3.6 is directly relevant:

Deleted cloud accounts must be reviewed by the IT provider or GM for residual access, orphaned data, or overlooked content.

Fourth, the change owner raises an emergency or expedited change ticket to remove the DNS record or reclaim the resource temporarily before removal. The ticket includes impact assessment, rollback plan, approvals, implementation evidence and post-change validation.

Fifth, the privacy lead assesses whether the subdomain processed or could have exposed personal data. Clarysec’s PII Security and Access Control Policy PII Security and Access Control Policy, Secure configuration and vulnerability management, clause 4.7.4 states:

[Both] The System Owner / Application Owner MUST record vulnerability assessment coverage for systems processing PII in REG12 at least quarterly and after material technical change.

Clause 4.7.5 adds:

[Both] The Information Security Lead MUST record unresolved high-risk vulnerabilities affecting PII in REG12 within five business days of validation.

These clauses apply whether the organization acts as controller or processor, because they are tagged [Both]. For a dangling DNS issue involving PII, the evidence must not sit only in a technical ticket. It must be reflected in the PII vulnerability evidence register.

Sixth, if an agency or SaaS provider hosted the campaign, Procurement checks third-party records. Clarysec’s Processor, Subprocessor and Third-Party Privacy Management Policy Processor, Subprocessor and Third-Party Privacy Management Policy, Relationship identification and classification, clause 4.1.2 states:

[All] The Process Owner / Business Owner MUST identify each proposed third-party relationship that will process, access, receive, store, transmit, support, or otherwise affect PII in REG08 before procurement, onboarding, renewal, or material third-party privacy change.

Clause 4.5.5 requires:

[Both] The Vendor / Procurement Owner MUST record processing locations, hosting locations, and international transfer indicators in REG08 and link applicable transfer evidence to REG09 before approving a processor, subprocessor, location change, or transfer-relevant service change.

Finally, the compliance lead packages the evidence. Clarysec’s Audit and Compliance Monitoring Policy Audit and Compliance Monitoring Policy, Objectives, clause 3.4 states that one objective is:

To generate defensible evidence and an audit trail in support of regulatory inquiries, legal proceedings, or customer assurance requests.

That is the outcome the CISO needs when a customer, regulator or auditor asks, “How do you know this will not happen again?”

Where the Zenith Blueprint fits

Clarysec’s Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint converts controls into audit-ready operating practices. Dangling DNS maps strongly to four areas.

In the Controls in Action phase, Step 22 covers organizational controls 5.1 to 5.18, including ISO/IEC 27002:2022 control 5.9. The Zenith Blueprint states:

No organization can protect what it doesn’t know it has. Control 5.9 formalizes this foundational principle, requiring the establishment and maintenance of an up-to-date inventory of all information and associated assets relevant to the ISMS.

It continues:

In its most strategic form, an asset inventory serves as the central nervous system of your ISMS.

Your subdomain inventory is not a side list. It feeds access decisions, vulnerability scanning, logging, supplier management, privacy mapping and incident response.

In Step 20, the Zenith Blueprint covers technological controls 8.18 to 8.26. For control 8.21, Security of network services, it instructs organizations to validate network service security:

List out all internal and external network services (DNS, VPN, SMTP, DHCP, API gateways, etc.).

This is why DNS providers, registrars, cloud DNS, CDN platforms and SaaS custom-domain features belong in the service registry.

In Step 19, the Zenith Blueprint covers technological controls 8.1 to 8.17. For control 8.8, it states:

Managing vulnerabilities is one of the most critical areas of modern cyber hygiene. While firewalls and antivirus tools provide protection, they can be undermined if unpatched systems or misconfigured services are left exposed.

A dangling DNS record is a misconfigured external service path. Even when there is no CVE, it should be handled through vulnerability management: validate, score, assign, remediate, retest and close.

In Step 23, the Zenith Blueprint addresses organizational controls 5.19 to 5.37. For control 5.23, it advises:

List all cloud services currently in use (5.23), including shadow IT where known. Identify who approved them and whether due diligence was performed. Develop a lightweight evaluation checklist that covers data location, access model, logging, and encryption.

For subdomain takeover prevention, add custom domains, DNS dependencies, decommissioning owner and exit evidence to that cloud service evaluation checklist.

NIS2, DORA and GDPR mapping

NIS2 makes dangling DNS governance a board-level issue for many essential and important entities. Article 20 requires management bodies to approve cybersecurity risk-management measures, oversee implementation and follow cybersecurity training. Article 21 requires appropriate and proportionate technical, operational and organizational measures using an all-hazards approach. Its minimum areas include risk analysis, incident handling, business continuity, supply chain security, secure acquisition, development and maintenance, vulnerability handling, effectiveness assessment, cyber hygiene, training, access control and asset management.

A dangling DNS program maps cleanly to those areas. Article 21(3) also requires supply chain security to consider vulnerabilities specific to each direct supplier or service provider. If a marketing agency, SaaS vendor, managed hosting provider or cloud platform manages custom domains, supplier-specific controls should cover DNS ownership, service exit, incident support and evidence handover.

Article 23 matters if takeover occurs or is capable of causing severe operational disruption, financial loss or considerable material or non-material damage. NIS2 uses staged reporting: early warning within 24 hours of becoming aware of a significant incident, notification within 72 hours, intermediate reports where requested and a final report within one month of the incident notification.

For financial entities, DORA is the sector-specific digital operational resilience regime. Articles 5 and 6 require an internal governance and control framework for ICT risk management, with ultimate management body responsibility, clear ICT roles, policies for availability, authenticity, integrity and confidentiality of data, audit plans, resources, third-party service policy and a documented ICT risk management framework.

Articles 8 to 14 form the operational core. Article 8 requires identification, classification and documentation of ICT-supported business functions, information assets, ICT assets, dependencies, ICT third-party interconnections, inventories, risk scenarios and legacy systems. A dangling CNAME is often a missed dependency. Article 9 requires protection and prevention. Article 10 requires detection of anomalous activity, ICT incidents and potential single points of failure. Articles 11 and 12 address continuity, recovery, backup and restoration. Article 13 requires learning from vulnerabilities, threats, incidents and tests.

Articles 17 to 19 formalize incident management, classification and reporting. Articles 28 to 30 make third-party ICT risk lifecycle-based. Financial entities remain fully responsible when using ICT service providers. For DORA readiness, Clarysec recommends adding four fields to every DNS and cloud service register: critical or important function support, ICT third-party provider, contract or register reference, and exit test status.

GDPR applies when the issue involves personal data. A subdomain takeover is not automatically a personal data breach, but it can become one if the affected subdomain collects credentials, captures form data, impersonates a service, exposes user identifiers or enables unauthorized access to personal data. GDPR Article 5 requires integrity, confidentiality and accountability. Article 32 requires appropriate security of processing. Article 33 may require supervisory authority notification if a personal data breach is likely to result in a risk to the rights and freedoms of natural persons.

Clarysec’s PII Incident and Breach Management Policy PII Incident and Breach Management Policy, Classification and breach assessment, clause 4.2.6 supports this multi-regime trigger analysis:

[Conditional] The Privacy Lead / PIMS Manager MUST evaluate applicable legal, sectoral, financial-sector, cybersecurity, contractual, customer, and service-recipient reporting triggers for each high-impact PII incident and record the applicability outcome in REG01, REG08, and REG10.

That decision record is exactly what is needed when a subdomain takeover could involve GDPR, NIS2, DORA, contracts and customer notification.

How auditors will test your evidence

An integrated ISMS should let you answer different auditors with the same evidence base. The wording of the question changes, but the proof is often the same.

A wider assurance lens often includes NIST CSF 2.0 and COBIT 2019. NIST CSF 2.0 helps express the target state through GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND and RECOVER outcomes. A Current Profile might show manual quarterly DNS reviews and inconsistent SaaS offboarding. A Target Profile might require automated weekly takeover checks, mandatory owner assignment, supplier exit evidence and integration with change management.

A COBIT 2019 or ISACA-oriented auditor will usually ask who owns the process, how risk is evaluated and directed, whether changes are controlled, whether suppliers are managed, whether configuration and assets are reliable, and whether assurance evidence supports management reporting. They may not ask first for a list of CNAMEs. They may ask how management knows that external digital services are controlled throughout their lifecycle.

What good audit evidence looks like

A dangling DNS audit pack should be small enough to maintain but complete enough to defend. Clarysec typically recommends the following evidence set:

• DNS zone inventory with source, date, record type, target and owner.
• External attack surface scan results showing takeover checks.
• Asset register entries for domains, subdomains, cloud services, SaaS applications and CDNs.
• Service registry showing internal or supplier responsibility.
• Change tickets for creation, modification and deletion of DNS records.
• Cloud and SaaS onboarding checklists including custom domain and DNS review.
• Supplier contracts or security clauses covering DNS, hosting, incident support and exit.
• Vulnerability tickets with severity, owner, remediation date and retest evidence.
• PII assessment where the subdomain processes or previously processed personal data.
• Incident classification records for suspected or confirmed takeover.
• Lessons learned and updated procedures after findings.

Metrics matter too. Management should see the number of external subdomains, percentage with assigned owners, number of dangling findings, mean time to remediate, overdue high-risk findings, supplier-hosted subdomains without current contract reference and percentage of cloud exits with DNS removal evidence.

These metrics turn technical hygiene into management oversight evidence.

Common failure patterns Clarysec finds

Across SaaS, fintech, healthcare technology, managed services and e-commerce clients, the same patterns recur.

First, DNS ownership is split between teams. Engineering owns cloud. Marketing owns campaigns. IT owns DNS provider access. Procurement owns SaaS termination. No one owns the full lifecycle.

Second, cloud deletion is treated as the end of the service. In reality, DNS, certificates, WAF rules, monitoring, secrets, documentation and supplier records may remain.

Third, vulnerability scanners focus on live hosts but miss provider-specific takeover conditions. Organizations need external attack surface checks that understand common SaaS and cloud error states.

Fourth, supplier exit procedures focus on invoices and data return but not custom domains, DNS records and subprocessor changes.

Fifth, privacy teams are notified too late. If a subdomain processed PII, the DPO or privacy lead should be part of classification before assumptions are made.

Sixth, evidence exists but is scattered. The DNS export is in one tool, change tickets in another, supplier contracts in procurement, vulnerability reports in scanners and privacy analysis in email. Auditors see fragmentation as weakness.

Clarysec’s toolkit solves this by connecting policies, registers, controls and evidence workflows.

A 30-day action plan for DNS governance

If you found one dangling DNS record, assume there are more. If you found none, make sure you can prove why.

Start with this 30-day plan:

1. Export all authoritative DNS zones.
2. Identify CNAME, ALIAS, A and AAAA records pointing to cloud, SaaS, CDN and agency-managed services.
3. Assign owners and business purposes.
4. Run takeover checks and validate suspicious records manually.
5. Create vulnerability tickets for confirmed risks.
6. Remove or reclaim exposed records through change control.
7. Update the asset register, cloud register and supplier register.
8. Review whether any affected subdomain processed PII.
9. Add DNS lifecycle checks to cloud onboarding, SaaS procurement and supplier exit.
10. Report metrics to management.

The technical fix for dangling DNS is often simple. The governance fix is what prevents the next takeover.

Clarysec can help you operationalize this using Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls, and our policy toolkit for asset management, cloud usage, vulnerability management, supplier governance, PII security, incident response and audit evidence.

If you want an audit-ready approach, Clarysec can help you build the DNS and cloud exposure evidence pack, map it to ISO/IEC 27001:2022, NIS2, DORA and GDPR, and turn forgotten subdomains into controlled, owned and monitored assets. Download the relevant Clarysec toolkit, request a demo or schedule a DNS governance assessment before a penetration tester, auditor or attacker finds the next forgotten pointer.