DORA Firewall-Compliance für deutsche Finanzdienstleister: Artikel-Mapping und Nachweispack

Der Digital Operational Resilience Act (DORA, Verordnung (EU) 2022/2554) gilt seit dem 17. Januar 2025 verbindlich für Banken, Versicherungen, Wertpapierfirmen, Zahlungsdienstleister und ihre kritischen IKT-Drittdienstleister im gesamten EU-Binnenmarkt. Für deutsche Finanzdienstleister liegt DORA über den bestehenden BaFin-Rundschreiben — BAIT, VAIT, KAIT und ZAIT — und verschärft die Erwartungen an Firewall-Change-Management, Nachweisführung und Drittparteien-Aufsicht erheblich.

Diese Anleitung übersetzt DORA in das, was Firewall-Teams in Deutschland tatsächlich liefern müssen: welche Artikel ein Auditor öffnet, welche Artefakte dieser anfordert und wo die wiederkehrenden Lücken aus über 280 Enterprise-Migrationen sitzen. Der Schwerpunkt liegt auf der praktischen Schnittstelle zwischen DORA-Pflichten und der täglichen Firewall-Praxis — nicht auf einer Volltext-Wiedergabe der Verordnung.

Wer in Deutschland unter DORA fällt

DORA adressiert in Deutschland im Wesentlichen drei Adressatengruppen: regulierte Finanzunternehmen, deren IKT-Drittdienstleister und — über das ESA-Aufsichtsregime — kritische Drittdienstleister mit grenzüberschreitender Bedeutung. Konkret betroffen sind:

• Kreditinstitute nach KWG — jede CRR-Bank in Deutschland
• Versicherungs- und Rückversicherungsunternehmen nach VAG
• Wertpapierinstitute nach WpIG sowie Wertpapierhandelsbanken
• Zahlungs- und E-Geld-Institute nach ZAG
• Kapitalverwaltungsgesellschaften nach KAGB — mit der bekannten Befreiung für rein kleine AIFs
• Zentralverwahrer, zentrale Gegenparteien sowie Datenbereitstellungsdienste
• IKT-Drittdienstleister der genannten Adressaten — vertraglich, nicht direkt aufsichtsrechtlich

Drei Punkte überraschen deutsche Finanzdienstleister regelmäßig im Audit. Erstens: Konzerninterne IT-Servicegesellschaften zählen als IKT-Drittdienstleister, auch wenn sie zur selben Gruppe gehören. Zweitens: Die BaFin behält ihre nationale Aufsichtskompetenz; DORA tritt nicht an deren Stelle, sondern legt sich darüber. Drittens: Die in BAIT bekannten Erwartungen aus AT 7.2 MaRisk werden durch DORA Artikel 5–15 in regulatorisch verbindliche, EU-weite Form gegossen.

Die fünf DORA-Säulen aus Firewall-Sicht

DORA ist in fünf inhaltliche Säulen organisiert. Aus Firewall-Sicht sind drei davon unmittelbar relevant, zwei haben mittelbare Implikationen.

Die operative Last liegt bei Säule 1 und Säule 4. Säule 2 ist eine Frage der Log-Disziplin, Säule 3 wird in vielen Häusern an externe Tester vergeben, Säule 5 ist mittelbar.

Artikel 9 — Schutz und Prävention

Artikel 9 verlangt die Einrichtung von Strategien, Verfahren und Tools, die die Verfügbarkeit, Authentizität, Integrität und Vertraulichkeit von Daten gewährleisten. Aus Firewall-Sicht zerfällt Artikel 9 in drei prüfbare Teile:

