FÜHRUNGSKRÄFTE-CYBERSECURITY-TRAINING · DORA

DORA · Berichte des Gremiums

DORA Board Reporting: Kennzahlen, Nachweise und ein Dashboard

Ein praxisnaher Leitfaden, um Resilienz-Daten in Entscheidungen zu übersetzen, die Vorstände nachvollziehen, hinterfragen und weiterverfolgen können.

Ein Laptop und Vorstandspapiere mit einem illustrativen Resilienz-Dashboard
Ein Laptop und Vorstandspapiere mit einem illustrativen Resilienz-Dashboard. KI-generierte redaktionelle Illustration.

Die Kurzantwort

Ein nützlicher DORA-Board-Report erklärt, welche Geschäftsdienste exponiert sind, was Tests tatsächlich gezeigt haben, welche Annahmen unbewiesen bleiben und was das Management entscheiden muss. Beginnen Sie mit Serviceauswirkung, Wiederherstellungsleistung, Anbieterabhängigkeiten, Vorfällen, überfälligen Behebungen und Lerndokumentation. Geben Sie für jede Kennzahl Definition, Nenner, Verantwortlichen, Berichtsdatum und verknüpfte Nachweise an. Das untenstehende Dashboard ist ein originelles Arbeitsbeispiel, kein vorgeschriebenes regulatorisches Template. Passen Sie es Ihrer Einheit, den geltenden Anforderungen und Governance-Vorgaben an und halten Sie die Diskussion und Entscheidungen neben den Zahlen fest.

1. Beginnen Sie mit den Entscheidungen, die der Vorstand treffen muss

Eine Vorstandspräsentation kann alle erfassten Sicherheitskennzahlen der Organisation enthalten und trotzdem die wichtigste Frage nicht beantworten: Kann das Unternehmen seine Kunden weiterhin bedienen, wenn etwas schiefgeht? Ein Bericht rechtfertigt seinen Platz in der Sitzung, wenn er eine wesentliche Unsicherheit offenlegt, einen Zielkonflikt erklärt oder eine Entscheidung zu Ressourcen, Prioritäten oder Risiken unterstützt.

Fragen Sie: Was hat sich seit dem vorherigen Meeting geändert? Welcher kundenorientierte Service könnte nun in einer für die Organisation nicht akzeptablen Weise ausfallen? Welche Entscheidung ist heute erforderlich? Stellen Sie die Antworten vor die unterstützenden Grafiken. Ein Vorstand sollte eine dringende Finanzierungsentscheidung nicht aus einer roten Zelle auf Seite dreißig ableiten müssen.

Im allgemeinen IKT-Rahmen bezieht sich Artikel 5 auf die Verantwortung der Leitungsgremien und regelmäßige Schulungen; Artikel 6 behandelt den Risiko-Rahmen und dessen Überprüfung; Artikel 13(5) verlangt mindestens jährliche Berichte leitender IKT-Verantwortlicher über festgestellte Sachverhalte und Empfehlungen. Siehe DORA, Artikel 5, 6 und 13.

Diese Vorgaben schreiben kein genehmigtes Dashboard oder ein einheitliches monatliches Vorstandspaket vor. Wählen Sie für Berichte eine dem Risikoexposure und Ihrer Governance angemessene Frequenz mit Eskalationswegen zwischen Sitzungen für dringende Themen. Grenzen Sie gesetzliche Berichterstattung, Aufsichtsanforderungen und internes Management-Reporting klar voneinander ab. Dieser Leitfaden gibt einen praktischen Vorschlag und ersetzt nicht die spezifische Prüfung Ihrer Pflichten. Zur übergreifenden Zuordnung der Verantwortlichkeiten lesen Sie unseren Leitfaden zu DORA Verantwortlichkeiten des Gremiums.

2. Berichten Sie strukturiert nach Diensten und Geschäftsauswirkungen

