DORA-Compliance für Cloud-Infrastrukturen: AWS & Azure Leitfaden 2025

Der Digital Operational Resilience Act (DORA — EU 2022/2554) ist seit dem 17. Januar 2025 vollständig anwendbar. Wenn Ihr Institut auf AWS oder Azure betrieben wird und im Bank-, Versicherungs-, Investment- oder Zahlungsdienstleistungssektor tätig ist, sind DORAb IKT-Anforderungen jetzt rechtlich bindend. Dieser Leitfaden ordnet die Infrastrukturpflichten der Verordnung konkreten Cloud-Konfigurationsprüfungen zu.

Wer ist von DORA betroffen?

DORA gilt für eine breite Palette von Finanzunternehmen, die in der EU tätig sind:

• Kreditinstitute (Banken) und Zahlungsinstitute
• Wertpapierfirmen und Vermögensverwaltungsgesellschaften
• Versicherungs- und Rückversicherungsunternehmen
• Kryptowert-Dienstleister (CASPs)
• Von den ESAs als „kritisch" eingestufte IKT-Drittdienstleister

Im Gegensatz zu NIS2, das Mitarbeiter- und Umsatzschwellen verwendet, gilt DORA nach Sektor — nicht nach Größe. Ein zweiköpfiges Fintech, das Zahlungen akzeptiert, fällt genauso in den Anwendungsbereich wie eine große Bank.

DORA IKT-RisikoAnforderungen (Artikel 5–16)

Kapitel II von DORA definiert einen umfassenden IKT-Risikomanagement-Rahmen. Für Cloud-Infrastrukturen gliedert sich dies in fünf technische Domänen:

1. Identifikation und Klassifizierung (Art. 8)

• Alle IKT-Assets inventarisiert — einschließlich Cloud-Konten, Regionen und Dienste
• Von jedem Asset unterstützte Geschäftsfunktionen dokumentiert
• Datenklassifizierung auf alle Speicherressourcen angewendet (S3, RDS, Azure Blob, SQL)
• Abhängigkeiten von IKT-Drittanbietern (AWS, Azure) formal dokumentiert

2. Schutz (Art. 9)

• MFA für alle IAM-Benutzer und privilegierten Konten erzwungen
• Verschlüsselung im Ruhezustand auf allen Speichern: S3 (SSE-KMS), RDS, EBS, DynamoDB, Azure SQL (TDE), Azure Storage
• Verschlüsselung während der Übertragung: TLS 1.2+ erzwungen, keine veralteten Cipher-Suites
• Netzwerksegmentierung: keine Sicherheitsgruppen offen für 0.0.0.0/0 auf sensiblen Ports
• KMS-Schlüsselrotation aktiviert (mindestens jährlich)
• Secrets in AWS Secrets Manager oder Azure Key Vault gespeichert — niemals in Umgebungsvariablen

3. Erkennung (Art. 10)

• CloudTrail in allen Regionen mit Log-Datei-Validierung und KMS-Verschlüsselung aktiviert
• Azure Monitor / Activity Log Aufbewahrung ≥ 12 Monate
• GuardDuty für Anomalie- und Bedrohungserkennung aktiviert
• VPC Flow Logs und Azure NSG Flow Logs aktiv
• CloudWatch-Alarme bei Root-Kontonutzung, IAM-Richtlinienänderungen und fehlgeschlagenen Auth-Ereignissen
• Zentralisierte SIEM-Aufnahme mit manipulationssicherem Log-Speicher

4. Reaktion und Wiederherstellung (Art. 11–12)

• Automatische RDS-Backups mit ≥7 Tagen Aufbewahrung; getestete Wiederherstellungen dokumentiert
• Multi-AZ für Produktionsdatenbanken aktiviert
• S3-Versionierung und regionsübergreifende Replikation für kritische Daten
• Azure SQL georedundantes Backup aktiviert
• Recovery Time Objective (RTO) und Recovery Point Objective (RPO) formal definiert
• Business-Continuity-Plan mindestens jährlich und nach größeren Vorfällen aktualisiert

5. Lernen und Weiterentwickeln (Art. 13)

• Post-Incident-Reviews mit Root-Cause-Analyse dokumentiert
• Threat-Intelligence-Feeds in Erkennungstools integriert
• Schwachstellenscanning auf allen EC2- und Container-Workloads (Amazon Inspector, Defender for Cloud)
• Patch-Management innerhalb definierter SLAs (DORA legt keine Zeitfenster fest — Sie müssen sie definieren und nachweisen)

Meldung von Vorfällen (Artikel 19) — die 72-Stunden-Uhr

DORA legt einen strengen dreistufigen Meldefahrplan für schwerwiegende IKT-Vorfälle fest:

• Erstmeldung: innerhalb von 4 Stunden nach Einstufung als schwerwiegend (oder 24 Stunden nach erster Kenntnis)
• Zwischenbericht: innerhalb von 72 Stunden — aktualisierte Folgenabschätzung und Eindämmungsstatus
• Abschlussbericht: innerhalb von 1 Monat — vollständige Root-Cause-Analyse und Korrekturmaßnahmen

Dies erfordert, dass Ihr Erkennungs- und Alarmierungs-Stack einen IKT-Vorfall innerhalb von Stunden identifizieren, klassifizieren und eskalieren kann. CloudWatch-Alarme, GuardDuty-Findings, die an PagerDuty oder Slack weitergeleitet werden, und ein dokumentierter Klassifizierungsprozess sind Mindestanforderungen.

