Stand: 2026-11-06
Diese Seite gilt für beide Rahmen: für Finanzunternehmen im Vollrahmen nach Art. 5 bis 15 DORA und für Unternehmen im vereinfachten Rahmen nach Art. 16, darunter ab dem 01.01.2027 die Institute nach § 1a Abs. 2a KWG wie Factoring- und Leasinginstitute. Sie richtet sich an Unternehmen, die schon ein Informationssicherheitsmanagementsystem (ISMS) nach ISO/IEC 27001:2022 betreiben, zertifiziert oder nicht. Wie man ein ISMS einführt und zertifizieren lässt, beschreibt Blackfort Technology auf der Firmenseite zur ISO-27001-Beratung. Für Unternehmen unter NIS2 steht das Gegenstück auf NIS2 und ISO 27001.
Wie verhalten sich ISO 27001 und DORA zueinander?
DORA ist Gesetz, ISO/IEC 27001 eine freiwillige Norm. DORA verweist nicht auf die Norm, öffnet aber die Tür: Die Sicherheitsrichtlinien im Vollrahmen berücksichtigen führende Praktiken und gegebenenfalls Normen (RTS (EU) 2024/1774 Art. 2 Abs. 2 lit. h, im Folgenden RTS), und für die Dokumentation dürfen Finanzunternehmen alle Unterlagen verwenden, über die sie schon verfügen (RTS Erwägungsgrund 2). Ein ISMS ist deshalb ein guter Ausgangspunkt. Die Unterschiede liegen weniger in den Schutzmaßnahmen als in Rahmen und Verbindlichkeit:
| Thema | ISMS nach ISO/IEC 27001 | DORA |
|---|---|---|
| Geltungsbereich | legt die Organisation selbst fest, etwa einen Standort oder eine Plattform | nach unserer Einordnung das IKT-Risiko des ganzen Finanzunternehmens |
| Maßnahmen | Anhang A als Referenzliste, Auswahl und Ausschlüsse begründet in der Anwendbarkeitserklärung | verbindliche Vorgaben, im Vollrahmen teils mit Fristen wie wöchentlichen Scans (RTS Art. 10 Abs. 2) |
| Risiko | Risikokriterien und Akzeptanz durch die Organisation | Toleranzschwelle für das IKT-Risiko, im Vollrahmen vom Leitungsorgan festgelegt (Art. 5 Abs. 2 lit. d, Art. 6 Abs. 8 lit. b) |
| Außenwirkung | Zertifikat einer Zertifizierungsstelle, wenn gewünscht | Meldungen, Register und Berichte an die BaFin, Aufsicht durch die BaFin |
Ein Zertifikat ersetzt keine DORA-Pflicht. Eine Zertifizierung für DORA selbst gibt es nicht, wie DORA geprüft wird, zeigt die Seite DORA-Prüfung.
Mapping der Klauseln 4 bis 10
Die Klauseln beschreiben das Managementsystem. Sie decken den Kreislauf aus Planung, Umsetzung, Prüfung und Verbesserung ab, den DORA für den IKT-Risikomanagementrahmen ebenfalls verlangt. Bezeichnungen sind eigene Kurzfassungen, die Deckung ist unsere Einordnung.
| Klausel | DORA Vollrahmen | Art.-16-Rahmen | Deckung | Was DORA zusätzlich verlangt |
|---|---|---|---|---|
| 4 Kontext und Anwendungsbereich | Art. 6 Abs. 1, Art. 8 | Art. 16 Abs. 1 lit. a, RTS Art. 30 | teilweise | Rahmen nach unserer Einordnung für das ganze Unternehmen, ausgehend von kritischen oder wichtigen Funktionen und ihren Abhängigkeiten |
| 5 Führung | Art. 5 Abs. 2 und 4 | RTS Art. 28 Abs. 1 und 2 | teilweise | letztendliche Verantwortung, Genehmigung von Strategie, Leitlinien, Plänen und Budget, Schulung der Mitglieder des Leitungsorgans (Vollrahmen), Genehmigung von Klassifizierung, BIA und Geschäftsfortführungsplänen (Art. 16) |
| 6 Planung | Art. 6 Abs. 8, RTS Art. 3 | RTS Art. 31 | weitgehend | Toleranzschwelle, im Vollrahmen DOR-Strategie und Inventar der Restrisiken (RTS Art. 3 lit. d) |
| 7 Unterstützung | Art. 5 Abs. 2 lit. g, Art. 13 Abs. 6, Art. 14 | Art. 16 Abs. 1 lit. h, RTS Art. 28 Abs. 2 lit. e | weitgehend | Schulung auch für die Geschäftsleitung, im Vollrahmen Kommunikationspläne für Vorfälle |
| 8 Betrieb | Art. 9 bis 12, RTS Titel II | RTS Art. 32 bis 39 | weitgehend | konkrete Einzelvorgaben aus dem RTS, siehe Anhang A unten |
| 9 Bewertung der Leistung | Art. 6 Abs. 5 bis 7, RTS Art. 27 | Art. 16 Abs. 2, RTS Art. 28 Abs. 5 und 6, Art. 41 | teilweise | Revision mit IKT-Fachwissen, Follow-up kritischer Feststellungen, Überprüfungsbericht mit vorgegebenem Inhalt |
| 10 Verbesserung | Art. 13 | Art. 16 Abs. 1 lit. h und Abs. 2 | weitgehend | Nachbetrachtung schwerwiegender Vorfälle, im Vollrahmen jährlicher Bericht an das Leitungsorgan (Art. 13 Abs. 5) |
Mapping von Anhang A
Anhang A der Norm von 2022 hat 93 Controls in vier Themen: Organisation (5.1 bis 5.37), Personal (6.1 bis 6.8), physische Sicherheit (7.1 bis 7.14) und Technik (8.1 bis 8.34). Die Tabelle fasst sie nach Themen zusammen. „Weitgehend“ heißt: Ein wirksam umgesetzter Control liefert den Großteil des Nachweises. „Teilweise“ heißt: DORA verlangt deutlich mehr. „Gering“ heißt: Die Norm berührt das Thema, die DORA-Pflicht ist eine andere.
| Anhang A | Thema | DORA Vollrahmen | Art.-16-Rahmen | Deckung | Was DORA zusätzlich verlangt |
|---|---|---|---|---|---|
| 5.1, 5.4 | Richtlinien, Pflichten der Leitung | Art. 9 Abs. 4 lit. a, RTS Art. 2 | RTS Art. 29 | weitgehend | Genehmigungsdatum des Leitungsorgans, Abstimmung auf die DOR-Strategie, Verzeichnis der Dokumentation (RTS Art. 2 Abs. 2 lit. a, b, f) |
| 5.2, 5.3 | Rollen, Aufgabentrennung | Art. 5 Abs. 2 lit. c, Art. 6 Abs. 4, RTS Art. 2 Abs. 2 lit. g | RTS Art. 28 Abs. 2 lit. b und Abs. 4 | teilweise | IKT-Risikokontrollfunktion mit angemessener Unabhängigkeit (Vollrahmen), Trennung von Kontrolle und Revision (beide) |
| 5.5, 5.6 | Kontakt zu Behörden und Fachkreisen | Art. 19, Art. 45 | Art. 19, Art. 45 | gering | Meldung schwerwiegender Vorfälle in drei Stufen mit Fristen, Mitteilung der Teilnahme an Vereinbarungen zum Informationsaustausch (Art. 45 Abs. 3) |
| 5.7 | Bedrohungsinformationen | Art. 13 Abs. 1 | RTS Art. 31 Abs. 3, Art. 34 lit. h | weitgehend | Bezug auf kritische oder wichtige Funktionen |
| 5.9 bis 5.13 | Inventar, Klassifizierung | Art. 8, RTS Art. 4, 5 | RTS Art. 30 | teilweise | Klassifizierung entlang kritischer oder wichtiger Funktionen mit Abhängigkeiten, auch bei Dienstleistern |
| 5.15 bis 5.18, 8.2, 8.3, 8.5 | Zugang, Identitäten, privilegierte Rechte, Authentifizierung | Art. 9 Abs. 4 lit. c, d, RTS Art. 20, 21 | RTS Art. 33 | weitgehend | Need-to-use, privilegierter Zugang nur bei Bedarf und protokolliert, starke Authentifizierung, im Vollrahmen Rezertifizierung mindestens alle sechs Monate bei Systemen kritischer oder wichtiger Funktionen (RTS Art. 21 lit. e iv) |
| 5.19 bis 5.23 | Lieferanten, Lieferkette, Cloud | Art. 28 bis 30 | Art. 28 bis 30 ohne Art. 28 Abs. 2, nicht für Kleinstunternehmen der KWG-Gruppe | teilweise | Informationsregister, Mindestinhalte der Verträge nach Art. 30, Konzentrationsrisiko (Art. 29), Ausstiegsstrategien (Art. 28 Abs. 8), im Vollrahmen Strategie für das Drittparteienrisiko (Art. 28 Abs. 2) |
| 5.24 bis 5.28, 6.8 | Vorfallmanagement | Art. 17 bis 19, RTS Art. 22, 23 | Art. 17 bis 19, RTS Art. 31 Abs. 4, Art. 34 lit. g | teilweise | Klassifizierung nach der Delegierten Verordnung (EU) 2024/1772 und Meldung an die BaFin |
| 5.29, 5.30, 8.14 | Sicherheit bei Störungen, IKT-Bereitschaft, Redundanz | Art. 11, Art. 12 Abs. 4, RTS Art. 24 bis 26 | RTS Art. 39, 40 | teilweise | Business-Impact-Analyse, Wiederherstellungsziele je Funktion, Szenarien, jährliche Tests, im Vollrahmen Krisenmanagementfunktion |
| 8.13 | Datensicherung | Art. 12 Abs. 1 bis 3, 7 | RTS Art. 39 Abs. 2 lit. g | weitgehend | Mindesthäufigkeit nach Kritikalität, im Vollrahmen Wiederherstellung auf getrennten Systemen und Datenabgleich |
| 5.31, 5.35, 5.36 | rechtliche Anforderungen, unabhängige Überprüfung, Einhaltung | Art. 6 Abs. 5 bis 7, RTS Art. 27 | Art. 16 Abs. 2, RTS Art. 28 Abs. 5, 6, Art. 41 | teilweise | interne Revision nach Revisionsplan, Überprüfungsbericht in durchsuchbarem elektronischem Format |
| 6.1 bis 6.6 | Personal vor, während und nach der Beschäftigung | RTS Art. 19 | keine ausdrückliche Vorgabe | weitgehend | Vorgaben auch für Beschäftigte von IKT-Drittdienstleistern, die Assets des Unternehmens nutzen (RTS Art. 19 lit. b) |
| 6.3 | Sensibilisierung und Schulung | Art. 5 Abs. 4, Art. 13 Abs. 6 | Art. 16 Abs. 1 lit. h | teilweise | Schulung für Personal und Geschäftsleitung, im Vollrahmen regelmäßige Schulung der Mitglieder des Leitungsorgans |
| 6.7, 8.1 | Telearbeit, Endgeräte | RTS Art. 11 Abs. 2 lit. f, j | RTS Art. 35 lit. b, g | weitgehend | Fernlöschung von Unternehmensdaten auf mobilen Geräten (Vollrahmen) |
| 7.1 bis 7.14 | physische Sicherheit | RTS Art. 18 | RTS Art. 32 | weitgehend | Ausrichtung an der Klassifizierung der Assets |
| 8.6, 8.9, 8.19 | Kapazität, Konfiguration, Softwareinstallation | Art. 7, RTS Art. 9, 11 | RTS Art. 34 lit. c, Art. 35 lit. b | weitgehend | sichere Konfigurationsbasis mit regelmäßiger Prüfung (Vollrahmen) |
| 8.7, 8.8 | Schadsoftware, Schwachstellen | RTS Art. 10, 11 Abs. 2 lit. d | RTS Art. 34 lit. d, i | teilweise | automatisierte Schwachstellensuche, im Vollrahmen mindestens wöchentlich bei Assets kritischer oder wichtiger Funktionen, Fristen und Eskalation für Patches, Schwachstellenmeldungen der Dienstleister |
| 8.10 bis 8.12 | Löschung, Maskierung, Schutz vor Datenabfluss | RTS Art. 11 Abs. 2 lit. g bis i, Art. 16 Abs. 5 | RTS Art. 34 lit. i, Art. 35 lit. e, f | weitgehend | im Vollrahmen anonymisierte, pseudonymisierte oder randomisierte Testdaten |
| 8.15 bis 8.17 | Protokollierung, Überwachung, Zeitsynchronisation | Art. 10, RTS Art. 12, 23 | RTS Art. 33, Art. 34 lit. f, g | weitgehend | Speicherfristen festlegen, Alarmschwellen für die Reaktion auf Vorfälle |
| 8.20 bis 8.23, 5.14 | Netze, Informationsübertragung | RTS Art. 13, 14 | RTS Art. 35 lit. c, d | weitgehend | - |
| 8.24 | Kryptografie | Art. 9 Abs. 4 lit. d, RTS Art. 6, 7 | RTS Art. 35 lit. a | teilweise | Schutz auch von Daten in Verwendung, im Vollrahmen Schlüsselmanagement über den Lebenszyklus und Register aller Zertifikate für Assets kritischer oder wichtiger Funktionen (RTS Art. 7 Abs. 4) |
| 8.25 bis 8.31, 8.33 | sichere Entwicklung, Sicherheitstests, Testdaten | RTS Art. 16 | RTS Art. 37 | teilweise | im Vollrahmen Quellcodeprüfung mit statischen und dynamischen Tests, auch für Code von Dritten und aus Open-Source-Projekten (RTS Art. 16 Abs. 3 und 8) |
| 8.32, 5.8 | Änderungen, Projekte | RTS Art. 15, 17 | RTS Art. 38 | weitgehend | Änderungen werden aufgezeichnet, getestet, bewertet, genehmigt, implementiert und verifiziert (RTS Art. 38 Abs. 2, im Vollrahmen ausführlicher RTS Art. 17) |
Was ein ISMS nicht liefert
Einige DORA-Pflichten haben in der Norm keine Entsprechung. Sie kommen zum ISMS hinzu:
| Pflicht | Fundstelle | Rahmen | Vertiefung |
|---|---|---|---|
| Informationsregister aller Verträge über IKT-Dienstleistungen | Art. 28 Abs. 3, Durchführungsverordnung (EU) 2024/2956 | beide, nicht für Kleinstunternehmen der KWG-Gruppe | Informationsregister |
| Klassifizierung und Meldung schwerwiegender IKT-Vorfälle an die BaFin | Art. 18, 19 | beide | IKT-Vorfälle melden |
| Mindestinhalte der Verträge, Ausstiegsstrategien, Konzentrationsrisiko | Art. 28 Abs. 8, Art. 29, 30 | beide, nicht für Kleinstunternehmen der KWG-Gruppe | IKT-Drittdienstleister steuern |
| Testprogramm und TLPT für bestimmte Unternehmen | Art. 24 bis 27 | Vollrahmen, Testprogramm im Art.-16-Rahmen nach unserer Lesart (siehe Art. 16 DORA) | DORA-Resilienztests |
| Pflichten und Schulung des Leitungsorgans | Art. 5 Abs. 2 und 4, RTS Art. 28 Abs. 2 | beide, Art. 5 Abs. 4 nur im Vollrahmen | IKT-Risikomanagement |
| DOR-Strategie und IKT-Risikokontrollfunktion | Art. 6 Abs. 4 und 8 | Vollrahmen | IKT-Risikomanagement |
| Business-Impact-Analyse und Wiederherstellungsziele je Funktion | Art. 11 Abs. 5, Art. 12 Abs. 6, RTS Art. 39 Abs. 2 lit. d | beide | IKT-Geschäftsfortführung |
Beispiel: ISMS-Abgleich eines Zahlungsinstituts
Fiktives Beispiel, kein Kunde. Die Muster-Zahlungsdienste GmbH ist das Zahlungsinstitut aus dem Beispiel auf der Seite ZAIT und DORA: 14 Beschäftigte, Kartenzahlungen für Onlinehändler, Vollrahmen. Ihr ISMS ist seit Jahren nach ISO/IEC 27001 zertifiziert, Geltungsbereich: Entwicklung und Betrieb des Händlerportals und der Anbindung an die Zahlungsplattform, die ein Processor als Cloud-Dienst liefert. Kundenservice, Buchhaltung und Meldewesen liegen außerhalb. Der Abgleich gegen DORA ergab:
| Bereich | Befund | DORA-Bezug | Maßnahme |
|---|---|---|---|
| Geltungsbereich | Das aufsichtliche Meldewesen ist eine kritische oder wichtige Funktion, liegt aber außerhalb des ISMS. | Art. 6 Abs. 1, Art. 8 | Rahmen auf das ganze Institut ausdehnen, Zertifikatsumfang bei der nächsten Rezertifizierung prüfen |
| Anwendbarkeitserklärung | Control 8.11 (Maskierung) ausgeschlossen, Tests laufen mit Produktionsdaten. | RTS Art. 16 Abs. 5 | Testdaten anonymisieren oder Ausnahmen mit Genehmigung regeln |
| Lieferanten | Verträge mit dem Processor und dem Anbieter der Betrugserkennung nach eigenem ISMS-Muster, ohne Prüfrechte der Aufsicht und ohne Ausstiegsunterstützung. | Art. 30 Abs. 2 und 3, Art. 28 Abs. 8 | Vertragsanlage nach Art. 30, Ausstiegspläne für beide Dienstleister |
| Schwachstellen | Scans monatlich. | RTS Art. 10 Abs. 2 | wöchentliche Scans für Assets kritischer oder wichtiger Funktionen |
| Leitungsorgan | Managementbewertung einmal im Jahr durch den ISB, die Geschäftsführung nimmt sie zur Kenntnis. | Art. 5 Abs. 2 und 4 | Genehmigung der Richtlinien und der Geschäftsfortführungsleitlinie durch die Geschäftsführung, Schulungsplan für ihre Mitglieder |
Die meisten Befunde betrafen Umfang, Verträge, Fristen und Verantwortung, weniger die Schutzmaßnahmen selbst.
Drei typische Lücken
| Lücke | Ursache | Wirkung | Abhilfe |
|---|---|---|---|
| Geltungsbereich des Zertifikats zu eng | Das ISMS wurde für einen Kundenanspruch zertifiziert, etwa nur für die Plattform oder das Rechenzentrum. | Funktionen außerhalb des Geltungsbereichs, oft Meldewesen oder Fachbereiche, fehlen in Risikobeurteilung, Tests und Nachweisen. | Kritische oder wichtige Funktionen gegen den Geltungsbereich legen und den Rahmen auf das ganze Unternehmen ausdehnen. Das Zertifikat darf enger bleiben. |
| Anwendbarkeitserklärung schließt aus, was DORA verlangt | Controls wurden aus Aufwandsgründen ausgeschlossen, etwa Maskierung, sichere Programmierung oder Sicherheitstests in der Entwicklung. | Für die ausgeschlossenen Themen fehlt jeder Nachweis, obwohl der RTS sie im Vollrahmen ausdrücklich vorgibt. | Jeden Ausschluss gegen DORA und RTS prüfen und in der Anwendbarkeitserklärung eine Spalte mit der DORA-Fundstelle ergänzen. |
| Managementbewertung gilt als Überprüfungsbericht | Der jährliche ISMS-Bericht wird der Aufsicht als Überprüfung des Rahmens angeboten. | Inhalt und Format nach RTS Art. 27 bzw. Art. 41 fehlen, etwa Genehmigungsdatum, Anlass, Zeitraum, zuständige Funktion oder Person und Abhilfemaßnahmen mit Termin. | Den Bericht nach der Gliederung des RTS aufbauen und die Managementbewertung als Quelle nutzen. |
Wie wir unterstützen
Die DORA-Gap-Analyse legt Ihr ISMS neben DORA und den RTS und nutzt dabei Ihre Anwendbarkeitserklärung als Ausgangspunkt, für Institute im vereinfachten Rahmen als Art.-16-Gap-Analyse. Institute der KWG-Gruppe, die zum 01.01.2027 von der BAIT wechseln, übertragen vorhandene ISMS-Unterlagen im Umstieg von der BAIT in die Gliederung des RTS.
Häufige Fragen
Schreibt DORA eine ISO-27001-Zertifizierung vor?+
Nein. DORA verlangt einen IKT-Risikomanagementrahmen mit festgelegten Inhalten, aber kein Zertifikat nach einer Norm. Die Sicherheitsrichtlinien sollen führende Praktiken und gegebenenfalls Normen berücksichtigen (RTS (EU) 2024/1774 Art. 2 Abs. 2 lit. h). Ob Sie dafür ISO/IEC 27001 nutzen und sich zertifizieren lassen, entscheiden Sie selbst.
Dürfen wir vorhandene ISMS-Dokumente für DORA weiterverwenden?+
Ja. Nach Erwägungsgrund 2 des RTS (EU) 2024/1774 dürfen Finanzunternehmen für die Dokumentationsanforderungen alle Unterlagen verwenden, über die sie bereits verfügen. Wichtig ist, dass jede Vorgabe des RTS in den Dokumenten auffindbar ist, etwa über eine Zuordnungsliste wie die Mapping-Tabelle oben, und dass die Dokumente die Genehmigung durch das Leitungsorgan zeigen, wo DORA sie verlangt.
Reicht das ISO-Zertifikat unseres IT-Dienstleisters aus?+
Es ist ein guter Hinweis, ersetzt aber Ihre eigenen Pflichten nicht. Sie dürfen nur mit Dienstleistern arbeiten, die angemessene Standards für Informationssicherheit einhalten, bei kritischen oder wichtigen Funktionen berücksichtigen Sie die aktuellsten und höchsten Qualitätsstandards (Art. 28 Abs. 5 DORA). Prüfen Sie Geltungsbereich und Datum des Zertifikats. Die Vertragsinhalte nach Art. 30 und Ihre Verantwortung nach Art. 28 Abs. 1 lit. a bleiben unabhängig davon bestehen.
Gilt das Mapping auch für IT-Grundschutz?+
Die Methode ja: Bausteine oder Anforderungen den Fundstellen in DORA und RTS zuordnen, Deckung bewerten, Fehlendes ergänzen. Eine Zuordnung der Grundschutz-Bausteine zu DORA enthält diese Seite nicht. Wie ein Sicherheitskonzept nach IT-Grundschutz entsteht, zeigt die Seite Sicherheitskonzept nach IT-Grundschutz.
Weiterlesen
- DORA Anforderungen: Pflichtenmatrix für Vollrahmen und Art. 16
- IKT-Risikomanagement nach DORA: Rahmen und DOR-Strategie
- Art. 16 DORA: der vereinfachte IKT-Risikomanagementrahmen
- DORA-Informationsregister: Aufbau, Pflichtfelder, Einreichung
- DORA-Meldepflicht: IKT-Vorfälle klassifizieren und melden
- DORA-Resilienztests: Testprogramm, Penetrationstest und TLPT
Quellen
- Verordnung (EU) 2022/2554 (DORA), Art. 5, 6, 8 bis 14, 16 bis 19, 24 bis 30, 45 (abgerufen am 2026-11-06)
- Delegierte Verordnung (EU) 2024/1774 (RTS IKT-Risikomanagement), Erwägungsgründe 2 und 6, Titel II und III (abgerufen am 2026-11-06)
- BSI: Mapping ISO/IEC 27001:2022 Annex A to GS++ (Control-Nummern von Anhang A), Stand-der-Technik-Bibliothek (abgerufen am 2026-11-06)
Diese Inhalte dienen der allgemeinen technischen und organisatorischen Information und stellen keine Rechtsberatung dar (keine Rechtsdienstleistung i. S. d. RDG).