Thema
DORA

DORA und ISO 27001: Wie bestehende ISMS-Strukturen genutzt werden können

Praxisorientierte Einordnung zu DORA und ISO 27001: Wie bestehende ISMS-Strukturen genutzt werden können: Anforderungen verstehen, Risiken priorisieren und eine belastbare Umsetzung für DORA aufbauen.
DORA und ISO 27001: Wie bestehende ISMS-Strukturen genutzt werden können – Fachbeitrag von BlackMount

Ein nach ISO/IEC 27001 aufgebautes Informationssicherheitsmanagementsystem ist eine starke Grundlage für DORA, aber kein Ersatz für die Verordnung. Das ISMS liefert Governance, Risikomanagement, dokumentierte Kontrollen, interne Audits und kontinuierliche Verbesserung. DORA ergänzt spezifische Anforderungen an digitale operationale Resilienz, kritische oder wichtige Funktionen, Vorfallmeldungen, Testprogramme, Informationsregister, Verträge und IKT-Drittparteien.

Der wirtschaftlichste Ansatz besteht nicht in zwei parallelen Managementsystemen. Finanzunternehmen sollten vorhandene ISO-Prozesse als gemeinsame Steuerungsplattform nutzen und DORA-spezifische Objekte, Entscheidungen und Nachweise ergänzen. Dafür braucht es ein belastbares Mapping, das nicht nur ähnliche Überschriften vergleicht, sondern Anwendungsbereich, Frequenz, Verantwortlichkeit und Evidenz.

Unterschiedliche Zwecke der Regelwerke

ISO/IEC 27001 ist eine international anwendbare Managementsystemnorm. Organisationen jeder Branche können einen Scope definieren, Informationssicherheitsrisiken bewerten, notwendige Kontrollen auswählen und das System freiwillig zertifizieren lassen. Im Mittelpunkt stehen Vertraulichkeit, Integrität und Verfügbarkeit von Informationen.

DORA ist unmittelbar geltendes EU-Recht für definierte Finanzunternehmen. Ziel ist die Fähigkeit, operative Integrität und Zuverlässigkeit auch bei IKT-Störungen aufrechtzuerhalten. Aufsichtsbehörden verlangen spezifische Meldungen, Register, Tests und Drittparteieninformationen.

Warum ein Zertifikat DORA nicht automatisch erfüllt

Ein ISO-Zertifikat bestätigt die Konformität des ISMS im ausgewiesenen Zertifizierungsscope. Es sagt nicht automatisch aus, dass alle DORA-relevanten Rechtsträger, kritischen Funktionen, IKT-Dienstleister und Verträge einbezogen sind. Stichproben und Auditkriterien folgen der Norm, nicht sämtlichen DORA-Rechtsakten.

Die Aufsicht kann daher zusätzliche Nachweise verlangen. Ein Zertifikat ist wertvolle Evidenz für Managementsystem und Kontrollen, ersetzt aber weder Informationsregister noch Vorfallmeldung, TLPT, Vertragsklauseln oder spezifische Funktions- und Konzentrationsanalysen.

Scope-Mapping als erster Schritt

ISO-Scope und DORA-Scope werden nebeneinandergelegt. Zu prüfen sind Rechtsträger, Standorte, Prozesse, Produkte, Systeme, Daten und externe Leistungen. Ein zertifiziertes Rechenzentrum kann nur einen Teil der End-to-End-Finanzfunktion abdecken.

Die Gap-Analyse kennzeichnet vollständig abgedeckte, teilweise abgedeckte und außerhalb des ISMS liegende DORA-Objekte. Lücken werden entweder in den ISMS-Scope aufgenommen oder über klar angebundene Governance gesteuert. Verantwortlichkeit des Finanzunternehmens bleibt bestehen.

Kontext und interessierte Parteien nutzen

ISO 27001 verlangt, interne und externe Themen sowie Anforderungen interessierter Parteien zu bestimmen. DORA, BaFin, europäische Aufsichtsbehörden, Kunden und kritische Dienstleister werden als verbindliche Anforderungen in diesen Prozess aufgenommen.

Das Rechtsregister enthält DORA-Level-1-Verordnung, delegierte und Durchführungsrechtsakte sowie nationale Aufsichtshinweise. Änderungen lösen Impactanalyse, Kontrollanpassung und Managementkommunikation aus. Dadurch wird regulatorisches Monitoring Teil des bestehenden ISMS-Zyklus.

Leitungsorgan und ISO-Führung verbinden

