Do EU financial institutions need to comply with both NIS2 and DORA?

It depends on the entity and national implementation. DORA applies directly to financial entities within its scope. NIS2 expressly avoids duplicating equivalent ICT risk-management and incident-reporting requirements where sector-specific EU law such as DORA applies, while other NIS2-derived or national obligations may still matter. Obtain advice for your entity and services.

Is DNS infrastructure in scope for DORA compliance?

DNS can be part of the ICT assets, dependencies and third-party services a financial entity must identify and manage. Whether a particular DNS event is reportable depends on the event, its impact and the applicable classification criteria.

What is the difference between NIS2 and DORA incident reporting timelines?

NIS2 requires an early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours of awareness, and a final report within one month of that notification. DORA requires an initial notification within four hours of major-incident classification and no later than 24 hours after awareness, an intermediate report within 72 hours of the initial notification, and a final report within one month of the intermediate report or latest update.

What DNS controls do auditors look for under NIS2 and DORA?

A review may examine named-user access, least-privilege permissions, change controls, protected and exportable history, incident procedures, DNSSEC, resilience, and the contractual terms for ICT providers. The exact evidence depends on the entity, service and assessment scope.

Can NIST SP 800-81r3 help with EU DNS compliance?

NIST SP 800-81r3 is US technical guidance, not an EU legal requirement. Its DNS-specific recommendations can still inform a technical baseline, but citing it does not establish NIS2 or DORA compliance.

← All updates

DNS compliance for EU financial institutions — NIS2 and DORA

Published 26 March 2026 Updated 22 September 2026

DORA supplier package is not currently available or included in subscriptions. The existing controls described below remain available, but do not constitute the complete supplier package. See Terms of Service for the services currently offered.

If you manage DNS for an EU financial entity, DORA and the NIS2 framework may both be relevant. Their application depends on the entity, its services and national implementation. Neither turns every DNS event into a reportable incident.

This article is not a product pitch. It is a practical orientation for IT and compliance teams who need to understand where these two regulations overlap and diverge for DNS — and who need to explain to management why DNS infrastructure requires compliance tooling.

Why DNS is in scope for both regulations

Under DORA, DNS can form part of the ICT assets, dependencies and third-party services that support a financial entity’s operations. A misconfigured zone, hijacked delegation or unauthorised record change can disrupt customer-facing services, email delivery or traffic routing, so DNS belongs in the entity’s ICT risk assessment.

Under NIS2, DNS service providers are expressly within the directive’s digital-infrastructure scope. That does not mean every financial entity or every outsourced DNS arrangement independently receives the same classification. Entity scope, sector-specific rules and national transposition must be assessed together.

Outsourcing DNS does not remove a financial entity’s responsibility to manage ICT third-party risk. The practical task is to document the service, dependencies, controls and contract, then determine which obligations apply.

How NIS2 and DORA interact — the lex specialis principle

DORA (Regulation EU 2022/2554) and NIS2 (Directive EU 2022/2555) were adopted in the same legislative cycle and their drafters anticipated the overlap. Article 4 of NIS2 and Recital 16 of DORA establish the lex specialis principle: where both regulations cover the same ground, DORA takes precedence for financial entities.

This is not a blanket rule that every provision of both instruments applies cumulatively. In broad terms:

Where DORA has a specific requirement (e.g., ICT incident reporting timelines), DORA’s version applies.
Other NIS2-derived duties may remain relevant where they are not displaced by equivalent sector-specific requirements, depending on national law and the entity’s scope.
Applicable requirements should be mapped obligation by obligation rather than reduced to a “stricter rule always wins” shortcut.

In practice, a DORA-oriented DNS control set creates useful evidence for related security obligations, but it does not by itself establish compliance with NIS2 or national law.

Where NIS2 and DORA align and diverge for DNS

Control area	NIS2	DORA	Notes
Access controls	Risk-management measures, Art. 21(2)(i)	Least privilege and need-to-know, Art. 9(4)(c)	Aligned — DORA is more specific about implementation
Change management	Implicit in risk management obligations	Explicit documented procedures, Art. 9(4)(e)	DORA adds an explicit requirement NIS2 does not
Audit logging	Supports incident handling and risk-management evidence	Logging procedures and protected logs under Art. 9 and Delegated Regulation 2024/1774, Art. 12	DORA’s technical standard specifies event categories and log protection
Incident reporting	24h early warning, 72h incident notification, 1 month final report, Art. 23	Initial notification within 4h of major classification and no later than 24h after awareness, 72h intermediate, 1 month final, Art. 19 and Delegated Regulation 2025/301	Different clocks and report stages must be mapped precisely
Third-party / supply chain	Supply chain security, Art. 21(2)(d)	ICT third-party risk management, Art. 28–44	DORA goes much deeper (contract terms, exit strategy, audit rights)
Cryptographic controls	Cryptography policies, Art. 21(2)(h)	Part of ICT security policies	Aligned
Data location	Relevant to supplier and risk assessment	Contract must identify service and data-processing locations, Art. 30	This is a transparency and risk requirement, not a blanket EU-only hosting rule
Resilience testing	Vulnerability handling, Art. 21(2)(e)	Digital operational resilience testing, Art. 24–27	DORA adds structured testing requirements

