Von BAIT, VAIT, KAIT und ZAIT zu DORA: Mapping und Umsetzung über das ISMS

Problem in der Praxis

Viele Häuser haben ihre IT-Governance über Jahre entlang der xAIT-Rundschreiben strukturiert, oft gestützt auf ein ISMS nach ISO/IEC 27001 oder IT-Grundschutz. Mit dem Geltungsbeginn von DORA zum 17.01.2025 entsteht der Reflex, ein zweites, paralleles DORA-Programm aufzusetzen. Das führt zu Doppelstrukturen: dieselbe Maßnahme wird zweimal beschrieben, zweimal geprüft und doch keinem Rahmen sauber zugeordnet.

Erschwerend wirkt die Unsicherheit über den Übergang. ZAIT, VAIT und KAIT wurden zum 16.01.2025 aufgehoben; für DORA-pflichtige Institute entfällt die Bindung an die BAIT ebenfalls ab diesem Zeitpunkt. Die vollständige Aufhebung der BAIT ist für einen späteren Zeitpunkt vorgesehen; das genaue Datum und etwaige Übergangsfälle sind national zu prüfen, da nicht jedes Institut zwingend in den DORA-Anwendungsbereich fällt. In dieser Gemengelage verlieren Organisationen leicht den Überblick, welche Anforderung aktuell aus welcher Quelle gilt.

CISO-Einordnung

DORA ist eine Verordnung und damit in allen Mitgliedstaaten unmittelbar anwendbar; eine nationale Umsetzung wie bei einer Richtlinie ist nicht erforderlich. In Deutschland regelt das Finanzmarktdigitalisierungsgesetz (FinmadiG) mit dem DORA-Durchführungsgesetz vor allem Zuständigkeiten und Durchführung; aufsichtlich federführend sind BaFin und Deutsche Bundesbank. Die xAIT waren demgegenüber Verwaltungspraxis der BaFin zur Auslegung der allgemeinen organisatorischen Pflichten und somit national geprägt.

Drei Beziehungen sind sauber zu trennen:

• DORA löst die xAIT ab und beschreibt das "Was" und "Wozu" der digitalen operationalen Resilienz entlang von fünf Säulen: IKT-Risikomanagement, Behandlung und Meldung IKT-bezogener Vorfälle, Resilienztests einschließlich TLPT für identifizierte Einheiten, Management des IKT-Drittparteienrisikos und Informationsaustausch.
• Das ISMS liefert das "Wie". ISO/IEC 27001, IT-Grundschutz und als Outcome-Bezugsrahmen das NIST Cybersecurity Framework stellen Controls bereit, mit denen ein großer Teil der DORA-Anforderungen abgebildet werden kann: Governance, Risikobehandlung, Asset- und Zugriffsmanagement, BCM, Lieferantenmanagement und Incident-Prozesse.
• MaRisk bleibt als Governance-Klammer für Institute relevant, soweit es nicht von DORA verdrängt wird. Wo MaRisk und DORA denselben Sachverhalt regeln, geht für Finanzunternehmen die spezifischere DORA-Vorgabe vor; die übergreifende Risikomanagement-Verantwortung des Leitungsorgans bleibt erhalten und trifft sich mit der Leitungsorgan-Verantwortung, die DORA selbst vorsieht.

Zugleich gilt: Ein ISMS ist kein Zertifizierungsersatz für DORA. DORA fordert Spezifika über ISO hinaus, etwa bedrohungsorientierte Penetrationstests (TLPT), die standardisierte Klassifizierung und Meldung schwerwiegender Vorfälle, das Register der Informationen, verbindliche Schlüsselvertragsbestimmungen und den EU-Aufsichtsrahmen für kritische IKT-Drittdienstleister. Diese Elemente sind als Delta zum vorhandenen ISMS zu behandeln.

Umsetzungsperspektive

Der CISO sollte den Übergang als Mapping-Projekt mit anschließendem Regelbetrieb organisieren, nicht als Neuaufbau:

• Mapping-Baseline: Die fünf DORA-Säulen werden auf das bestehende Control-Set (ISO/IEC 27001, IT-Grundschutz, NIST CSF) und auf die fortgeltenden MaRisk-Bezüge abgebildet. Ergebnis ist eine Zuordnung, welche vorhandene Maßnahme welche DORA-Anforderung adressiert.
• Gap-Identifikation: Sichtbar werden die DORA-Spezifika ohne klares ISMS-Pendant. Diese Lücken werden priorisiert geschlossen, nicht das gesamte Programm dupliziert.
• Doppelnutzung der Nachweise: Ein Nachweis sollte mehrere Rahmen zugleich bedienen. Ein und derselbe BCM-Test, Vorfallbericht oder Lieferantenprüfbericht kann ISMS-Audit, DORA-Pflicht und interne MaRisk-Governance belegen, wenn er einmal sauber erzeugt und mehrfach referenziert wird.
• Verbindlichkeitslogik: Verbindliche Details werden konsequent auf den Verordnungstext und die einschlägigen technischen Standards (RTS/ITS) zurückgeführt, nicht auf die abgelösten xAIT-Formulierungen.

So entsteht ein einziges Steuerungsmodell, in dem DORA die regulatorische Pflicht setzt und das ISMS die wiederholbare Umsetzung trägt.

