DORA and UK Operational Resilience: What They Mean for Data and AI Platforms

DORA and the UK operational resilience rules treat data and AI platforms as part of the service a customer receives, not as back-office plumbing. Firms must map which platforms each important service depends on, record third-party dependencies, plan exits from critical providers, and prove through testing that the service recovers within tolerance when a platform fails.

Most data teams first meet these regimes as a questionnaire from the resilience function. That framing undersells them. The rules ask questions the data platform is uniquely placed to answer, and uniquely likely to fail: where a number came from, how quickly a pipeline can be rebuilt, and what happens to a customer journey when a cloud region or a model API goes dark.

This article sets out what each regime requires, what that means for the engineering of a data and AI platform, and where firms are spending effort that the rules do not demand. It is an engineering reading of the rules, not legal advice; your compliance and legal teams own the interpretation for your firm.

#Why Data Platforms Are Now Inside the Resilience Perimeter

What this means for you: if a customer-facing service reads a risk score, a balance, a fraud signal or a model output, the platform that produces it is in scope, whatever your organisation chart says.

For years, operational resilience in financial services focused on payment systems, core banking and channels. Data platforms sat further back, feeding reports that could be a day late without anyone outside finance noticing. That separation has gone. Credit decisions, fraud screening, pricing, customer communications and regulatory reporting now read from the same pipelines and, increasingly, from AI services built on them.

The regulators' answer has been to define resilience by service rather than by system. The UK rules start from the important business service and work backwards to every resource it needs. DORA starts from the ICT risk underneath critical or important functions. Both routes arrive at the same place: the data platform, its cloud provider and its model dependencies.

A late report used to be an inconvenience. A late fraud signal is a customer harm with a regulator attached.

The concentration question has sharpened this. In November 2025 the European Supervisory Authorities published their first list of 19 critical ICT third-party providers under DORA, including the largest cloud platforms. In July 2026 HM Treasury made the first four designations under the UK critical third parties regime. Supervisors can now look directly at the providers on which many firms' data platforms run.

#What DORA Requires, Read for a Data Team

What this means for you: DORA turns five areas of good practice into obligations with deadlines, and three of them land squarely on the data platform.

The Digital Operational Resilience Act (Regulation (EU) 2022/2554) applied from 17 January 2025 to banks, insurers, investment firms, payment institutions and other in-scope financial entities operating in the EU. It is organised around five pillars.

The fifth pillar, information sharing, is voluntary. Above all of this sits the oversight framework for critical ICT third-party providers, which the ESAs supervise directly.

#Incident Reporting Runs on Data You May Not Have

DORA sets reporting clocks for major ICT incidents: an initial notification within four hours of classifying an incident as major and no later than 24 hours after becoming aware of it, an intermediate report within 72 hours, and a final report within a month. Classification depends on criteria such as clients affected, data losses and duration.

For a data platform, the hard part is not the form. It is knowing within hours which downstream services a failed pipeline feeds, how many customers read from it, and whether any data was corrupted rather than merely delayed. That is a data lineage question, and most estates cannot answer it at that speed.

#The Register of Information Is an Architecture Document

Every in-scope entity must keep a register of information covering its contractual arrangements with ICT third-party providers, and the first registers were due with the ESAs by 30 April 2025. Firms that built it from procurement records alone often found it incomplete: it listed the cloud contract but not the managed database, the SaaS ingestion tool, the vector store or the model API a team signed up for on a card.

The register is most useful when it is generated from the platform's own inventory rather than reconciled against it annually. If your infrastructure is defined as code, the dependency list already exists.

#What the UK Rules Require

What this means for you: the UK regime asks one question of every important service, can it stay within tolerance in a severe but plausible scenario, and your data platform must be part of the answer.

The UK rules, set out by the FCA in PS21/3 and the PRA in SS1/21, took effect on 31 March 2022 with a transition period. By 31 March 2025, firms had to be able to remain within their impact tolerances for each important business service. The obligation is now continuous rather than a project with an end date.

