Was diese Aufgabenblätter Ihnen geben
Praxisnahe Analyse-Aufgaben zu realen DORA-Situationen — für Selbststudium oder Team-Workshop. Jedes Blatt enthält ein Szenario, fünf Analysefragen, eine Root-Cause-Analyse, einen Maßnahmenkatalog, eine Reflexionsfrage und eine vollständige Musterlösung.
Workshop-Modus
3er-Gruppen, jede Gruppe übernimmt eine Analysefrage (20 Min. Bearbeitung), dann Plenum-Synthese (30 Min.). Die Moderation hält die Musterlösung zurück — sie wird erst nach der Synthese verteilt. Rollenverteilung: ein Schreiber pro Gruppe, ein Sprecher fürs Plenum, ein Zeitwächter.
Aufgabenblatt 1
DORA Art. 24–27
Die Pen-Test-Falle
Resilienztesting — warum bestandene Tests keine Sicherheit bedeuten
Ein mittelgroßer Finanzdienstleister führt jährlich klassische Penetrationstests durch. Die Tests werden regelmäßig bestanden, die Berichte sind formal sauber und ohne kritische Findings. Das Management ist zufrieden. Der CISO präsentiert die Ergebnisse im Board als Beleg für eine robuste Sicherheitsarchitektur.
Im Rahmen eines Projekts zur Prozessoptimierung verzahnt ein internes Projektteam mehrere Kernprozesse mit einem externen Zahlungsdienstleister. Die neue Abhängigkeit wird technisch umgesetzt und operativ eingeführt — aber nicht explizit in die bestehenden Test- und Risikoprozesse integriert. Im nächsten jährlichen Penetrationstest taucht die neue Schnittstelle nicht auf.
Neun Monate nach der Integration kommt es zu einem Ausfall in der Lieferkette. Die Schnittstelle zum Zahlungsdienstleister fällt für vier Stunden aus. Ein geschäftskritischer Prozess steht still. Kunden beschweren sich. Regulatorische Fristen werden verpasst.
Die Geschäftsleitung fragt in der Nachbesprechung: «Warum wurde dieses Risiko beim Penetrationstest nicht erkannt?»
Die Antwort des IT-Teams: «Der Drittanbieter war kein Teil des Testumfangs.»
1
Welche impliziten Annahmen über «Sicherheit» haben die beteiligten Teams getroffen?
Ihre Antwort ↓
2
Warum konnte ein klassischer Penetrationstest dieses Risiko strukturell nicht identifizieren?
Ihre Antwort ↓
3
Welche technischen und organisatorischen Abhängigkeiten wurden übersehen — und warum?
Ihre Antwort ↓
4
Wo liegt das eigentliche Versagen: in der Technik, im Prozess oder in der Governance?
Ihre Antwort ↓
5
Welche Hinweise im Szenario deuten auf eine systemische — nicht rein technische — Ursache hin?
Ihre Antwort ↓
Technischer Fehler — der Drittanbieter hatte eine unbekannte Schwachstelle
Team- oder Schnittstellenproblem — Kommunikation zwischen Projektteam und Security hat versagt
Struktureller Fehler: ungeeignetes Test- und Resilienzverfahren — klassische Penetrationstests erfassen keine systemischen Abhängigkeiten empfohlen
Stress- oder Überlastungsreaktion — das Projektteam hat unter Zeitdruck gehandelt
→
Begründung Ihrer Wahl
Ihre Begründung ↓
Risikobasiertes, mehrschichtiges Resilienztestprogramm etablieren (Szenario-, Failover-, End-to-End- und Drittanbieter-Ausfalltests); bei behördlicher Auswahl bzw. entsprechender Risikolage zusätzlich TLPT nach Art. 26–27 — TLPT ersetzt die übrigen Verfahren nicht
Integration von Lieferketten und Drittparteien in Resilienz- und Testkonzepte — explizit und verpflichtend bei jeder neuen Abhängigkeit
Erhöhung der Anzahl klassischer Penetrationstests
Erweiterung der Risikobewertung um Geschäftsprozess- und Drittanbieter-Abhängigkeiten
Gemeinsame Szenario-Workshops mit kritischen Drittparteien zur Simulation von Ausfallszenarien
Disziplinarmaßnahmen gegen die Projektverantwortlichen
Welche Annahme über Sicherheit war in diesem Fall besonders gefährlich — und warum halten so viele Organisationen trotzdem an ihr fest?
Denken Sie dabei nicht nur an das Szenario, sondern auch an Ihre eigene Organisation. Wo könnte dieselbe Annahme gerade wirksam sein — ohne dass jemand sie explizit benennt?
1 · Implizite Annahmen über Sicherheit
Die Hauptannahme: Bestandene Tests bedeuten Sicherheit. Das Projektteam nahm an, dass die neue Drittanbieter-Anbindung durch das bestehende Testregime abgedeckt sei — ohne das je zu überprüfen. Der CISO nahm an, dass neue Abhängigkeiten automatisch im Testumfang auftauchen. Das Management nahm an, dass ein sauberer Testbericht ein sauberes Risikoprofil bedeutet. Alle drei Annahmen sind falsch — und keine wurde explizit kommuniziert.
2 · Strukturelle Grenzen klassischer Penetrationstests
Klassische Penetrationstests prüfen definierte Systeme gegen bekannte Angriffsmuster. Sie testen, ob eine Schwachstelle vorhanden ist — nicht, wie das System auf einen realen Ausfall oder eine reale Angriffskette reagiert. Was sie strukturell nicht erfassen: neue Abhängigkeiten, die nach dem letzten Test entstanden sind; Drittanbieter-Schnittstellen außerhalb des Testumfangs; systemische Ausfallkaskaden über Organisationsgrenzen hinweg; die Reaktionsfähigkeit von Menschen und Prozessen. Das ist keine Schwäche der Methode — es ist ihre Grenze. DORA adressiert diese Grenze durch szenariobasiertes Resilienztesting (Art. 24–27).
3 · Übersehene Abhängigkeiten
Technisch: Die API-Schnittstelle zum Zahlungsdienstleister und deren Ausfallverhalten — kein Failover, kein Timeout-Handling, keine Alternativroute. Organisatorisch: Das Projektteam hat die neue Abhängigkeit eingeführt, ohne das Security-Team oder den CISO in den Integrationsprozess einzubinden. Es gab keinen Prozess, der eine neue Drittanbieter-Abhängigkeit automatisch in die Risikoanalyse und den Testumfang überführt. Genau diesen Prozess verlangen DORA Art. 28(3) (laufende Aktualisierung des ICT-Registers), Art. 28(4) (Risikobewertung neuer Abhängigkeiten) und Art. 30 (vertragliche Mindestanforderungen, einschließlich Auditrechte).
4 · Wo liegt das eigentliche Versagen?
Der unmittelbare Fehler ist methodisch — das Testverfahren erfasst keine systemischen Abhängigkeiten. Die zugrundeliegende Ursache liegt aber in der Governance: Es fehlte ein verbindlicher Mechanismus, der bei jeder neuen Drittanbieter-Abhängigkeit automatisch eine Risikobewertung und eine Testumfang-Prüfung auslöst. Dieser Mechanismus ist keine Frage von Technik oder individuellem Prozesswissen — er ist eine Frage von Governance-Struktur: Wer entscheidet wann, dass eine neue Abhängigkeit das bestehende Resilienz-Testregime verändert? Unter DORA Art. 5 liegt diese Verantwortung beim Leitungsorgan.
5 · Systemische Ursachen im Szenario
Zwei Hinweise sind besonders aufschlussreich: Erstens — «Die neue Abhängigkeit wurde nicht in bestehende Test- und Risikoprozesse integriert». Das ist kein Vergessen, sondern ein strukturelles Fehlen: Es gab keinen Prozess, der das hätte erzwingen sollen. Zweitens — «Im nächsten jährlichen Penetrationstest taucht die Schnittstelle nicht auf». Das zeigt, dass das Testregime statisch ist: Es prüft, was beim letzten Mal geprüft wurde — nicht, was jetzt relevant ist. Beide Punkte deuten nicht auf einen Einzelfehler, sondern auf ein System, das keine Mechanismen hat, um sich selbst aktuell zu halten.
Reflexionsfrage · Modell-Antwort
Die gefährlichste Annahme ist: «Wenn der Test bestanden ist, sind wir sicher.» Sie ist gefährlich, weil sie in beide Richtungen falsch ist — ein bestandener Test belegt nicht Sicherheit, und ein nicht bestandener Test ist kein vollständiges Bild der Risiken. Organisationen halten an ihr fest, weil sie einfach, kommunizierbar und entlastend ist. Ein sauberer Testbericht erlaubt es dem Management zu sagen: «Wir haben geprüft.» Systemische Resilienz ist schwieriger zu messen, schwieriger zu kommunizieren — und erzeugt Fragen, auf die man keine bequemen Antworten hat. DORA zwingt Organisationen, diesen Komfort aufzugeben: Art. 24 verlangt Tests, die tatsächlich das testen, was im Ernstfall relevant ist — nicht das, was technisch gut abschneidet.
Aufgabenblatt 2
DORA Art. 17–23
Die falsche Einstufung
Incident-Klassifikation — wenn vier Teams denselben Vorfall vier verschiedene Probleme nennen
Ein Zahlungsdienstleister erlebt einen 45-minütigen Ausfall seines Authentifizierungsdienstes. Während des Ausfalls können Kunden sich nicht einloggen. Transaktionen, die auf laufenden Sessions basieren, werden abgebrochen. Mehrere Unternehmenskunden melden sich beim Support. Zwei regulatorische Fristen werden verpasst, weil ein automatisierter Meldeprozess den Authentifizierungsdienst benötigt.
Nach Behebung des Ausfalls beurteilen vier Teams den Vorfall unterschiedlich:
IT Operations: «Technisches Timeout auf einem Load Balancer. Bekanntes Muster, wurde behoben. Kein Sicherheitsvorfall.»
Legal: «Keine Datenschutzverletzung, keine Datenlecks. Kein meldepflichtiger Vorfall nach DSGVO.»
Customer Success: «Beschwerden sind eingegangen. Wir haben kommuniziert. Das ist erledigt.»
Risikomanagement: «Das war ein normaler Betriebsvorfall. Melden wäre ein Eingeständnis von Schwäche gegenüber dem Regulator.»
Ergebnis: Kein Team meldet den Vorfall. Kein Team dokumentiert die Klassifikationsentscheidung. Sechs Wochen später fragt die Aufsichtsbehörde nach dem Vorfall — auf Basis einer Kundenbeschwerde.
1
Welche DORA-Kriterien hätten geprüft werden müssen, um festzustellen, ob dieser Vorfall meldepflichtig ist?
Ihre Antwort ↓
2
Warum kommen vier Teams zu vier verschiedenen Einschätzungen — und welche Einschätzung ist am gefährlichsten?
Ihre Antwort ↓
3
Was ist das Problem mit «keine Datenschutzverletzung = kein meldepflichtiger Vorfall»?
Ihre Antwort ↓
4
Welche Governance-Lücken zeigt die Reaktion der vier Teams — und wer trägt dafür die Verantwortung?
Ihre Antwort ↓
5
Was hätte das Unternehmen tun müssen — auch wenn es zu dem Schluss käme, dass der Vorfall nicht meldepflichtig ist?
Ihre Antwort ↓
Technischer Fehler — der Load Balancer hätte mit besserer Architektur nicht ausgefallen
Kommunikationsproblem — die vier Teams haben sich nicht koordiniert
Struktureller Fehler: fehlende Incident-Klassifikationsmatrix und unklare Governance-Kette — niemand war berechtigt und verpflichtet, die DORA-Schwellenwerte zu prüfen und eine verbindliche Entscheidung zu treffen empfohlen
Kulturelles Problem — das Unternehmen scheut Transparenz gegenüber der Aufsicht
→
Begründung Ihrer Wahl
Ihre Begründung ↓
Incident-Klassifikationsmatrix einführen: vordefinierte Schwellenwerte (Dauer, betroffene Nutzer, Prozessauswirkung, wirtschaftliche Wirkung) mit automatischer Prüfpflicht
Governance-Kette definieren: Wer bewertet, wer entscheidet, wer meldet — mit namentlicher Benennung und Eskalationsweg
Technische Verbesserung des Load Balancers zur Vermeidung zukünftiger Ausfälle
Dokumentationspflicht für Nicht-Meldungen: Jeder Incident, der geprüft und nicht gemeldet wird, wird mit Begründung dokumentiert
Kritikalität aller Services festlegen: Welche Dienste unterstützen kritische oder wichtige Funktionen — und welche Ausfallzeiten lösen welche Pflichten aus?
Ausweitung der Kommunikations-SLAs mit Kunden zur Verbesserung der Wahrnehmung
DORA verlangt keine perfekte Klassifikation — sondern eine nachvollziehbare Entscheidung. Was ist der Unterschied — und warum ist er für die Praxis entscheidend?
Denken Sie dabei an die Risikomanagement-Aussage im Szenario: «Melden wäre ein Eingeständnis von Schwäche.» Was verrät diese Aussage über das Verständnis von DORA im Unternehmen?
1 · Relevante DORA-Kriterien für die Meldepflicht
DORA Art. 18 definiert Kriterien für die Klassifikation als schwerwiegenden Vorfall. Relevant im Szenario: Dauer und Auswirkung (45 Minuten Ausfall eines Authentifizierungsdienstes); betroffene Kunden (Kunden konnten sich nicht einloggen, Transaktionen wurden abgebrochen); Auswirkungen auf kritische Prozesse (verpasste regulatorische Fristen durch den ausgefallenen Meldeprozess); wirtschaftliche Auswirkungen (abgebrochene Transaktionen). Die Meldepflicht-Entscheidung erfordert eine Bewertung gegen diese Schwellenwerte — keine isolierte DSGVO-Prüfung, keine rein technische Fehleranalyse.
2 · Vier Teams, vier Einschätzungen
Jedes Team bewertet den Vorfall durch die Linse seiner eigenen Verantwortlichkeit: IT Operations prüft technische Schwere. Legal prüft Datenschutzrecht. Customer Success prüft Kundenkommunikation. Risikomanagement prüft Reputationsrisiko. Keine dieser Prüfungen entspricht der DORA-Logik, die nach Auswirkungen auf kritische oder wichtige Funktionen fragt. Am gefährlichsten ist die Aussage des Risikomanagements: «Melden wäre ein Eingeständnis von Schwäche.» Sie zeigt ein grundlegendes Missverständnis: DORA verlangt keine Selbstbezichtigung, sondern Transparenz als Element von Governance-Reife. Eine fristgerechte, vollständige und sachgerechte Meldung zeigt funktionierende Governance; ebenso wichtig ist, nicht meldepflichtige Vorfälle korrekt zu klassifizieren und intern zu behandeln. Gemeldet wird, weil die gesetzlichen Kriterien erfüllt sind — nicht als symbolische Vertrauensgeste.
3 · «Keine DSGVO-Verletzung = kein meldepflichtiger Vorfall»
Das ist ein Kategorienfehler. DSGVO und DORA haben unterschiedliche Meldetatbestände. Die DSGVO-Meldepflicht betrifft Datenschutzverletzungen. Die DORA-Meldepflicht betrifft Auswirkungen auf die ICT-Verfügbarkeit, -Integrität und den Geschäftsbetrieb — unabhängig davon, ob personenbezogene Daten betroffen sind. Ein Ausfall, der keine Datenschutzverletzung ist, kann trotzdem ein schwerwiegender ICT-Incident nach DORA sein. Die Aussage von Legal ist rechtlich korrekt — für die DSGVO. Für DORA ist sie nicht relevant.
4 · Governance-Lücken und Verantwortung
Drei Lücken sind sichtbar: Erstens — keine Incident-Klassifikationsmatrix mit DORA-Schwellenwerten. Niemand hatte eine Grundlage, gegen die er den Vorfall hätte prüfen können. Zweitens — keine definierte Governance-Kette: Wer ist zuständig für die Meldepflicht-Entscheidung? Vier Teams haben geantwortet — keines hatte die Kompetenz und den Auftrag, verbindlich zu entscheiden. Drittens — keine nachvollziehbare Dokumentation von Nicht-Meldungen. Auch eine Entscheidung gegen eine Meldung sollte dokumentiert werden (geprüfte Kriterien, zugrunde gelegte Daten, Entscheider, Zeitpunkt einer Neubewertung). Das ist zentrale Governance- und Nachweispraxis aus Incident-Management und internem Kontrollsystem — Art. 20 DORA enthält allerdings keine eigenständige Pflicht mit diesem Wortlaut (Art. 20 beauftragt die ESAs mit technischen Standards; die Meldedetails konkretisiert u. a. die Delegierte Verordnung 2025/301). Die Gesamtverantwortung für einen wirksamen Governance-, Risiko- und Kontrollmechanismus liegt nach Art. 5 beim Leitungsorgan; die operative Klassifikation kann delegiert werden, muss aber klar zugeordnet und eskalierbar sein.
5 · Was auch bei Nicht-Meldung hätte passieren müssen
DORA verlangt keine perfekte Klassifikation — aber eine nachvollziehbare Entscheidung. Das bedeutet konkret: Die DORA-Kriterien für schwerwiegende Incidents wurden geprüft. Die Prüfung ist dokumentiert. Die Entscheidung, nicht zu melden, ist begründet und namentlich verantwortet. Das Incident-Log enthält den Vorfall. Legal und Compliance waren eingebunden. Wenn die Aufsicht sechs Wochen später fragt, kann das Unternehmen zeigen: «Wir haben geprüft — hier ist die Dokumentation.» Ohne diese Dokumentation ist die Frage der Aufsicht nicht «Warum haben Sie nicht gemeldet?» sondern «Haben Sie überhaupt geprüft?» Das ist eine deutlich schwierigere Ausgangslage.
Reflexionsfrage · Modell-Antwort
Der Unterschied ist präzise: Perfekte Klassifikation bedeutet, dass die Entscheidung im Nachhinein als richtig bewertet wird. Nachvollziehbare Entscheidung bedeutet, dass der Prozess, der zur Entscheidung geführt hat, rekonstruierbar und begründet ist — unabhängig vom Ergebnis. DORA fordert Letzteres. Eine falsch klassifizierte Entscheidung, die dokumentiert und begründet ist, ist besser als eine richtig klassifizierte Entscheidung, die nirgendwo festgehalten wurde. Die Aussage «Melden wäre ein Eingeständnis von Schwäche» zeigt, dass das Risikomanagement DORA als Reputationsmanagement-Instrument versteht — nicht als Governance-Rahmen. Das ist das eigentliche Problem: Nicht das Nicht-Melden, sondern die falsche Grundannahme darüber, wofür Transparenz gegenüber der Aufsicht da ist.