DORA and NIS2 for Financial Services: What Your AI & Data Platform Must Do Now

Where we are (and why this hits AI/data, not just "IT risk")

The Digital Operational Resilience Act (DORA) applies to EU financial entities from 17 January 2025. It turns resilience into a hard obligation with evidence: governance of information and communication technology (ICT), incident handling, testing, and tougher oversight of critical third-party providers. Regulators expect continuity even when core services are stressed. That includes your machine learning pipelines, vector indexes, retrieval services, model endpoints, and monitoring—not only networks and laptops. (ESMA)

Alongside DORA sits NIS2, the EU-wide cybersecurity baseline for "essential" and "important" entities across 18 sectors. Member States were due to transpose NIS2 by 17 October 2024; some have, others are catching up, but the direction of travel is settled: risk management, incident reporting, supply-chain security, and accountability. If you are a bank or insurer, you already meet a higher bar under DORA; if parts of your group fall under NIS2 rather than financial-sector rules, aim for consistency so controls look the same to auditors. (Digital Strategy of the European Union)

What DORA actually asks you to prove (in plain language)

DORA does not ask for glossy "resilience strategies"; it asks whether you can withstand, respond to, and recover from disruptive events across the systems that run your business. For an AI/data platform that means: you have a clear map of services and dependencies; you can detect and classify incidents fast; you can keep customer-facing processes running or degrade gracefully; and you can show what happened afterwards—logs, timelines, fixes. Supervisors and the European Supervisory Authorities have reinforced this with technical standards on major incident reporting (think hours, not weeks, for initial notifications) and a new EU oversight regime for critical ICT providers. (European Banking Authority)

How this lands on your AI & data stack (concrete examples)

Imagine a claims triage platform that uses retrieval-augmented generation. Documents are ingested, chunked, and indexed; a retrieval service populates context; a model endpoint drafts summaries; a human approves.

When the index fails over: DORA care is not "we fixed it next sprint"; it is: the index has an RTO/RPO you can meet; failover is rehearsed; and frontline teams can continue working with reduced features.
When prompts or guardrails change: you keep a signed changelog of prompt templates, retrieval filters, and model versions so you can reconstruct behaviour later.
When the upstream provider breaks: you know whether that provider is "critical," you have exit options, and your contracts give you the logs/support needed for incident reporting.

The same applies to data science: feature stores, training jobs, batch scoring, event streams. If a broken job pushes corrupt features into fraud controls, DORA is the reason you can explain how quickly you detected it, how you limited blast radius, and how you proved it is fixed. (ESMA)

NIS2 in the background (why you still have to care)

NIS2 requires broadly similar outcomes—risk management, incident handling, business continuity, supply-chain security, and technical measures such as access control and logging—implemented through national laws. Even where transposition has been patchy, the Commission has pressed Member States to close the gap. If any part of your organisation is in scope for NIS2 rather than DORA (for example, shared services or non-regulated subsidiaries), align to the stricter standard and use one set of playbooks, not two. It simplifies audits and avoids "scope bingo." (Digital Strategy of the European Union)

Incident reporting (the bit everyone worries about)

Under DORA, "major ICT-related incidents" must be reported to competent authorities on tight timelines. Draft Regulatory Technical Standards from the European Banking Authority and its sister authorities set expectations like an initial notice within hours (for example, four hours after classification and within 24 hours of detection), followed by interim and final reports. These are aligned with NIS2 so you are not writing two different stories about the same outage. The practical takeaway: decide now who classifies incidents, what evidence they capture in the first hour, and how you consolidate logs from model endpoints, retrieval layers, and data stores. (European Banking Authority)

What "good" looks like without boiling the ocean

Start with the services that keep customers and regulators awake: onboarding, payments, claims, underwriting, collections. For each:

Name the services and suppliers: vector database, object store, retrieval API, model endpoint, monitoring, feature store; mark what is "critical."
Write the one-page playbook: who declares an incident, who talks to the regulator, how to fail over the index, how to roll back prompts, where to find the logs.
Rehearse once: table-top the worst morning you can imagine (index corruption, model outage, bad data in the feature store). Capture timings and fix the gaps.

You do not need to rebuild your platform to satisfy DORA; you need to make the operating model legible and prove you can keep going under stress. That is the spirit of the law. (Skadden)

Third-party risk (and why AI teams must be at the table)

DORA introduces EU-level oversight for critical third-party ICT providers. Even where your vendor won't be designated "critical," you still owe robust due diligence: data residency and access, log availability, incident support, performance under load, exit strategy. For AI-heavy stacks, add questions about prompt/response logging, evaluation harnesses, red-team support, and model rollback. Do this when you sign, not when you are in the middle of an outage. (European Banking Authority)

A month-one plan that works in real organisations

Week 1: inventory the services and suppliers behind two high-impact journeys (e.g., First Notice of Loss and payments). Week 2: write the playbooks, define incident thresholds, and wire the "first hour" evidence kit (timestamps, model version, prompt template hash, retrieval corpus ID). Week 3: test failover for the index and storage; run a short cyber exercise; fix what breaks. Week 4: brief the approval forum; agree the onward schedule (quarterly test, annual supplier review, and a single cross-standard report for DORA/NIS2).

That gets you to something you can show a supervisor: names, runbooks, and proof you have rehearsed the failure modes that matter. (ESMA)

Need help making DORA and NIS2 real?

We can work with your platform, security, and risk teams to produce the inventories, one-page playbooks, incident evidence kit, and a rehearsal you can run each quarter—plus vendor due-diligence questions that make sense for retrieval-augmented generation and model endpoints.

Book a free consultation

Sources

ESMA / EIOPA / EBA on DORA: regulation in force; application from 17 January 2025; scope includes ICT risk management, incident reporting, testing, and critical third-party oversight. (ESMA)
EBA draft RTS on major incident reporting: proposes tight timelines for initial, interim and final reports; aligned with NIS2. (European Banking Authority)
EUR-Lex (Regulation (EU) 2022/2554): the legal text for DORA. (EUR-Lex)
European Commission digital-strategy page for NIS2: scope, sectors, and obligations; national transposition. (Digital Strategy of the European Union)
Transposition status: Commission opened infringement procedures where Member States missed the 17 Oct 2024 deadline; implementation remains uneven. (ECSO)
Legal and practitioner briefings summarising entity expectations under DORA (incident management, testing, third-party risk). (Skadden)