DORA Compliance as Data Plumbing: Why Cloud Sovereignty Became Infrastructure

The Digital Operational Resilience Act has been in force for over sixteen months. The first mandatory Register of Information submission cycle closed on 31 March 2026, with the ESA correction window running through 30 April. What the first full cycle exposed is not a reporting failure. It is an architectural one.

DORA does not use the language of engineering. It speaks the language of risk and resilience. But its operational requirement, the ability to exit an ICT third-party arrangement cleanly for critical or important functions, is a data infrastructure requirement in everything but name. The firms that can execute that exit on a regulator-credible timeline are the firms that built their stack with portability as a design property. The firms that cannot will spend the next two years rebuilding underneath running services.

What Article 28(8) Actually Requires

The statutory anchor is not Article 30, which sets contract clauses. It is Article 28(8), which requires that financial entities put in place exit strategies for any ICT services supporting critical or important functions. Those strategies must be comprehensive, documented, tested, and reviewed periodically. They must let the firm exit without disrupting business activities, without limiting compliance with regulatory requirements, and without prejudicing service continuity and quality.

DORA itself does not specify a numerical exit timeline. What it specifies is harder. The exit has to be executable, on demand, with the data intact and the regulatory file unbroken. National supervisors and the ESAs have, in practice, anchored their expectations around the kind of six-month transition window that prior EBA outsourcing guidelines treated as a working benchmark. The number is a guideline, not a statute. The obligation behind it is binding.

For a firm running KYC case files, transaction monitoring outputs, and beneficial ownership evidence on a single hyperscaler, that requirement is not satisfied by a contract clause. It is satisfied or not satisfied by the architecture underneath.

Why Portability Is Now a Compliance Property, Not an Engineering Preference

Before DORA, cloud provider risk was framed operationally. Uptime, disaster recovery, security certifications. DORA reframed it as systemic. The question is no longer whether the provider stays up. The question is whether the financial entity survives if the relationship has to terminate on supervisory timelines.

This reframing has downstream consequences that most procurement and ICT teams are still catching up to. A firm cannot meaningfully depend on proprietary cloud features it cannot port elsewhere. It cannot store compliance evidence in provider-specific schemas it cannot extract without rebuilding the audit trail. It cannot accept switching costs that would take longer than the supervisor's tolerance to absorb.

The first list of 19 designated Critical ICT Third-Party Providers, published by the ESAs on 18 November 2025, made the concentration question concrete. AWS, Microsoft Azure, Google Cloud, IBM, Oracle, and SAP are now under direct ESA oversight. Any financial entity that depends on a designated CTPP for a critical function is now expected to document that dependency in its Register of Information and assess concentration risk against it. The supervisor is not asking whether the provider is good. The supervisor is asking what the firm does if the provider becomes unavailable, ineligible, or non-compliant with its own oversight obligations.

The Standards Convergence That Makes Portability Possible

DORA did not create the technical movement toward standardised, non-proprietary interfaces. It did make that movement non-negotiable for regulated financial services.

Three threads are visible. First, ISO 20022, the global messaging standard developed under ISO and operationalised across the financial sector by SWIFT, the European Central Bank, and the Federal Reserve. The SWIFT cross-border coexistence period ended on 22 November 2025, after which ISO 20022 became the sole standard for in-scope payment instructions. The ECB completed its TARGET2 migration in 2023. The Federal Reserve completed Fedwire on 14 July 2025. Payments infrastructure is now a single data language.

Second, open banking and personal financial data portability, most visibly in the EU's PSD2 and PSD3 framework and, until recently, in the CFPB's Section 1033 Personal Financial Data Rights rule (finalised October 2024, currently stayed pending reconsideration following litigation in the Eastern District of Kentucky). Where the rules survive, they all converge on the same principle: financial data must flow through documented, standardised, non-proprietary interfaces under consumer or institutional control.

Third, the Financial-grade API (FAPI) profile, maintained by the OpenID Foundation and the technical baseline for the UK Open Banking implementation. FAPI is not an EU-wide mandate, but it is the de facto reference for how regulated financial data should be exchanged with third parties under strong authentication.

These threads emerged independently. They converge on a single architectural principle. Financial data and service requests should be carryable across providers without rebuilding the underlying contract.

