DORA Compliance in 2026: Complete Guide for EU Financial Entities

DORA in 2026: one year of application, what changed

One year ago, on 17 January 2025, the Digital Operational Resilience Act entered application. As a regulation rather than a directive, DORA applied directly across all 27 EU Member States from day one — no transposition needed, no national variations on core obligations. By May 2026, the framework has moved past the implementation phase and into the active enforcement phase. National competent authorities — BaFin in Germany, ACPR in France, CSSF in Luxembourg, MNB in Hungary, ČNB in Czechia and their equivalents across the Union — have shifted from guidance-issuing to inspection-conducting.

The transition has not been smooth. The European Supervisory Authorities' 2024 dry-run exercise on the Register of Information found that only 6.5% of nearly 1,000 firms across the EU successfully passed all 116 data quality checks. The 2025 cycle showed improvement but still revealed significant compliance gaps in third-party risk documentation, incident classification procedures, and operational resilience testing. The 2026 cycle, with reference date 31 December 2025, is the first to be fully evaluated under an enforcement posture.

Two developments in late 2025 and early 2026 have crystallised the regulatory landscape. First, on 18 November 2025, the European Supervisory Authorities published the first official list of 19 designated Critical ICT Third-Party Providers under DORA — including AWS, Microsoft Azure, Google Cloud, IBM, Bloomberg, the London Stock Exchange Group, Tata Consultancy Services and Orange. These designations bring named global providers under direct EU oversight, with Joint Examination Teams now active.

Second, the Commission's review under Article 58, due by 17 January 2026, has examined whether DORA's requirements should be strengthened for statutory auditors and audit firms — currently within scope but with limited obligations. The review opens the door to incremental scope adjustments later in the decade. For now, in-scope entities are operating under the original framework, and the practical test is whether they can produce defensible evidence within the four-hour clock when an incident occurs.

For organisations subject to DORA, this guide focuses on the operational test rather than the policy text. Article 19's three-stage reporting cascade is the most consequential single obligation in the regulation, and the four-hour initial notification window is significantly tighter than NIS2's 24-hour early warning. The remainder of the regulation — third-party risk, operational testing, sanctions — orbits around this central point: when something goes wrong, can your organisation document what happened with the speed and integrity that the regulator now expects?

Scope: who falls under DORA

DORA's scope is defined positively and broadly. Unlike NIS2, which uses sector criticality plus a size-cap rule, DORA applies to virtually every regulated financial entity in the European Union — with no minimum size threshold for most categories. The European Banking Authority estimates that approximately 22,000 financial entities fall within DORA's scope across the Union.

Financial entities in scope (non-exhaustive list)

The categories include credit institutions, payment institutions and electronic money institutions, investment firms, crypto-asset service providers, central securities depositories, central counterparties, trading venues, trade repositories, managers of alternative investment funds, management companies of UCITS, data reporting service providers, insurance and reinsurance undertakings, insurance intermediaries, institutions for occupational retirement provision, credit rating agencies, statutory auditors and audit firms, administrators of critical benchmarks, crowdfunding service providers, and securitisation repositories. Almost every category specifically defined in EU financial services law is included.

No general size-cap exemption

This is a fundamental difference from NIS2. Where NIS2 exempts entities below 50 employees and €10M turnover by default, DORA generally applies regardless of size. Smaller financial entities — small payment institutions, smaller investment firms, smaller crypto-asset service providers — fall within scope alongside the largest banks. DORA does contain a proportionality principle: the regulation explicitly requires obligations to be applied in a simplified manner to certain microenterprises and smaller institutions, but the substantive obligations apply.

ICT third-party service providers as a separate category

ICT third-party service providers serving financial entities are addressed differently. They are not direct subjects of DORA's risk management or incident reporting obligations. Instead, they are reached indirectly through Chapter V's contractual requirements imposed on financial entities, and directly — for the largest providers — through the oversight framework for Critical ICT Third-Party Providers (CTPPs). The 19 CTPPs designated in November 2025 are now subject to direct EU oversight through Joint Examination Teams and pay an oversight fee.

Geographic reach and extraterritorial effect

DORA applies to financial entities established in the Union. ICT third-party service providers established outside the Union but serving in-scope EU financial entities are reached contractually through Chapter V requirements — the financial entity must impose DORA-compliant terms on the third party, regardless of where the third party is established. This has effectively pushed DORA-equivalent obligations into the standard contract terms of major global cloud providers, software vendors, and outsourcing partners, even when those providers are headquartered in the United States or elsewhere outside the EU.