Starten Sie mit einer kurzen Liste von Geschäftsleistungen, die den Vorständen bekannt sind: eine Zahlung ausführen, ein Investmentkonto aufrufen, eine Transaktion abwickeln oder einen Versicherungsfall erhalten. Ordnen Sie diese der Bewertung kritischer oder wichtiger Funktionen Ihrer Organisation zu. Ersetzen Sie nicht stillschweigend eine Geschäftssicht durch eine Applikationsliste. Ein Dienst kann mehrere Anwendungen, Teams, Standorte und externe Anbieter umfassen.

Berichten Sie entlang eines Geschäftsprozesses: Wichtiger Service; Kunde betroffen; Wiederherstellungsfähigkeit; Lieferantenexponierung; Entscheidung erforderlich.
Vorgeschlagene Berichtstruktur: Stellen Sie Servicekonsequenzen vor technischen Messwerten dar.

Für jeden Service bestimmen Sie eine(n) betriebsverantwortliche(n) Person und beschreiben Sie die Folgen einer Störung. Beziehen Sie betroffene Kunden oder Transaktionen, zeitkritische Fristen, manuelle Ersatzprozesse und den Punkt, an dem Rückstände schwer abzuarbeiten sind, ein. Unterscheiden Sie gemessene Auswirkungen von Schätzungen. Sind Kundenanzahlen unvollständig, benennen Sie die Unsicherheit statt eines scheinbar präzisen Gesamtwerts.

Eine nützliche Dienst-Zeile kombiniert Exponierung und Nachweis: das Haupt-Fehlerszenario, das Wiederherstellungsziel, den letzten relevanten Test und die verbleibende Schwäche. Eine erfolgreiche Datenbankwiederherstellung liefert wenig Aussagekraft für den Zahlungsdienst, wenn Identitätszugang, Abstimmung und ausgehende Konnektivität im Test fehlten.

Machen Sie Änderungen sichtbar. Ein neuer Anbieter, eine Übernahme, Produkteinführung oder Migration kann die bisherige Servicelandkarte ungültig machen. Markieren Sie eine Bewertung als aktualisierungsbedürftig, wenn eine wesentliche Abhängigkeit sich ändert. Andernfalls kann das Dashboard weiterhin visuell grün bleiben, obwohl die Belege ein Betriebsmodell beschreiben, das nicht mehr existiert.

Halten Sie technische Detailinventare über kontrollierte Links verfügbar. Die Vorstandsseite sollte Konsequenzen und Entscheidungen erklären; die Nachweisschicht muss es Prüfern ermöglichen, diese Aussagen zurück bis zu den verantwortlichen Teams zurückzuverfolgen.

3. Definieren Sie jede Kennzahl, bevor Sie ihr eine Farbe zuordnen

Ein Prozentsatz ohne Nenner lädt zu Missverständnissen ein. „Recovery-Tests abgeschlossen: 90 %“ könnte neun von zehn geplanten Übungen, neun von zehn Geschäftsdiensten oder neun von zehn Anwendungen bedeuten. Diese Aussagen beschreiben Verschiedenes. Schreiben Sie Zähler und Nenner an die Kennzahl und machen Sie ausgeschlossene Elemente sichtbar.

Definieren Sie die Kennzahl vor der Farbe: Zweck; Umfang und Nenner; Quelle und Datum; Schwelle; Verantwortlicher und Maßnahme.
Vorgeschlagenes Metrik-Lexikon: Eine Farbe ohne Kontext zu Gültigkeitsbereich, Quelle und Entscheidungsrahmen ist schwache Evidenz.
  • Zweck: Die Entscheidungs- oder Risiko-Frage, die die Kennzahl beantworten soll.
  • Population: die einbezogenen Dienste, Systeme, Anbieter oder Personen, sowie Ausschlüsse.
  • Berechnung: genauer Zähler, Nenner, Einheit und Umgang mit fehlenden Daten.
  • Rechenschaftspflicht: Der Geschäftsinhaber, Datenproduzent und Prüfer.
  • Zeitpunkte: Beobachtungszeitraum, Extraktionsdatum, Prüftermin und nächste Aktualisierung.
  • Nachweis: Das kontrollierte Protokoll, das das Ergebnis und seine Version stützt.
  • Eskalation: Die intern vereinbarte Schwelle und die von einer Überschreitung ausgelöste Aktion.