Beide Rahmen verlangen Führung, Rollen und Ressourcen. DORA ist jedoch besonders konkret: Das Leitungsorgan trägt die Verantwortung für den IKT-Risikomanagementrahmen, genehmigt Risikotoleranz, Strategie, Kontinuität, Auditpläne und Drittparteienentscheidungen und muss regelmäßig geschult werden.

Bestehende ISMS-Managementbewertungen können erweitert werden. DORA-Kennzahlen zu kritischen Funktionen, Vorfällen, Tests, Registerqualität, Konzentration und Exit werden fester Bestandteil. Beschlüsse und Überwachung sind aufsichtsfähig dokumentiert.

Risikomanagement gemeinsam betreiben

ISO 27001 verlangt einen wiederholbaren Prozess zur Identifikation, Analyse, Bewertung und Behandlung von Informationssicherheitsrisiken. DORA verlangt einen umfassenden IKT-Risikomanagementrahmen als Teil des Gesamtrisikomanagements und verbindet ihn eng mit operativer Resilienz.

Die gemeinsame Methode ergänzt DORA-spezifische Felder: kritische Funktion, IKT-Asset, Dienstleister, Auswirkungs- und Risikotoleranz, Vorfallhistorie, Testresultat und Aufsichtsrelevanz. Risiken werden nicht nur auf Informationswerte, sondern auf die fortlaufende Finanzdienstleistung bezogen.

Statement of Applicability sinnvoll erweitern

Das ISO-Statement of Applicability dokumentiert notwendige Kontrollen, Anwendbarkeit und Umsetzungsstatus. Es kann als Ausgangspunkt für ein integriertes Kontrollregister dienen. DORA-Anforderungen werden jedoch nicht künstlich als Annex-A-Control ausgegeben.

Ein ergänzendes Mapping verbindet DORA-Artikel und technische Standards mit ISMS-Prozess, Kontrolle, Scope, Verantwortlichem, Frequenz und Nachweis. Mehrere Rechtsanforderungen können dieselbe Kontrolle nutzen, behalten aber ihre eigenen Prüfkriterien.

Assetmanagement und kritische Funktionen

ISO-Kontrollen zu Inventar, Eigentum und Klassifizierung unterstützen DORA-Artikel 8. DORA verlangt zusätzlich die Verbindung zu IKT-gestützten Unternehmensfunktionen, Rollen, Assets und Abhängigkeiten. Kritische oder wichtige Funktionen sind ein regulatorisch relevantes Objekt.

CMDB und Informationsinventar werden mit BIA, Servicekatalog und DORA-Funktionsregister verknüpft. Eine Anwendung kann mehrere Funktionen unterstützen; eine Funktion kann von vielen internen und externen Assets abhängen. Diese Beziehungen steuern Tests und Drittparteienbewertung.

Schutz- und Präventionskontrollen wiederverwenden

ISO-orientierte Prozesse für Identitäten, Zugriff, Kryptografie, Schwachstellen, Konfiguration, Netzwerk, Entwicklung und Lieferanten sind direkt nutzbar. DORA und Delegierte Verordnung 2024/1774 konkretisieren Ausgestaltung, Dokumentation und Einbettung in den IKT-Rahmen.

Die Gap-Analyse prüft nicht nur, ob eine Kontrolle existiert, sondern ob sie für alle kritischen Funktionen gilt, angemessen häufig getestet und mit messbarer Wirkung betrieben wird. Proportionalität wird begründet.

Incident Management um DORA-Meldung ergänzen

ISO 27001 unterstützt Erkennung, Bewertung, Reaktion und Lernen aus Informationssicherheitsvorfällen. DORA verlangt zusätzlich eine spezifische Klassifizierung IKT-bezogener Vorfälle und die Meldung schwerwiegender Ereignisse in verbindlichen Stufen, Fristen und Formaten.

Der vorhandene Incident-Prozess erhält DORA-Kriterien, regulatorische Uhr, BaFin-Meldeweg und Pflichtdaten. Ein Vorfall kann ISO-intern relevant sein, ohne DORA-meldepflichtig zu werden; umgekehrt muss eine operative Störung nicht auf einen erfolgreichen Angriff zurückgehen, um DORA-Relevanz zu besitzen.

Kontinuität stärker auf Finanzfunktionen ausrichten

ISO Annex A enthält Kontrollen zur Informationssicherheit bei Störungen und IKT-Bereitschaft für Geschäftskontinuität. DORA verlangt detaillierte IKT-Kontinuitäts-, Reaktions-, Wiederherstellungs- und Backupstrukturen mit BIA, RTO, RPO und schweren plausiblen Szenarien.