The five pillars of DORA at a glance

DORA is conventionally described as resting on five pillars, corresponding to its main substantive chapters. Understanding the five pillars and how they interlock provides the framework for the rest of this guide.

Pillar 1: ICT risk management (Articles 5–16)

Financial entities must implement a comprehensive ICT risk management framework, with responsibility resting at the management body level. The framework must cover identification, protection, detection, response, recovery, and continuous learning. Article 6 lists the components: governance arrangements, ICT business continuity policy, response and recovery procedures, and learning and evolving mechanisms. The framework must be reviewed at least annually and updated after significant ICT-related incidents.

Pillar 2: ICT-related incident management, classification and reporting (Articles 17–23)

Articles 17 to 23 establish how financial entities must detect, classify, manage, and report ICT-related incidents. The reporting obligations under Article 19 — and the tight three-stage timeline they impose — are the most operationally demanding component of DORA for incident response teams. This pillar is the focus of much of this guide.

Pillar 3: Digital operational resilience testing (Articles 24–27)

Financial entities must regularly test their digital operational resilience, with the testing programme proportionate to size and risk. Article 25 specifies basic testing requirements applicable to all in-scope entities; Article 26 introduces threat-led penetration testing for significant financial entities, based on the TIBER-EU framework, conducted at least every three years on live production systems.

Pillar 4: Management of ICT third-party risk (Articles 28–44)

Chapter V addresses third-party risk, which the regulator views as the principal vector for systemic disruption in modern financial services. The chapter includes obligations on contractual terms, supplier due diligence, the Register of Information, subcontracting controls, and — most distinctively — the oversight framework for Critical ICT Third-Party Providers. This is where the regulation's most novel structural innovations sit.

Pillar 5: Information sharing arrangements (Article 45)

Article 45 encourages financial entities to participate in information sharing arrangements concerning cyber threat information and intelligence. Participation is voluntary, but the regulation establishes a permissive legal framework — including, importantly, clarifying that information sharing within the framework's parameters does not constitute a breach of confidentiality or data protection obligations. The pillar is operationally lighter than the others but legally enabling.

ICT risk management framework (Articles 5–16)

Chapter II of DORA, comprising Articles 5 to 16, establishes the ICT risk management framework that every in-scope financial entity must implement and maintain. The framework is the foundation on which the incident response, testing, and third-party risk pillars rest. Where the framework is weak, the dependent obligations cannot be discharged credibly during inspection.

Management body responsibility (Article 5)

Article 5 places ultimate responsibility for the ICT risk management framework on the management body — board of directors or equivalent. The management body must define and approve the framework, oversee its implementation, and ensure adequate budget and human resources. Members of the management body must maintain sufficient knowledge and skills to understand and assess ICT risk; this is a substantive obligation, not a formal one, and the regulator can demand evidence of board-level training and active engagement.

Comprehensive ICT risk management framework (Article 6)

Article 6 specifies the components: a documented framework approved by the management body, organisational arrangements with clear roles and responsibilities, business continuity policy, response and recovery procedures, learning mechanisms, and the protection of ICT assets across their lifecycle. The framework must be proportionate to the entity's size, nature, complexity, and risk profile — but the substantive elements are mandatory. Proportionality affects intensity, not coverage.

Identification, protection, detection, response, recovery (Articles 7–13)

Articles 7 through 13 elaborate the functional capabilities. Identification covers ICT systems, classification of information assets, and identification of ICT-supported business functions. Protection covers security policies, identity and access management, encryption, and operations security. Detection covers monitoring, anomaly detection, and alerting. Response and recovery cover business continuity, response procedures, and crisis communication. Learning covers post-incident reviews, root-cause analysis, and continuous improvement.

Crisis communication plan (Article 14)

Article 14 requires entities to have a crisis communication plan covering internal staff, clients, financial counterparts, the public, and supervisory authorities. The plan must address how communication will be coordinated when an incident occurs across multiple stakeholder groups — for which forensic evidence becomes essential, both as input to the communications and as a defensive record in case communications are later questioned by clients, counterparties, or regulators.

Annual review (Article 6(5))

The framework must be reviewed at least annually and updated whenever significant ICT-related incidents occur, when supervisory instructions arise, or when significant changes to the entity's ICT environment take place. The annual review is itself documented and demonstrable; it forms part of the audit trail that supervisory authorities examine during inspections, and gaps in the review history have become a recurring point of supervisory feedback in the early enforcement phase.

