DORA Readiness Checkliste für Cloud-Teams

Wer in Scope ist - und warum Proportionalität zählt

DORA gilt für die meisten regulierten Finanzunternehmen in der EU: Kreditinstitute, Zahlungs- und E-Geld-Institute, Wertpapierfirmen, Versicherer, Krypto-Dienstleister und weitere (Artikel 2). Sie erreicht auch IKT-Drittdienstleister - Cloud-Provider eingeschlossen - über den Überwachungsrahmen und, praktisch relevanter für Sie, über die Vertragsanforderungen, die Ihre Aufsicht in Ihren Cloud-Verträgen erwartet.

Das Proportionalitätsprinzip (Artikel 4) ist real: Von einem Drei-Personen-Fintech wird nicht dasselbe Programm erwartet wie von einer systemrelevanten Bank. Aber Proportionalität ändert die Tiefe der Artefakte, nicht die Liste. Jedes Unternehmen in Scope braucht einen dokumentierten IKT-Risikorahmen, einen Incident-Prozess, ein Testprogramm und ein Drittparteien-Register.

Säule 1: IKT-Risikomanagement (Artikel 5-16)

Das Leitungsorgan trägt unter DORA die Verantwortung für IKT-Risiken. Sie lässt sich nicht an einen CISO oder ein Cloud-Team wegdelegieren. Was das Cloud-Team verantwortet, ist der Nachweis, dass der Rahmen die Realität beschreibt: ein Asset-Inventar, das dem tatsächlichen Betrieb entspricht, Netzwerk- und Identitätsdokumentation und eine Zuordnung kritischer Geschäftsfunktionen zu den Cloud-Diensten, die sie tragen.

• ✓Ein aktuelles Inventar der IKT-Assets und Cloud-Accounts, mit Verantwortlichen.
• ✓Dokumentierte Identifikation kritischer oder wichtiger Funktionen und der unterstützenden Systeme.
• ✓Nachweise zum Zugriffsmanagement: SSO, Least Privilege, Joiner-Mover-Leaver-Prozess, keine geteilten Langzeit-Credentials.
• ✓Backup- und Restore-Richtlinie mit Nachweisen aus tatsächlich getesteten Restores.
• ✓Ein Business-Continuity- und Disaster-Recovery-Plan mit definierten RTO/RPO für kritische Funktionen.

Säule 2: Incident-Management und Meldung (Artikel 17-23)

DORA verlangt einen Prozess, um schwerwiegende IKT-Vorfälle zu erkennen, zu klassifizieren und der zuständigen Behörde zu melden - mit Erstmeldung, Zwischenbericht und Abschlussbericht in festen Fristen. Die Klassifizierungskriterien (betroffene Kunden, Dauer, geografische Ausbreitung, Datenverluste, Kritikalität der Dienste, wirtschaftliche Auswirkung) stehen in den technischen Regulierungsstandards.

Für ein Cloud-Team heißt das: Monitoring und On-Call brauchen eine Brücke in die regulatorische Meldung. Wer Bereitschaft hat, muss wissen, welche Schweregrade die Compliance-Uhr starten und wer diese Entscheidung um 3 Uhr nachts trifft. Aufschreiben, eine Tabletop-Übung durchführen, Protokoll aufbewahren.

Säule 3: Resilienz-Tests (Artikel 24-27)

Alle Unternehmen in Scope brauchen ein verhältnismäßiges Programm zum Testen der digitalen operationalen Resilienz: Schwachstellenanalysen, szenariobasierte Tests und - für von der Aufsicht bestimmte Unternehmen - bedrohungsorientierte Penetrationstests (TLPT) mindestens alle drei Jahre. Die meisten Cloud-Teams tun Teile davon längst. Die Lücke ist meist, dass nichts als Programm dokumentiert ist.

Starten Sie mit dem, was da ist: Dependency-Scanning, Restore-Tests, Chaos- oder Failover-Übungen. In einen Kalender eintragen, definieren, welchen Nachweis jeder Lauf erzeugt, und die Nachweise dort ablegen, wo ein Prüfer sie findet.

Säule 4: Drittparteien-Risiko und das Register (Artikel 28-30)

Diese Säule trifft Cloud-Teams am härtesten. Sie müssen ein Informationsregister über alle vertraglichen Vereinbarungen mit IKT-Drittdienstleistern führen (Art. 28 Abs. 3) - Hyperscaler, SaaS-Tools, Managed-Service-Provider - und Ihre Aufsicht kann es anfordern. Verträge für kritische oder wichtige Funktionen müssen die konkreten Bestimmungen aus Artikel 30 enthalten: Audit- und Zugangsrechte, Exit-Strategien, Service Level, Incident-Unterstützung und Kündigungsrechte.

Praktische Reihenfolge: jeden Provider inventarisieren, der Produktion berührt; klassifizieren, welche kritische Funktionen tragen; dann diese Verträge gegen Artikel 30 prüfen. Für AWS, Azure und GCP existieren Financial-Services-Vertragszusätze, die die meisten Klauseln abdecken, aber man muss sie tatsächlich unterzeichnen und ablegen.

Eine realistische 90-Tage-Sequenz

Wer spät startet: Reihenfolge schlägt Vollständigkeit. Wochen 1-4: Asset- und Provider-Inventar, Kritikalitäts-Mapping, Register-Gerüst. Wochen 5-8: Incident-Klassifizierung in den On-Call-Prozess bringen, Restore-Test mit Nachweis, Vertrags-Gap-Analyse. Wochen 9-12: die risikoreichsten Vertragslücken schließen, das Testprogramm dokumentieren, das Leitungsorgan briefen. Das ist eine verteidigbare Position und ein deutlich besseres Gespräch mit der Aufsicht als ein perfekter Plan, der nie gestartet ist.

FAQ