Trennen Sie „nicht getestet“, „Test nicht bestanden“ und „kein Nachweis verfügbar“. Werden diese in einem einzigen Grün- oder Gelb-Status zusammengefasst, bleibt der notwendige Arbeitsaufwand verborgen. Zeigen Sie absolute Zahlen neben Prozentwerten, damit kleine Bestände kein falsches Vertrauen schaffen. Eine Veränderung von einer auf zwei überfällige Maßnahmen ist eine Verdopplung, deren Bedeutung jedoch von betroffenem Service und Schweregrad abhängt.

Wahren Sie Vergleichbarkeit. Wenn sich der Nenner nach einer Übernahme erweitert, zeigen Sie sowohl die neue Population als auch den Grund für die Diskontinuität. Interpretieren Sie einen gesunkenen Abschlussprozentsatz nicht ohne Überprüfung des Umfangs als Verschlechterung der Ausführung.

4. Trennen Sie Wiederherstellungsziele von gezeigter Leistung

Das Recovery Time Objective (RTO) beschreibt die Zielzeit zur Wiederherstellung eines Dienstes oder einer Funktion nach einer Störung. Das Recovery Point Objective (RPO) gibt das zulässige Datenverlustfenster in Zeit an. Beides beweist keine echte Wiederherstellung. Ziel und beobachtetes Ergebnis müssen getrennt mit Szenario, Umfang und Messgrenzen berichtet werden.

Zwei verschiedene Wiederherstellungsziele: RTO · Recovery Time — Zielzeit für die Wiederherstellung des Dienstes; RPO · Recovery Point — Zielgrenze für Datenverlust, gemessen in Zeit.
Vergleichen Sie jedes Ziel mit separat gemessenem Testergebnis. Diese Zielwerte belegen keine nachgewiesene Wiederherstellungsfähigkeit.

Ein vierstündiges RTO bedeutet nicht, dass der Wiederherstellungsbefehl innerhalb von vier Stunden enden muss und der Abgleich später erfolgt. Definieren Sie, wann die Zeit beginnt und welches Geschäftskriterium sie beendet. Für das RPO dokumentieren Sie den letzten nutzbaren Wiederherstellungspunkt und ob Transaktionsabgleiche die Vollständigkeit bestätigt haben. Ein System kann schnell wieder anlaufen, aber mit zu alten oder unzuverlässigen Daten.

Im vollständigen Rahmen deckt Artikel 11(6) jährliche Tests des Kontinuitäts- bzw. Wiederherstellungsplans über alle Funktionen und wesentliche Änderungsanlässe ab. Artikel 24(6) verlangt jährliche angemessene Tests aller IKT-Systeme und Anwendungen, die kritische oder wichtige Funktionen unterstützen, ausgenommen Kleinstunternehmen. Siehe DORA Testvorgaben. Bestätigen Sie den unternehmensspezifischen Geltungsbereich, bevor Sie diese Anforderungen in einen Kalender überführen.

Delegierte Verordnung 2024/1774, Artikel 25, verknüpft Kontinuitätstests mit Geschäftsfolgen- und Risikoanalysen und verlangt, dass Defizite analysiert, adressiert und an das Leitungsorgan berichtet werden. Verknüpfen Sie in Ihrem Paket jedes nicht erreichte Ziel mit einem verantwortlichen Korrekturpunkt und einem Nachtest-Plan.

Führen Sie threat-led Penetration Testing, oder TLPT, gesondert durch. Es gilt für identifizierte Einheiten, nicht universell; Auswahlkriterien und Testanforderungen sind ausführlich beschrieben in Delegierte Verordnung 2025/1190, zusammen mit den DORA-Artikeln 26–27. Ein Tabletop, ein Schwachstellenscan oder ein gewöhnlicher Penetrationstest sollte nicht als TLPT bezeichnet werden. Berichten Sie, welche Art von Nachweis jede Übung tatsächlich liefert.

5. Anbieterkonzentration über Dienstabhängigkeiten visualisieren