Article 19: the three-stage reporting timeline

Article 19 is the operational heart of DORA for incident response. It establishes a three-stage reporting cascade triggered when an ICT-related incident is classified as major — and the timelines are noticeably tighter than NIS2's equivalent obligations. The detailed timelines and content requirements are specified in Commission Delegated Regulation (EU) 2025/301 of 23 October 2024, with templates and procedures specified in Commission Implementing Regulation (EU) 2025/302.

Stage 1 — initial notification: 4 hours from classification, max 24 hours from detection

The initial notification must reach the competent authority within 4 hours of the moment the financial entity classifies the incident as major. The classification itself must occur as soon as reasonably practicable after detection, and in any event within 24 hours of detection. The combined effect: from detection to initial notification, the maximum permissible elapsed time is 28 hours — but in practice, regulators expect the chain to compress to a matter of hours, not days. Withholding notification because investigation is incomplete is explicitly not compliant; the initial notification is intended to provide early awareness, not a complete analysis.

Stage 2 — intermediate report: 72 hours from initial notification

Within 72 hours of the initial notification, the financial entity must submit an intermediate report providing a substantively richer description of the incident, including current status, refined classification, impact assessment, and any further information requested by the competent authority. Where the incident remains active or where root-cause analysis is incomplete, the intermediate report explicitly acknowledges this and outlines next steps. The 72 hours run from the initial notification, not from detection — a critical distinction from GDPR.

Stage 3 — final report: no later than one month after the intermediate report

No later than one month after the intermediate report, the financial entity submits the final report. This contains a comprehensive description of the incident, its root cause, the technical and operational details, the impact (including financial loss and number of affected clients), the remedial actions taken, the lessons learned, and the planned improvements. The final report is the document that supervisory authorities return to during subsequent inspections and audits — its quality determines how the incident is remembered in the regulatory record.

Voluntary notification of significant cyber threats (Article 19(2))

Article 19(2) permits — but does not require — financial entities to notify significant cyber threats voluntarily. The voluntary notification regime allows entities to share threat intelligence even where no incident has materialised, helping the broader financial sector prepare. Member States may extend voluntary notification routing to NIS2 CSIRTs as well. While voluntary, these notifications are part of the regulator's view of the entity's ICT risk maturity and engagement posture.

Client notification obligation (Article 19(3))

Where a major ICT-related incident has an impact on the financial interests of clients, the financial entity must — without undue delay, as soon as it becomes aware — inform clients about the incident and the measures taken to mitigate adverse effects. Client notifications are part of the public evidentiary record; once published, they constrain how the entity can later characterise the incident in regulatory submissions or in litigation. Forensic capture of the client notifications themselves — including the version published, the timestamp, and any subsequent updates — becomes part of the defensive record.

Major incident classification: the seven criteria

Only major ICT-related incidents trigger Article 19's reporting obligations. The threshold is defined by Commission Delegated Regulation (EU) 2024/1772, which specifies seven classification criteria and the materiality thresholds for each. Understanding the criteria precisely is essential — an incorrect classification is itself a compliance failure, and over-reporting is not penalised whereas under-reporting carries direct administrative consequences.

The seven classification criteria

The seven criteria are: criticality of the services affected; number and relevance of affected clients, financial counterparts, and transactions; reputational impact; duration and service downtime; geographical spread; data losses; and economic impact. Each criterion has its own materiality threshold, and the classification logic combines them through a dual-trigger structure rather than treating any single criterion as decisive.

The dual trigger: critical services + data loss OR two thresholds

An ICT-related incident is classified as major when critical or important services have been impaired, and either the materiality threshold for data losses has been reached — meaning any successful, malicious, and unauthorised access to network and information systems resulting in data loss — or at least two of the other materiality thresholds have been exceeded. The dual-trigger logic ensures that severe single-criterion incidents (especially data losses) are captured alongside multi-faceted disruptions that may not individually breach any single ceiling.

Quantitative materiality thresholds

Several thresholds are quantitative. The number of affected financial counterparts must exceed 30% of all financial counterparts using the affected service. The number of affected transactions must exceed 10% of the daily average number, or 10% of the daily average value, of transactions related to the service. Other thresholds are qualitative, including reputational impact assessed against factors such as mainstream media coverage, regulatory scrutiny escalation, and material customer churn risk.

