DORA-Prüfungen: Warum Finanzinstitute ohne prüfungsfeste IT- und Datenschutz-Artefakte scheitern

Schwerpunkt: Datenschutz & Datensicherheit

DORA ist die härteste Nagelprobe für IT-Resilienz in der Finanzwirtschaft. Wer prüfungsfeste Artefakte nicht liefern kann, fällt im Audit durch – unabhängig davon, wie robust die Systeme sind. Banken, Versicherer und FinTechs scheitern nicht an Firewalls, sondern an fehlender Dokumentation.

von Dr. Jan Scharfenberg und Jakob Liebert, Isico Datenschutz

DORA verlangt nicht nur Sicherheits­maßnahmen, sondern deren prüfbare Nachweise. Prüfer wollen sehen, ob Prozesse dokumentiert, nachvollziehbar und manipulationssicher sind.

Diese Dokumentation nennt man „Artefakte“. Sie entstehen im operativen Alltag – in Logs, Reports, Verträgen oder Risikoanalysen. Entscheidend ist, dass sie auditfest aufbereitet und verfügbar sind.

Sechs Artefakte sind für Finanzinstitute besonders kritisch:

1. Incident-Response- und Vorfallsprotokolle

Ein Vorfall, der nicht dokumentiert ist, hat regulatorisch nie stattgefunden. Prüfer wollen nachvollziehen, ob Institute Angriffe und Störungen systematisch erkennen und behandeln.
–Erwartung: Manipulationssichere Protokolle mit Zeitstempeln, Klassifizierung des Vorfalls, ergriffenen Maßnahmen, forensischen Ergebnissen und Lessons Learned. Auch Verantwortlichkeiten müssen erkennbar sein.
–Typisches Problem: Logs liegen verteilt in unterschiedlichen Systemen oder werden nur in Excel-Listen geführt. Oft fehlt ein zentrales, unveränderbares Register.
–Empfehlung: Aufbau eines SIEM-Systems mit Write-Once-Read-Many-Speicher. Vorfälle sollten in standardisierten Playbooks dokumentiert werden, sodass Prüfer den gesamten Ablauf vom Erkennen bis zum Abschluss nachvollziehen können.

2. Third-Party Risk Assessments & AV-Verträge

IT-Dienstleister sind integraler Teil der Wertschöpfung. DORA verlangt, dass Banken und Versicherer deren Risiken kontinuierlich kontrollieren. Die DSGVO schreibt zudem klare Auftragsverarbeitungsverträge vor.
–Erwartung: Vollständiges Outsourcing-Register, Risikobewertungen jedes Dienstleisters (inklusive Subdienstleister) sowie Verträge, die Audit- und Kontrollrechte enthalten.
–Typisches Problem: Subdienstleister fehlen in den Verzeichnissen, Verträge sind veraltet oder rein formal. Sicherheitsbewertungen beschränken sich oft auf Selbstauskünfte.
–Empfehlung: Einrichtung eines zentralen Outsourcing-Registers, verknüpft mit Governance, Risk & Compliance-Managementsystemen (GRC). Regelmäßige Security-Scores, ergänzt durch unabhängige Auditberichte oder Penetrationstests der Provider, schaffen Prüfbarkeit.

3. Penetrations-Tests und Vulnerability-Reports

Technische Resilienz ohne Nachweis existiert im Audit nicht. Prüfer wollen sehen, dass Schwachstellen erkannt, priorisiert und geschlossen wurden – mit Belegen.
–Erwartung: Reports, die CVE-Referenzen, CVSS-Scores, Remediation-Timelines und Regression-Tests enthalten. Dokumentierte Prozesse, wie Lücken geschlossen und anschließend überprüft wurden.
–Typisches Problem: Viele Institute beschränken sich auf einen jährlichen Pentest. Das genügt DORA nicht, weil Resilienz kontinuierlich nachgewiesen werden muss.
–Empfehlung: Aufbau eines kontinuierlichen Vulnerability-Managements mit regelmäßigen Scans, automatischer Ticket-Erstellung im ITSM und klaren Remediation-Deadlines. Reports sollten zeigen, wann welche Lücken behoben wurden und wie die Wirksamkeit geprüft wurde.