Bestehende BCM-Pläne werden um kritische Funktionen, Anbieterabhängigkeiten und regulatorische Kommunikationswege ergänzt. Restore-Tests müssen die fachliche Leistung belegen. Umschaltung und Rückkehr zur Primärumgebung werden praktisch getestet.

Interne Audits als DORA-Prüfplattform

ISO 27001 verlangt ein risikobasiertes Auditprogramm und Managementbewertung. Diese Struktur kann DORA-Kontrollen aufnehmen. Auditoren benötigen jedoch ausreichende DORA- und IKT-Kompetenz sowie Unabhängigkeit.

Audituniversum und Stichproben werden um Funktionsmapping, Informationsregister, Vorfallmeldung, Resilienztests, Verträge und Exit erweitert. Ein ISO-Audit ersetzt keine aufsichtliche Prüfung, erzeugt aber belastbare interne Evidenz und frühe Findings.

DORA-Testprogramm geht über übliche ISMS-Tests hinaus

ISO verlangt Überwachung, Messung und Wirksamkeitsbewertung, lässt die konkrete Methodik aber risikobasiert offen. DORA fordert ein umfassendes Programm und mindestens jährliche angemessene Tests aller Systeme und Anwendungen, die kritische oder wichtige Funktionen unterstützen.

Das ISMS-Testregister wird um Funktionsabdeckung, Ende-zu-Ende-, Kontinuitäts- und Drittanbietertests ergänzt. Für identifizierte Unternehmen kommt TLPT mindestens im vorgesehenen Dreijahreszyklus hinzu. Findings benötigen Retest und interne Validierung.

Lieferantenmanagement um DORA-Lebenszyklus erweitern

ISO-Lieferantenkontrollen unterstützen Auswahl, Verträge, Überwachung und Änderungen. DORA verlangt IKT-Drittparteienrisiko als Bestandteil des IKT-Rahmens, Ex-ante-Bewertung, Konzentrationsanalyse, Informationsregister, Mindestvertragsinhalte und Exit-Strategien.

Das Vendor-Management ergänzt Kritikalität der unterstützten Funktion, Anbieter- und Unterauftragnehmerkette, Standort, Ersetzbarkeit und aufsichtliche Anzeigen. Ein ISO-Zertifikat des Anbieters ist ein Nachweis, nicht die vollständige Due Diligence.

Informationsregister ist eine eigenständige DORA-Lücke

ISO 27001 verlangt kein Register nach dem relationalen Datenmodell der Durchführungsverordnung 2024/2956. Vorhandene Lieferanten- und Vertragslisten liefern Quellen, müssen aber mit Funktionen, IKT-Diensten, Anbietern, Unterauftragnehmern, Standorten und Identifikatoren verknüpft werden.

Datenqualität, Konsolidierung und Aufsichtseinreichung benötigen eigene Governance. Das ISMS kann Dokumentenlenkung, interne Kontrolle und Verbesserung bereitstellen. Die fachlichen Templates bleiben DORA-spezifisch.

Vertragsklauseln nicht aus ISO-Nachweisen ableiten

ISO-orientierte Verträge enthalten oft Vertraulichkeit, Sicherheitsanforderungen und Auditrechte. Artikel 30 DORA verlangt darüber hinaus konkrete Mindestinhalte und erweiterte Klauseln für kritische oder wichtige Funktionen, darunter Leistungsstandorte, Unterstützung, Kontinuität und Exit.

Eine Klauselmatrix vergleicht jeden Vertrag. Zertifikate oder Standardbedingungen des Anbieters kompensieren keine fehlende Pflichtklausel. Operative Nutzbarkeit wird zusätzlich geprüft.

Messung und Kennzahlen integrieren

ISO-Ziele und Messprogramme können DORA-Kennzahlen aufnehmen. Relevante Größen sind Verfügbarkeit kritischer Funktionen, Zeit bis Erkennung und Wiederherstellung, Testabdeckung, kritische Findings, Registerfehler, Konzentration und getestete Exits.

Kennzahlen werden nicht isoliert optimiert. Eine niedrige Vorfallzahl kann auf schwache Erkennung hindeuten; hohe Testabdeckung kann ohne kritische Funktionssicht wertlos sein. Managementberichte erklären Kontext und Trend.

Dokumentenlenkung für DORA nutzen

ISO-Prozesse für Freigabe, Version, Verteilung, Aufbewahrung und Änderung eignen sich für DORA-Richtlinien, Registerdefinitionen, Testpläne und Berichte. Der Dokumentenkatalog erhält Rechtsreferenz, Eigentümer, Reviewfrequenz und Schutzklasse.