Successful malicious unauthorised access as automatic trigger

As with NIS2's Commission Implementing Regulation 2024/2690, DORA's classification rules treat successful malicious unauthorised access as an automatic significance indicator. Where an attacker has gained access to network and information systems with apparent malicious intent, and the access has resulted in or may result in data loss, the incident is major irrespective of the other thresholds. This removes the debate during the first hours of response: if an intruder is confirmed and the access is suspicious, the four-hour clock starts.

Recurring incidents and aggregate assessment

A series of smaller incidents can collectively meet the major threshold even if no individual event would. The classification regulation requires entities to assess recurring incidents in aggregate, particularly where the same root cause produces multiple distinct events. Documenting the link between incidents is itself an evidence challenge — requiring consistent log retention, forensic capture of recurring web-facing attack artefacts, and a documented analytical chain connecting the events across what may be weeks or months.

Why evidence preservation equals DORA compliance

DORA's four-hour initial notification window changes the operational calculus for incident response in a way that few first-year DORA-regulated entities have fully internalised. Where NIS2's 24-hour early warning permits some triage time, DORA expects the initial notification to be submitted with whatever information is available — and refined later in the intermediate and final reports. This means the evidence supporting the eventual final report has to be captured during the first hours of the incident, when teams are simultaneously containing the attack, restoring services, and notifying authorities. The window for capability building closes the moment detection occurs.

Commission Delegated Regulation (EU) 2025/301, which specifies the content of the initial and subsequent notifications, requires the initial report to include — where available — information on whether the incident involves malicious activity, the immediate impact on services, the geographic spread, and the affected financial counterparts. By the intermediate report, this content must be refined and expanded. By the final report, root-cause analysis, technical details of the attack, and lessons learned must all be documented. None of these are achievable without forensic evidence preserved from the moment of detection.

The most operationally vulnerable evidence category for financial entities is web-facing attack infrastructure. Phishing pages impersonating retail banking interfaces, fake payment authorisation portals, fraudulent KYC document submission pages, lookalike investment platforms, and brand-impersonation campaigns on social media are all designed to harvest financial credentials, payment data, or onboarding documentation. Each of these is hosted on infrastructure the financial entity does not control. Hosting providers take phishing pages down within hours of notification. Attackers abandon infrastructure that has been detected. By the time the intermediate report is due 72 hours later, the evidence is gone unless it was captured during the first hours.

This is the operational gap that forensic web evidence platforms such as GetProofAnchor are designed to fill. A capture made at the moment of incident detection produces a tamper-evident package — full HTML, rendered screenshot, extracted content, network metadata, and where applicable the TLS certificate chain — bound together by a qualified electronic timestamp under eIDAS Article 42 and anchored independently into the Bitcoin blockchain via OpenTimestamps. When the national competent authority asks two weeks later for proof that the phishing page existed and operated against the bank's customers, the evidence is available with mathematical integrity rather than reconstructed memory.

The point is not that every DORA entity needs to adopt one specific tool. The point is that evidence preservation during the first hours of an incident is a first-class compliance obligation under DORA — and that financial entities which have not built this capability before an incident happens will discover, during the four-hour clock, that the absence of preserved evidence becomes its own reportable failure. The intermediate report is due 72 hours after the initial notification. The final report is due one month later. The evidence supporting both has to be intact, and it has to be defensible to a supervisor.

Capturing financial-sector ICT incident evidence forensically

Financial sector ICT incidents leave their primary forensic trail in distinctive patterns. Understanding the specific evidence categories that recur in DORA-major incidents — and how to capture them in a way that satisfies competent authority expectations — is one of the highest-leverage operational capabilities a financial entity can develop in 2026. The following five categories cover the bulk of web-facing forensic evidence in DORA incidents.

Phishing pages impersonating retail banking interfaces

Retail banking phishing pages are the most common single attack vector against bank customers, and they are also the most evidentially fragile. A phishing operator stands up the page on a lookalike domain, runs the campaign for hours or days, and abandons or migrates the infrastructure once the page is reported. Forensic capture must include the full HTML, the visual rendering across desktop and mobile viewports, the TLS chain showing the lookalike domain's certificate (often a free Let's Encrypt certificate, which is itself evidentially relevant), and the network captures showing the credential exfiltration endpoint. The supervisory authority will want the underlying DOM and the network identity of the malicious infrastructure, not a screenshot.

