Einleitung
Mit der Verordnung (EU) 2022/2554 über die digitale operationale Resilienz im Finanzsektor (DORA) hat die Europäische Union einen verbindlichen Rechtsrahmen geschaffen, um die Widerstandsfähigkeit von Finanzunternehmen gegenüber IKT-Risiken systematisch zu stärken. Neben technischen und organisatorischen Anforderungen rückt ein bislang häufig unterschätzter Aspekt in den Mittelpunkt der Aufsicht: die systematische Dokumentation.
Die BaFin veröffentlichte am 17. Dezember 2024 eine Übersicht zu den Dokumentationsanforderungen nach DORA. Ziel ist es, die in der Verordnung sowie in den zugehörigen technischen Standards (RTS/ITS) verteilten Anforderungen strukturiert darzustellen und Finanzunternehmen eine Orientierungshilfe für die Umsetzung zu geben.
Für Compliance Manager und Wirtschaftsprüfer bedeutet dies:
- DORA ist nicht nur ein IT-Thema, sondern ein Governance-, Risiko- und Nachweisthema.
- Dokumentation wird zum zentralen Prüfobjekt.
- Eine klare Zuordnung von Dokumenten zu einzelnen Artikeln ist Voraussetzung für Audit- und Aufsichtsfähigkeit.
1. Bedeutung der Dokumentation unter DORA
DORA verpflichtet Finanzunternehmen, ihre IKT-Risiken aktiv zu steuern und diese Steuerung jederzeit nachweisen zu können. Dokumentation erfüllt dabei drei zentrale Funktionen:
Nachweisfunktion
- Beleg gegenüber Aufsichtsbehörden (BaFin, EZB)
- Beleg gegenüber Abschlussprüfern
- Beleg für interne Revision
Steuerungsfunktion
- Transparenz über Risiken, Abhängigkeiten und Schwachstellen
- Grundlage für Managemententscheidungen
- Kontrolle der Wirksamkeit von Maßnahmen
Lernfunktion
- systematische Auswertung von Vorfällen
- Ableitung von Verbesserungsmaßnahmen
- kontinuierliche Erhöhung der digitalen Resilienz
Dokumentation ist damit kein Nebenprodukt, sondern integraler Bestandteil des IKT-Risikomanagementrahmens.
2. Dokumentationsanforderungen gegliedert nach DORA-Artikeln (deutsche Fassung)
Die DORA-Verordnung (EU) 2022/2554 verpflichtet Finanzunternehmen nicht nur zur Einführung wirksamer organisatorischer und technischer Maßnahmen zur Steuerung von IKT-Risiken, sondern ausdrücklich auch zur systematischen Erstellung, Pflege und Aktualisierung einer umfangreichen Dokumentation. Diese Dokumentation bildet die zentrale Grundlage für die Nachweisführung gegenüber Aufsichtsbehörden und Wirtschaftsprüfern und ist zugleich Voraussetzung für eine wirksame interne Steuerung der digitalen operationalen Resilienz. Die nachfolgende Übersicht stellt die wesentlichen Dokumente dar, die sich unmittelbar aus den einzelnen Kapiteln und Artikeln der DORA-Verordnung ergeben. Sie dient als praxisorientierte Orientierungshilfe für Compliance Manager und Prüfer, um Vollständigkeit, Struktur und Prüfungsfähigkeit der DORA-Umsetzung sicherzustellen.
Im Kapitel 6 werden die erforderlichen Dokumente gemäß der DORA (deutsche Version) aufgeführt. Diese kann als Checkliste zur Vollständigkeit der Dokumentation herangezogen werden.
Dabei ist zu beachten, dass die Dokumente in jeder Organisation anders benannt und inhaltlich strukturiert sein können und die in Kapitel 8 genutzten Bezeichnungen synonym zu verwenden sind. Um den Überblick zu behalten, empfiehlt sich der Aufbau einer Dokumentenlandkarte als „Inhaltsverzeichnis“. Im nächsten Kapitel wird darauf eingegangen.
3. Umsetzung in der Praxis für Compliance Manager
Nachdem die Dokumentationsanforderungen artikelgenau strukturiert wurden, stellt sich für Compliance Manager die zentrale Frage, wie diese regulatorischen Vorgaben operativ, effizient und dauerhaft in bestehende Governance-, Risiko- und Compliance-Strukturen integriert werden können.
Die Umsetzung von DORA darf nicht als isoliertes IT- oder Cybersecurity-Projekt verstanden werden, sondern muss als integraler Bestandteil eines unternehmensweiten Compliance-Management-Systems (CMS) etabliert werden. Ziel ist der Aufbau eines konsistenten, prüfbaren und kontinuierlich gepflegten Steuerungssystems für digitale operationelle Resilienz.
Im Mittelpunkt steht dabei die Überführung der regulatorischen Anforderungen in klar definierte Compliance-Prozesse, die sich an bewährten CMS-Zyklusmodellen orientieren (Plan – Do – Check – Act).
3.1 Aufbau einer DORA-Dokumentenlandkarte als Compliance-Instrument
Ein zentrales Steuerungsinstrument für Compliance Manager ist die sogenannte DORA-Dokumentenlandkarte. Sie dient als Übersetzungslogik zwischen regulatorischem Text und internen Governance-Dokumenten.
Diese Dokumentenlandkarte bildet systematisch ab:
Artikel → Dokument → Inhalte → Prozess → Verantwortlich → Status → letzte Aktualisierung
Damit entsteht eine nachvollziehbare Compliance-Matrix, die sowohl für interne Steuerung als auch für Prüfungen durch Aufsichtsbehörden oder Wirtschaftsprüfer geeignet ist.
Beispielhafte Struktur:
- DORA-Artikel (z. B. Art. 6 IKT-Risikomanagement)
- zugehörige Dokumente (Policy, Verfahren, Arbeitsanweisungen)
- betroffene Compliance-Prozesse (Risikobewertung, Kontrollüberwachung, Reporting)
- Rollen (Compliance Officer, ISMS-Beauftragter, IT-Risikomanager)
- Review- und Freigabezyklen
- Evidenzen (Protokolle, Reports, Testnachweise)
Diese Landkarte fungiert als:
- Kontrollinstrument
- Steuerungsinstrument
- Nachweis gegenüber Aufsicht und Revision
- Grundlage für Gap-Analysen
3.2 Integration in bestehende Compliance-Management-Prozesse (CMS)
Die DORA-Anforderungen müssen in die bestehenden CMS-Kernprozesse integriert werden, nicht parallel dazu existieren.
a) Einbindung in den Compliance-Risikomanagementprozess
DORA-relevante Risiken (IKT-Risiken, Drittparteienrisiken, Resilienzrisiken) werden als eigene Risikokategorie im Compliance-Risikoinventar aufgenommen.
Typische Prozessschritte:
- Identifikation von DORA-Risiken
- Bewertung nach Eintrittswahrscheinlichkeit und Auswirkung
- Definition von Kontrollen und Maßnahmen
- Dokumentation im Compliance-Risikoregister
- regelmäßige Neubewertung
So wird DORA Bestandteil des unternehmensweiten Risikomanagements und nicht nur der IT-Abteilung.
b) Integration in den Richtlinien- und Policy-Prozess
Alle DORA-relevanten Dokumente (z. B. IKT-Risikostrategie, Incident-Management-Verfahren, Drittparteienmanagement) unterliegen dem formalen CMS-Dokumentenprozess:
- Erstellung nach einheitlichem Policy-Standard
- rechtliche und fachliche Prüfung
- Freigabe durch Management oder zuständiges Gremium
- Veröffentlichung im Dokumentenmanagementsystem
- Schulung der betroffenen Mitarbeiter
Damit wird sichergestellt, dass DORA-Dokumente denselben Governance-Regeln folgen wie andere Compliance-Richtlinien.
c) Integration in Kontroll- und Überwachungsprozesse
Compliance Manager müssen sicherstellen, dass die Einhaltung der DORA-Anforderungen regelmäßig überwacht wird. Dazu gehören:
- Definition von Key Compliance Controls (KCC) für DORA
- regelmäßige Kontrolltests (z. B. Incident-Reporting, Backup-Konzepte, Dienstleisterbewertungen)
- Dokumentation der Ergebnisse
- Ableitung von Maßnahmen bei Abweichungen
DORA wird damit Teil des laufenden Compliance-Monitorings und nicht nur ein Projekt zum Go-Live-Zeitpunkt.
3.3 Verzahnung mit ISMS und Risikomanagement
Die DORA-Dokumentation ist eng mit bestehenden Managementsystemen zu verzahnen:
a) ISMS (z. B. nach ISO/IEC 27001)
Viele DORA-Anforderungen überschneiden sich mit ISMS-Prozessen:
- Asset Management
- Risikoanalysen
- Incident Management
- Business Continuity
- Notfallübungen
Compliance Manager übernehmen hier eine koordinierende Rolle:
- Sicherstellung der regulatorischen Abdeckung
- Abgleich zwischen DORA-Artikeln und ISMS-Kontrollen
- Dokumentation der regulatorischen Konformität
- Nachweisführung für Prüfungen
b) Unternehmensweites Risikomanagement
DORA-relevante Risiken müssen konsistent in das Enterprise Risk Management (ERM) integriert werden:
- Harmonisierung der Bewertungsmethodik
- gemeinsame Risikoberichte
- Einbindung in Management-Reporting
- Abstimmung mit operativen Risiko-Ownern
Damit wird verhindert, dass parallele Risiko-Welten entstehen (IT vs. Compliance vs. Business).
3.4 Klare Verantwortlichkeiten im Compliance-Prozessmodell
Ein zentrales Element der praktischen Umsetzung ist die eindeutige Zuordnung von Verantwortlichkeiten entlang des Dokumenten- und Compliance-Lebenszyklus:
Rollenbezogene Verantwortlichkeiten:
- Erstellung (fachlicher Owner)
- Aktualisierung (Prozessverantwortlicher)
- Prüfung (Compliance / Legal / ISMS)
- Freigabe (Management, Ausschuss)
- Archivierung (Dokumentenmanagement)
- Monitoring (Compliance-Funktion)
Diese Rollen sollten formell festgelegt werden in:
- RACI-Matrizen
- Organisationsrichtlinien
- Governance-Dokumenten
- Prozessbeschreibungen
So wird sichergestellt, dass keine regulatorischen Anforderungen „verwaisen“.
3.5 Regelmäßige Reviews als Compliance-Kernprozess
DORA fordert explizit eine laufende Aktualisierung der Dokumentation. Für Compliance Manager bedeutet dies die Implementierung eines formellen Review-Prozesses:
- zyklische Überprüfung (z. B. jährlich oder anlassbezogen)
- Trigger-Ereignisse (Incidents, neue Dienstleister, neue IT-Systeme)
- Dokumentation der Review-Ergebnisse
- Management-Berichterstattung
- Nachverfolgung von Maßnahmen
Der Review-Prozess ist Bestandteil des kontinuierlichen Verbesserungsprozesses (KVP) im CMS.
3.6 Versionierung und revisionssichere Ablage
Alle DORA-relevanten Dokumente müssen:
- versioniert
- nachvollziehbar geändert
- revisionssicher archiviert
- zugriffsgesteuert abgelegt werden
Typische Compliance-Anforderungen:
- Änderungsverfolgung (wer, wann, warum)
- Historisierung alter Versionen
- Aufbewahrungsfristen
- Audit-Trail-Funktionalität
Damit wird die Nachweisfähigkeit gegenüber Aufsicht, Revision und externen Prüfern gewährleistet.
3.7 Die DORA-Dokumentation als „lebendes Compliance-System“
Die DORA-Dokumentation ist kein statisches Regelwerk, sondern ein dynamisches Steuerungssystem innerhalb des CMS.
Sie bildet:
- regulatorische Anforderungen
- operative Prozesse
- Kontrollmechanismen
- Managemententscheidungen
- Nachweise
in einem integrierten Framework ab.
Für Compliance Manager bedeutet dies:
- kontinuierliche Pflege statt Einmalprojekt
- klare Prozessverantwortung
- enge Verzahnung mit ISMS und Risikomanagement
- transparente Steuerung über Kennzahlen und Reports
Nur so kann DORA langfristig wirksam, prüfungssicher und wirtschaftlich umgesetzt werden.
4. Bedeutung für Wirtschaftsprüfer:innen – Prüfungsumfang, Prüfungshandlungen und Wirksamkeitsnachweise
Mit Inkrafttreten der DORA-Verordnung (EU) 2022/2554 und in Verbindung mit der deutschen Prüfungsberichtsverordnung (PrüfbV) ergeben sich für Wirtschaftsprüfer:innen deutlich erweiterte Prüfpflichten im Bereich der IT-Governance und des IKT-Risikomanagements. Während in der Vergangenheit häufig die formale Angemessenheit von Regelungen im Vordergrund stand, verschiebt sich der Prüfungsfokus nun klar in Richtung einer verpflichtenden Wirksamkeitsprüfung.
Damit wird das IKT-Risikomanagement auf eine Stufe mit klassischen internen Kontrollsystemen gestellt. Der Prüfungsmaßstab orientiert sich dabei an den Grundsätzen des ISA [DE] 315 (revised 2019), der den Wirtschaftsprüfer verpflichtet, Risiken wesentlicher falscher Darstellungen zu identifizieren und zu beurteilen und hierfür ein hinreichendes Verständnis der IT-gestützten Prozesse und der zugehörigen Kontrollen zu erlangen.
4.1 Was muss geprüft werden? – Prüfungsgegenstand nach DORA und PrüfbV
Der Prüfungsgegenstand umfasst sämtliche wesentlichen Elemente der digitalen operationalen Resilienz. DORA definiert diese materiellrechtlich, während die PrüfbV die Prüfungspflicht und den Prüfungsmaßstab vorgibt.
4.2 Wie wird geprüft? – Prüfungshandlungen und Prüfungsansatz
Die PrüfbV verlangt einen kombinierten Prüfungsansatz aus Angemessenheitsprüfung (Design) und Wirksamkeitsprüfung (Operating Effectiveness). Eine reine Dokumentensichtung genügt nicht.
Typische Prüfungshandlungen sind:
- Dokumentenprüfung
Analyse von Richtlinien, Konzepten, Registern und Berichten (z. B. Incident-Response-Plan, Teststrategie, Outsourcing-Register). - Walkthroughs realer Prozesse
Nachvollziehen konkreter Abläufe anhand tatsächlicher Fälle, etwa eines gemeldeten IKT-Vorfalls oder eines durchgeführten Resilienztests. - Stichprobenprüfungen (Operating Effectiveness)
Auswahl einzelner Vorfälle, Tests oder Verträge und Abgleich mit den dokumentierten Soll-Prozessen. - Interviews mit Fachbereichen
Gespräche mit IT, Informationssicherheit, Compliance, Notfallmanagement und Auslagerungsmanagement zur Plausibilisierung der Umsetzung. - Beobachtungen von Tests und Prozessen
Teilnahme an Notfallübungen, Restore-Tests oder Penetrationstests als Beobachter.
Ziel dieser Prüfungshandlungen ist es, eine belastbare Aussage darüber zu treffen, ob die dokumentierten Kontrollen tatsächlich gelebt werden.
4.3 Wirksamkeitsprüfung als Kernanforderung (DORA + PrüfbV + ISA [DE] 315 rev. 2019)
Ein zentraler Paradigmenwechsel besteht darin, dass mit DORA und der PrüfbV die Wirksamkeitsprüfung verpflichtend wird. Diese entspricht inhaltlich den Anforderungen des ISA [DE] 315 (revised 2019) zur Beurteilung von Risiken und Kontrollen in IT-gestützten Prozessen.
Nicht mehr ausreichend ist:
„Es gibt eine Policy.“
Erforderlich ist:
„Die Policy wird angewendet und ist wirksam.“
Der Wirtschaftsprüfer muss beurteilen, ob Prozesse geeignet sind, die identifizierten Risiken zu steuern, und ob sie im operativen Betrieb tatsächlich funktionieren.
Beispiele:
| Bereich | Angemessenheit | Wirksamkeit |
| Incident-Management | Prozess existiert | Vorfälle wurden korrekt klassifiziert und bearbeitet |
| Backup | Policy vorhanden | Restore wurde erfolgreich getestet |
| Drittparteiensteuerung | Vertrag enthält Auditrechte | Auditrecht ist praktisch durchsetzbar |
| Resilienztests | Teststrategie existiert | Tests wurden durchgeführt und ausgewertet |
Die PrüfbV verlangt ausdrücklich die Beurteilung der Wirksamkeit der IT-Kontrollen. Damit wird die digitale operationale Resilienz prüferisch wie ein internes Kontrollsystem behandelt.
4.4 Test-of-One – Voraussetzungen und Grenzen
Ein sogenannter Test-of-One (Prüfung eines einzelnen Falls) kann zulässig sein, wenn es sich um selten auftretende, aber wesentliche Prozesse handelt (z. B. schwerwiegende IKT-Vorfälle, TLPT-Tests oder einzelne Resilienztests).
Ein Test-of-One ist jedoch nur dann prüferisch belastbar, wenn die zugrunde liegenden General IT Controls (GITC) wirksam implementiert sind. Dies betrifft insbesondere:
- Konfigurationsmanagement,
- Programmänderungsverfahren (Change Management) und
- Benutzerberechtigungsverfahren (Access Management).
Nur wenn sichergestellt ist, dass Änderungen an Parametern, Systemeinstellungen oder Programmen ausschließlich autorisiert, dokumentiert und kontrolliert erfolgen können, ist gewährleistet, dass eine automatisierte Kontrolle über den gesamten Prüfungszeitraum hinweg unverändert und wirksam betrieben wurde.
Ohne wirksame GITC besteht das Risiko, dass Prüfungslogiken oder Schwellenwerte zwischenzeitlich verändert wurden. In diesem Fall ist ein Test-of-One nach den Anforderungen des ISA [DE] 315 (revised 2019) nicht ausreichend, und es sind erweiterte Stichprobenprüfungen erforderlich.
4.5 Nachweis der Wirksamkeit durch Logs als Prüfungsnachweise
Nach ISA [DE] 315 (revised 2019) muss der Prüfer ausreichende und geeignete Prüfungsnachweise („sufficient and appropriate audit evidence“) erlangen. Zum sicheren Nachweis der Wirksamkeit der automatisierten Kontrollen und der GITC sind insbesondere System- und Prozess-Logs heranzuziehen.
Hierzu zählen u. a.:
- Änderungsprotokolle aus dem Change-Management-System,
- Konfigurationsänderungslogs,
- Benutzer- und Berechtigungsänderungsprotokolle,
- Freigabe- und Genehmigungslogs (Vier-Augen-Prinzip),
- Systemlogs automatisierter Kontrollen.
Diese Logs belegen, dass:
- Änderungen nur autorisiert vorgenommen wurden,
- Kontrollmechanismen nicht unzulässig verändert wurden,
- und die geprüfte automatische Kontrolle während des gesamten Prüfungszeitraums wirksam war.
Erst durch diese technische Evidenz wird ein Test-of-One prüferisch belastbar.
4.6 Konsequenzen für Institute
Für Institute bedeutet dieser neue Prüfungsansatz erhebliche Konsequenzen. Prüfungen werden:
- technischer,
- evidenzbasierter,
- stärker prozessorientiert.
Reine Papier-Compliance ist nicht mehr ausreichend. Fehlende Wirksamkeit führt zu:
- Prüfungsfeststellungen,
- Nachbesserungsauflagen,
- erhöhter aufsichtlicher Aufmerksamkeit.
DORA professionalisiert damit die IT- und Cyber-Prüfung im Finanzsektor und hebt sie auf ein europaweit harmonisiertes Niveau. Institute müssen ihre Dokumentation so gestalten, dass sie nicht nur vollständig, sondern auch mit realen Prozessen verknüpft und prüfbar ist.
5. Fazit
Rückgrat eines auditfähigen IKT-Governance-Frameworks.
Für Compliance Manager und Wirtschaftsprüfer bedeutet dies:
- klare Artikelzuordnung
- belastbare Nachweise
- Wirksamkeitsprüfungen statt Papier-Compliance
- erhöhte Prüf- und Aufsichtstiefe
Die BaFin-Übersicht ist ein Einstieg – die nachhaltige Umsetzung entscheidet über die tatsächliche Resilienz des Instituts.
6. Checkliste zur Vollständigkeit der Dokumentation
Dieses Kapitel bildet den Kern der Umsetzung und orientiert sich strikt an Kapitel II der DORA (Art. 5–16) in der deutschen Fassung.
KAPITEL II – IKT-Risikomanagement (Art. 5–16)
Art. 5 – Governance und Organisation
Dokumente:
- IKT-Governance-Konzept
- Rollen- und Verantwortlichkeitsmatrix (Board, Management, Kontrollfunktionen)
- Beschlüsse des Leitungsorgans zur IKT-Strategie
- Berichts- und Eskalationsordnung
- Protokolle der Management-Reviews
Art. 6 – IKT-Risikomanagementrahmen
Dokumente:
- IKT-Risikomanagement-Framework (Policy)
- Methodik zur Risikoidentifikation und -bewertung
- Risikoappetit- und Risikotoleranzdefinition
- Integration ins Gesamtrisikomanagement
- Review- und Aktualisierungsnachweise
Art. 7 – IKT-Systeme, -Protokolle und -Tools
Dokumente:
- IKT-Systemverzeichnis
- Architekturdiagramme
- Protokollübersicht (Netzwerk, Kommunikationsprotokolle)
- Tool-Inventar (Monitoring-, Security-, Betriebs-Tools)
- Lifecycle- und Änderungsdokumentation
Art. 8 – Identifikation
Dokumente:
- Klassifikation kritischer/wichtiger Funktionen
- Asset-Inventar (IKT-Assets)
- Abhängigkeitsanalysen (intern & extern)
- Risiko-Szenarien
- Aktualisierungsprotokolle
Art. 9 – Schutz und Prävention
Dokumente:
- IT-Sicherheitsrichtlinien (Access, IAM, Netzwerk, Endpoint)
- Technische und organisatorische Maßnahmen (TOM-Dokumentation)
- Schwachstellenmanagement-Prozess
- Patchmanagement-Prozess
- Verschlüsselungs- und Zugriffskonzepte
Art. 10 – Erkennung
Dokumente:
- Monitoring- und Logging-Konzept
- SIEM-Richtlinien
- Schwellenwertdefinitionen
- Eskalationsregeln
- KPI/KRI-Berichte
Art. 11 – Reaktion und Wiederherstellung
Dokumente:
- Incident-Response-Plan
- Krisenmanagement-Konzept
- Wiederanlauf- und Wiederherstellungspläne (DR-Pläne)
- Kommunikationspläne
- Vorfallberichte
Art. 12 – Sicherungskopien und Wiederherstellungsverfahren
Dokumente:
- Backup-Policy
- Wiederherstellungsstrategie
- Restore-Testberichte
- Aufbewahrungs- und Schutzkonzepte
Art. 13 – Lernen und Weiterentwicklung
Dokumente:
- Lessons-Learned-Berichte
- Root-Cause-Analysen
- Maßnahmenkataloge
- Management-Reports
Art. 14 – Tests der digitalen operationalen Resilienz
Dokumente:
- Teststrategie
- Mehrjahres-Testplan
- Testmethodenkatalog
- Testberichte
- Maßnahmenverfolgung
Art. 15 – Erweiterte Tests (TLPT)
Dokumente:
- TLPT-Konzept
- Scope-Definition
- Szenarienbeschreibung
- Ergebnisberichte
- Abhilfemaßnahmenpläne
Art. 16 – Vereinfachter IKT-Risikomanagementrahmen
Dokumente:
- Begründung der Vereinfachung
- Dokumentation der Abweichungen
- Angemessenheitsnachweise
KAPITEL III – Meldung IKT-bezogener Vorfälle (Art. 17–23)
Art. 17 – Klassifizierung IKT-bezogener Vorfälle
Dokumente:
- Klassifikationsschema
- Schwellenwertdefinitionen
- Entscheidungslogik zur Einstufung
- Prozessbeschreibung zur Klassifikation
Art. 18 – Meldung schwerwiegender Vorfälle
Dokumente:
- Meldeprozess an Aufsichtsbehörden
- interne Meldewege
- Meldeformulare / Templates
- Fristenüberwachung
- Register gemeldeter Vorfälle
Art. 19 – Kundeninformation
Dokumente:
- Kommunikationskonzept für Kunden
- Textbausteine
- Entscheidungsregeln zur Kundeninformation
- Nachweise versandter Informationen
Art. 20 – Analyse schwerwiegender Vorfälle
Dokumente:
- Impact-Analysen
- Kosten-/Schadensberichte
- Betriebsunterbrechungsberichte
Art. 21 – Abschlussberichte
Dokumente:
- Abschlussberichte je Vorfall
- Maßnahmenverfolgung
- Management-Zusammenfassungen
Art. 22 – Informationsaustausch mit Behörden
Dokumente:
- Koordinationsprozesse
- Kommunikationsprotokolle
- Dokumentation freiwilliger Meldungen
Art. 23 – Freiwillige Meldungen
Dokumente:
- Prozess für freiwillige Meldungen
- Dokumentation gemeldeter Cyberbedrohungen
KAPITEL IV – Tests der digitalen operationalen Resilienz (Art. 24–27)
Art. 24 – Grundsätze für Testprogramme
Dokumente:
- Gesamt-Teststrategie
- Testleitlinien
- Governance für Testprogramme
Art. 25 – Durchführung der Tests
Dokumente:
- Testpläne
- Testprotokolle
- Testergebnisse
- Abstellmaßnahmen
Art. 26 – Bedrohungsorientierte Penetrationstests (TLPT)
Dokumente:
- TLPT-Rahmenkonzept
- Scope-Definition
- Genehmigungen
- Ergebnisberichte
- Maßnahmenpläne
Art. 27 – Gegenseitige Anerkennung
Dokumente:
- Anerkennungsnachweise
- Koordinationsdokumente bei Gruppen
KAPITEL V – Management des IKT-Drittparteienrisikos (Art. 28–44)
Art. 28 – Strategie für IKT-Drittparteienrisiken
Dokumente:
- Drittparteienstrategie
- Klassifizierung kritischer Anbieter
Art. 29 – Vorvertragliche Analyse
Dokumente:
- Due-Diligence-Berichte
- Risikoanalysen
- Anbieterbewertungen
Art. 30 – Vertragsinhalte
Dokumente:
- Verträge mit Mindestinhalten:
- Audit- und Zugangsrechte
- Sicherheitsanforderungen
- Exit-Strategien
- Unterauslagerungsregeln
Art. 31 – Register der Auslagerungen
Dokumente:
- zentrales Outsourcing-Register
- Mapping kritischer Funktionen
- Abhängigkeiten
Art. 32–34 – Überwachung
Dokumente:
- SLA-Reports
- Leistungsberichte
- Risikoüberwachungsberichte
- Review-Protokolle
Art. 35–44 – Kritische IKT-Drittdienstleister
Dokumente:
- Kooperationsvereinbarungen mit Lead Overseer
- Prüfberichte
- Abhilfemaßnahmen
- Aufsichtskommunikation
KAPITEL VI – Informationsaustausch (Art. 45)
Art. 45 – Vereinbarungen zum Informationsaustausch
Dokumente:
- Vereinbarungen zum Informationsaustausch (MoUs)
- interne Richtlinien zum Austausch
- Dokumentation ausgetauschter Informationen
