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.
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 ↓
Umstieg auf szenariobasiertes, Threat-Led Testing (TLPT / TIBER-EU)
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 verlangt DORA Art. 28: Das ICT-Register muss aktuell gehalten und neu entstehende Abhängigkeiten müssen bewertet werden.
4 · Wo liegt das eigentliche Versagen?
Das Versagen liegt primär in der Governance — nicht in der Technik oder im Prozess allein. 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.»
Operations: «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 wesentliche 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 Operations-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. Operations prüft Reputationsrisiko. Keine dieser Prüfungen entspricht der DORA-Logik, die nach Auswirkungen auf kritische oder wesentliche Funktionen fragt. Am gefährlichsten ist die Aussage von Operations: «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 proaktive Meldung stärkt die Aufsichtsbeziehung — eine nicht erfolgte Meldung, die später aufgedeckt wird, schwächt sie dauerhaft.
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 Dokumentationspflicht für Nicht-Meldungen. Das ist der gravierendste Punkt: DORA Art. 20 Abs. 5 verlangt, dass auch die Entscheidung, nicht zu melden, begründet und dokumentiert wird. Die Verantwortung liegt nach DORA Art. 5 beim Leitungsorgan — es muss sicherstellen, dass die Governance-Kette für Incident-Klassifikation steht.
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 Operations 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.