Begleitung zur DORA-Compliance-Page. Praktische Checkliste für Plattform-Engineers und Cloud-Architekten zur DORA-Umsetzung.
DORA-Geltungsbereich
DORA gilt für betroffene Finanzunternehmen und ihre IKT-Drittanbieter mit kritischen Funktionen.
Architektonische Anforderungen
Workload-Portabilität (Artikel 28(8))
- Dokumentierter Exit-Plan pro kritischer Funktion
- Test des Exit-Plans innerhalb der letzten 24 Monate
- Plattform-Abstraktion existiert auf ≥2 Anbietern
Konzentrationsrisiko-Transparenz
- Service-Katalog mit Lieferanten-Mapping
- Sub-Lieferantenketten bis zur zweiten Hop dokumentiert
- Konzentrationsrisiko-Position dokumentiert und annual reviewed
Operative Resilienz
- RTO/RPO dokumentiert und annual getestet
- Architektur unterstützt kontrollierte Failure-Injection
- Backup und DR funktionieren über Regionen hinweg
Souveränität und Aufsichtszugang
- Datenresidenz auf jeder Schicht durchgesetzt (Produktion, Backup, Observability, CI/CD)
- Verschlüsselung at rest, in transit, in use
- Verschlüsselungsschlüssel unter Kundenkontrolle
- Audit-Logs in Standardformaten exportierbar
Vertragliche und Lieferanten-Risiken
- Alle IKT-Drittanbieter-Vereinbarungen inventarisiert
- Article-30-Vertragsinhalt für kritische Funktionen
- Konzentrations-Schwellenwerte vereinbart
Häufige Lücken in bestehenden Setups
- Observability verlässt den Aufsichtsbereich leise — SaaS-Observability prozessiert Logs in den USA
- Exit-Plan nie getestet — DORA Article 28(8) erfordert Tests
- Konzentrationsrisiko als Beschaffungsfrage behandelt — vertragliche Diversität ohne architektonische Diversität
- Sub-Lieferantenkette unsichtbar nach erstem Hop
Wie geht es weiter?
Strukturierte DORA-Bewertung → Platform Readiness Assessment.
Ænix ist das Team hinter Cozystack.
Wissens-Check: DORA-Checkliste für Cloud-Architektur
5 questions · ~2 min
Question 1 / 5
Welcher DORA-Artikel verlangt einen dokumentierten Ausstiegsplan für kritische Funktionen?
Why: DORA Artikel 28(8) verlangt für kritische Funktionen einen dokumentierten Ausstiegsplan und zusätzlich einen tatsächlichen Test innerhalb der letzten 24 Monate. Ein Plan ohne Probe reicht nicht — die Ausstiegsdauer bleibt sonst eine Zahl auf dem Papier.
Question 2 / 5
Wie tief muss die Lieferkette nach den Erwartungen aus Artikel 28 und 30 mindestens dokumentiert sein?
Why: Lieferantentransparenz bis zur zweiten Ebene. Dazu gehören ein Servicekatalog mit Lieferantenzuordnung, dokumentierte Sublieferantenketten für kritische Funktionen und eine jährlich überprüfte Position zum Konzentrationsrisiko.
Question 3 / 5
Was ist laut Artikel die häufigste DORA-Lücke?
Why: Lücke 1: Observability verlässt unbemerkt den Aufsichtsbereich. Die Produktionsdatenbank kann konform sein, der SaaS-Observability-Stack, der ihre Logs einsammelt, ist es in der Regel nicht. Die Residenzerwartungen aus DORA Artikel 28 gelten für die gesamte Vereinbarung mit dem IKT-Drittanbieter.
Question 4 / 5
Was ist für operative Resilienz im Cloud-Kontext sicherzustellen?
Why: Operative Resilienz verlangt RTO und RPO dokumentiert und jährlich getestet, nicht bloß dokumentiert; eine Architektur, die kontrollierte Fehlerinjektion (Chaos Engineering) ohne unzumutbare Kundenwirkung verträgt; sowie Backup und Disaster Recovery über mindestens zwei Regionen.
Question 5 / 5
Was meint der Artikel mit „Konzentrationsrisiko als Beschaffungsfrage behandelt“?
Why: Häufige Lücke: Das Konzentrationsrisiko wird erkannt und dann mit vertraglichen Diversitätsklauseln beruhigt — ohne dass sich architektonisch etwas daran ändert, wie stark die Workloads von einem Anbieter abhängen. DORA fordert die tatsächliche Resilienz, nicht die vertragliche Formalie.
0 / 5