1. Netzsegmentierung mit dokumentierter Begründung. Artikel 9(2)(c) verlangt „angemessene Sicherheitsmaßnahmen für das Netz und die Netzsicherheit“. In der Prüfungspraxis bedeutet das: ein Zonen-Diagramm, ein dokumentiertes Zonen-Modell und das vollständige Regelwerk der zonenübergreifend erlaubten Flüsse. Pauschal-Allow-Regeln zwischen kritischen Zonen sind ein direkter DORA-Finding.
2. Zugriffskontrolle nach Least-Privilege. Firewall-Regeln, die mit ANY-Source oder ANY-Destination arbeiten, erfüllen Artikel 9(4)(c) nicht. Die BaFin hat in frühen DORA-Prüfungen 2025 explizit nach der Begründung breiter Regeln gefragt.
3. Verschlüsselung an Vertrauensgrenzen. TLS-Inspection-Policies, Schlüsselverwaltung und die Definition, an welchen Punkten Klartext geprüft werden darf, gehören in das DORA-Beweispaket.

Wer den Aufbau einer Nachweis-Architektur strukturiert angehen will, findet im Nachweispack für NIS2 Artikel 21 einen weitgehend deckungsgleichen Rahmen — rund 80 Prozent der Artefakte werden für DORA wiederverwendet.

Artikel 10 — Erkennung

Artikel 10 verlangt Mechanismen zur Erkennung anomalen Verhaltens, einschließlich Netzwerk-Performance- und Sicherheitsabweichungen. Für Firewall-Teams bedeutet das in der Praxis drei Lieferungen:

• Vollständige Logging-Konfiguration auf jeder produktiven Firewall — mit dokumentiertem Begründungstext, falls Logging gezielt deaktiviert ist (z.B. für hochfrequente Health-Check-Regeln)
• SIEM-Anbindung mit Mindest-Aufbewahrung — DORA selbst gibt keine Frist; die in der Praxis akzeptierte Untergrenze liegt bei 12 Monaten online plus 24 Monaten Archiv für kritische IKT-Systeme
• Drift-Detection — ein dokumentierter Prozess, der Abweichungen vom genehmigten Soll-Zustand des Regelwerks erkennt. Wie das in der Praxis aussieht, beschreibt der Beitrag Policy-Drift-Detection im Detail.

Artikel 16 — IKT-Change-Management

Artikel 16 ist der Artikel, an dem Firewall-Teams in den ersten DORA-Audits am häufigsten scheitern. Er verlangt einen formalen IKT-Change-Management-Prozess, der jede Änderung an einem produktiven IKT-System dokumentiert, genehmigt, testet und nachverfolgbar implementiert.

Für Firewall-Changes heißt das konkret: pro Änderungsantrag muss nachweisbar sein, wer angefordert, wer technisch geprüft, wer genehmigt, wann implementiert und wer validiert hat. E-Mail-Ketten erfüllen das nicht. Spreadsheets erfüllen das nicht. Eine genaue Aufschlüsselung dieses Workflows findet sich im Leitfaden zum Firewall-Change-Management-Prozess.

Notfalländerungen sind in Artikel 16(2)(d) ausdrücklich vorgesehen, müssen aber innerhalb eines definierten Zeitfensters (typisch 5 Werktage) nachdokumentiert werden. Die wiederkehrende Audit-Lage zeigt: Notfall-Records sind die erste Lieferung, die ein DORA-Prüfer anfordert — weil dort die Disziplin am häufigsten bröckelt.

DORA und der bestehende BAIT/VAIT/KAIT-Rahmen

Für Verwirrung sorgt im deutschen Markt regelmäßig die Frage, ob BAIT, VAIT, KAIT und ZAIT durch DORA verdrängt werden. Die Antwort der BaFin ist klar: Nein. DORA ist eine EU-Verordnung mit unmittelbarer Anwendung; die nationalen Rundschreiben bleiben in den Bereichen bestehen, in denen sie zusätzliche Anforderungen stellen oder DORA-Themen präzisieren.

In der Praxis gilt eine einfache Faustregel: wo DORA und BAIT denselben Sachverhalt regeln, gilt der strengere Standard. Wo BAIT zusätzliche, nationale Erwartungen formuliert (z.B. Auslagerungsfragen), bleiben diese vollumfänglich anwendbar.

IKT-Drittparteien-Register und Firewall-Vendoren