Die Anzahl der Anbieter zeigt keine Konzentration. Drei Lieferanten können auf dieselbe Cloud-Region, Identitätsplattform oder Telekommunikationsroute angewiesen sein. Fragen Sie bei jedem wichtigen Dienst, welche Abhängigkeiten gemeinsam ausfallen könnten und ob die vorgeschlagene Alternative operativ unabhängig ist. Unterscheiden Sie vertragliche Alternativen von solchen, die konfiguriert, besetzt und erprobt wurden.

Die Leitlinie der EBA zum Informationsregister erklärt das Register der IKT-Vertragsverhältnisse und stellt Reporting-Ressourcen bereit. Nutzen Sie das Register als Eingabe für die Vorstandsübersicht. Ein vollständiges Register ist wertvoll, aber das Gremium benötigt dennoch eine Einordnung, was diese Beziehungen für die Servicekontinuität bedeuten.

Ein kompaktes Abhängigkeitsfeld kann zeigen, welche Dienste ein Anbieter unterstützt, das neueste Sicherheitsaudit, ungelöste Einschränkungen, den geschätzten Ausstiegszeitpunkt und den nächsten Entscheidungspunkt. Ein Ausstiegszeitpunkt bleibt ein Schätzwert, bis belastbare Arbeitsergebnisse vorliegen. Berücksichtigen Sie Datenextraktion, Migration, Qualifikationen, vertragliche Beschränkungen und Kundenumstellung und nicht nur den Austausch von Infrastruktur.

Stellen Sie eine entscheidungsorientierte Frage: Wenn dieser Anbieter ausfiele oder ungeeignet wäre, welcher Dienst würde zuerst eine Reaktion erzwingen und was würde einen geordneten Übergang verhindern? Weisen Sie fehlende Informationen und ungeklärte Abhängigkeitsverantwortlichkeiten ausdrücklich aus. Unsere DORA Leitfaden IKT-Drittrisiko Entwickelt die Fragen an Lieferanten und zu Verträgen ausführlicher.

6. Erklären Sie Vorfallstrends und das Alter ungeklärter Schwachstellen

Die Anzahl der Vorfälle benötigt Kontext. Ein Anstieg kann auf bessere Erkennung statt verschlechterte Resilienz hindeuten. Ein Rückgang kann auf eine unvollständige Datenbasis zurückzuführen sein. Geben Sie die verwendete Definition, den Beobachtungszeitraum, wesentliche Auswirkungen auf Dienste und eventuelle Änderungen bei den Erhebungsmethoden an. Interne Schweregrade dürfen nicht mit der aufsichtsrechtlichen Vorfallklassifizierung vermischt werden; ein Vorstandsbericht darf den Meldeprozess nicht stillschweigend umdefinieren.

Machen Sie offene Risiken sichtbar: Feststellung und Auswirkung; Verantwortlicher und Fälligkeitsdatum; Nachweis der Schließung; Unabhängige Überprüfung.
Vorgeschlagene Nachverfolgung für Korrekturmaßnahmen: Zeigen Sie Alter, Konsequenz und Zuständigkeit statt nur die Anzahl offener Aufgaben.

Aussagekräftige Übersichten umfassen Störungszeiten nach Dienst, Wiederholungsursachen, erfolglose Änderungen, Wiederherstellungsleistung und das Alter wichtiger Korrekturmaßnahmen. Für Erkennungs- oder Reaktionszeit-Kennzahlen wählen Sie konsistente Start- und Endereignisse. Durchschnitte können eine einzelne, langwierige Unterbrechung verschleiern: zeigen Sie die Spanne oder die wesentlichste Ausnahme, sofern sie die Entscheidung beeinflusst.

Maßnahmen aus Vorfällen, Tests, Audits und Lieferantenbewertungen in einer gemeinsamen Entscheidungsübersicht verfolgen und ihre Herkunft bewahren. Jeder Punkt benötigt einen Verantwortlichen, ursprüngliches Fälligkeitsdatum, aktuelles Fälligkeitsdatum, betroffenen Dienst, Nachweis zur Erledigung und einen Prüfer. Ein Ticket mit dem Status „Erledigt“ bedeutet nicht automatisch, dass die zugrunde liegende Schwäche beseitigt wurde.