Fake payment authorisation and confirmation pages

A more sophisticated variant intercepts the payment authentication flow — typically by presenting a fake 3-D Secure or PSD2 strong customer authentication page during what appears to be a legitimate transaction. These pages exist to capture one-time passcodes alongside primary credentials. The evidentiary value lies in showing the precise visual mimicry, the network calls capturing the OTP, and the redirection logic. Capture must occur during the live operation of the campaign; after the page is taken down, the forensic trail consists exclusively of whatever was captured at the time, and the bank's defensive position depends on that capture's quality.

Brand-impersonating investment platforms and crypto exchanges

A growing share of DORA-significant incidents in 2025 and 2026 has involved fake investment platforms and lookalike crypto-asset service provider interfaces. These typically combine domain impersonation with substantial multi-page mimicry — fake account dashboards, fake transaction histories, fake deposit interfaces. Forensic capture must walk through the full user journey of the impersonation, ideally capturing each page of the attacker's interface alongside the network state at the time of capture. The resulting evidence package supports both DORA reporting and subsequent law-enforcement engagement under national criminal procedure law.

Fake KYC and onboarding document submission portals

Some attacker campaigns target customer onboarding rather than active accounts. Fake KYC portals harvest identity documents — passports, driving licences, proof of address — which are then resold or used in subsequent fraud. From the financial entity's perspective, evidence of these campaigns is relevant both for DORA incident reporting and for GDPR Article 33 personal data breach notifications. A single forensic capture supports both regulatory tracks, provided it is constructed with the integrity primitives both regulators expect.

Critical ICT third-party provider outage and incident evidence

When a designated Critical ICT Third-Party Provider experiences an outage that affects a financial entity's services, the financial entity must capture evidence of the third-party state at the time of the incident. This is genuinely novel evidentiary territory under DORA — the entity has to document something it does not control, on infrastructure operated by a CTPP under direct ESAs oversight. Forensic capture of the CTPP's status page, the entity's own service degradation telemetry, and any public statements the CTPP issued during the incident becomes the foundation of the entity's DORA incident report and any subsequent recovery claim against the CTPP.

ICT third-party risk management (Chapter V)

Chapter V of DORA — Articles 28 through 44 — addresses what European supervisors view as the principal vector for systemic disruption in modern financial services: the dependency of financial entities on a small number of large ICT third-party service providers. The chapter is the most internally controversial element of DORA in industry consultations and the most operationally demanding for in-scope entities, particularly those that have outsourced substantial portions of their technology stack over the past decade.

Article 28 establishes the general principle: financial entities remain fully responsible for compliance with all their obligations under DORA, regardless of the extent to which they rely on ICT third-party service providers. This non-delegation principle is the foundation of the third-party regime — the regulator cannot pursue the third party for the entity's failures, but the entity cannot escape responsibility by pointing to the third party. The contractual chain has to bring the third party's behaviour within the entity's control through specific, enforceable mechanisms.

Article 30 specifies mandatory contractual provisions for ICT third-party services supporting critical or important functions. The contracts must include — among other items — a complete description of services, locations where services are provided and where data is processed, service level requirements, ICT security and resilience requirements, the entity's audit rights, termination rights including exit strategies, cooperation with competent authorities, and incident notification obligations from the third party to the financial entity. Commission Delegated Regulation (EU) 2025/532 of 24 March 2025 specifies the elements financial entities must determine and assess when subcontracting ICT services supporting critical or important functions.

The Register of Information — required under Article 28(3) and specified in implementing technical standards — is the centralised inventory financial entities must maintain of all their contractual arrangements with ICT third-party service providers, including subcontractors. The 2026 reporting cycle covers arrangements with reference date 31 December 2025, with national submission deadlines varying by Member State. The ESAs' 2024 dry-run exercise found that only 6.5% of nearly 1,000 firms across the EU successfully passed all 116 data quality checks — illustrating the scale of the operational adjustment still required for full compliance with even the documentary obligations of Chapter V.

Critical ICT third-party providers: the November 2025 designations

On 18 November 2025, the European Supervisory Authorities — EBA, EIOPA, and ESMA — published the first official list of 19 designated Critical ICT Third-Party Providers under DORA. The designation places these providers under direct EU oversight for the first time, separate from and additional to whatever sectoral regulation already applies. The 19 designated CTPPs include the dominant hyperscale cloud providers (AWS, Microsoft Azure, Google Cloud), key financial data and platform providers (Bloomberg, the London Stock Exchange Group, IBM), and other major service providers serving the EU financial sector (Tata Consultancy Services, Orange).

