SASE in regulierten Umgebungen: DORA-Anforderungen an Architektur, Verträge und Nachweise

Das Wichtigste im Überblick

• Die Netzwerkanforderungen stehen im technischen Regulierungsstandard. Die Details regelt Artikel 13 der Delegierten Verordnung (EU) 2024/1774, von der Segmentierung bis zur Sitzungsbeendigung bei Inaktivität (Quelle: Delegierte Verordnung (EU) 2024/1774).
• Der SASE-Anbieter ist ein IKT-Drittdienstleister. DORA gilt für ihn nur mittelbar über den Vertrag; direkt beaufsichtigt werden nur als kritisch eingestufte Anbieter (Quelle: BaFin, FAQ zu DORA).
• Kein reiner SASE-Anbieter wird direkt überwacht. Die erste Liste kritischer IKT-Drittdienstleister vom 18. November 2025 nennt 19 Unternehmen, darunter keinen reinen SASE- oder SSE-Anbieter (Quelle: ESAs, Liste der CTPPs).
• Zertifikate reichen allein nicht. Finanzunternehmen dürfen sich auf Dauer nicht ausschließlich auf Zertifizierungen oder Prüfberichte des Anbieters stützen (Quelle: Delegierte Verordnung (EU) 2024/1773, Art. 8).
• Dritte sind die häufigste Ursache. Rund 50 Prozent der 2025 an die BaFin gemeldeten IKT-Vorfälle gingen auf Probleme oder Fehler bei Drittparteien zurück (Quelle: BaFin, IKT-Vorfälle 2025).

Welche DORA-Anforderungen betreffen eine SASE-Architektur?

DORA selbst formuliert die Grundsätze, etwa zu Schutz und Prävention in Artikel 9 und zum IKT-Drittparteienrisiko in den Artikeln 28 bis 30 (Quelle: EBA, Interactive Single Rulebook zu DORA). Die technischen Einzelheiten stehen in Delegierten Verordnungen. Für ein SASE-Projekt sind die folgenden Fundstellen maßgeblich:

Wie setzt SASE die Netzwerkanforderungen aus Artikel 13 um?

Artikel 13 der Delegierten Verordnung (EU) 2024/1774 verlangt, dass Finanzunternehmen Richtlinien, Verfahren, Protokolle und Werkzeuge für das Netzwerksicherheitsmanagement entwickeln, dokumentieren und umsetzen (Quelle: Delegierte Verordnung (EU) 2024/1774, Art. 13). Die einzelnen Buchstaben lassen sich SASE-Funktionen zuordnen, ersetzen aber nicht die Verantwortung des Instituts für die Konfiguration.

Segmentierung nach Kritikalität (Buchstabe a). ZTNA (Zero Trust Network Access) gewährt Zugriff auf einzelne Anwendungen statt auf Netzsegmente. Die Richtlinien sollten sich an der Klassifizierung nach Artikel 8 Absatz 1 DORA orientieren, auf die der Artikel ausdrücklich verweist. Anwendungen, die kritische oder wichtige Funktionen unterstützen, erhalten eigene Zugriffsregeln mit strengeren Bedingungen an Gerät und Authentifizierung.

Dokumentation aller Verbindungen und Datenflüsse (Buchstabe b). Eine SASE-Plattform führt Richtlinien und Verkehrsdaten an einer Stelle zusammen. Daraus lässt sich die geforderte Dokumentation laufend erzeugen, statt sie aus Firewall-Regelwerken zusammenzusuchen. Verbindungen außerhalb von SASE, etwa Direktanbindungen zu Zahlungsverkehrsnetzen oder Rechenzentrumsdienstleistern, müssen weiterhin gesondert dokumentiert werden.

Separates Administrationsnetz (Buchstabe c). Administrativer Zugriff auf IKT-Assets braucht ein eigenes, dediziertes Netz (Quelle: Delegierte Verordnung (EU) 2024/1774, Art. 13). In der Praxis heißt das: Admin-Zugriffe laufen über eigene ZTNA-Richtlinien in Verbindung mit einer Lösung für privilegierte Zugriffe, getrennt vom Zugriff auf Fachanwendungen. Auch die Administration der SASE-Plattform selbst gehört in diesen Rahmen.

Netzwerkzugangskontrolle (Buchstabe d). Die Verordnung fordert Kontrollen, die Verbindungen nicht autorisierter Geräte oder Endpunkte verhindern und erkennen, die die Sicherheitsanforderungen nicht erfüllen. SASE-Clients prüfen vor dem Verbindungsaufbau den Gerätezustand, etwa Verschlüsselung, Patchstand und laufenden Endpunktschutz.

