Zum Inhalt springen
Resilience Platform Resilience Platform

DORA Chapter VII

Meeting Notification Deadlines.

DORA defines reporting and notification obligations for incidents, significant outsourcing, and material changes. A structured reporting architecture reduces regulatory risk and accelerates crisis management.

Hinweis: Diese Seite stellt eine originäre Zusammenstellung praktischer Umsetzungshinweise für DORA dar. Sie dient ausschließlich der internen Strukturierung und Planung und erhebt keinen Anspruch auf Vollständigkeit oder Rechtsverbindlichkeit. Es wird keine Rechtsberatung angeboten.

Incident Notification Simulator

Wählen Sie die korrekte Meldefrist für jedes Szenario gemäß DORA Art. 19

Incident Type Severity Korrekte Frist Ihre Auswahl Feedback
Punktestand

/

Management-Zusammenfassung

  • Meldepflichten nach Art. 19 DORA (Vorfallsmeldung an Aufseher) sind mit definierten Eskalationsstufen und Fristen abgebildet.
  • Anzeigepflichten nach Art. 20 DORA (erhebliche Auslagerungen, wesentliche Änderungen) werden vorab geprüft und dokumentiert.
  • Drittdienstleister-Meldungen nach Art. 25 DORA sind vertraglich und prozessual an das interne Meldewesen angebunden.
  • Großvorfälle nach Art. 26 DORA werden mit Cross-Funktions-Workflows (IT, Compliance, Kommunikation) in maximal 4 Stunden initial gemeldet.

Sollzustand

  • Vorfallsmeldung (Art. 19): Klassifizierung nach Schweregrad (Major/Significant/Minor), Eskalationsmatrix, 2-Stunden-Initialmeldung bei Major, 24-Stunden-Update-Zyklen.
  • Anzeigepflichten (Art. 20): Erhebliche Auslagerungen und wesentliche Änderungen werden vor Umsetzung im Gremium geprüft und mit Begründung dokumentiert.
  • Drittdienstleister-Meldung (Art. 25): Lieferanten melden Vorfälle eigenständig; Meldewege, Inhalte und Zeiträume sind vertraglich und in SLAs verankert.
  • Großvorfall (Art. 26): Cross-Funktions-Team (CISO, Compliance, Recht, Kommunikation) aktiviert innerhalb von 4 Stunden; regulatorische Meldung folgt nach definiertem Schema.
  • Dokumentation: Jede Meldung ist mit Nachweis (Log, Timeline, Impact-Analyse, Maßnahmen) archiviert und revisionssicher aufbewahrt.

Umsetzungsschritte

  • 1. Meldepflichten-Katalog erstellen: Art. 19, 20, 24, 25, 26 mit Fristen, Empfängern und Inhaltsanforderungen je Meldetyp.
  • 2. Meldeprozess designen: Klassifizierungslogik (Major/Significant/Minor), Eskalationsstufen, Verantwortliche pro Stufe, Kommunikationskanäle.
  • 3. Templates und Formulare vorbereiten: Vorfallsmeldung, Update-Meldung, Abschlussbericht, Drittdienstleister-Meldung, Anzeige erheblicher Änderung.
  • 4. IT-Integration: Anbindung an SIEM/Ticketing-Systeme für automatisierte Klassifizierung, Erinnerung und Eskalation; API-Schnittstelle zu Aufseher-Portalen prüfen.
  • 5. Schulung und Simulation: Halbjährliche Tabletop-Übungen für Major-Vorfall-Szenarien; Schulung aller Meldeverantwortlichen.
  • 6. Review und Optimierung: Quartalsweise Auswertung der Meldezeiten, Qualität der Meldungen, Lessons-Learned-Integration.

Typische Lücken & ISO/IEC 27001-Verbindung

  • Unklare Vorfalls-Klassifizierung: fehlende einheitliche Kriterien führen zu unter- oder übermeldung; Abhilfe: definierte Schweregrad-Matrix mit quantitativen und qualitativen Kriterien.
  • Fristen nicht eingehalten: manuelle Prozesse, fehlende Erinnerungen; Abhilfe: automatisierte Workflow-Engine mit Eskalation.
  • Unvollständige Meldungen: fehlende Impact-Analyse oder Maßnahmen; Abhilfe: Template-gesteuerte Meldung mit Pflichtfeldern.
  • ISO/IEC 27001:2022: A.5.24 (Planung und Vorbereitung auf Informationssicherheitsvorfälle), A.5.25 (Bewertung und Entscheidung über Informationssicherheitsvorfälle), A.5.26 (Reaktion auf Informationssicherheitsvorfälle), A.5.27 (Lernen aus Informationssicherheitsvorfällen), A.8.15 (Protokollierung), A.8.16 (Überwachung).