The useful pattern is that one set of well-evidenced DNS controls can support several obligations. Applicability, reporting thresholds and contractual requirements still need separate legal and operational assessment.

What auditors will ask about your DNS infrastructure

When preparing for compliance assessments, expect these questions. Each maps to specific regulatory obligations.

Who can modify DNS records, and how is that access controlled? Auditors want to see named-user access with role-based permissions — not shared credentials or unrestricted admin accounts. (DORA Art. 9(4)(c), NIS2 Art. 21(2)(i))
Can you produce protected, attributable change history for an appropriate period? Show which resources and actions are covered, what metadata is captured, who can access it, and how it can be exported. Set retention from applicable obligations and documented policy rather than assuming a universal 12-month rule. (DORA Art. 10, NIS2 Art. 21)
What is your change management process? Which DNS changes require separate approval, who may self-approve, and what evidence does the review retain? (DORA Art. 9(4)(e))
How do you detect unauthorised or anomalous DNS changes? Bulk deletions, off-hours modifications, changes from unexpected IPs — these should be flagged automatically, not discovered during a post-incident review. (DORA Art. 10, Art. 17)
What are your incident classification and reporting timelines? Under DORA, the initial notification is due within four hours of major-incident classification and no later than 24 hours after awareness. Under NIS2, the early warning is due within 24 hours of awareness. Can your process classify incidents and track the later reporting stages from the correct anchors? (DORA Art. 19 and Delegated Regulation 2025/301, NIS2 Art. 23)
Is DNSSEC deployed, and what algorithm are you using? Record the signing status, algorithm and key-management process, then compare them with the current guidance your organisation has adopted. (NIS2 Art. 21(2)(h))
Where are services and data processed? Record the relevant locations, subprocessors, transfer mechanisms and contractual commitments instead of relying on an unsupported residency slogan. (DORA Art. 28–44)

Building the case for DNS compliance tooling

If you are reading this, you probably already understand why DNS compliance matters. The harder conversation is often with the people who control budget. Here are arguments grounded in regulatory reality.

DNS is both a single point of failure and an audit target. It is one of the few infrastructure components that can simultaneously cause an outage and fail an audit. If your DNS management does not produce attributable change records, you have an operational risk and a compliance gap at the same time.

The regulatory consequences are material. NIS2 provides for national supervisory and enforcement measures, while DORA establishes financial-sector supervision and an EU oversight framework for designated critical ICT third-party providers. Which regime and measures apply depends on the entity and obligation. Do not assume penalties simply stack for the same requirement.

Retrospective evidence is fragile. Reconstructing who changed which DNS records, when and under whose authority is difficult if the system did not preserve attributable history. Define the evidence and retention policy before an incident or assessment creates an urgent request.

The DORA reporting timetable requires a rehearsed process. A major incident needs prompt classification, ownership and evidence collection. The four-hour clock begins at major-incident classification, while the initial notification is also capped at 24 hours after awareness. Tooling can surface deadlines and structure reports, but the customer remains responsible for classification, escalation and submission to the competent authority.

Evaluating DNS platforms for dual compliance

When assessing whether a DNS management platform can support NIS2 and DORA compliance, these are the capabilities that matter:

Protected, attributable audit trail with policy-based retention and export to CSV or equivalent (DORA Art. 10, NIS2 Art. 21)
Granular RBAC with zone-level scoping and per-action permission control (DORA Art. 9(4)(c), NIS2 Art. 21(2)(i))
Change approval workflow with diff review and an explicit policy for self-approval (DORA Art. 9(4)(e))
Anomaly detection flagging bulk changes, off-hours activity, and unexpected source IPs (DORA Art. 10, Art. 17)
Incident lifecycle tracking with reporting stages based on the correct anchors for DORA and NIS2, including DORA’s 24-hour awareness cap and NIS2’s one-month final report (DORA Art. 19 and Delegated Regulation 2025/301, NIS2 Art. 23)
DNSSEC with current algorithms, key-age visibility and documented rollover procedures (NIS2 Art. 21(2)(h))
Documented processing and service locations, subprocessors, transfer safeguards and exit provisions (DORA Art. 28–44)

DNS by echo reply implements controls that can contribute evidence in these areas, including granular RBAC, append-protected management history with CSV export, optional stashed-change review, DNSSEC, detection rules, incident lifecycle tracking, and Enterprise PDF/CSV compliance reports. These controls support a customer’s programme. They do not make an organisation automatically compliant. See our DORA compliance article and NIS2 compliance guide for the detailed mappings.