IKT-Incident Response unter DORA: Detection, Klassifikation und Nachweise

Was DORAs Incident-Kapitel auf hoher Ebene erwartet

Artikel 17 setzt allgemeine Anforderungen an IKT-Incident-Management: Policies, Verfahren, Rollen und Werkzeuge zur Erkennung, Steuerung und Benachrichtigung bei IKT-bezogenen Vorfällen, proportional zu Größe und Risiko des Instituts.

Artikel 18 behandelt Klassifikation - Abgrenzung von Vorfällen, die unter den in EU-Level-2-Maßnahmen entwickelten Kriterien (einschließlich RTS zu Klassifikation und Meldung) major oder anderweitig signifikant sind. Artikel 19 betrifft die Meldung majorer IKT-Vorfälle an zuständige Behörden, mit Detail in delegierten Rechtsakten zu Inhalt und Fristen. Artikel 20-23 regeln Zwischen- und Schlussberichte, freiwillige Meldung und Informationsaustausch, soweit anwendbar.

Exakte Schwellen, Fristen und Berichtsvorlagen sind rechtliche und aufsichtsrechtliche Themen. Der Beitrag von Engineering: Klassifikationsinputs wahrheitsgemäß machen - Zeitstempel, betroffene Funktionen, Datenkategorien, Kundenausmaß, Logs, die die ersten Stunden eines Events überdauern.

Detection und Logging, die Klassifikation stützen

Wer den Beginn einer Anomalie nicht rekonstruieren kann, debattiert Klassifikation mit Mutmaßungen. Für cloud-gehostete kritische Funktionen kombiniert die Baseline-Detection typischerweise:

• ✓Zentralisierte Security- und Platform-Logs mit unveränderlichem oder WORM-fähigem Storage für die von Ihrer Policy geforderte Retention.
• ✓Alert-Routing mit On-call-Ownership - kein Shared Mailbox, das nachts niemand quittiert.
• ✓Korrelation zwischen Application-Metriken, Auth-Anomalien und Infrastruktur-Events für im IKT-Register als kritisch oder wichtig gemappte Services.
• ✓Runbooks, die benennen, wo Evidence gezogen wird (CloudTrail, Activity Logs, Kubernetes Audit, SaaS-Admin-Logs), bevor Logs rotieren.

Response-Verfahren vs. Tabletop-Übungen

Artikel 17 erwartet operative Verfahren, nicht nur Krisen-Slides. Ein in Produktion genutztes Runbook listet konkrete Schritte: contain, eradicate, recover, intern kommunizieren, forensische Kopien sichern, an Legal/Compliance für externe Meldeentscheidungen übergeben.

Tabletop-Übungen (Artikel 25 zu Testing stärkt zudem Resilienz-Kultur) prüfen, ob Runbooks zur Realität passen. Ein Tabletop ohne Log-Queries, Backup-Restore oder Comms-Templates erzeugt Vertrauen ohne Fähigkeit. Wechselnde Szenarien (Cloud-Region-Ausfall, IdP-Ausfall, Ransomware im Backup-Pfad) mit zeitgebundenen Entscheidungspunkten decken Lücken vor dem echten Incident auf.

Meldefristen: Engineering-Inputs, Legal-Entscheidungen

Artikel 19 und die umsetzenden Standards definieren, wann major Incidents gemeldet werden müssen und was Initial-, Zwischen- und Schlussberichte enthalten. Diese Uhren starten aus aufsichtsrechtlichen Definitionen von Kenntnis und Klassifikation - nicht ab dem ersten verdächtigen Metric in Engineering.

Platform-Teams sollten Detection-Zeit, Eskalationszeit und technische Fakten in einem Incident Record (Ticket oder IR-Tool) dokumentieren. Legal und Compliance mappen diesen Record auf Meldepflichten, Kundenkommunikation und BaFin- oder andere Behördenkanäle, wo anwendbar. Engineering sollte keine externen Regulierungsmeldungen selbst autorisieren; es soll die faktische Timeline verteidigbar machen.

Drittanbieter- und Cloud-Incidents

Viele major Incidents entstehen bei IKT-Drittanbietern - einschließlich Hyperscale-Cloud-Ausfällen oder SaaS-Abhängigkeiten im Artikel-28-Register. Vertragliche Kooperationsklauseln (Artikel 30) erwarten Unterstützung bei Vorfällen; operativ heißt das: Sie wissen, welche Status Page, Support-Stufe und Technical Account Teams zu jeder kritischen Funktion gehören, und haben Logs exportiert, bevor Provider-Retention-Fenster schließen.

Incident Records mit Register-Einträgen verknüpfen: welche Funktion ausfiel, welcher Vertrag, welches Recovery-Ziel. Dieser Join ist es, den Internal Audit und Aufsicht prüfen, ob Outsourcing-Governance zur Realität passt.

Was Stratoworks engineeriert - und was nicht

Wir implementieren zentrales Logging, Alert-Pfade, Backup-/Restore-Test-Nachweise und technische Runbooks für Ihre kritischen Workloads auf AWS, Azure und GCP. Wir moderieren Tabletops mit realistischen Cloud-Szenarien und aktualisieren IaC und Monitoring, wenn Lücken sichtbar werden.

Wir erteilen keine Rechtsberatung, klassifizieren Incidents nicht als „major“ unter DORA und reichen keine Berichte bei Behörden ein. Wir verkleinern die Lücke zwischen Engineering-Wissen und Legal-Entscheidung - mit Zeitstempeln, Logs und Verfahren, die Review standhalten.

FAQ