Three concepts carry the regime. An important business service is one whose disruption could cause intolerable harm to consumers or market integrity, or threaten the firm's safety and soundness. An impact tolerance is the maximum tolerable disruption, usually expressed as time. Mapping identifies the people, processes, technology, facilities and information each service relies on.

Information is named explicitly in that list, and it is where data platforms most often go missing from the map. A payments service map that stops at the payments engine, and omits the sanctions screening data feed or the fraud model's feature pipeline, will pass a desk review and fail a real outage.

The UK also has its own critical third parties regime, created by the Financial Services and Markets Act 2023, with rules in force from 1 January 2025. It binds a provider only once HM Treasury designates it, and the first designations took effect in July 2026. Designation brings the provider under direct oversight; it does not remove any responsibility from the firm that uses it.

#Cloud Concentration and Credible Exit Plans

What this means for you: an exit plan that has never been rehearsed is an assumption, and supervisors increasingly expect evidence rather than assumptions.

DORA requires exit strategies for ICT services that support critical or important functions, and the UK regime expects firms to manage the risks of outsourcing and third-party dependencies, including how they would continue a service if a provider failed. For data platforms, this is where the conversation usually becomes uncomfortable.

A credible exit is not a plan to migrate the whole platform to another cloud in a weekend. It is a statement of how each important service would continue, at reduced capability if necessary, while the primary platform is unavailable, and how the firm would move away over a longer period if the relationship ended.

Open table formats have materially improved the economics of exit. If curated data sits as Apache Iceberg or Delta tables in storage the firm controls, the most expensive part of leaving a platform is already done; our Snowflake versus Databricks guide explains why the catalogue decision matters as much as the format. The cloud platform design and the exit plan should be written together, not by different teams a year apart.

#AI Services Are Third-Party Dependencies Too

What this means for you: a model API that a customer journey depends on is an ICT third-party service, with the same register, testing and exit questions as a database.

Generative and predictive AI services have entered customer journeys faster than resilience frameworks have absorbed them. A complaints-handling assistant, a document extraction service in onboarding, or a fraud model served from a managed endpoint can all sit on the critical path of an important service.

Three questions expose most of the gaps. Is the model service in the register of information, with its underlying provider named? What does the journey do when the model is unavailable, slow or returning degraded answers? And can the firm reconstruct what the model saw and returned for a given customer, during and after an incident?

If a journey cannot run without the model, the model has quietly become a critical dependency nobody chose.

The answers belong in the resilience programme, while the governance of model behaviour, approvals and evidence belongs in the AI operating model set out in our article on GenAI governance under the EU AI Act. The security controls around retrieval, masking and access are covered in our guide to securing enterprise RAG. Resilience asks a narrower question: when the AI service fails, does the business service stay within tolerance?

#Recovery Testing That Proves Something

What this means for you: a backup that has never been restored into a working service is not a recovery capability, and scenario tests should prove the service, not the infrastructure.

Both regimes expect testing against severe but plausible scenarios. For data platforms, useful scenarios are specific: the loss of a cloud region hosting the warehouse, a corrupted batch propagated to downstream services, a compromised credential in a pipeline, the unavailability of a SaaS ingestion tool, or a model endpoint returning errors.

#Test Restore Points, Not Just Restores

Corruption is the scenario most data platforms are worst at. Restoring yesterday's tables is straightforward; knowing which restore point predates the corruption, which downstream tables inherited it, and how to replay changes since then is not. Change data capture streams and immutable raw layers make replay feasible, but only if someone has rehearsed it.

#Make Detection Part of the Test

A recovery test that starts at the moment someone declares an incident hides the most dangerous interval. Measure time to detect as well as time to recover, using the same data observability signals that would fire in production: freshness, volume, schema and distribution checks on the datasets that feed important services.

#Where Firms Over-Engineer Resilience

What this means for you: the rules ask for proportionate, evidenced resilience for important services, not maximum resilience for everything.