IKT-Drittparteienrisiko (Artikel 28–44)

DORA legt erhebliche Pflichten dafür fest, wie Sie Cloud-Anbieter wie AWS und Azure verwalten. Wesentliche Anforderungen:

• Schriftliche Vertragsvereinbarungen mit allen IKT-Drittanbietern (Art. 30) — Ihr Cloud-MSA und DPA erfüllen die Grundlage
• Register aller IKT-Drittparteienabhängigkeiten gepflegt und aktualisiert
• Exit-Strategie für kritische Drittparteienabhängigkeiten dokumentiert
• Jährliche Risikobewertung der Drittparteienkonzentration — wenn 90 % Ihres Workloads auf einem einzigen Cloud-Anbieter laufen, muss dies bewertet und gemindert werden
• Für kritische IKT-Drittanbieter (von den ESAs benannt): erweiterter Aufsichtsrahmen gilt direkt — derzeit für große Cloud-Hyperscaler in der Bewertung

DORA vs. NIS2 — was überschneidet sich?

DORA und NIS2 teilen ungefähr 40 % der technischen Controls auf Infrastrukturebene. Beide erfordern Verschlüsselung, Zugangskontrolle, Protokollierung, Incident Response und Business Continuity. Die wesentlichen Unterschiede:

• Anwendungsbereich: NIS2 deckt kritische Infrastrukturen breit ab; DORA ist finanzsektor-spezifisch
• Meldefristen: NIS2 verlangt 24h Frühwarnung + 72h Benachrichtigung; DORA verlangt 4h initial + 72h Zwischenmeldung + 1 Monat abschließend
• Drittparteienrisiko: DORA geht viel weiter — Art. 28-44 fehlen größtenteils in NIS2
• Tests: DORA schreibt jährliche TLPT (Threat-Led Penetration Testing) für bedeutende Einrichtungen vor — NIS2 empfiehlt, schreibt aber nicht vor

Wenn Ihre Organisation beiden unterliegt, deckt die Behebung der NIS2-Lücken zuerst den größten Teil der DORA-Grundlage ab — dann konzentrieren Sie sich auf DORA-spezifische Ergänzungen (Drittparteienregister, TLPT, 4h-Klassifizierungsprozess).

DORA-Sanktionen

Aufsichtsbehörden (nationale zuständige Behörden — NCA) können verhängen:

• Verwaltungsstrafen bis zu 1 % des durchschnittlichen täglichen weltweiten Umsatzes pro Verstoß, pro Tag der Nichteinhaltung
• Regelmäßige Strafzahlungen von bis zu 1 % des Tagesumsatzes für bis zu 6 Monate
• Öffentliche Erklärungen, die das Institut und die Art des Verstoßes nennen
• Für kritische IKT-Drittanbieter: Strafen bis zu €5 Mio. oder 1 % des weltweiten Umsatzes

So automatisieren Sie DORA-Compliance-Prüfungen

DORAb IKT-Risikovoraussetzungen bilden sich direkt auf Infrastrukturkonfiguration ab. Jede Verschlüsselungs-, Zugangskontroll- und Protokollierungsanforderung in den Artikeln 9–10 kann automatisch gegen Ihre live Cloud-Umgebung verifiziert werden.

ConformScan führt DORA-zugeordnete Prüfungen über Ihre AWS- und Azure-Konten in unter 2 Minuten durch — einschließlich Verschlüsselung im Ruhe- und Übertragungszustand, IAM-Controls, Protokollierungsvollständigkeit, Backup-Konfiguration und Netzwerkexposition. Sie erhalten:

• DORA-zugeordnete Findings mit SLA-Countdowns (3 → 14 → 30 Tage, abgestimmt auf Art.-19-Fristen)
• Framework-übergreifende Ansicht: sehen Sie, welche Findings gleichzeitig DORA, NIS2 und ISO 27001 betreffen
• Terraform- und CLI-Abhilfecode für jeden Fund
• PDF-Berichte bereit für Ihren Compliance-Beauftragten, Prüfer oder NCA-Einreichung
• Geplante tägliche Scans, um Konfigurationsdrift zu erkennen, bevor sie zu einem meldepflichtigen Vorfall wird

Wo fangen Sie an?

Wenn Sie Ihr DORA-Compliance-Programm heute beginnen, priorisieren Sie in dieser Reihenfolge:

1. Basis-Scan durchführen — kennen Sie Ihre aktuelle Exposition über alle IKT-Risikodomänen
2. Kritische Findings zuerst beheben — Verschlüsselungslücken, öffentliche Datenbanken, fehlende MFA
3. Ihr IKT-Asset-Register aufbauen — Cloud-Konten, Dienste und Drittparteienabhängigkeiten dokumentieren
4. Ihren Incident-Klassifizierungsprozess etablieren — die 4h-Uhr beginnt, wenn Sie Kenntnis erlangen, nicht wenn Sie entscheiden, dass es schwerwiegend ist
5. Drittparteienverträge dokumentieren — Ihre AWS- und Azure-MSAs gegen DORA Art.-30-Anforderungen prüfen

DORA ist kein Projekt mit einem Enddatum — es erfordert kontinuierliche Überwachung Ihrer IKT-Risikolage. Automatisiertes Scanning über conformscan.com stellt sicher, dass Ihre Controls zwischen Audits wirksam bleiben.