The designation framework operates through criteria set out in Article 31 and elaborated in delegated acts. CTPPs are designated based on systemic importance — measured against the number and significance of in-scope financial entities relying on them, the irreplaceability of their services, and the consequences of their failure. Designation triggers direct oversight by Joint Examination Teams coordinated by the relevant lead overseer, an oversight fee paid by the CTPP, and a range of supervisory powers including investigation, on-site inspection, and binding recommendations.

For financial entities, the practical implications of CTPP designation are substantial. Reliance on a designated CTPP must be documented explicitly in the Register of Information. Concentration risk — the risk that the financial entity is excessively dependent on one CTPP or on a small group of CTPPs operating in correlated ways — must be assessed and managed. Exit strategies must be credible: contracts must permit transition to an alternative provider in a manageable timeframe, even where the practical reality is that no fully equivalent alternative exists.

Joint Examination Teams have started oversight activities during the first quarter of 2026. The CTPPs themselves are now operating under direct EU-level supervisory engagement for the first time, in addition to whatever sectoral regulation — often in the United States, where most of the designated entities are headquartered — already applies. The interplay between EU oversight and home-country regulation is itself a developing area of practice that will shape DORA's enforcement reality over the coming years.

For incident response specifically, CTPP designation creates a new evidentiary dimension. When a designated CTPP experiences an incident affecting a financial entity's services, the financial entity's DORA report will need to coordinate with the CTPP's own incident response, with the Joint Examination Team's oversight engagement, and with any parallel regulatory enquiries. Forensic capture of the CTPP's external state during the incident — public status pages, incident communications, partial service evidence — becomes a critical piece of the financial entity's defensive record, particularly where contract negotiations or service-credit claims subsequently arise.

Threat-led penetration testing (Article 26) and TIBER-EU

Article 26 of DORA introduces a substantively new operational testing obligation for significant financial entities: threat-led penetration testing, or TLPT. The framework is based on TIBER-EU — the Threat Intelligence-Based Ethical Red Teaming framework developed by the European Central Bank — and represents a step-change from conventional penetration testing in scope, intensity, and regulatory engagement.

TLPT is required for financial entities identified as significant by the competent authority. The list is not public, but the criteria are based on the entity's systemic importance, role in critical financial market infrastructures, and ICT risk profile. Once identified, the entity must conduct a TLPT exercise at least once every three years. The testing is conducted on live production systems — not isolated test environments — covering critical or important functions, and follows a structured methodology including threat intelligence preparation, red team execution, and remediation.

The testing scope must cover several critical or important functions and must include live production. This is the most operationally invasive single obligation under DORA. The competent authority is involved throughout, from scope definition to red team selection (which must include accredited testers) to outcome assessment. The competent authority can require additional testing if the initial exercise produces inadequate coverage or unsatisfactory results.

Mutual recognition across Member States is a key feature: a TLPT exercise conducted under the supervision of one Member State's competent authority is recognised by other Member States where the financial entity operates. This avoids duplicative testing for cross-border entities, while ensuring that each entity is tested under a single coordinated regime. The framework's implementation has been gradual through 2025 and 2026, with the first cycle of TLPT exercises now underway across significant financial entities.

From an evidence perspective, TLPT generates a substantial documentary trail — threat intelligence assessments, red team plans, exploitation findings, remediation plans, and post-exercise reports. The integrity of this documentation matters because TLPT findings can themselves become the basis for supervisory action where critical or important functions are shown to be inadequately protected. Maintaining this audit trail with the same evidentiary integrity expected for incident reporting is part of building a coherent DORA evidence architecture.

Sanctions, personal liability, and cross-sector cooperation

DORA's sanctions framework operates at two levels: administrative penalties imposed by national competent authorities on financial entities, and the periodic penalty payments imposed by the lead overseer on Critical ICT Third-Party Providers under the oversight framework. Member States may also provide for criminal sanctions under national law where DORA breaches involve violations of national criminal law (Article 52).

Article 50 requires Member States to ensure that competent authorities have the power to impose appropriate administrative penalties and remedial measures for breaches of DORA. The specific quantitative limits are left to national transposition of the supporting Directive (EU) 2022/2556, with the result that maximum fines vary across the Union. In practice, several Member States have implemented maxima in the range of €5–10 million or 10% of total annual turnover, mirroring the scale of comparable financial-sector sanctions for governance failures.