The most common waste is applying the same recovery target to every dataset. Most of a data estate supports internal analysis that can tolerate days of disruption. Active-active multi-cloud architecture for a monthly management dashboard spends money the regulations do not ask for and diverts engineers from the handful of datasets that matter.

The second is treating multi-cloud as the default answer to concentration risk. Running warm standby on a second provider doubles the operating model, the skills requirement and the security surface. For many services, a rehearsed degraded mode and data held in open formats deliver a credible position at a fraction of the cost. Multi-cloud is justified where the tolerance is short and no manual fallback exists, and rarely elsewhere.

The third is buying a resilience tool before the mapping exists. A tool can store a map; it cannot tell you which datasets a fraud model reads. That knowledge sits with the engineers who built the pipelines, and the mapping work has to start with them. Smaller firms in particular should note that DORA includes proportionality and a simplified framework for some entities, so the right scale of programme depends on size and risk profile.

#Where to Start

What this means for you: begin with one important service and make its data dependencies provable; the rest of the programme reuses the method.

1. Select one important business service with a data or AI dependency on its critical path, such as payments with fraud screening or onboarding with document extraction.
2. Map it to named datasets and services, using lineage from the platform rather than interviews alone, and record every third-party provider underneath, including model APIs.
3. Set data-level recovery objectives derived from the service's impact tolerance: maximum staleness, restore point and rebuild time for each critical dataset.
4. Rehearse one severe but plausible scenario, including detection, and record the evidence: timings, decisions, gaps.
5. Generate the register and the map from the platform, so that infrastructure-as-code, the data catalogue and the resilience register stay consistent as the estate changes.

The engineering behind those steps is security and compliance architecture work as much as resilience work, because lineage, access control and evidence are shared foundations. Done once properly, the same enterprise data architecture answers the resilience team, the AI governance board and the auditors from one source.

#Frequently Asked Questions

#Does DORA apply to UK financial firms?

DORA is an EU regulation, so it applies to in-scope financial entities operating in the EU, including EU subsidiaries of UK groups. UK firms without EU entities follow the UK operational resilience rules from the FCA and PRA and the UK critical third parties regime instead. Groups operating in both markets typically run one programme that satisfies both regimes, mapping each requirement to shared controls and evidence.

#Are data platforms in scope of operational resilience rules?

Yes, wherever an important business service or a critical or important function depends on them. The UK rules require firms to map the information and technology each important business service relies on, and DORA covers ICT systems supporting critical or important functions. A data platform that feeds fraud screening, credit decisions or regulatory reporting therefore needs mapping, recovery objectives and testing.

#What is an impact tolerance?

An impact tolerance is the maximum tolerable level of disruption to an important business service, usually expressed as a length of time, set by a UK firm under the FCA and PRA operational resilience rules. Firms had to be able to remain within their impact tolerances in severe but plausible scenarios by 31 March 2025, and must continue to evidence it through mapping and testing.

#Do we need multi-cloud to meet DORA or UK resilience rules?

Neither regime mandates multi-cloud. Both require firms to manage concentration and third-party risk, plan exits from critical providers, and show that important services can recover within tolerance. Multi-region designs, data held in open formats, documented degraded modes and contractual exit support can provide a credible position. A warm standby on a second provider suits services with short tolerances and no manual fallback.

#Are AI and model APIs covered by DORA?

An AI service delivered by an external provider is an ICT service, so where it supports a critical or important function it belongs in the register of information, the third-party risk assessment and the exit strategy. Firms should also define what the business journey does when the model is unavailable, and keep enough records to reconstruct model inputs and outputs during and after an incident.

Unolabs is a Data and AI first engineering consultancy, headquartered in the United Kingdom with engineering operations in Pune and active engagements across the UK, Australia, and Hong Kong. We help enterprises build the architectural foundation for autonomous AI execution — governed data platforms, semantic intelligence, and agentic systems that enterprises can stand behind.

If you are weighing how your data and AI platforms meet DORA and the UK operational resilience rules, book a discovery call and we will work through it with you.