Zeigen Sie Verlängerungen und erneut eröffnete Maßnahmen. Wird das Fälligkeitsdatum verschoben, kann sich das Überfällig-Diagramm verbessern, ohne das Risiko zu verringern. Notieren Sie, wer die Verlängerung genehmigt hat, den Grund, temporäre Schutzmaßnahmen und den nächsten Prüfungstermin. Die Konsequenzen der verbleibenden Schwachstelle sollten Vorrang vor der Schließung vieler wenig relevanter Tickets haben.

Beenden Sie das Panel mit einer kurzen Erklärung des wiederkehrenden Musters und des vorgeschlagenen Eingriffs. Wenn mehrere Vorfälle dieselbe Eigentumslücke sichtbar machen, könnte ein neues Dashboard weniger nützlich sein als eine klare operative Entscheidung.

7. Lernnachweise mit gezeigtem Urteilsvermögen verknüpfen

Abgeschlossene Schulungen sind ein nützlicher Nachweis für die Teilnahme, zeigen aber nicht, ob Gremienmitglieder optimistische Wiederherstellungszusagen hinterfragen oder schwierige Priorisierungsentscheidungen für Dienste treffen können. Kombinieren Sie Lernnachweise mit wenigen Praxisübungen. Lassen Sie die Beteiligten fehlende Nachweise identifizieren, Eskalationspunkte wählen und die Abwägungen in einer fiktiven Störung erklären.

Berichten Sie die Lernpopulation, zugewiesene Inhalte und Version, Abschlussdaten, Bewertungsansatz und weiterführende Anforderungen. Erfassen Sie Rollenwechsel und neu ernannte Mitglieder, um den Nenner korrekt zu halten. Falls jemand relevante Vorerfahrung besitzt, dokumentieren Sie, wie diese berücksichtigt wurde und welches organisationsspezifische Wissen noch behandelt werden muss.

Eine nützliche Lerndiskussion kann erkennen, dass Teilnehmende die Terminologie rund um Ransomware verstehen, jedoch nicht erklären können, wer eine Notfallausgabe genehmigen darf. Die Maßnahmen sind dann klar: Zuständigkeiten präzisieren, Plan anpassen und Anwendung üben. Vermeiden Sie es, einen Durchschnittwert im Quiz als Maß für die Resilienz der gesamten Organisation darzustellen.

Für die Programmgestaltung verwenden Sie unser Leitfaden zu DORA-Gremiumstrainingsanforderungen. Zur Übung, die Leitfaden zum Executive-Tabletop für die Incident Response zeigt, wie sich eine Unterbrechung in Entscheidungen und dokumentiertes Lernen umwandeln lässt. Halten Sie individuelle Lernnachweise angemessen eingeschränkt; das Board-Pack benötigt in der Regel Übersicht, Lücken und resultierende Maßnahmen, nicht jede einzelne Antwort der Teilnehmenden.

8. Ein fiktives Vorstands-Dashboard mit umsetzbaren Ausnahmen

Das folgende Beispiel ist vollständig fiktiv. Die Zahlen dienen als Veranschaulichung und sind keine Branchenbenchmarks, gesetzlichen Schwellenwerte oder Aussagen über reale Unternehmen. Angenommen, eine Finanzinstitution hat für diesen Bericht vier Services bestimmt. Das September-Paket verwendet den 30. September als Stichtag und benennt Beweisverantwortliche für das Follow-up.