Typische Fehler

1. DORA wird als paralleles Programm neben dem ISMS aufgebaut, statt die DORA-Anforderungen auf vorhandene Controls zu mappen.
2. Alte xAIT-Texte werden als Auslegungsgrundlage weitergenutzt, obwohl verbindlich nur noch DORA und die technischen Standards sind.
3. Die DORA-Spezifika (TLPT, standardisierte Vorfallmeldung, Register der Informationen, Schlüsselvertragsbestimmungen) werden übersehen, weil das ISMS als ausreichend angenommen wird.
4. MaRisk wird entweder vollständig verworfen oder unverändert weitergeführt, ohne die Abgrenzung zu DORA zu klären.
5. Nachweise werden je Rahmen getrennt erzeugt, sodass derselbe Sachverhalt mehrfach dokumentiert und doch nirgends sauber zugeordnet ist.
6. Die Proportionalität wird ignoriert; kleinere Einheiten unter dem vereinfachten Rahmen bauen unnötig schwere Strukturen.

Risiken und Trade-offs

Ein reines Mapping kann ein vorhandenes ISMS überschätzen: Wer Controls nur formal zuordnet, ohne ihre Wirksamkeit gegen die DORA-Outcomes zu prüfen, erzeugt eine Scheinabdeckung. Umgekehrt führt ein vollständiger Neuaufbau zu Doppelarbeit und bindet Ressourcen, die für die echten Lücken fehlen.

Auch die Governance-Frage ist ein Trade-off. Wer MaRisk und DORA zu eng verzahnt, riskiert Unklarheit, welche Vorgabe im Konfliktfall gilt; wer sie zu strikt trennt, erzeugt zwei Steuerungswelten mit getrennten Berichtswegen. Maßstab ist die Angemessenheit nach Größe, Risikoprofil und Komplexität, die DORA durchgängig vorsieht. Die Wahl des Mapping-Bezugsrahmens (ISO, IT-Grundschutz, NIST CSF) ist zudem nicht normativ entschieden; sie sollte zur vorhandenen ISMS-Landschaft passen, statt einen neuen Standard einzuführen.

Entscheidungspunkte

• Fällt das Haus vollständig in den DORA-Anwendungsbereich, und wie wirkt sich das auf die Fortgeltung der BAIT und die MaRisk-Abgrenzung aus?
• Welcher ISMS-Rahmen dient als Mapping-Baseline, und wer verantwortet die Pflege der Zuordnung?
• Welche DORA-Spezifika sind als echte Lücke einzustufen, und mit welcher Priorität werden sie geschlossen?
• Wie werden Nachweise so gestaltet, dass sie DORA, ISMS und fortgeltende MaRisk-Bezüge zugleich bedienen?
• Wo gilt im Konfliktfall MaRisk, wo DORA, und wie wird diese Abgrenzung dokumentiert und kommuniziert?

Praktische Empfehlungen

1. Erstellen Sie eine belastbare Mapping-Matrix von den fünf DORA-Säulen auf das bestehende Control-Set und die fortgeltenden MaRisk-Bezüge.
2. Behandeln Sie nur die DORA-Spezifika als Neubau und schließen Sie diese Lücken priorisiert, statt das gesamte Programm zu duplizieren.
3. Führen Sie verbindliche Aussagen stets auf den Verordnungstext und die technischen Standards (RTS/ITS) zurück, nicht auf abgelöste xAIT-Texte.
4. Gestalten Sie Nachweise als Mehrfachbeleg, damit ein Test- oder Prüfergebnis mehrere Rahmen zugleich bedient.
5. Klären Sie die Abgrenzung zwischen MaRisk und DORA ausdrücklich und halten Sie fest, welche Vorgabe im Konfliktfall vorgeht.
6. Berücksichtigen Sie die Proportionalität und den vereinfachten Rahmen für kleinere Einheiten, statt einheitlich maximale Strukturen vorzugeben.

Relevante Normreferenzen

• DORA, Verordnung (EU) 2022/2554: unmittelbar geltendes EU-Recht, löst die aufsichtlichen IT-Anforderungen ab; verbindliche Details über EUR-Lex und die RTS/ITS der ESAs.
• Nationale Durchführung in Deutschland: Finanzmarktdigitalisierungsgesetz (FinmadiG) mit DORA-Durchführungsgesetz; Zuständigkeit bei BaFin und Deutscher Bundesbank. Aufhebung von ZAIT, VAIT, KAIT sowie Befreiung von der BAIT für DORA-pflichtige Institute; konkrete Termine national zu prüfen.
• MaRisk (Mindestanforderungen an das Risikomanagement) als fortgeltende Governance-Klammer, soweit nicht von DORA verdrängt.
• ISO/IEC 27001 sowie IT-Grundschutz als ISMS-Umsetzungsrahmen: nutzbar zur Abbildung, kein Ersatz für DORA-Pflichten.
• NIST Cybersecurity Framework als Outcome- und Control-Bezugsrahmen (Mapping möglich, nicht normativ).
• NIS2 (Richtlinie (EU) 2022/2555): DORA ist für Finanzunternehmen lex specialis und geht insoweit vor.