4. Data Protection Impact Assessment (DPIA)

DPIAs sind mehr als juristische Pflichtübungen. Sie dokumentieren, dass Datenschutzrisiken bei kritischen Systemen, Cloud-Lösungen oder KI-Einsatz systematisch bewertet und minimiert wurden.
–Erwartung: Risikoanalysen mit nachvollziehbarer Methodik, Schwere-/Wahrscheinlichkeitsbewertung, konkrete Abhilfemaßnahmen.
–Typisches Problem: DPIAs bestehen oft nur aus juristischen Textblöcken ohne technische Risiko-Szenarien oder Kontrollen. Für Prüfer sind sie damit wertlos.
–Empfehlung: DPIAs sollten technische Maßnahmen wie Verschlüsselung, Zugriffskontrolle, Pseudonymisierung und Logging enthalten. Sinnvoll ist eine „lebende“ DPIA, die bei jeder Systemänderung automatisch aktualisiert wird.

5. Technische und organisatorische Maßnahmen (TOM) – Nachweise

Das Draften von Richtlinien allein reicht nicht aus. Prüfer wollen sehen, dass Maßnahmen nicht nur auf dem Blatt existieren, sondern technisch und nachweisbar implementiert sind.
–Erwartung: Evidenzen wie MFA-Logs, Backup-Protokolle, dokumentierte Netzwerksegmentierungen oder Encryption-Key-Management-Prozesse. Jede Anforderung muss mit einem technischen Nachweis hinterlegt sein.
–Typisches Problem: TOM sind in Word-Dokumenten beschrieben, aber es fehlen Verknüpfungen zu den Evidenzen.
–Empfehlung: Nutzung eines GRC-Systems, das TOM direkt mit Logs und Nachweisen verknüpft. So lässt sich im Audit beweisen, dass Maßnahmen nicht nur geplant, sondern implementiert und aktiv überwacht sind.

6. Business Continuity & Recovery-Pläne (inkl. Testnachweise)

Ein Notfallplan, der nie getestet wurde, ist im Audit wertlos. DORA fordert den Nachweis, dass kritische Funktionen auch im Krisenfall aufrechterhalten werden können.
–Erwartung: Dokumentierte Recovery Time Objectives (RTO), Restore-Zeiten Recovery Point Objectives (RPO), Ergebnisse von Tabletop-Übungen, Failover-Tests und Maximal Tolerierbare Ausfallzeiten (MTA).
–Typisches Problem: Viele Institute haben Pläne, die nie praktisch erprobt wurden – oder deren Tests nicht dokumentiert sind.
–Empfehlung: Jährliche Tests der BC/DR-Pläne mit dokumentierten Ergebnissen. Restore-Übungen müssen zeigen, ob RTO und RPO eingehalten werden. Nur so entsteht der prüfbare Nachweis der Handlungsfähigkeit.

Fazit: Artefakte sind der eigentliche Prüfungsmaßstab

DORA macht IT-Resilienz zu einer prüfbaren Disziplin. Entscheidend sind nicht nur Firewalls oder Backups, sondern die Artefakte, die deren Wirksamkeit belegen. Wer Logs, Verträge, Reports und Testnachweise auditfest sammelt, übersteht nicht nur DORA-Prüfungen, sondern gewinnt gleichzeitig Transparenz und Sicherheit im operativen Alltag.
Institute sollten deshalb jedes Artefakt einem klaren Verantwortlichen zuordnen, Nachweise zentral und manipulationssicher speichern und regelmäßig interne Audits durchführen. Nur so wird Resilienz auch regulatorisch belastbar. Dr. Jan Scharfenberg, Isico Datenschutz GmbH und Jakob Liebert, Isico GmbH