DORA Artikel 28(3) verlangt von jedem Finanzunternehmen ein vollständiges Register aller IKT-Drittdienstleister-Vereinbarungen. Dieses Register ist nicht nur ein internes Werkzeug — ein Auszug muss jährlich an die zuständige nationale Behörde übermittelt werden, in Deutschland an die BaFin.

Für das Firewall-Estate ist relevant: jeder Hersteller, dessen Firewall im produktiven Betrieb steht, ist ein IKT-Drittdienstleister. Auch Reseller und Managed-Service-Provider, die Firewall-Operations als Dienstleistung erbringen, gehören ins Register. Der Datensatz pro Eintrag umfasst u.a.:

• Name und LEI des Drittdienstleisters
• Art der erbrachten IKT-Dienstleistung
• Konzern- oder Gruppenzugehörigkeit
• Standorte der Datenverarbeitung
• Substituierbarkeitsbewertung — wie lange dauert ein Wechsel
• Letzte Risikobewertung des Anbieters

Mehrhersteller-Estates entstehen dabei selten aus strategischer Absicht; sie wachsen historisch. Die operative Realität einer solchen Landschaft — und der Aufwand, den ein Mehrhersteller-Register erzeugt — wird im Beitrag zum Multi-Vendor-Firewall-Management diskutiert.

Wiederkehrende Lückenmuster aus 280 Migrationen

Über mehr als 280 Enterprise-Firewall-Migrationen, die ich analysiert habe, wiederholen sich vier Lücken konsistent. Sie gelten für NIS2 ebenso wie für DORA — aber DORA macht sie kostspieliger, weil die ESA-Aufsicht keine Schonfrist gewährt.

Erstens: Notfall-Änderungen werden nicht nachdokumentiert. Die Disziplin, einen Notfall-Change innerhalb von 5 Werktagen formal nachzuziehen, bröckelt unter operativer Last. Bei DORA-Prüfungen ist das die Lieferung, die ein Auditor zuerst anfordert.

Zweitens: Vendor-Zugriffsregeln werden nie zurückgezogen. Eine Wartungs-Regel für einen Drittdienstleister wird während eines Projekts geschaltet, das Projekt endet, die Regel bleibt. DORA Artikel 28 erwartet einen aktiven Stilllegungsprozess, nicht nur einen Aktivierungsprozess.

Drittens: Segmentierungs-Diagramme altern schneller als das Netz. Diagramme, die 18 Monate alt sind, sind nach zwei Zonen-Restrukturierungen veraltet. Für Threat-led Penetration Tests nach DORA Artikel 26 ist ein veraltetes Diagramm ein Befund vor dem ersten Paket.

Viertens: Aufbewahrungsrichtlinie und Speicherrealität klaffen auseinander. Die Policy nennt 12 Monate. Die tatsächliche SIEM-Rotation liegt bei 90 Tagen, weil das Storage-Budget gekürzt wurde. Beide Dokumente existieren; sie widersprechen sich. Auditoren prüfen die tatsächliche Speicherkonfiguration gegen die deklarierte Policy.

Das DORA-Pre-Audit-Pack für Firewall-Teams

Für ein deutsches Finanzunternehmen vor dem ersten DORA-Auditzyklus deckt ein Bundle aus sieben Artefakten in einem gemeinsamen Ordner den Großteil der firewall-relevanten Pflichten ab:

1. IKT-Risikoanalyse mit dokumentierter Verbindung zur Firewall-Policy (Art. 6, 8)
2. Netzwerk-Segmentierungsdiagramm mit Datum der letzten Prüfung (Art. 9)
3. Auszug aus dem Firewall-Change-Register der letzten 12 Monate, einschließlich Notfall-Records (Art. 16)
4. Logging- und Aufbewahrungsnachweis — Konfigurationsbeleg plus Speicher-Realitätsprüfung (Art. 10, 12)
5. Incident-Response-Runbook mit Firewall-Aktionen und BaFin-Meldekette (Art. 17–19)
6. IKT-Drittparteien-Register-Auszug mit Firewall-Vendoren und Service-Providern (Art. 28)
7. Letzter Penetrationstest- oder TLPT-Bericht mit Aussagen zur Segmentierungswirksamkeit (Art. 24–26)

