Cloud-native banking in 2026 is in DORA audit phase. Regulation (EU) 2022/2554 ⧉ has been in force since 17 January 2025. The critical third-party provider (CTPP) designation regime under Articles 28-44 has been opening through 2025-2026, with AWS, Microsoft (Azure), Google (GCP), and Salesforce inside or near the designation perimeter. The European Supervisory Authorities (EBA, EIOPA, ESMA) published the final RTS and ITS on the Register of Information ⧉ in 2024. The ECB Banking Supervision team has explicit programmes on cloud-disruption preparedness and threat-led penetration testing in the 2026-28 supervisory priorities ⧉. The institutional question is not whether to align cloud strategy to DORA — that's settled — but whether the institution's platform-engineering primitives produce evidence at the speed of the deployment pipeline rather than in PDFs assembled the week before the exam.
Executive Summary / Key Takeaways
- DORA cloud resilience in active enforcement since 17 January 2025. Articles 6, 8, 18, 26 and 28-44 all in force. Supervisory findings from the first exam wave landed in Q4 2025. The "preparation" framing is two cycles out of date.
- CTPP designation regime opening. AWS, Microsoft, Google, Salesforce — inside or near. Designation gives the ESAs direct oversight rights including information requests, on-site inspections, and supervisory recommendations.
- Platform engineering is the deliverable. Kubernetes paved roads (EKS / AKS / GKE / OpenShift), Backstage-style developer portal, GitOps (ArgoCD or Flux), Open Policy Agent at admission, OpenTelemetry end-to-end. Five named primitives; anything missing is a finding.
- Sovereign cloud is engineering, not branding. AWS European Sovereign Cloud, Microsoft EU Data Boundary, Bleu (Capgemini + Orange + Microsoft), Thales / S3NS, Oracle EU Sovereign Cloud — each addresses a specific Schrems II + DORA Article 28 dimension; none is a turnkey answer.
- Tested exit evidence required. EBA/GL/2019/02 paragraphs 81 and 113-117. Quarterly tabletop is insufficient; supervisors expect annual end-to-end exit-execution testing for every critical or important function.
- RTO / RPO from CIF inventory. Tier 1: 2h / 15min. Tier 2: 4h / 1h. Tier 3: 24h / 4h. Derived from business-impact analysis, not platform-team capacity.
Why DORA Cloud Resilience Is in Audit Phase #
Three reasons the "preparation" framing is wrong in 2026.
First, the timeline. DORA was published in December 2022. The 24-month application period closed on 17 January 2025. The ESAs' final RTS and ITS — including the ITS on the Register of Information used for CTPP designation — were published through 2024. The first wave of supervisory exams ran through 2025; findings on Article 6 ICT risk-management framework completeness and Article 8 register reconciliation landed in Q4 2025 across multiple tier-1 institutions.
Second, the CTPP designation regime. Article 31 sets the criteria for designation as a critical third-party provider: systemic impact in case of failure, criticality of services provided, scale and complexity of services, substitutability. The ESAs maintain the register and publish designation decisions. AWS, Microsoft (Azure), Google (GCP), and Salesforce are inside or near the designation perimeter, depending on financial-services market share by member state. Designation gives the lead overseer (one of the ESAs, allocated per provider) direct oversight authority: information requests under Article 37, on-site inspections under Article 38, recommendations under Article 35, and the public-disclosure regime under Article 41. The banks supervised over those CTPPs are subject to corresponding supervisory expectations on how they manage that designated dependency.
Third, the ECB's 2026-28 supervisory priorities. The priorities document names two explicit programmes that affect cloud-native banking directly: preparedness for major cloud-service disruption (modelled supervisory scenarios test the institution's ability to absorb a sustained outage of a designated CTPP) and TIBER-EU-aligned TLPT (every TIBER-EU exercise scopes the institution's critical and important functions, which now includes public-cloud-hosted services). The 2026 exam wave will produce findings on both.
The framing for 2026 is not "DORA is coming"; it is "DORA exam findings are arriving in your institution's mailbox, and the platform-engineering decisions you made through 2024-2025 are what the supervisor scrutinises in those findings."
The 2026 Index Architecture #
| Index Layer | What "Ready" Looks Like | Readiness Metric | Failure Mode |
|---|---|---|---|
| Platform maturity | >80% of workloads on a paved-road Kubernetes platform (EKS / AKS / GKE / OpenShift) with policy-as-code admission, GitOps deployment, automated DR testing | % of CIFs on paved-road platform; shadow-deployment count; mean time to onboard a new service to the platform | Shadow platforms with inconsistent controls; CIFs running on un-paved infrastructure invisible to the Article 8 register reconciliation |
| Article 8 register integrity | Register of Information reconciles automatically to the platform's third-party API consumption + cloud-bill-of-materials; criticality classification consistent with the institution's CIF inventory | % register entries reconciled to platform telemetry; orphan-entry count; CTPP-perimeter integrity check | ESAs identify a designated CTPP dependency the institution failed to disclose under Article 8; individual finding and CTPP-perimeter consequence |
| Cloud concentration | Critical functions mapped to cloud providers AND sub-cloud regions AND services AND substitutability assessment; cross-CIF correlated exposure quantified | Concentration score per CIF; correlated exposure across CIFs sharing a designated CTPP region | A single AWS us-east-1 IAM outage takes down four CIFs the institution thought were independently resourced |
| Tested exit capability | Annual end-to-end exit execution test for every CIF dependent on a designated CTPP; documented RTO / RPO meets BIA-derived targets; data-portability path tested | Test pass rate per CIF; mean exit-execution time vs RTO target; data-portability path latency | Exit plan that exists only as a PDF; tabletop says 4h RTO, actual test shows 48h on first attempt |
| Observability + incident reporting | OpenTelemetry traces end-to-end across services; automated Article 18 4-hour classification helper wired into the incident-management platform | % CIF traffic covered by OTel traces; mean time from incident detection to Article 18 classification decision | Major incident classified outside the 4-hour window because the criticality determination required a triage meeting; Article 18 finding |
| TLPT integration | TLPT scope derived from CIF inventory and refreshed continuously; findings feed back into platform policy-as-code; closed findings produce supervisory-ready evidence packets | TLPT findings closure rate; finding-to-policy-update cycle time | TLPT discovers a vulnerability the institution's platform-engineering team can't fix in less than two release cycles |
Current Signals to Track #
| Signal | What It Means for Banks | Source |
|---|---|---|
| DORA in active enforcement since 17 Jan 2025 | First-wave supervisory findings landed Q4 2025; second-wave findings expected through 2026 H2 | EUR-Lex ⧉ |
| CTPP designation opening through 2025-2026 | AWS, Microsoft, Google, Salesforce inside or near perimeter; designation gives ESAs direct oversight rights | EBA ⧉ |
| ECB 2026-28 supervisory priorities name cloud disruption explicitly | Modelled supervisory scenarios test ability to absorb sustained designated-CTPP outage | ECB Banking Supervision ⧉ |
| TIBER-EU aligned to DORA Article 26 | TLPT scope covers critical / important functions including cloud-hosted services | ECB TIBER-EU ⧉ |
| EBA outsourcing guidelines (EBA/GL/2019/02) interlock with DORA Article 28 | Substantive presence (¶64), substitutability assessment (¶81), exit strategy (¶113-117) — the paragraphs supervisors actually test for | EBA ⧉ |
| EU Cloud Services Scheme (EUCS) draft progressing | Future Sovereign-cloud certification scheme under EU Cybersecurity Act; ENISA-published draft | ENISA EUCS ⧉ |
Platform Engineering: The Five Named Primitives #
Cloud-native maturity in 2026 reduces to five engineering primitives that interlock to produce supervisory evidence at the speed of the deployment pipeline. Missing any one is a finding waiting to happen.
1. Kubernetes-Based Paved Roads #
Every CIF runs on a managed Kubernetes platform — EKS, AKS, GKE, or OpenShift on a designated CTPP, or a vendor-managed alternative. The platform team operates a single golden cluster pattern with controlled deviation: nodes from a documented base image; namespace-per-team isolation; pod-security-standards-restricted profile; network policies; service-mesh injection (Istio or Linkerd) for inter-service authentication and observability. New services join the paved road through a templated onboarding workflow that produces the Article 8 register entry as a deployment artefact.
2. Backstage-Style Developer Portal #
A central developer portal — Spotify's open-source Backstage ⧉ is the reference implementation, with various enterprise alternatives — provides the system of record for what runs where. The catalogue lists every service, owner, dependency, criticality classification, runbook, on-call rotation. The portal interlocks with the Article 8 register: every catalogue entry maps to a register entry; entries without register references trigger CI failure; register entries without catalogue presence trigger supervisor-pre-empting alerts.
3. GitOps Deployment via ArgoCD or Flux #
Production deployment runs through a GitOps controller — ArgoCD or Flux is the production standard in 2026 — that reconciles a Git-versioned declarative state to the running cluster. Manual kubectl apply is disabled; the only path to production is a merged pull request. The Git repository is the audit trail; supervisors asking "show me the configuration of service X at date Y" get a Git tag, not a screenshot.
4. Open Policy Agent at Admission #
Open Policy Agent (OPA) sits in the cluster admission chain enforcing platform policy: pod-security profile compliance, image provenance, resource limits, network-policy presence, criticality-tier-appropriate replication, sub-region placement under sovereign-cloud constraints. Policies are Git-versioned and change-managed alongside service configurations. Rejected deployments produce reviewable rationales that feed the change-management evidence packet.
5. OpenTelemetry End-to-End #
Every service emits OpenTelemetry traces, metrics, and logs. The platform team operates a centralised observability pipeline — typically Tempo or Jaeger for traces, Prometheus for metrics, Loki or OpenSearch for logs — that surfaces end-to-end CIF health, dependency mapping, and incident-classification inputs. The 4-hour Article 18 classification window starts with detection; the OTel pipeline shortens the path from detection to classification to a queryable lookup, not a triage meeting.
Sovereign Cloud as Engineering, Not Branding #
Sovereign-cloud strategy in 2026 must answer four specific Schrems II + DORA + EBA outsourcing questions:
- Where is the data processed and stored? EU member-state location; sub-region for high-criticality flows; data residency commitments in writing.
- Who has legal access to the data? Local-employee-only operations; Foreign-government access requests subject to local-court process; tested response to lawful-access requests.
- What is the substitutability profile? EBA/GL/2019/02 ¶81 substitutability assessment; tested exit-execution; alternative provider identified and contracted (or documented why not feasible).
- What is the technical sovereignty model? Customer-controlled keys; cryptographic separation; sovereign management plane; auditable supply chain.
The 2026 vendor options addressing these questions:
- AWS European Sovereign Cloud (announced 2023, GA expected H2 2026): physical region operated by EU-resident AWS subsidiary; EU-resident operations and support; customer-controlled keys via KMS-XKS pattern. Pending DORA Article 28 contractual content alignment in 2026.
- Microsoft EU Data Boundary (GA 2024) + Bleu (Capgemini + Orange + Microsoft, France-only): Data Boundary keeps EU customer data in EU regions; Bleu is the SecNumCloud-aligned French sovereign cloud running Microsoft Azure stack under French operational control.
- Google Cloud sovereign partnerships: Thales / S3NS in France (Bleu equivalent); T-Systems in Germany.
- Oracle EU Sovereign Cloud (GA 2023): dual-region pattern (Frankfurt + Madrid) with EU-resident operations; cleanly Schrems II-compliant.
- Gaia-X-aligned providers (OVHcloud, Scaleway, Stackit, Aruba Cloud, IONOS): native-EU providers with Gaia-X labelling; smaller scale and ecosystem than hyperscalers but no Foreign Intelligence Surveillance Act exposure.
The strategic decision is rarely binary. Tier-1 banks typically run a hyperscaler-with-Data-Boundary configuration for the bulk of workloads, a sovereign-cloud option for designated high-sensitivity flows (e.g. AML / sanctions case-management systems handling EU-resident personal data), and a contingency-substitutability path tested annually under DORA Article 28.
Tested Exit Execution #
EBA/GL/2019/02 ⧉ paragraphs 113-117 are the exit-strategy provisions. The text is explicit on what is required: "Institutions and payment institutions should ensure that they are able to exit outsourcing arrangements without undue disruption to their business activities… The exit strategies should also be documented and tested as part of the regular reviews of the outsourcing arrangements."
The supervisory expectation in 2026 is annual end-to-end exit-execution testing for every CIF dependent on a designated CTPP. Tabletop exercises and document reviews are insufficient. The test must produce:
- Time-to-restore measurement: actual elapsed time from declaration of exit through workload restoration on the alternative provider, against the BIA-derived RTO target.
- Data-portability evidence: tested data export from primary, validated against the destination provider's import path, with reconciliation evidence.
- Functional equivalence: tested workload running on the alternative provider with equivalent SLOs.
- Cost evidence: documented exit-execution cost vs the cost-of-restoration assumption in the institution's contingency planning.
The first attempt at end-to-end exit testing for a CIF typically reveals a 5-10× gap between the documented RTO and the actual RTO. Closing that gap is engineering work that takes months. Banks discovering it during a supervisory inspection rather than during their own annual test cycle face a Q3 finding cycle they could have avoided.
RTO / RPO Targets from CIF Inventory #
Each critical or important function maps to a tier classification derived from the institution's business-impact analysis. The tier drives the RTO and RPO targets that the platform engineering team commits to deliver.
| Tier | Examples | RTO | RPO |
|---|---|---|---|
| Tier 1 (mission-critical) | RTGS connectivity (CHAPS / T2 / Fedwire), retail payment authorisation, customer authentication for digital channels | 2 hours | 15 minutes |
| Tier 2 (critical) | AML / sanctions screening, fraud-detection pipelines, ATM authorisation, batch payment processing | 4 hours | 1 hour |
| Tier 3 (important) | Reporting and regulatory submission, customer-facing knowledge bases, internal collaboration platforms | 24 hours | 4 hours |
| Tier 4 (non-critical) | Internal HR systems, marketing tooling, non-customer-facing reporting | 72 hours | 24 hours |
These numbers are illustrative — the institution's BIA produces its own. The platform engineering deliverable is a regression-tested capability to meet the BIA-derived targets, evidenced through automated DR testing per service and validated through the annual exit-execution test for CTPP-dependent CIFs.
What This Means by Bank Type #
Global Systemically Important Banks #
The hard problem is scale across business lines: thousands of services, hundreds of CIFs, multiple designated-CTPP exposures across products, jurisdictions and resilience profiles. The investment is the central platform-engineering capability — Kubernetes paved roads, Backstage portal, GitOps, OPA, OTel — that produces the Article 8 register reconciliation, the CTPP concentration map, and the CIF-by-CIF exit-execution capability without per-business-line bespoke construction.
Universal and Mid-Sized Banks #
The platform-engineering investment is justified at this tier but the scope is constrained: pick the two or three highest-criticality CIFs, build the paved-road pattern around them, accept the legacy estate continues on existing controls for the medium term. The supervisory positioning is more important than the platform breadth — being able to evidence DORA Article 8 register integrity and tested exit for the top three CIFs covers the supervisor's primary concerns.
Regional and Smaller Banks #
Vendor selection over internal build. Pick a banking-platform vendor whose Kubernetes-native architecture is documented, whose Article 8 register integration is built in, and whose DORA Article 28 contractual content commitments are clear. The internal engineering capability is around configuration, monitoring, and incident response — not platform construction.
Fintechs, PSPs, and SaaS Providers Serving Banks #
The product question for vendors selling into EU banks in 2026 is whether the platform produces the Article 8 register entries and DORA Article 28 contractual content the bank's compliance function needs. Vendors with structured outputs win enterprise deals; vendors with PDF templates lose to competitors with structured JSON.
Conclusion #
DORA cloud resilience is in audit phase. The platform-engineering decisions made through 2024-2025 are what the 2026 supervisory cycle scrutinises. The institutions that look credible to the ECB and the EBA in 2026-2028 are the ones running Kubernetes paved roads with Backstage-style portals and GitOps deployment under Open Policy Agent admission with OpenTelemetry end-to-end — producing Article 8 register evidence as a deployment artefact and tested exit-execution evidence as an annual cycle, not a supervisory request response.
The institutions that did not make those investments will discover whether their second-line compliance team can absorb the first round of supervisory findings before the second round arrives.
Measure the platform the way you measure any operational programme: paved-road coverage, register reconciliation rate, CTPP concentration score, tested exit time vs RTO target, Article 18 classification mean time, TLPT closure rate. Evidence at the speed of the pipeline; documentation packets only when the supervisor asks for one.
Questions? Answers.
Is DORA cloud resilience still in preparation phase in 2026?
No. DORA has been in active enforcement since 17 January 2025. The CTPP designation regime under Articles 28-44 is opening through 2025-2026. ECB exam findings on Article 6 ICT risk-management and Article 8 register integrity landed across multiple tier-1 institutions in Q4 2025. The 2026 supervisory question is institution-specific exam evidence, not regulatory readiness.
Which cloud providers are designated as CTPPs?
The ESAs publish designation decisions on their websites. The institutions inside or near the perimeter in 2026 include AWS, Microsoft (Azure), Google (GCP), Salesforce, and a small number of others depending on financial-services market share by member state. Banks supervised over those providers face corresponding supervisory expectations on how they manage that dependency.
Does sovereign cloud eliminate the need for DORA Article 28 contractual content?
No. Sovereign cloud addresses the Schrems II + data-residency dimension; DORA Article 28 contractual content is a separate obligation that applies regardless of where the data sits. The sovereign-cloud provider's contract must still cover data accessibility, security, residency, audit rights, exit strategies, and continuity per Article 28.
What is the engineering deliverable that demonstrates DORA cloud resilience?
Five platform-engineering primitives interlocking: Kubernetes paved roads (managed cluster with policy-controlled deviation), Backstage-style developer portal (catalogue reconciling to Article 8 register), GitOps deployment (ArgoCD or Flux), Open Policy Agent at admission, OpenTelemetry end-to-end. Evidence at the speed of the pipeline rather than at exam time.
How often does exit execution need to be tested?
Annual end-to-end exit-execution testing per CIF dependent on a designated CTPP. Tabletop exercises and document reviews are insufficient. The test must produce time-to-restore, data-portability evidence, functional equivalence, and cost evidence — measured against the BIA-derived RTO and RPO targets.
References #
- European Union, (2022). Regulation (EU) 2022/2554 — Digital Operational Resilience Act (DORA) ⧉.
- European Banking Authority, (2019). EBA/GL/2019/02 — Guidelines on outsourcing arrangements ⧉.
- European Banking Authority, (2026). Digital Operational Resilience Act ⧉.
- European Supervisory Authorities, (2024). Final Report on the ITS on the Register of Information under DORA ⧉.
- ECB Banking Supervision, (2025). Supervisory priorities 2026-28 ⧉.
- European Central Bank, (2024). TIBER-EU framework ⧉.
- ENISA, (2024). EU Cybersecurity Scheme for Cloud Services (EUCS) ⧉.
- Spotify, (2020-2024). Backstage developer portal ⧉.
- Cloud Native Computing Foundation, (2018). Open Policy Agent (OPA) ⧉.
- Cloud Native Computing Foundation, (2019). OpenTelemetry ⧉.
Last reviewed .