DORA compliance for DNS infrastructure — what IT teams need to know

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.

The Digital Operational Resilience Act (Regulation (EU) 2022/2554) has applied since 17 January 2025. It covers a defined range of EU financial entities and establishes an oversight framework for ICT third-party providers designated as critical.

If you manage DNS for a financial entity, the service may form part of the entity’s ICT assets, dependencies and third-party risk. Whether DORA applies to a particular entity or provider, and whether a particular event is reportable, requires a scope and impact assessment.

This article highlights DORA requirements relevant to DNS operations and maps them to controls implemented in DNS by echo reply. The mapping is supporting evidence, not a certification or a substitute for the customer’s governance, legal analysis and reporting process.

What DORA requires and why it matters for DNS

DORA is not a general cybersecurity directive — it is specifically about operational resilience of ICT systems. Unlike NIS2, which is broader in scope, DORA targets the financial sector and goes deeper on incident reporting, third-party risk, and change management.

DNS is a foundational ICT service. A misconfigured zone, an unauthorized record change, or a compromised delegation can take down customer-facing services. DORA treats this kind of risk seriously.

Requirement mapping

ICT asset identification and documentation (Art. 8(1))

DORA requires financial entities to identify, classify, and document all ICT assets and their dependencies.

For DNS, useful evidence includes the zones you operate, their records and dependencies, and who can change them. A financial entity should decide how that evidence fits its authoritative ICT asset inventory.

Implemented platform control: Organisation-scoped zone and record inventories are queryable in the platform. Its append-protected management history records supported model changes and can contribute change evidence. It should not be treated as the customer’s complete ICT asset register.

Access control and authentication policies (Art. 9(4)(c))

DORA requires entities to implement access control policies based on the principles of least privilege and need-to-know.

Shared DNS credentials are a common anti-pattern. When everyone uses the same login to a DNS provider, you cannot attribute changes, enforce separation of duties, or revoke access without rotating credentials for the entire team.

Implemented platform control: Role-based access control has 16 granular permission flags, six editable presets and custom roles. Organisation-scoped access supports separation between tenants. Customers remain responsible for assigning roles, reviewing access and protecting individual accounts.

ICT change management (Art. 9(4)(e))

DORA requires documented change management procedures for ICT systems, including assessment of changes before deployment.

DNS changes going live without review is a risk. A typo in an MX record can break email for an entire organization. A wrong CNAME can redirect traffic to the wrong endpoint.

Implemented platform control: Stashed changes support proposal, diff review, approval and rejection. Users with the separate self-approval permission can apply their own changes, so customers must configure roles and review policy to match their separation-of-duties requirements.

Logging of ICT activities (DORA Art. 9 and Delegated Regulation 2024/1774, Art. 12)

DORA’s technical standards require documented logging procedures, including the events and retention periods in scope. They cover access control, capacity, change management, ICT operations, and network traffic, and require protection against tampering, deletion, and unauthorised access.

Implemented platform control: Append-protected, tenant-scoped management history and activity views retain timestamps and available actor/change metadata for supported resources. CSV history export and Enterprise PDF/CSV compliance reports are available. Login history and management-model history are distinct datasets, so fields such as IP address and before/after values are not promised for every event. Retention must follow the applicable policy. This article does not assert a universal duration.

Anomaly detection and incident classification (Art. 10, Art. 17)

DORA requires entities to detect anomalous activities and classify ICT-related incidents based on defined criteria.

Implemented platform control: Configurable detection rules evaluate patterns including bulk changes, unusual timing and new-login context. Rules can create detection history and, where configured, breach alerts. They provide signals for investigation. They do not determine whether an incident is legally reportable.

ICT incident reporting (Art. 19)

This is where DORA diverges significantly from NIS2. The reporting timeline is more granular:

Stage	Deadline	What is required
Initial notification	Within 4 hours after classifying as major, and no later than 24 hours after awareness	Initial information required by the reporting template
Intermediate report	72 hours after initial notification	Updated impact, root cause (if known), mitigation steps
Final report	1 month after the intermediate report or latest updated intermediate report	Root cause, resolution, costs and losses, and recurring-incident information where applicable

These time limits come from Commission Delegated Regulation (EU) 2025/301. The initial-notification window is tight, and its 24-hour awareness cap matters when classification takes time. The financial entity needs a rehearsed process for detection, major-incident classification, ownership and submission.

Implemented platform control: Breach-alert lifecycle tracking lets an authorised user select the applicable framework and record major-incident classification. The platform creates and surfaces DORA’s classification-anchored initial stage and the later reporting stages. Customers must separately ensure that the 24-hour awareness cap is met. The platform can structure evidence and reports, but the customer decides classification and remains responsible for notifications to the competent authority.

ICT third-party risk management (Art. 28–44)

DORA places significant obligations on financial entities regarding ICT third-party risk. Relevant contracts must address matters including service and data-processing locations, access and recovery, cooperation, termination and audit rights, as applicable.

Customer and provider responsibility: Obtain current contractual and operational evidence for service locations, subprocessors, transfers, resilience and exit support. This article makes no blanket claim that all echo reply data stays in the EU or that no third-country transfer occurs. Those facts must be established for the deployed service and its complete data path.

DORA and NIS2 overlap

If you are already working toward NIS2 compliance, you are not starting from zero on DORA. For a full analysis of how the two regulations interact for DNS at financial institutions, see DNS compliance for EU financial institutions — NIS2 and DORA. Both regulations require:

Risk management frameworks for ICT systems
Incident detection and reporting
Access controls and audit trails
Supply chain / third-party risk management

The main differences are that DORA is sector-specific to financial services, uses a classification-based initial deadline alongside a 24-hour awareness cap, and places more emphasis on third-party ICT provider oversight. NIS2 uses awareness-based deadlines and, because it is a directive, must be read with the applicable national implementation.

DNS by echo reply provides controls that can support evidence for both frameworks, including RBAC, append-protected history, stashed-change review, detection rules, breach-alert tracking and framework-aware reporting stages. Customers must configure and operate those controls, connect them to their wider incident process, and determine which legal duties apply.

What this means in practice

If you are evaluating DNS management platforms for a financial entity, here is what to look for:

Audit trail — Can you prove who changed what, when, and why? Can you export this for regulators?
Access controls — Can you enforce least privilege? Can you isolate access between teams or clients?
Change management — Which changes require another person’s approval, who can self-approve, and is the decision retained?
Incident tracking — Can the platform preserve incident evidence and surface deadlines while leaving classification and filing with accountable staff?
Provider evidence — Are service and processing locations, subprocessors, transfer safeguards, resilience measures and exit provisions documented?

These questions help a financial entity assess DNS within its DORA programme. A feature checklist alone cannot establish compliance. Governance, configuration, contracts, operational testing and customer procedures matter as well.