Ein Dashboard sollte zu einer Entscheidung führen: Service · Was ist gefährdet?; Nachweis · Was wissen wir?; Ausnahme · Was bedarf Überprüfung?; Entscheidung · Wer agiert bis wann?
Ein Interpretationsleitfaden für das fiktive Dashboard unten. Es ist kein verbindliches regulatorisches Berichtsformular.
BereichBeobachtungNachweis und Verantwortlicher.Entscheidung oder Folgemaßnahme
ZahlungsrückgewinnungRTO 4 Stunden; beobachtet 5 Stunden 20 Minuten. RPO 15 Minuten; beobachtete Datenlücke 8 Minuten.18. September Wiederherstellungsübung; Betriebsleiter. Abstimmung eingeschlossen.Ressourcen für Abstimmungsautomatisierung freigeben; Nachtest bis 30. November.
Testabdeckung3 von 4 Diensten innerhalb des internen Meldefensters getestet; vierte Beweisführung steht noch aus.Serviceinventar und Testregister; Leiter für Resilienz.Bestätigen Sie den fehlenden Übungsumfang und Liefertermin; halten Sie unbekannten Status bis zur Prüfung fest.
Abhängigkeit vom Anbieter2 von 4 Diensten teilen einen Identitätsanbieter; alternatives Zugriffsverfahren ungetestet.Abhängigkeitskarte vom 12. September; Technologiedirektor.Veranlassen Sie eine kontrollierte Übung zum Zugriffsverlust mit Beteiligung aus dem Geschäftsbetrieb.
Behebung2 von 9 hochpriorisierten Maßnahmen überfällig; älteste seit 45 Tagen über dem ursprünglichen Fälligkeitsdatum.Aktionsprotokoll am 29. September überprüft; Risiko-Verantwortlicher.Entscheiden Sie über Finanzierung oder Eskalation; dokumentieren Sie vorläufige Schutzmaßnahmen und einen verantwortlichen Eigentümer.
Vorstandslernen7 von 8 zugewiesenen Mitgliedern haben das aktuelle Modul abgeschlossen; eine Onboarding-Session steht noch aus.Lernregister und Übungsnotizen; Unternehmenssekretär.Planen Sie die ausstehende Sitzung ein und prüfen Sie die Lücke in der Ausübungs- oder Entscheidungsbefugnis der Übung.

In diesem Beispiel wurde das Ziel für Datenverlust eingehalten, jedoch das Ziel für die Wiederherstellungszeit verfehlt. Würde man beides in einem einzigen Label „Recovery bestanden“ zusammenfassen, würde die Serviceverzögerung verschleiert. Die Zeile Abdeckung misst Dienste, nicht die vollständige Systemtest-Population; das zugrundeliegende Testregister muss diesen getrennten Scope beibehalten.

Die Tabelle behauptet auch nicht, dass ein unbekanntes Ergebnis ein fehlgeschlagener Test ist. Direktoren sehen, welche Unsicherheit Nachforschung erfordert und welche nachgewiesene Schwäche finanzierte Maßnahmen verlangt. Verknüpfen Sie jede Zeile mit ihrer kontrollierten Evidenz und führen Sie die Entscheidung in die nächste Präsentation weiter, bis das Ergebnis verifiziert ist.

9. Machen Sie den Bericht zu einem wiederholbaren Entscheidungsprozess

Dokumentieren Sie jede wesentliche Ausnahme mit einem kurzen Entscheidungsprotokoll. Beschreiben Sie den betroffenen Dienst, das Szenario, verfügbare Nachweise und verbleibende Unsicherheiten. Stellen Sie realistische Alternativen, deren Kosten oder Ressourcenbedarf, die Empfehlung der Geschäftsleitung und die Auswirkung einer Verzögerung dar. Benennen Sie die autorisierte Entscheiderin und das Entscheidungsdatum.

Beispielhafte Entscheidungsformulierung: Genehmigen Sie die vorgeschlagene Verbesserung der Wiederherstellung für den Zahlungsdienst, wobei der Betriebsleiter für die Ausführung verantwortlich ist. Fordern Sie einen erneuten Test an den definierten Zielen bis zum vereinbarten Termin. Dokumentieren Sie Zwischenmaßnahmen, verbleibende Risiken und Auslöser für Eskalationen. Leiten Sie das Ergebnis und die Nachweise an das nächste zuständige Gremium weiter.