For firms under DORA, that convergence is what makes a six-month exit even imaginable. A KYC platform built on standard messaging, standard authentication, and standard data formats can be lifted off one provider and onto another. A platform built on a provider's proprietary identity service, proprietary document store, and proprietary workflow orchestration cannot.

What This Looks Like in Practice

The architectural pattern that has emerged across DORA-compliant deployments is not a secret. It is the same pattern that broader cloud engineering has been converging on for a decade, now with regulatory pressure pushing the laggards.

The orchestration layer is Kubernetes. AWS EKS, Azure AKS, Google Cloud GKE, or a self-managed deployment all expose the same workload contract. A Kubernetes manifest that runs on one runs on the others with manageable adjustment. This is portability at the compute layer.

The environment-definition layer is Infrastructure-as-Code, most often Terraform or OpenTofu. Compute, networking, identity, and storage are described in version-controlled configuration that can target multiple providers from the same source of truth. This is portability at the definition layer.

The data layer is the hardest. The pattern is standardisation on PostgreSQL for relational workloads (available natively or through managed equivalents on every major cloud) and S3-compatible object storage for documents, evidence, and bulk artifacts. S3-compatible storage is offered by every hyperscaler, by sovereign providers like OVHcloud and Scaleway, and by self-hosted systems like MinIO. The cost is in the discipline. Provider-native data services with proprietary extensions are easier to start with, and significantly harder to leave.

None of this is exotic. The point is that under DORA, it stopped being a matter of engineering preference and became a matter of regulatory exposure.

What This Means for Management Companies, TCSPs, and Fund Administrators

For firms under CSSF or FSC supervision, the read-across is concrete. A Luxembourg management company that runs its KYC platform on a single hyperscaler's proprietary services has, by DORA's standard, an exit problem. Not because the platform is bad. Because the firm cannot demonstrate, to a supervisor, that it can move the platform off that provider inside the kind of window the supervisor considers credible.

For TCSPs (Trust and Company Service Providers), the question is sharper still. The data that matters under AMLR and the AMLA supervisory cycle is the compliance evidence: beneficial ownership records, source-of-wealth documentation, sanctions screening outputs, customer due diligence files. That data has to remain auditable across a migration. If the audit trail is held in a provider-specific logging service, the migration breaks the file. The exit happens, but the regulatory record does not survive intact.

For fund administrators, the question becomes operational. A multi-jurisdictional book that runs partly on EU regions of a US hyperscaler is exposed to two things at once. The hyperscaler is now a designated CTPP under ESA oversight, which raises the bar on documented dependency assessment. And the broader sovereignty conversation, including the European Commission's Cloud Sovereignty Framework, is moving toward a world in which jurisdictional control of compliance data becomes its own supervisory question.

Three practical questions worth working through. First, can the firm produce a complete inventory of which ICT services support which critical or important functions, mapped against its Register of Information? Second, for each of those services, what is the documented, tested exit plan, and what is the estimated execution time on a realistic engineering capacity? Third, what evidence would be lost in transit if that exit had to be executed under pressure, and what would the firm submit to a CSSF or FSC examiner to demonstrate the audit chain survived?

The Competitive Angle Is Real, but Secondary

DORA compliance is not a binary checkbox. It is a spectrum, and the firms whose systems are genuinely portable will compete from a stronger position. A management company that can migrate between providers on a tested plan is a management company that negotiates provider contracts from optionality. An administrator that can adopt a new sovereign provider without rewriting its evidence chain is an administrator that can respond to client and regulator demands without betting the firm on a single vendor's continued availability.

This is not the main argument. The main argument is regulatory. The competitive advantage is what falls out when a firm builds the data infrastructure that DORA requires anyway.

The firms that treated DORA as a contract review and a policy update will face the next supervisory cycle from behind. The firms that treated it as a catalyst to rebuild compliance infrastructure on portable, standards-based, evidence-preserving foundations will face it from a position where the regulator's question and the firm's existing architecture are already aligned.

Compliance is a data infrastructure problem with a regulatory deadline on top. DORA is the version of that problem aimed at ICT third-party risk. The firms that internalise this read of the regulation will spend the next two years optimising. The firms that do not will spend them rebuilding.

If your firm is evaluating whether its DORA exit plans are credible against the architecture they would actually have to run on, we can help you assess the gap.