For Critical ICT Third-Party Providers, Article 35 empowers the lead overseer to impose periodic penalty payments of up to 1% of the average daily worldwide turnover of the CTPP in the preceding business year. The periodic nature is significant: the penalty accrues daily during the period of non-compliance, creating sustained pressure to remediate rather than treating a fixed penalty as a cost of doing business. The first invocations of this power are expected during 2026 and 2027 as Joint Examination Teams' oversight engagements mature.

Personal liability for senior management is implicit rather than explicitly structured the way it is in NIS2 Article 20. DORA places ICT risk management responsibilities on the management body (Article 5) and on senior management more broadly, with the result that failures in these areas trigger fitness-and-propriety considerations under sectoral financial regulation — banking supervision, insurance supervision, securities supervision — which can include personal sanctions, management bans, and disqualifications. The mechanism is indirect but the consequences are direct.

Article 47 establishes formal cooperation between DORA competent authorities and the NIS2 architecture — the CSIRTs designated under NIS2, the EU CSIRTs network, and ENISA. The cooperation operates both ways: DORA authorities receive information from NIS2 CSIRTs about incidents potentially affecting financial entities, and they may channel DORA-reported incidents to NIS2 CSIRTs where the cross-sectoral implications warrant it. For financial entities, this means that a single incident may produce regulatory engagement across DORA, NIS2 (via the CSIRT cooperation channel), GDPR (where personal data is involved), and sectoral financial regulation — with each regulator assessing the same underlying facts independently.

DORA, NIS2 and GDPR: lex specialis and overlapping obligations

DORA operates within a regulatory cluster that includes NIS2, GDPR, the CER Directive, and sector-specific financial supervision. For a single significant ICT-related incident, a financial entity may face simultaneous obligations under three, four, or five of these frameworks. Understanding how they interlock is essential to avoiding both gaps and duplicated effort during what is already a high-pressure response phase.

DORA is lex specialis to NIS2 for financial entities. Article 4 of Directive (EU) 2022/2555 (NIS2) explicitly exempts financial entities from NIS2's risk management and incident reporting obligations, recognising DORA as the applicable framework. The exemption is not absolute — Member States may still designate financial entities as critical entities under the CER Directive, and the NIS2 CSIRT cooperation channel applies through DORA Article 47 — but the operational obligations rest in DORA. This is the cleanest cross-framework relationship in EU cybersecurity law.

GDPR Article 33, by contrast, applies in parallel without displacement. If a DORA-major ICT-related incident involves a personal data breach — and most attacks against financial entities do — the 72-hour notification to the relevant Data Protection Authority runs alongside DORA's 4-hour / 72-hour / 1-month cascade. The triggers differ (DORA: operational impact; GDPR: risk to data subjects), so a single incident can trigger both. The evidence supporting both must be preservable in a form that satisfies the strictest applicable requirements — typically meaning cryptographic hashing of artefacts, qualified electronic timestamps under eIDAS Article 42, and independent verifiability by third parties.

Forensic web evidence platforms such as GetProofAnchor are designed to produce evidence packages that satisfy all three regulators simultaneously. The Evidence ZIP — sealed with a qualified eIDAS timestamp delivered through an EU-listed qualified trust service provider, anchored independently into the Bitcoin blockchain via OpenTimestamps, and supplied with an open-source verification utility — works equally for the DORA competent authority, the NIS2 CSIRT (where the cooperation channel is invoked), and the Data Protection Authority. A single capture made at the moment of incident detection serves all subsequent reporting obligations without further work.

Beyond these three regulators, financial entities should also consider sectoral interactions. Payment Services Directive 2 (PSD2) operational and security incident reporting was largely replaced by DORA for in-scope payment institutions, but its substantive obligations have migrated into DORA's Article 19 cascade. The eIDAS Regulation governs the trust services used for evidence preservation. Sectoral financial regulation continues to operate alongside DORA. Building one coherent evidence architecture — rather than separate evidence flows for each regulator — is the operational efficiency that distinguishes well-prepared financial entities in the DORA era.

DORA incident evidence checklist (15 points)

The following checklist consolidates the operational priorities from this guide. It is not a substitute for legal advice or for the specific guidance of your national competent authority, but it captures the distinguishing characteristics of financial entities that are operationally DORA-ready as opposed to merely documentary-ready.