Wird ein Risiko vorübergehend akzeptiert, dokumentieren Sie Begründung, Befugnis, Bedingungen und Ablauf dieser Akzeptanz. Akzeptanz ist eine Governance-Entscheidung; sie lässt eine nicht erfüllte rechtliche Verpflichtung nicht verschwinden. Ein pauschales Protokoll, dass der Vorstand „den Bericht zur Kenntnis genommen“ hat, liefert wenig Informationen zur Herausforderung, zu Alternativen oder zur Nachverfolgung.

  1. Vereinbaren Sie die Service-Population und ordnen Sie sie den geltenden Anforderungen und inneren Verantwortungen zu.
  2. Select a small starting set of metrics and write their definitions before automating collection.
  3. Weisen Sie Datenverantwortliche und Prüfer zu, mit einer Frist und einer expliziten Behandlung fehlender Nachweise.
  4. Stellen Sie eine Beispielmetrik ihrer Quelle gegenüber und prüfen Sie, ob die Darstellung dem zugrundeliegenden Ergebnis entspricht.
  5. Führen Sie eine Probe mit einer fiktiven Ausnahme durch und überprüfen Sie, ob das Paket eine klare Entscheidung ermöglicht.
  6. Protokollieren Sie die Entscheidung, kommunizieren Sie die Maßnahme und überprüfen Sie deren Wirkung in späteren Berichten.

Beginnen Sie mit einem verlässlichen Paket, dem widersprochen werden kann. Automatisieren Sie stabile Definitionen später. Für eine gemeinsame Grundlage im Aufsichtsgremium, DORA Board & Executive Training bietet das achtmodulige Akademie-Board-Programm mit etwa drei Stunden geleiteter Lernzeit. Verwenden Sie es im Rahmen eines breiteren Programms aus organisationsspezifischer Diskussion, Praxis und Nachbereitung; allein der Abschluss begründet keine regulatorische Compliance.

Fragen, die Führungskräfte stellen

Erfordert DORA ein spezielles Vorstands-Dashboard?

Kein einziges genehmigtes Dashboard ist vorgeschrieben. Das Design in diesem Artikel ist eine praktische Orientierung. Stimmen Sie Ihre Berichterstattung auf die für Ihre Organisation geltenden Pflichten und Governance-Vereinbarungen ab, bewahren Sie die zugrunde liegende Evidenz auf und machen Sie Entscheidungen nachvollziehbar.

Soll das Dashboard monatlich oder quartalsweise sein?

Wählen Sie den internen Berichterstattungszyklus auf Basis Ihres Risikos, Ihrer Entscheidungsbedarfe und Governance, während Sie die geltenden rechtlichen und aufsichtsrechtlichen Vorgaben einhalten. Definieren Sie eine dringende Eskalation außerhalb dieses Zyklus, damit wesentliche Entwicklungen nicht auf das nächste planmäßige Reporting warten müssen.

Reicht ein abgeschlossener Wiederherstellungstest aus, um Resilienz als grün zu markieren?

Überprüfen Sie zuerst Umfang, Szenario, Ziele, Beobachtungen und ungelöste Schwächen. Ein abgeschlossener Test kann eine Zielverfehlung demonstrieren. Eine erfolgreiche technische Wiederherstellung kann kundenrelevante Prozesse ausschließen, die für den Betrieb benötigt werden.

Kann ein Kursabschlussbericht den Nachweis der Compliance allein erbringen?

Nein. Es dokumentiert eine Lernaktivität. Kombinieren Sie dies mit einem geeigneten Programm, Nachweisen zum Verständnis, der spezifischen Übertragung auf Ihr Unternehmen und den erforderlichen Governance- und operativen Maßnahmen.

Quellen und weiterführende Informationen

Hauptgesetzgebung und aufsichtsrechtliches Material. Praktische Beispiele und Vorlagen in diesem Leitfaden sind Vorschläge, keine vorgeschriebenen regulatorischen Formulare.

  1. Verordnung (EU) 2022/2554 — DORA, insbesondere Artikel 5, 6, 11, 13 und 24–27
  2. Delegierte Verordnung (EU) 2024/1774 — Rahmenwerk für das IKT-Risikomanagement, insbesondere Artikel 24–27
  3. Delegierte Verordnung (EU) 2025/1190 — Auswahl und Anforderungen für threat-led Penetrationstests
  4. Europäische Bankenaufsichtsbehörde — DORA Informationsregister

Dieser Leitfaden dient der Schulung. Überprüfen Sie mit Ihrem Rechts- und Compliance-Team den Geltungsbereich, anzuwendenden Rahmen und aufsichtsrechtliche Anforderungen für Ihr Unternehmen.

← Zurück zu allen Leitfäden