Verschlüsselung über fremde Netze (Buchstabe e) und Internetverkehr (Buchstabe g). Verbindungen über Unternehmens-, öffentliche, häusliche, Drittanbieter- und Funknetze sind zu verschlüsseln; der Verkehr zwischen internem Netz und Internet ist abzusichern (Quelle: Delegierte Verordnung (EU) 2024/1774, Art. 13). Beides ist Kernfunktion von SASE über verschlüsselte Tunnel und das Secure Web Gateway.

Sitzungsbeendigung (Buchstabe l). Sitzungen sind nach einer festgelegten Inaktivitätsdauer zu begrenzen, zu sperren und zu beenden. Die Werte sollten je Anwendungsklasse festgelegt und in den ZTNA-Richtlinien hinterlegt werden.

Artikel 14 ergänzt den Schutz von Informationen während der Übertragung, einschließlich der Verhinderung und Erkennung von Datenabflüssen (Quelle: Delegierte Verordnung (EU) 2024/1774, Art. 14). Hier leisten DLP-Funktionen im SASE-Dienst einen Beitrag, sofern sie auf die Datenklassifizierung des Hauses abgestimmt sind.

Was gilt für Authentifizierung, Protokollierung und Vorfallmeldung?

Starke Authentifizierung: Artikel 21 der Delegierten Verordnung (EU) 2024/1774 verlangt starke Authentifizierungsmethoden nach anerkannten Verfahren für den Fernzugriff auf das Netz des Finanzunternehmens, für privilegierte Zugriffe, für den Zugriff auf IKT-Assets, die kritische oder wichtige Funktionen unterstützen und für öffentlich zugängliche Assets (Quelle: Delegierte Verordnung (EU) 2024/1774, Art. 21). Ein SASE-Dienst sollte deshalb an den zentralen Identitätsanbieter angebunden sein und phishing-resistente Verfahren unterstützen. Artikel 20 fordert zusätzlich eine eindeutige Identifizierung von Personen und Systemen.

Protokollierung: Artikel 12 verlangt Protokollierungsverfahren, die unter anderem Zugriffskontrolle und Netzwerkaktivitäten erfassen sowie Schutz der Protokolle vor Manipulation, Löschung und unbefugtem Zugriff (Quelle: Delegierte Verordnung (EU) 2024/1774, Art. 12). Für SASE bedeutet das: vollständiger Export der Logs in das eigene SIEM, festgelegte Aufbewahrungsfristen, geklärter Speicherort und eine Zeitsynchronisation, die Ereignisse aus Plattform und eigenen Systemen zusammenführbar macht.

Vorfallmeldung: Die Erstmeldung eines schwerwiegenden IKT-Vorfalls ist spätestens vier Stunden nach der Einstufung und höchstens 24 Stunden nach Kenntnis fällig, der Zwischenbericht spätestens 72 Stunden nach der Erstmeldung, der Abschlussbericht spätestens einen Monat danach. Kreditinstitute dürfen Erstmeldung und Zwischenbericht nicht auf den nächsten Werktag verschieben (Quelle: Delegierte Verordnung (EU) 2025/301, Art. 5). Fällt der SASE-Dienst aus oder wird er kompromittiert, braucht das Institut die Informationen des Anbieters innerhalb dieser Fristen. Das gehört in den Vertrag.

Unterstützt der SASE-Dienst eine kritisch wichtige Funktion?

Diese Einstufung bestimmt, welche zusätzlichen Pflichten gelten. Sie hängt davon ab, wofür der Dienst genutzt wird. Ein SASE-Dienst, über den Beschäftigte und Dienstleister auf Kernbankensysteme, Zahlungsverkehr oder Handelsanwendungen zugreifen, unterstützt in aller Regel eine kritische oder wichtige Funktion: Fällt er aus, ist der Zugriff auf diese Funktionen gestört. Ein reiner Webfilter für Internetverkehr kann anders zu bewerten sein.

