Cloud-natives Banking befindet sich 2026 in der DORA-Prüfungsphase. Die Verordnung (EU) 2022/2554 ⧉ gilt seit dem 17. Januar 2025. Das Designationsregime für kritische IKT-Drittdienstleister (CTPP) nach Artikeln 28-44 öffnet sich im Zeitraum 2025-2026, wobei AWS, Microsoft (Azure), Google (GCP) und Salesforce innerhalb oder am Rand des Designationsperimeters liegen. Die Europäischen Aufsichtsbehörden (EBA, EIOPA, ESMA) haben die finalen RTS und ITS zum Informationsregister ⧉ im Jahr 2024 veröffentlicht. Die EZB-Bankenaufsicht führt in ihren Aufsichtsprioritäten 2026-28 ⧉ explizite Programme zur Vorbereitung auf Cloud-Ausfälle und zu bedrohungsgesteuerten Penetrationstests. Die institutionelle Frage lautet nicht mehr, ob die Cloud-Strategie an DORA auszurichten ist — das ist entschieden —, sondern ob die Plattform-Engineering-Primitive des Instituts Nachweise im Takt der Deployment-Pipeline produzieren statt in PDFs, die in der Woche vor der Prüfung zusammengestellt werden.
Executive Summary / Wesentliche Erkenntnisse
- DORA-Cloud-Resilienz seit 17. Januar 2025 in aktiver Durchsetzung. Artikel 6, 8, 18, 26 und 28-44 alle in Kraft. Aufsichtliche Feststellungen aus der ersten Prüfungswelle sind im Q4 2025 eingegangen. Der Rahmen „Vorbereitung" ist zwei Zyklen veraltet.
- CTPP-Designationsregime öffnet sich. AWS, Microsoft, Google, Salesforce — innerhalb oder am Rand. Die Designation gibt den ESAs direkte Aufsichtsrechte einschließlich Auskunftsersuchen, Vor-Ort-Inspektionen und aufsichtlicher Empfehlungen.
- Plattform-Engineering ist das Ergebnis. Kubernetes-Paved-Roads (EKS / AKS / GKE / OpenShift), Backstage-artiges Entwicklerportal, GitOps (ArgoCD oder Flux), Open Policy Agent am Admission, OpenTelemetry End-to-End. Fünf benannte Primitive; jedes Fehlende ist eine Feststellung.
- Souveräne Cloud ist Engineering, nicht Branding. AWS European Sovereign Cloud, Microsoft EU Data Boundary, Bleu (Capgemini + Orange + Microsoft), Thales / S3NS, Oracle EU Sovereign Cloud — jedes Angebot adressiert eine spezifische Dimension von Schrems II plus DORA-Artikel 28; keines ist eine schlüsselfertige Antwort.
- Getestete Exit-Nachweise erforderlich. EBA/GL/2019/02 Randnummern 81 und 113-117. Vierteljährliches Tabletop reicht nicht; die Aufsicht erwartet jährliche End-to-End-Exit-Ausführungstests für jede kritische oder wichtige Funktion.
- RTO/RPO aus dem CIF-Inventar. Tier 1: 2 h / 15 min. Tier 2: 4 h / 1 h. Tier 3: 24 h / 4 h. Abgeleitet aus der Business-Impact-Analyse, nicht aus der Kapazität des Plattformteams.
Warum sich DORA-Cloud-Resilienz in der Prüfungsphase befindet #
Drei Gründe, warum der Rahmen „Vorbereitung" 2026 falsch ist.
Erstens, die Zeitleiste. DORA wurde im Dezember 2022 veröffentlicht. Die 24-monatige Anwendungsfrist endete am 17. Januar 2025. Die finalen RTS und ITS der ESAs — einschließlich der ITS zum Informationsregister, das für die CTPP-Designation verwendet wird — wurden im Verlauf von 2024 veröffentlicht. Die erste Welle aufsichtlicher Prüfungen lief durch 2025; Feststellungen zur Vollständigkeit des IKT-Risikomanagementrahmens nach Artikel 6 und zur Registerabstimmung nach Artikel 8 sind im Q4 2025 bei mehreren Tier-1-Instituten eingegangen.
Zweitens, das CTPP-Designationsregime. Artikel 31 legt die Kriterien für die Designation als kritischer Drittdienstleister fest: systemische Auswirkung im Ausfallfall, Kritikalität der erbrachten Dienste, Umfang und Komplexität der Dienste, Substituierbarkeit. Die ESAs führen das Register und veröffentlichen die Designationsentscheidungen. AWS, Microsoft (Azure), Google (GCP) und Salesforce liegen innerhalb oder am Rand des Designationsperimeters, abhängig vom Marktanteil im Finanzdienstleistungssektor je Mitgliedstaat. Die Designation verleiht dem federführenden Aufseher (eine der ESAs, je Anbieter zugewiesen) direkte Aufsichtsbefugnisse: Auskunftsersuchen nach Artikel 37, Vor-Ort-Inspektionen nach Artikel 38, Empfehlungen nach Artikel 35 sowie das Offenlegungsregime nach Artikel 41. Die Banken, die diese CTPPs nutzen, unterliegen entsprechenden aufsichtlichen Erwartungen an den Umgang mit dieser designierten Abhängigkeit.
Drittens, die EZB-Aufsichtsprioritäten 2026-28. Das Prioritätendokument nennt zwei explizite Programme, die Cloud-natives Banking direkt betreffen: Vorbereitung auf größere Cloud-Dienst-Störungen (modellierte Aufsichtsszenarien testen die Fähigkeit des Instituts, einen anhaltenden Ausfall eines designierten CTPP zu absorbieren) sowie TIBER-EU-konformer TLPT (jede TIBER-EU-Übung scopt die kritischen und wichtigen Funktionen des Instituts, was nun Public-Cloud-gehostete Dienste einschließt). Die Prüfungswelle 2026 wird zu beidem Feststellungen produzieren.
Der Rahmen für 2026 lautet nicht „DORA kommt"; er lautet „DORA-Prüfungsfeststellungen landen im Postfach Ihres Instituts, und was die Aufsicht in diesen Feststellungen untersucht, sind die Plattform-Engineering-Entscheidungen aus 2024-2025."
Die Architektur des Index 2026 #
| Index-Ebene | Wie „bereit" aussieht | Reifegrad-Metrik | Fehlermodus |
|---|---|---|---|
| Plattformreife | >80 % der Workloads auf einer Paved-Road-Kubernetes-Plattform (EKS / AKS / GKE / OpenShift) mit Policy-as-Code-Admission, GitOps-Deployment, automatisiertem DR-Test | % der CIFs auf Paved-Road-Plattform; Anzahl Schatten-Deployments; mittlere Zeit, einen neuen Dienst auf die Plattform aufzunehmen | Schattenplattformen mit inkonsistenten Kontrollen; CIFs auf un-paved-Infrastruktur, unsichtbar für die Artikel-8-Registerabstimmung |
| Integrität des Artikel-8-Registers | Informationsregister stimmt automatisch mit dem Drittparteien-API-Verbrauch der Plattform und der Cloud-Bill-of-Materials ab; Kritikalitätsklassifizierung konsistent zum CIF-Inventar des Instituts | % Registereinträge, die mit Plattform-Telemetrie abgestimmt sind; Anzahl Waiseneinträge; Integritätsprüfung des CTPP-Perimeters | ESAs identifizieren eine designierte CTPP-Abhängigkeit, die das Institut nach Artikel 8 nicht offengelegt hat; individuelle Feststellung und CTPP-Perimeter-Folge |
| Cloud-Konzentration | Kritische Funktionen zugeordnet zu Cloud-Anbietern UND Sub-Cloud-Regionen UND Services UND Substituierbarkeitsanalyse; übergreifende korrelierte Exposition über CIFs quantifiziert | Konzentrationsscore je CIF; korrelierte Exposition über CIFs, die sich eine designierte CTPP-Region teilen | Ein einzelner AWS-us-east-1-IAM-Ausfall legt vier CIFs lahm, von denen das Institut annahm, sie seien unabhängig ressourciert |
| Getestete Exit-Fähigkeit | Jährlicher End-to-End-Exit-Ausführungstest für jedes CIF, das von einem designierten CTPP abhängt; dokumentierte RTO / RPO erfüllen die BIA-abgeleiteten Ziele; Datenportabilitätspfad getestet | Test-Bestehensquote je CIF; mittlere Exit-Ausführungszeit gegen RTO-Ziel; Latenz des Datenportabilitätspfads | Exit-Plan, der nur als PDF existiert; Tabletop sagt 4 h RTO, der echte Test zeigt 48 h beim ersten Versuch |
| Observability + Vorfallmeldung | OpenTelemetry-Traces End-to-End über Dienste hinweg; automatisierter Vier-Stunden-Klassifikationshelfer nach Artikel 18 in die Incident-Management-Plattform verdrahtet | % CIF-Verkehr durch OTel-Traces abgedeckt; mittlere Zeit von Vorfallserkennung bis zur Klassifikationsentscheidung nach Artikel 18 | Größerer Vorfall außerhalb des Vier-Stunden-Fensters klassifiziert, weil die Kritikalitätsbestimmung ein Triage-Meeting erforderte; Feststellung nach Artikel 18 |
| TLPT-Integration | TLPT-Scope aus dem CIF-Inventar abgeleitet und kontinuierlich aktualisiert; Feststellungen fließen in Plattform-Policy-as-Code zurück; geschlossene Feststellungen produzieren aufsichtsreife Nachweis-Pakete | Schließungsquote der TLPT-Feststellungen; Zykluszeit von Feststellung zu Policy-Update | TLPT entdeckt eine Schwachstelle, die das Plattform-Engineering-Team in weniger als zwei Release-Zyklen nicht beheben kann |
Aktuelle Signale, die zu verfolgen sind #
| Signal | Was es für Banken bedeutet | Quelle |
|---|---|---|
| DORA seit 17. Januar 2025 in aktiver Durchsetzung | Erste Welle aufsichtlicher Feststellungen in Q4 2025 eingegangen; zweite Welle erwartet im H2 2026 | EUR-Lex ⧉ |
| CTPP-Designation öffnet sich im Zeitraum 2025-2026 | AWS, Microsoft, Google, Salesforce innerhalb oder am Rand des Perimeters; die Designation gibt den ESAs direkte Aufsichtsrechte | EBA ⧉ |
| EZB-Aufsichtsprioritäten 2026-28 nennen Cloud-Störung explizit | Modellierte Aufsichtsszenarien testen die Fähigkeit, einen anhaltenden Ausfall eines designierten CTPP zu absorbieren | EZB-Bankenaufsicht ⧉ |
| TIBER-EU an DORA-Artikel 26 ausgerichtet | TLPT-Scope deckt kritische / wichtige Funktionen einschließlich Cloud-gehosteter Dienste ab | EZB TIBER-EU ⧉ |
| EBA-Auslagerungsleitlinien (EBA/GL/2019/02) greifen mit DORA-Artikel 28 ineinander | Substanzielle Präsenz (¶64), Substituierbarkeitsanalyse (¶81), Exit-Strategie (¶113-117) — genau die Randnummern, auf die die Aufsicht prüft | EBA ⧉ |
| EU Cloud Services Scheme (EUCS) — Entwurf macht Fortschritte | Künftiges Zertifizierungsschema für souveräne Cloud unter dem EU-Cybersicherheitsakt; ENISA-veröffentlichter Entwurf | ENISA EUCS ⧉ |
Plattform-Engineering: Die fünf benannten Primitive #
Cloud-native Reife reduziert sich 2026 auf fünf Engineering-Primitive, die ineinandergreifen, um aufsichtliche Nachweise im Takt der Deployment-Pipeline zu produzieren. Jedes Fehlende ist eine Feststellung, die nur darauf wartet, einzutreten.
1. Kubernetes-basierte Paved Roads #
Jedes CIF läuft auf einer gemanagten Kubernetes-Plattform — EKS, AKS, GKE oder OpenShift auf einem designierten CTPP oder eine vom Anbieter gemanagte Alternative. Das Plattformteam betreibt ein einheitliches Golden-Cluster-Muster mit kontrollierter Abweichung: Knoten aus einem dokumentierten Base-Image; Namespace-pro-Team-Isolation; restriktives Pod-Security-Standards-Profil; Netzwerk-Policies; Service-Mesh-Injektion (Istio oder Linkerd) für Inter-Service-Authentifizierung und Observability. Neue Dienste schließen sich der Paved Road über einen templatisierten Onboarding-Workflow an, der den Artikel-8-Registereintrag als Deployment-Artefakt produziert.
2. Backstage-artiges Entwicklerportal #
Ein zentrales Entwicklerportal — Spotifys Open-Source-Lösung Backstage ⧉ ist die Referenzimplementierung, mit diversen Enterprise-Alternativen — liefert das Aufzeichnungssystem dafür, was wo läuft. Der Katalog listet jeden Dienst, Owner, Abhängigkeit, Kritikalitätsklassifikation, Runbook, Rufbereitschaft. Das Portal greift mit dem Artikel-8-Register ineinander: jeder Katalogeintrag bildet auf einen Registereintrag ab; Einträge ohne Registerverweis lösen einen CI-Fehler aus; Registereinträge ohne Katalog-Präsenz lösen aufseherantizipierende Alarme aus.
3. GitOps-Deployment via ArgoCD oder Flux #
Produktions-Deployments laufen über einen GitOps-Controller — ArgoCD oder Flux ist 2026 der Produktionsstandard —, der einen Git-versionierten deklarativen Zielzustand mit dem laufenden Cluster abgleicht. Manuelles kubectl apply ist deaktiviert; der einzige Weg in Produktion ist ein gemergter Pull Request. Das Git-Repository ist das Audit-Protokoll; die Aufsicht, die fragt „zeigen Sie mir die Konfiguration von Dienst X zum Datum Y", erhält ein Git-Tag, keinen Screenshot.
4. Open Policy Agent am Admission #
Open Policy Agent (OPA) sitzt in der Cluster-Admission-Kette und setzt Plattform-Policy durch: Konformität mit Pod-Security-Profil, Image-Provenienz, Resource-Limits, Vorhandensein von Network-Policies, Kritikalitätsstufen-gerechte Replikation, Sub-Region-Platzierung unter Vorgaben der souveränen Cloud. Policies sind Git-versioniert und werden parallel zu den Service-Konfigurationen änderungsmanaged. Abgelehnte Deployments produzieren prüfbare Begründungen, die in das Change-Management-Nachweispaket einfließen.
5. OpenTelemetry End-to-End #
Jeder Dienst emittiert OpenTelemetry-Traces, -Metriken und -Logs. Das Plattformteam betreibt eine zentrale Observability-Pipeline — typischerweise Tempo oder Jaeger für Traces, Prometheus für Metriken, Loki oder OpenSearch für Logs —, die End-to-End-CIF-Zustand, Abhängigkeitskartierung und Inputs für die Vorfallklassifikation sichtbar macht. Das Vier-Stunden-Klassifikationsfenster nach Artikel 18 beginnt mit der Erkennung; die OTel-Pipeline verkürzt den Weg von Erkennung zu Klassifikation zu einem abfragbaren Lookup, statt zu einem Triage-Meeting.
Souveräne Cloud als Engineering, nicht als Branding #
Die Souveräne-Cloud-Strategie 2026 muss vier konkrete Fragen aus Schrems II + DORA + EBA-Auslagerung beantworten:
- Wo werden die Daten verarbeitet und gespeichert? EU-Mitgliedstaatlicher Standort; Sub-Region für hochkritische Flüsse; Datenstandortzusagen schriftlich.
- Wer hat rechtlichen Zugriff auf die Daten? Betrieb ausschließlich durch lokale Mitarbeiter; Auskunftsersuchen ausländischer Regierungen unterliegen lokalem Gerichtsverfahren; getestete Reaktion auf rechtmäßige Zugriffsersuchen.
- Wie ist das Substituierbarkeitsprofil? Substituierbarkeitsanalyse nach EBA/GL/2019/02 ¶81; getestete Exit-Ausführung; identifizierter und kontrahierter Alternativanbieter (oder dokumentierte Begründung, warum nicht machbar).
- Wie sieht das technische Souveränitätsmodell aus? Kundenkontrollierte Schlüssel; kryptografische Trennung; souveräne Management-Plane; auditierbare Lieferkette.
Die Anbieteroptionen 2026 zu diesen Fragen:
- AWS European Sovereign Cloud (angekündigt 2023, GA erwartet H2 2026): physische Region, betrieben durch eine EU-ansässige AWS-Tochter; EU-ansässiger Betrieb und Support; kundenkontrollierte Schlüssel über KMS-XKS-Muster. Vertragsinhaltliche Ausrichtung an DORA-Artikel 28 steht 2026 noch aus.
- Microsoft EU Data Boundary (GA 2024) + Bleu (Capgemini + Orange + Microsoft, ausschließlich Frankreich): Data Boundary hält EU-Kundendaten in EU-Regionen; Bleu ist die SecNumCloud-konforme französische souveräne Cloud, die den Microsoft-Azure-Stack unter französischer operativer Kontrolle betreibt.
- Sovereign-Cloud-Partnerschaften von Google Cloud: Thales / S3NS in Frankreich (Bleu-Äquivalent); T-Systems in Deutschland.
- Oracle EU Sovereign Cloud (GA 2023): Dual-Region-Muster (Frankfurt + Madrid) mit EU-ansässigem Betrieb; sauber Schrems-II-konform.
- Gaia-X-konforme Anbieter (OVHcloud, Scaleway, Stackit, Aruba Cloud, IONOS): nativ-europäische Anbieter mit Gaia-X-Label; geringerer Maßstab und Ökosystem als die Hyperscaler, dafür keine Exposition gegenüber dem Foreign Intelligence Surveillance Act.
Die strategische Entscheidung ist selten binär. Tier-1-Banken fahren typischerweise eine Hyperscaler-mit-Data-Boundary-Konfiguration für das Gros der Workloads, eine souveräne Cloud-Option für ausgewiesen hochsensitive Flüsse (z. B. AML-/Sanktions-Fallbearbeitungssysteme mit Personenbezug zu EU-Ansässigen) sowie einen jährlich nach DORA-Artikel 28 getesteten Substituierbarkeits-Notfallpfad.
Getestete Exit-Ausführung #
EBA/GL/2019/02 ⧉ Randnummern 113-117 sind die Exit-Strategie-Vorgaben. Der Text ist explizit, was verlangt ist: „Institute und Zahlungsinstitute sollten sicherstellen, dass sie in der Lage sind, Auslagerungsvereinbarungen ohne unzumutbare Störung ihres Geschäftsbetriebs zu beenden… Die Exit-Strategien sollten auch dokumentiert und im Rahmen der regelmäßigen Überprüfungen der Auslagerungsvereinbarungen getestet werden."
Die aufsichtliche Erwartung für 2026 ist jährliches End-to-End-Exit-Ausführungstesting für jedes CIF, das von einem designierten CTPP abhängt. Tabletop-Übungen und Dokumentenreviews reichen nicht. Der Test muss Folgendes produzieren:
- Zeit-bis-Wiederherstellung-Messung: tatsächlich verstrichene Zeit von der Exit-Erklärung bis zur Workload-Wiederherstellung beim Alternativanbieter, gegen das BIA-abgeleitete RTO-Ziel.
- Nachweis der Datenportabilität: getesteter Datenexport vom Primäranbieter, validiert gegen den Importpfad des Zielanbieters, mit Abstimmungsnachweis.
- Funktionale Äquivalenz: getesteter Workload, der beim Alternativanbieter mit äquivalenten SLOs läuft.
- Kostennachweis: dokumentierte Exit-Ausführungskosten gegen die Kosten-der-Wiederherstellung-Annahme in der Notfallplanung des Instituts.
Der erste Versuch eines End-to-End-Exit-Tests für ein CIF offenbart typischerweise eine Lücke von Faktor 5-10 zwischen dokumentiertem RTO und tatsächlichem RTO. Das Schließen dieser Lücke ist Engineering-Arbeit, die Monate dauert. Banken, die dies während einer aufsichtlichen Inspektion statt während ihres eigenen jährlichen Testzyklus entdecken, stehen vor einem Feststellungszyklus im Q3, den sie hätten vermeiden können.
RTO-/RPO-Ziele aus dem CIF-Inventar #
Jede kritische oder wichtige Funktion wird einer Stufenklassifikation zugeordnet, die aus der Business-Impact-Analyse des Instituts abgeleitet ist. Die Stufe steuert die RTO- und RPO-Ziele, zu deren Lieferung sich das Plattform-Engineering-Team verpflichtet.
| Stufe | Beispiele | RTO | RPO |
|---|---|---|---|
| Tier 1 (geschäftskritisch) | RTGS-Anbindung (CHAPS / T2 / Fedwire), Retail-Zahlungsautorisierung, Kundenauthentifizierung für digitale Kanäle | 2 Stunden | 15 Minuten |
| Tier 2 (kritisch) | AML-/Sanktions-Screening, Fraud-Detection-Pipelines, GAA-Autorisierung, Batch-Zahlungsverarbeitung | 4 Stunden | 1 Stunde |
| Tier 3 (wichtig) | Reporting und regulatorische Einreichung, kundengerichtete Wissensdatenbanken, interne Kollaborationsplattformen | 24 Stunden | 4 Stunden |
| Tier 4 (nicht kritisch) | Interne HR-Systeme, Marketing-Werkzeuge, nicht-kundengerichtetes Reporting | 72 Stunden | 24 Stunden |
Diese Werte sind illustrativ — die BIA des Instituts erzeugt die eigenen. Das Plattform-Engineering-Ergebnis ist eine regressionsgetestete Fähigkeit, die BIA-abgeleiteten Ziele zu erfüllen, nachgewiesen durch automatisierte DR-Tests je Dienst und validiert durch den jährlichen Exit-Ausführungstest für CTPP-abhängige CIFs.
Was das je nach Banktyp bedeutet #
Global systemrelevante Banken #
Das harte Problem ist die Skalierung über Geschäftsbereiche hinweg: Tausende von Diensten, Hunderte von CIFs, mehrere designierte CTPP-Expositionen über Produkte, Jurisdiktionen und Resilienzprofile. Die Investition liegt in der zentralen Plattform-Engineering-Fähigkeit — Kubernetes-Paved-Roads, Backstage-Portal, GitOps, OPA, OTel —, die die Artikel-8-Registerabstimmung, die CTPP-Konzentrationskarte und die CIF-für-CIF-Exit-Ausführungsfähigkeit ohne pro-Geschäftsbereich-Sonderbau liefert.
Universal- und mittelgroße Banken #
Die Plattform-Engineering-Investition ist auf dieser Stufe gerechtfertigt, aber im Scope eingeschränkt: die zwei oder drei kritikalitätshöchsten CIFs auswählen, das Paved-Road-Muster darum herum aufbauen, akzeptieren, dass der Legacy-Bestand mittelfristig auf den bestehenden Kontrollen weiterläuft. Die aufsichtliche Positionierung ist wichtiger als die Plattformbreite — die Fähigkeit nachzuweisen, dass die Integrität des DORA-Artikel-8-Registers und der getestete Exit für die Top-3-CIFs gegeben sind, deckt die Primäranliegen der Aufsicht ab.
Regional- und kleinere Banken #
Anbieterauswahl statt interner Eigenbau. Einen Banking-Plattform-Anbieter wählen, dessen Kubernetes-native Architektur dokumentiert ist, dessen Integration in das Artikel-8-Register eingebaut ist und dessen vertragliche Inhaltszusagen zu DORA-Artikel 28 klar sind. Die interne Engineering-Fähigkeit liegt rund um Konfiguration, Monitoring und Vorfallreaktion — nicht im Plattformbau.
Fintechs, PSPs und SaaS-Anbieter für Banken #
Die Produktfrage für Anbieter, die 2026 an EU-Banken verkaufen, ist, ob die Plattform die Artikel-8-Registereinträge und die vertraglichen DORA-Artikel-28-Inhalte produziert, die die Compliance-Funktion der Bank benötigt. Anbieter mit strukturierten Ausgaben gewinnen Enterprise-Deals; Anbieter mit PDF-Vorlagen verlieren gegen Wettbewerber mit strukturiertem JSON.
Fazit #
DORA-Cloud-Resilienz ist in der Prüfungsphase. Was der Aufsichtszyklus 2026 untersucht, sind die Plattform-Engineering-Entscheidungen aus 2024-2025. Die Institute, die EZB und EBA 2026-2028 als glaubwürdig erscheinen, sind jene, die Kubernetes-Paved-Roads mit Backstage-artigen Portalen und GitOps-Deployment unter Open Policy Agent am Admission mit OpenTelemetry End-to-End fahren — die Artikel-8-Registernachweise als Deployment-Artefakt und getestete Exit-Ausführungsnachweise als jährlichen Zyklus produzieren, nicht als Antwort auf eine aufsichtliche Anfrage.
Die Institute, die diese Investitionen nicht getätigt haben, werden herausfinden, ob ihr Second-Line-Compliance-Team die erste Runde aufsichtlicher Feststellungen absorbieren kann, bevor die zweite Runde eintrifft.
Messen Sie die Plattform so, wie Sie jedes operative Programm messen: Paved-Road-Abdeckung, Registerabstimmungsquote, CTPP-Konzentrationsscore, getestete Exit-Zeit gegen RTO-Ziel, mittlere Klassifikationszeit nach Artikel 18, TLPT-Schließungsquote. Nachweise im Takt der Pipeline; Dokumentationspakete nur dann, wenn die Aufsicht eines anfordert.
Häufig gestellte Fragen #
Befindet sich die DORA-Cloud-Resilienz 2026 noch in der Vorbereitungsphase?
Nein. DORA ist seit dem 17. Januar 2025 in aktiver Durchsetzung. Das CTPP-Designationsregime nach Artikeln 28-44 öffnet sich im Zeitraum 2025-2026. EZB-Prüfungsfeststellungen zum IKT-Risikomanagement nach Artikel 6 und zur Registerintegrität nach Artikel 8 sind im Q4 2025 bei mehreren Tier-1-Instituten eingegangen. Die aufsichtliche Frage 2026 betrifft institutsspezifische Prüfungsnachweise, nicht regulatorische Vorbereitung.
Welche Cloud-Anbieter sind als CTPPs designiert?
Die ESAs veröffentlichen die Designationsentscheidungen auf ihren Websites. Die Institutionen innerhalb oder am Rand des Perimeters 2026 umfassen AWS, Microsoft (Azure), Google (GCP), Salesforce und eine kleine Zahl weiterer, je nach Marktanteil im Finanzdienstleistungssektor je Mitgliedstaat. Banken, die diese Anbieter nutzen, sehen sich entsprechenden aufsichtlichen Erwartungen an den Umgang mit dieser Abhängigkeit ausgesetzt.
Hebt souveräne Cloud die Notwendigkeit der vertraglichen DORA-Artikel-28-Inhalte auf?
Nein. Souveräne Cloud adressiert die Dimension Schrems II plus Datenstandort; die vertraglichen DORA-Artikel-28-Inhalte sind eine eigenständige Pflicht, die unabhängig davon gilt, wo die Daten liegen. Der Vertrag des Souveräne-Cloud-Anbieters muss weiterhin Datenzugänglichkeit, Sicherheit, Standort, Auditrechte, Exit-Strategien und Kontinuität nach Artikel 28 abdecken.
Was ist das Engineering-Ergebnis, das DORA-Cloud-Resilienz nachweist?
Fünf ineinandergreifende Plattform-Engineering-Primitive: Kubernetes-Paved-Roads (gemanagter Cluster mit policy-kontrollierter Abweichung), Backstage-artiges Entwicklerportal (Katalog mit Abstimmung gegen das Artikel-8-Register), GitOps-Deployment (ArgoCD oder Flux), Open Policy Agent am Admission, OpenTelemetry End-to-End. Nachweise im Takt der Pipeline, nicht zum Prüfungstermin.
Wie oft muss die Exit-Ausführung getestet werden?
Jährliches End-to-End-Exit-Ausführungstesting je CIF, das von einem designierten CTPP abhängt. Tabletop-Übungen und Dokumentenreviews reichen nicht. Der Test muss Zeit-bis-Wiederherstellung, Nachweis der Datenportabilität, funktionale Äquivalenz und Kostennachweis produzieren — gemessen gegen die BIA-abgeleiteten RTO- und RPO-Ziele.
Quellenverzeichnis #
- Europäische Union, (2022). Verordnung (EU) 2022/2554 — Digital Operational Resilience Act (DORA) ⧉.
- European Banking Authority, (2019). EBA/GL/2019/02 — Leitlinien zu Auslagerungsvereinbarungen ⧉.
- European Banking Authority, (2026). Digital Operational Resilience Act ⧉.
- Europäische Aufsichtsbehörden, (2024). Final Report on the ITS on the Register of Information under DORA ⧉.
- EZB-Bankenaufsicht, (2025). Aufsichtsprioritäten 2026-28 ⧉.
- Europäische Zentralbank, (2024). TIBER-EU-Rahmenwerk ⧉.
- 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 ⧉.
Zuletzt geprüft .
Zuletzt überprüft .