• Determine your DORA classification (financial entity subcategory) and document the determination with supporting references to Article 2's scope provisions and your national supervisory framework.
• Identify the competent authority and any applicable supervisory authority specific to your subcategory, and establish pre-incident communication channels including templates for the initial notification, intermediate report, and final report.
• Define internal classification criteria for major ICT-related incidents aligned with Commission Delegated Regulation (EU) 2024/1772, including the dual-trigger logic (critical services + data loss OR critical services + two thresholds), and review them at least annually.
• Ensure 24/7 detection capability so that the four-hour initial notification clock can start at the moment of classification, regardless of business hours or weekends.
• Designate a primary incident-reporting officer and at least one deputy with full authority to file initial notifications within the four-hour window without management ratification delays.
• Implement tamper-evident logging across the ICT estate with documented integrity primitives (hash chains, qualified electronic timestamps, or equivalent) and retention proportionate to sectoral expectations — typically 12 months minimum, with longer periods for specific categories.
• Establish forensic capture procedures for the web-facing attack artefacts most relevant to financial entities — phishing pages impersonating retail interfaces, fake payment authorisation pages, brand-impersonating investment platforms, fake KYC portals, and Critical ICT Third-Party Provider status during outages.
• Bind capture artefacts together through cryptographic manifests (SHA-256 over all files) and submit the manifest hash to an EU-listed qualified trust service provider for a qualified electronic timestamp under Article 42 of Regulation (EU) 910/2014.
• Anchor evidence packages independently — for example, through Bitcoin blockchain via OpenTimestamps — so that integrity can be verified without reliance on the entity, the trust service provider, or any single point of failure.
• Document chain of custody in line with ISO/IEC 27037:2012 phases (identification, collection, acquisition, preservation) for each evidence item, with roles, timestamps, and actions recorded.
• Maintain a current Register of Information for all ICT third-party arrangements supporting critical or important functions, with subcontractor mapping aligned with Commission Delegated Regulation (EU) 2025/532, ready for submission at the national reporting cycle.
• Identify your reliance on each of the 19 designated Critical ICT Third-Party Providers (as of November 2025), assess concentration risk, and document exit strategies as required by Article 28.
• Conduct or schedule the threat-led penetration testing exercise under Article 26 if you are a significant financial entity, with the exercise plan agreed with the competent authority and documented evidence preservation for the test itself.
• Map the overlap between DORA and other applicable regulations (NIS2 cooperation channel via Article 47, GDPR Article 33, PSD2 transition, sectoral financial regulation) so that a single incident produces coordinated notifications across all applicable regimes, supported by a single coherent evidence package.
• Make all evidence packages independently verifiable by third parties — competent authorities, the lead overseer for CTPP-related matters, courts, insurers, counsel — using open-source verification tools and without dependency on the producing entity's infrastructure.

Frequently asked questions and conclusion

The following answers address the questions that arise most often when financial entities begin operationalising DORA evidence-handling. They are intended as practical orientation, not as legal advice for any specific situation.

DORA's first year of application has confirmed what was widely anticipated during the preparation phase: the regulation is operationally demanding, the timelines are tight, and the supervisory engagement is sustained. The 2024 dry-run's 6.5% pass rate illustrated the gap between policy compliance and operational readiness. The 2026 reporting cycle, conducted under active enforcement, will produce a clearer picture of where individual entities stand.

The capabilities that distinguish operationally DORA-ready financial entities are recognisable. Detection systems that can classify incidents at speed. Reporting workflows that produce initial notifications within the four-hour window without management ratification delays. Forensic preservation of incident artefacts — particularly the web-facing attack infrastructure that disappears fastest in the hours after detection. Independent verifiability of the resulting evidence by the competent authority, the lead overseer in CTPP-related matters, and any subsequent court or insurer. None of these capabilities is exotic; what distinguishes the well-prepared entity is that all of them are in place before the first major incident.

GetProofAnchor exists to make the forensic preservation component of this stack — specifically the web-facing artefacts that disappear fastest in the moments after detection — straightforward, defensible, and independently verifiable across DORA, NIS2 cooperation, and GDPR simultaneously. If your financial entity is building its DORA evidence-handling capability and would like to see how qualified-timestamped forensic web capture integrates with the four-hour reporting workflow, the most direct way is to create a sample proof from any public URL and inspect the Evidence ZIP. Verification is open-source and runs on any laptop. The standard is reproducible because, under DORA, it has to be.