Die BaFin stellt eine Übersicht DORA-bezogener Dokumentationsanforderungen bereit. Sie dient als Vollständigkeitskontrolle, ersetzt aber keine fachliche Verknüpfung und Wirksamkeitsprüfung. Dokumente werden schlank gehalten und auf reale Prozesse abgestimmt.

Zertifizierungsscope strategisch weiterentwickeln

Wenn kritische Funktionen oder zentrale IKT-Dienste außerhalb des ISO-Scope liegen, kann eine Erweiterung sinnvoll sein. Sie erhöht unabhängige Assurance und vereinheitlicht Governance. Aufwand und Nutzen werden gegen bestehende Aufsichtsnachweise bewertet.

Die Zertifizierung sollte nicht allein für ein Compliance-Siegel erweitert werden. Der Scope muss echte Steuerungsverantwortung und End-to-End-Abhängigkeiten abbilden. Ausgelagerte Dienste bleiben über Lieferantenkontrollen eingebunden.

Ein Mapping mit sechs Spalten

  1. DORA-Artikel und konkretisierenden technischen Standard erfassen.
  2. Anwendbaren Rechtsträger, Funktion und Systemscope bestimmen.
  3. Bestehenden ISO-Prozess oder Kontrolle zuordnen.
  4. DORA-spezifische Ergänzung, Frequenz und Entscheidung dokumentieren.
  5. Verantwortlichen und belastbaren Betriebsnachweis benennen.
  6. Gap, Priorität, Termin und unabhängigen Nachtest festlegen.

Beispiel: Vorhandenes ISO-Risikoregister

Eine Bank bewertet Anwendungen bereits nach Vertraulichkeit, Integrität und Verfügbarkeit. Für DORA ergänzt sie kritische Funktionen, Auswirkungs- und Risikotoleranz, Dienstleister, Testresultate und Wiederherstellungsziele. Risiken werden auf die Finanzleistung zurückgeführt.

Das bestehende Genehmigungs- und Reviewverfahren bleibt erhalten. DORA-Trigger wie schwerwiegender Vorfall, wesentlicher Systemwechsel oder Aufsichtshinweis lösen zusätzliche Überprüfung aus. Dadurch entsteht Erweiterung statt Parallelregister.

Beispiel: ISO-zertifizierter Cloudanbieter

Das Zertifikat des Anbieters unterstützt Due Diligence zu Managementsystem und Kontrollen. Das Finanzunternehmen prüft zusätzlich Scope, konkrete Serviceleistung, Unterauftragnehmer, Standort, Vorfallunterstützung, Auditfähigkeit, Konzentration und Exit. Kritische oder wichtige Funktionen erfordern erweiterte Vertragsregelungen.

Ein jährlich gelieferter Zertifizierungsbericht kann Überwachungsevidenz sein. Er ersetzt keine Bewertung von Serviceausfällen und keine eigene Exit-Übung. Findings werden mit der eigenen Funktion und Risikotoleranz verknüpft.

Typische Mapping-Fehler

Der häufigste Fehler ist ein Kreuz in einer Tabelle, weil ISO und DORA beide „Risikomanagement“ nennen. Ohne Scope, Frequenz, Datenobjekt und Nachweis bleibt unklar, ob die DORA-Anforderung tatsächlich erfüllt ist. Ebenso problematisch ist die pauschale Behauptung, Annex A decke sämtliche technische Standards ab.

Das Gegenstück ist der komplette Neuaufbau. Dadurch entstehen doppelte Risiken, Kontrollen und Audits. Ein gutes Mapping nutzt bestehende Prozesse, benennt aber DORA-spezifische Erweiterungen transparent.

Fazit: Das ISMS ist das Betriebssystem, DORA das Fachprofil

ISO 27001 liefert den stabilen Managementrahmen für Führung, Risiken, Kontrollen, Audits und Verbesserung. DORA fügt ein verbindliches Fachprofil für digitale operationale Resilienz im Finanzsektor hinzu. Die Kombination ist effizient, wenn Scope und Nachweise präzise gemappt werden.

BlackMount unterstützt beim integrierten DORA- und ISO-27001-Mapping, bei Gap-Analyse, Kontrollregister und Nachweisdesign. Ziel ist ein gemeinsames wirksames Managementsystem ohne Doppelstrukturen und ohne unbelegte Compliance-Aussagen.

Verwendete Primärquellen