Mit der Einstufung als kritisch wichtig greifen die erweiterten Vertragsbestimmungen nach Artikel 30 Absatz 3 DORA (Quelle: EBA, Interactive Single Rulebook, DORA Art. 30) und die Anforderungen der Delegierten Verordnung (EU) 2024/1773 an Prüfung, Überwachung und Exit (Quelle: Delegierte Verordnung (EU) 2024/1773). Vor Vertragsschluss ist nach Artikel 29 DORA außerdem eine vorläufige Bewertung des IKT-Konzentrationsrisikos vorzunehmen (Quelle: EBA, Interactive Single Rulebook, DORA Art. 29). Bei SASE ist das kein theoretischer Punkt: Die EZB stellte fest, dass Banken unter ihrer Aufsicht die Hälfte ihres IKT-Budgets für Drittanbieter bei nur 30 Anbietern ausgeben (Quelle: EZB, Supervision Newsletter vom 19.02.2025).

Unabhängig von der Einstufung gehört der Vertrag in das Informationsregister. Die BaFin erwartet die Einreichung jährlich bis zum 31. März mit Stand 31. Dezember des Vorjahres über die Melde- und Veröffentlichungsplattform (Quelle: BaFin, Fachartikel vom 15.01.2025).

Was muss im Vertrag mit dem SASE-Anbieter stehen?

Artikel 30 DORA legt die wesentlichen Vertragsbestimmungen fest (Quelle: EBA, Interactive Single Rulebook, DORA Art. 30). Eine ergänzende Übersicht der verpflichtenden Mindestvertragsinhalte stellt die BaFin in ihren Umsetzungshinweisen zur DORA-Implementierung bereit. Dabei wird zwischen allgemeinen Vertragsanforderungen und zusätzlichen Anforderungen für IKT-Dienstleistungen zur Unterstützung kritischer oder wichtiger Funktionen unterschieden. Für einen SASE-Vertrag sind insbesondere die folgenden Punkte relevant:

Zur Unterauftragsvergabe konkretisiert die Delegierte Verordnung (EU) 2025/532, welche Bedingungen bei wesentlichen Änderungen gelten und wann ein Kündigungsrecht besteht (Quelle: Delegierte Verordnung (EU) 2025/532).

Zertifizierungen wie BSI C5 oder ISO 27001 sowie externe Prüfberichte können die Überprüfung von SASE-Dienstleistern erleichtern. Artikel 8 der Delegierten Verordnung (EU) 2024/1773 erlaubt ihre Nutzung als Prüfmethoden. Die letztendliche Verantwortung für die Bewertung und Überwachung des IKT-Drittdienstleisters verbleibt jedoch beim Finanzunternehmen. Dieses darf sich langfristig nicht ausschließlich auf Zertifizierungen oder externe Prüfberichte stützen. (Quelle: Delegierte Verordnung (EU) 2024/1773, Art. 8). Die BaFin bestätigt, dass externe Prüfberichte in der Regel genutzt werden können und hält es für sinnvoll, gegebenenfalls eine Erweiterung des Prüfungsumfangs zu verlangen (Quelle: BaFin, FAQ zu DORA).

Wie sehen Exit-Plan und Ausfallvorsorge aus?

Bei der Nutzung von SASE-Diensten müssen Finanzinstitute sowohl kurzfristige Störungen als auch einen möglichen Anbieterwechsel berücksichtigen. Dabei sind technische Resilienz, Notfallmanagement und Exit-Management voneinander zu unterscheiden. Für IKT-Dienstleistungen, die kritische oder wichtige Funktionen unterstützen, gelten zudem spezifische Anforderungen an dokumentierte und regelmäßig zu überprüfende Exit-Pläne. (Quelle: Delegierte Verordnung (EU) 2024/1773, Art. 10).

1. Notfallmanagement bei kurzfristigen Ausfällen. Für den Ausfall eines SASE-Dienstes sollten alternative Zugriffsmöglichkeiten vorgesehen werden, etwa ein eng begrenzter und besonders abgesicherter Fernzugang für Administratoren und kritische Rollen. Wie relevant solche Szenarien sind, zeigen die Ausfälle bei Cloudflare am 12. Juni und 18. November 2025, bei denen unter anderem Dienste für die Zugriffskontrolle beeinträchtigt waren (Quellen: Cloudflare, Postmortem vom 12.06.2025; Cloudflare, Postmortem vom 18.11.2025).
2. Technische Resilienz bei Störungen. Für unterschiedliche Anwendungen und Verkehrsarten ist festzulegen, wie sich die Sicherheitsarchitektur bei Nichterreichbarkeit des SASE-Dienstes verhält. Dabei ist insbesondere zwischen Fail-open und Fail-closed abzuwägen. Für sicherheitskritische Zugriffe ist ein Fail-closed-Verhalten grundsätzlich vorzuziehen, während für weniger kritische Verbindungen risikobasierte Ausnahmen möglich sein können.
3. 3. Exit-Management bei einem Anbieterwechsel. Ein belastbarer Exit-Plan berücksichtigt die Übertragbarkeit von Richtlinien und Konfigurationen, eine dokumentierte Übergangsarchitektur, vertragliche Mitwirkungspflichten sowie realistische Migrationsfristen. Für IKT-Dienstleistungen, die kritische oder wichtige Funktionen unterstützen, sind die einschlägigen regulatorischen Anforderungen an Exit-Strategien und Exit-Pläne zu beachten. Die praktische Umsetzbarkeit sollte durch geeignete Tests überprüft werden.

