DORA Interne Revision: Kompetenz einkaufen, Verantwortung behalten

DORA regelt die Prüfung an zwei getrennten Stellen: Kapitel II adressiert die interne Prüfung des IKT‑Risikomanagementrahmens. Kapitel IV regelt das Programm zum Testen der digitalen operationalen Resilienz.

Beide verlangen Unabhängigkeit, folgen aber unterschiedlicher Logik: Die Revision beurteilt, ob Kontrollen wirksam sind. Das Testprogramm prüft, ob Systeme technisch standhalten. Wer beides vermengt, erzeugt Doppelarbeit und Lücken zugleich. DORA Artikel 6 Absatz 6 verlangt eine regelmäßige interne Revision des IKT-Risikomanagementrahmens und rückt die operative Wirksamkeit von IKT-Kontrollen stärker in den Mittelpunkt. Aufsichtsbehörden erwarten, dass Institute nicht nur Richtlinien, Kontrollkonzepte und Berichte vorlegen können. Entscheidend ist, ob Kontrollen im laufenden Betrieb funktionieren und ob Schwächen rechtzeitig erkannt werden.
Für die interne Revision bedeutet das einen Perspektivwechsel. Klassische Prüfpläne bleiben wichtig, reichen aber allein nicht mehr aus. Viele Institute arbeiten weiterhin mit jährlichen Prüfzyklen, manueller Evidenzerhebung und heterogenen Nachweisen in Tabellen, Dokumenten oder Systemexporten. Gleichzeitig steigen die Anforderungen an technische Tiefe, Aktualität und Nachvollziehbarkeit.

Damit wird die IKT-Prüfung zu einem dauerhaften Steuerungsthema, das nicht nur relevant ist, wenn eine Prüfung ansteht oder die Aufsicht Nachweise einfordert. Hier stoßen Banken jedoch oft an ihre Grenzen: Cloud, IAM, Changemanagement und IKT-Dienstleister erfordern technisches und regulatorisches Detailwissen, das generalistische Teams in dieser Breite oft nicht dauerhaft abdecken können.

Unentdeckte Kontrollschwächen können aufsichtsrechtliche Feststellungen, operative Ausfälle oder Reputationsschäden nach sich ziehen. Besonders kritisch sind unkontrollierte Zugriffsrechte, Change-Fehler, Cloud-Fehlkonfigurationen oder unzureichend überwachte IKT-Dienstleister.

Daher passt ein jährlicher Prüfzyklus nicht mehr zur Dynamik moderner IT‑Umgebungen. Zugriffsrechte ändern sich laufend, Cloud-Konfigurationen ebenfalls. Wenn Schwächen erst in der nächsten Prüfung auffallen, können die Risiken bereits deutlich gewachsen sein.

Für Vorstände und Prüfungsausschüsse entsteht dadurch ein neuer Transparenzbedarf. Sie müssen nicht jedes technische Detail kennen. Aber sie benötigen ein belastbares Bild darüber, ob wesentliche IKT-Kontrollen funktionieren, welche Schwächen bestehen und wie schnell diese geschlossen werden.

Audit-as-a-Service bedeutet nicht, die Verantwortung der internen Revision auszulagern. Die Letztverantwortung bleibt bei der Bank. Der Ansatz besteht vielmehr darin, fehlende IKT-Audit-Kapazität, regulatorische Tiefe und Automatisierungskompetenz gezielt verfügbar zu machen. Der Basler Ausschuss für Bankenaufsicht hält in seinem Bericht zur Digitalisierung der Finanzwirtschaft von Mai 2024 fest, dass Institute und Aufseher prüfen sollten, ob Personalbestand und Schulungsprogramme noch zu den eingesetzten Technologien passen, und dass die Ergänzung um Spezialisten erforderlich sein kann.

Wirksam wird dieser Ansatz, wenn IKT-Audit, IT-Risk und Datenanalyse zusammengeführt werden. So lassen sich komplexe Prüffelder fachlich sauber bewerten und wiederkehrende Nachweise schrittweise automatisieren. Genau hier liegt der Unterschied zu einer reinen Tool-Einführung: Daten allein ersetzen keine Prüfungsmethodik. Gute Methodik bleibt jedoch begrenzt, wenn Nachweise dauerhaft manuell erhoben werden.

Ein realistischer Einstieg beginnt deshalb nicht mit vollständiger Continuous Assurance. Sinnvoller ist ein stufenweiser Aufbau.

Am Anfang steht ein Quick Assessment. In wenigen Wochen entsteht Transparenz über Prüfinventar, wesentliche Kontrolllücken und priorisierte Quick Wins. Das schafft eine gemeinsame Grundlage für Revision, IT, Risikomanagement und Informationssicherheit.

Darauf folgt die Audit-Durchführung in ausgewählten kritischen Prüffeldern, etwa IAM, Change, Cloud und/oder Drittparteienrisiko. Standardisierte Prüffeld-Blueprints und prüffähige Arbeitspapiere sorgen dafür, dass Ergebnisse auch einer aufsichtlichen Nachschau standhalten.

Im dritten Schritt werden wiederkehrende Nachweise automatisiert. Das kann mit einem priorisierten Prüffeld beginnen: Datenabfragen, Nachweisstrecken, Dashboards und Berichtsvorlagen werden passend zur Systemreife des Instituts aufgebaut.

Im vierten Schritt wird das Ziel erreicht: Continuous Assurance. Kritische Kontrollen werden laufend überwacht, Auffälligkeiten früher eskaliert und Reporting-Strukturen für Vorstand, Prüfungsausschuss und Kontrollfunktionen etabliert.

Kritisch ist dabei die Zusammenarbeit über unterschiedliche Abteilungen und Funktionen hinweg: interne Revision, CISO, Compliance, Chief Risk Officer … Die Bundesbank benennt Schwächen bei Unabhängigkeit, Berichtswegen und Ressourcen der IKT-Kontrollfunktion als wiederkehrenden Prüfungsbefund. Audit-as-a-Service schließt die Lücken bei der Übergabe zwischen Methodik, Daten und Bewertung durch eine neutrale dritte Partei.

Die Bedeutung der internen Revision steigt durch DORA, weil IKT-Risiken unabhängiger, technischer und kontinuierlicher geprüft werden müssen. Banken müssen daher ihre Revisionsfunktion so stärken, dass sie mit steigenden Anforderungen Schritt hält.

Dabei gilt es, folgende Fragen für sich zu beantworten: Verfügen die eingesetzten Prüfer nachweisbar über IKT-Fachkompetenz und Unabhängigkeit im Sinne von Artikel 6 Absatz 6? Ist die Nachverfolgung so ausgestaltet, dass kritische Feststellungen mit Frist, Verantwortlichem und Nachweis geschlossen werden?

Wo eine dieser Fragen offen bleibt, ist Audit-as-a-Service ein pragmatischer Weg, diese Lücke zu schließen. Es verbindet spezialisierte IKT-Audit-Kompetenz, regulatorisches Verständnis und Automatisierung. So können Banken Risiken früher erkennen, Nachweise belastbarer führen und ihre Revision entlasten, ohne die eigene Steuerungsverantwortung abzugeben.