Diese sieben Artefakte decken — mit kleinen Formatanpassungen — auch BAIT, VAIT, NIS2 Artikel 21 und ISO 27001 Annex A.13 weitgehend ab. Wer das Pack auf DORA-Niveau aufbaut, besteht angrenzende Audits in der Regel mit denselben Nachweisen. Die zugrundeliegende Methodik — abgeleitet aus der Datenanalyse von 280 Firewall-Migrationen — ist die Grundlage der FwChange-Audit-Pack-Architektur.

Sanktionen und Aufsichtsrealität

DORA Artikel 50 erlaubt nationalen Behörden Bußgelder bis zu einem Prozent des durchschnittlichen täglichen weltweiten Konzernumsatzes pro Tag der Zuwiderhandlung — ohne harten Maximalbetrag. Für kritische IKT-Drittdienstleister, die unter ESA-Direktaufsicht stehen, liegt die Obergrenze bei einem Prozent des durchschnittlichen täglichen weltweiten Umsatzes des Anbieters.

Die Aufsichtsrealität in Deutschland ist im Jahr 2025 noch im Aufbau. Die BaFin hat Prüfhandbücher angepasst und 2025 erste Stichproben durchgeführt. Bußgelder sind selten, formelle Findings sind häufig. Die operativen Konsequenzen aus einem DORA-Finding — vor allem die Pflicht zur Wiedervorlage innerhalb fester Fristen — binden in der Regel mehr Ressourcen als das Bußgeld selbst.

Häufige Fragen

Ist DORA auf interne IT-Servicegesellschaften anwendbar?

Ja. DORA Artikel 3(19) definiert den IKT-Drittdienstleister so weit, dass konzerninterne IT-Servicegesellschaften eingeschlossen sind, sobald sie regulierte Konzerngesellschaften beliefern. Vertragliche und Audit-Anforderungen gelten dann sinngemäß.

Ersetzt DORA das BAIT-Rundschreiben?

Nein. Die BaFin hat ausdrücklich kommuniziert, dass BAIT, VAIT, KAIT und ZAIT in den Bereichen weiter gelten, in denen sie zusätzliche oder präzisere Anforderungen stellen. In der Prüfung gilt die strengere Vorschrift.

Welche Aufbewahrungsfrist gilt für Firewall-Logs?

DORA selbst nennt keine konkrete Frist. Die in der Prüfungspraxis akzeptierte Untergrenze liegt bei 12 Monaten online plus 24 Monaten Archiv für kritische IKT-Systeme. Für KRITIS-regulierte Finanzdienstleister gilt zusätzlich BSIG § 8a.

Müssen alle Firewall-Hersteller in das IKT-Drittparteien-Register?

Ja, sobald sie produktiv im Betrieb sind. Hersteller, deren Hardware nur ohne Wartungsvertrag betrieben wird, sind eine seltene Konstellation; in der Regel besteht ein Supportvertrag, der den Hersteller zum IKT-Drittdienstleister macht. Reseller mit Managed-Service-Komponenten gehören ebenfalls ins Register.

Wie hängt DORA mit NIS2 zusammen?

DORA hat für Finanzdienstleister Vorrang vor NIS2 (Lex specialis). Der materielle Überlapp ist groß: rund 80 Prozent des Nachweispacks ist deckungsgleich. Wer die NIS2-Anforderungen für KMU bereits umsetzt, deckt einen erheblichen Teil von DORA mit derselben Dokumentation ab.

Weiterführend

Offizielle Quellen für die Vertiefung:

• DORA-Verordnung (EU) 2022/2554 — Volltext auf EUR-Lex
• BaFin DORA-Themenseite
• EBA DORA-Regelwerksübersicht

Eine englischsprachige Fassung dieses Beitrags mit dem Schwerpunkt auf EU-weiten Erwartungen findet sich unter DORA Firewall Compliance — What Financial Institutions Must Document.