Die Bedeutung einer angemessenen Drittparteiensteuerung unterstreichen auch die europäischen Meldedaten: Laut dem Bericht der Europäischen Aufsichtsbehörden über schwerwiegende IKT-bezogene Vorfälle im Jahr 2025 war bei nahezu einem Drittel der 3.383 gemeldeten Vorfälle ein Fehler bei einem Drittanbieter ursächlich (Quelle: ESAs, Report on major ICT-related incidents 2025, JC 2026 16).

Welche Rolle spielen BaFin-Vorgaben neben DORA?

Für Institute, die DORA anwenden, gelten die BAIT nicht mehr; die BaFin hebt sie mit Ablauf des 31. Dezember 2026 vollständig auf. VAIT, KAIT und ZAIT sind bereits seit dem 16. Januar 2025 aufgehoben (Quelle: BaFin, Meldung „DORA kommt“). Die sektoralen Auslagerungsregeln, bei Banken MaRisk AT 9, sind laut BaFin grundsätzlich weiterhin parallel zu beachten (Quelle: BaFin, FAQ zu DORA).

Für Cloud-Dienste bleibt die Aufsichtsmitteilung der BaFin zu Auslagerungen an Cloud-Anbieter vom 1. Februar 2024 eine Orientierung; sie enthält Hinweise zum Übergang auf DORA (Quelle: BaFin, Meldung vom 01.02.2024). Die 9. MaRisk-Novelle wurde am 30. Juni 2026 als Rundschreiben 06/2026 veröffentlicht (Quelle: BaFin, Rundschreiben 06/2026); ihre Auswirkungen auf AT 9 sollten im Einzelfall geprüft werden.

Welche Nachweise erwarten Aufsicht und Revision?

Für eine Prüfung sollte das Institut die folgenden Unterlagen vorhalten können:

• Netzwerkdokumentation mit allen Verbindungen und Datenflüssen, einschließlich der Verbindungen über den SASE-Dienst
• Richtlinien für Netzwerksicherheit, Zugriff, Authentifizierung und Protokollierung mit Bezug auf die Artikel 12, 13, 14, 20 und 21 der Delegierten Verordnung (EU) 2024/1774
• Risikoanalyse und Einstufung des SASE-Dienstes sowie die Bewertung des Konzentrationsrisikos
• Vertrag mit einer Zuordnung zu den Anforderungen aus Artikel 30 DORA und Nachweise zu Unterauftragnehmern
• Eintrag im Informationsregister
• Prüfberichte und Zertifikate des Anbieters sowie eigene Prüfhandlungen
• Exit-Plan mit Testprotokoll und dokumentiertem Notfallzugang
• Nachweis der Log-Integration in SIEM und Vorfallprozess

Rund 40 Prozent der 2025 an die BaFin gemeldeten Angriffe richteten sich gegen einen Dienstleister des betroffenen Finanzunternehmens (Quelle: BaFin, Fachartikel vom 16.07.2026). Diese Entwicklung unterstreicht die Bedeutung einer wirksamen Steuerung und Überwachung von IKT-Drittdienstleistern sowie der entsprechenden Nachweisführung gegenüber Aufsicht und Revision.

Fazit: DORA-Konformität entsteht in der Planung

SASE passt gut zu den Netzwerkanforderungen von DORA, weil Segmentierung, Zugangskontrolle, Verschlüsselung und Protokollierung zentral steuerbar und dokumentierbar werden. Gleichzeitig wird der Anbieter zu einem Dienstleister, dessen Ausfall den Zugriff auf kritisch wichitge Funktionen stören kann. Institute, die Architektur, Vertrag, Register, Exit-Plan und Log-Integration in einem Projekt zusammen planen, schaffen die Grundlage für eine prüffeste Umsetzung. Werden diese Punkte erst nach dem Rollout ergänzt, entstehen Lücken, die in der nächsten Prüfung sichtbar werden.