Wie deutsche Banken mit Datensouveränität DORA-Compliance erreichen

Deutsche Banken stehen vor einer doppelten regulatorischen Herausforderung. Der Digital Operational Resilience Act (DORA), der seit Januar 2025 vollständig in Kraft ist, verlangt ein umfassendes ICT-Sicherheitsrisikomanagement, Meldepflichten für Sicherheitsvorfälle und eine Überwachung von Drittparteien im gesamten Finanzsektor. Gleichzeitig fordern nationale Vorgaben zur Datensouveränität und strikte Auslegungen der DSGVO, dass sensible Finanzdaten ausschließlich in deutscher oder EU-kontrollierter Infrastruktur verbleiben. Um beiden Anforderungen gerecht zu werden, sind eine präzise Architektur und disziplinierte Abläufe erforderlich.

Dieser Artikel erläutert, wie deutsche Banken DORA-Compliance mit Datensouveränität erreichen: durch den Aufbau sicherer, revisionssicherer Workflows für sensible Daten, die Implementierung von zero trust-Sicherheitskontrollen für Drittparteien-Kommunikationskanäle und die Pflege unveränderlicher Audit-Trails, die beide regulatorischen Rahmenwerke erfüllen.

Executive Summary

Deutsche Finanzinstitute müssen die Anforderungen an die operative Resilienz aus DORA erfüllen und gleichzeitig die strengen deutschen Vorgaben zur Datensouveränität einhalten. Dieses doppelte Mandat beeinflusst, wie Banken Kundendaten mit Drittanbietern teilen, Vorfallmanagement-Workflows steuern und ihre Audit-Bereitschaft nachweisen. Erfolgreiche Banken integrieren Datensouveränität als Kontrollschicht in ihre DORA-Implementierung. Sie sichern Kommunikationskanäle für sensible Daten mit zero trust-Architektur und Zugriffssteuerungen, pflegen granulare Audit-Logs, die beiden regulatorischen Rahmenwerken entsprechen, und automatisieren die Sammlung von Compliance-Nachweisen. Das Ergebnis ist eine einheitliche Sicherheitslage, die regulatorische Risiken reduziert, Audit-Zyklen beschleunigt und Kundendaten an jedem Drittparteien-Touchpoint schützt.

wichtige Erkenntnisse

• Takeaway 1: Deutsche Banken müssen DORAs ICT-Risikomanagement-Rahmen mit nationalen Anforderungen an die Datensouveränität in Einklang bringen, indem sie sicherstellen, dass sensible Daten bei Drittparteien-Austausch niemals deutsche oder EU-kontrollierte Infrastruktur verlassen. Dies erfordert speziell entwickelte Kommunikationskanäle mit durchsetzbaren geografischen Kontrollen.

• Takeaway 2: Zero-trust-Architektur ist unter DORA unerlässlich. Banken müssen datenbewusste Zugriffskontrollen implementieren, die Identität, Gerätezustand und Datenklassifizierung prüfen, bevor Dateiaustausch mit externen Anbietern, Prüfern oder Aufsichtsbehörden erfolgt.

• Takeaway 3: Unveränderliche Audit-Trails sind die Grundlage der DORA-Compliance. Jeder Dateitransfer, jeder Zugriffsversuch und jede Richtlinienentscheidung muss fälschungssichere Protokolle erzeugen, die sowohl die Meldepflichten aus DORA als auch die Nachweispflichten der DSGVO erfüllen.

• Takeaway 4: Das Drittparteien-Risikomanagement unter DORA geht über vertragliche Vereinbarungen hinaus. Banken müssen technische Kontrollen durchsetzen, die den Zugriff Dritter auf Daten, deren Speicherort und die Dauer der Speicherung in geteilten Umgebungen begrenzen.

• Takeaway 5: Compliance-Automatisierung verkürzt Audit-Zyklen und erhöht die regulatorische Belastbarkeit. Banken, die Kontrollnachweise in Echtzeit DORA-Artikeln, BaFin-Rundschreiben und DSGVO-Vorgaben zuordnen, zeigen operative Reife und entlasten ihre Compliance-Teams.

Schnittstelle zwischen DORA und deutscher Datensouveränität verstehen

DORA schafft einen einheitlichen Standard für Compliance und operative Resilienz im EU-Finanzsektor. Banken müssen ICT-Assets identifizieren und klassifizieren, robuste Prozesse für das Vorfallmanagement etablieren, digitale Resilienz durch Threat-Led Penetration Testing prüfen und Drittanbieter von ICT-Dienstleistungen mit erhöhter Sorgfalt steuern. Diese Anforderungen verlangen messbare Kontrollen, dokumentierte Workflows und Nachweisprotokolle, die von Prüfern validiert werden können.

Deutsche Banken unterliegen einer zusätzlichen Aufsichtsebene. BaFin und Bundesbank betonen starke Datenschutzkontrollen und operative Resilienz. Während die DSGVO Datenflüsse innerhalb der EU erlaubt, setzen deutsche Finanzinstitute häufig auf Datenlokalisierung, um mehr Kontrolle über sensible Kundendaten zu behalten und den gestiegenen Erwartungen an Datensouveränität gerecht zu werden. Diese Praxis spiegelt sowohl regulatorische Vorgaben als auch Marktanforderungen an verbesserten Datenschutz wider.

Die Schnittstelle dieser Rahmenwerke zwingt deutsche Banken zu einer entscheidenden Frage: Wie bleibt die operative Resilienz in verteilten ICT-Umgebungen erhalten, während Kundendaten, Transaktionsaufzeichnungen und Vorfallprotokolle innerhalb souveräner Grenzen verbleiben? Die Antwort liegt im Aufbau sicherer Datenkommunikationskanäle mit eingebetteten geografischen Kontrollen, zero trust-Zugriffsrichtlinien und Compliance-Mappings, die beide regulatorischen Regime erfüllen.

Warum herkömmliches Filesharing weder DORA noch Souveränitätsanforderungen erfüllt

Viele Banken nutzen weiterhin E-Mail-Anhänge, Consumer-Filesharing-Plattformen oder FTP-Server, um sensible Dokumente mit externen Prüfern, Aufsichtsbehörden und Drittanbietern auszutauschen. Diese Kanäle schaffen sofortige Compliance-Lücken. E-Mails bieten keine native Verschlüsselung im ruhenden Zustand, erzwingen keine geografischen Speicherorte und erzeugen fragmentierte Audit-Logs. Consumer-Filesharing-Tools speichern Daten in Multi-Tenant-Clouds, in denen Banken weder Datenresidenz noch unautorisierte Replikation kontrollieren können.

DORA Artikel 28 verlangt von Finanzinstituten, umfassende ICT-bezogene Vorfallregister zu führen, die Ursache, Auswirkungen und Behebung jeder wesentlichen Störung dokumentieren. Werden Vorfallberichte oder forensische Beweise per E-Mail oder unkontrolliertem Dateitransfer geteilt, kann die Bank keine Chain of Custody nachweisen, keine Zugriffskontrolle belegen und nicht bestätigen, dass sensible Daten in autorisierten Jurisdiktionen verblieben. Das schafft Audit-Risiken und setzt das Institut sowohl DORA-Strafen als auch potenziellen DSGVO-Verstößen aus.

Das Drittparteien-Risikomanagement verschärft das Problem. DORA Artikel 30 schreibt vor, dass Banken ein Register aller ICT-Drittanbieter führen und deren operative Resilienz bewerten. Vertragsklauseln sind jedoch keine technischen Kontrollen. Greift ein Anbieter über ein unsicheres Portal auf Kundendaten zu oder lädt sensible Dateien auf nicht konforme Infrastruktur herunter, trägt die Bank die regulatorische Verantwortung – unabhängig von den Servicevereinbarungen.

Fragmentierte Compliance-Tools erhöhen die operative Komplexität. Banken, die separate Plattformen für Vorfallmeldungen, Drittparteien-Dateiaustausch und Audit-Trail-Sammlung einsetzen, vergrößern ihre Angriffsfläche und erschweren die Nachweiserbringung. Fordern Prüfer einen Nachweis, dass ein bestimmter Dateiaustausch sowohl DORA- als auch Souveränitätsanforderungen entsprach, müssen Compliance-Teams Logs aus verschiedenen Systemen abgleichen und manuell prüfen, ob geografische Kontrollen eingehalten wurden. Ein einheitlicher Ansatz beseitigt diese Ineffizienzen.

Zero-Trust-Architektur für den Austausch sensibler Daten aufbauen

Zero trust ist eine zentrale Anforderung im DORA-ICT-Risikomanagement. Banken müssen jeden Anwender, jedes Gerät und jede Anwendung verifizieren, bevor sie Zugriff auf kritische Systeme oder sensible Daten gewähren. Dies gilt für alle externen Kommunikationskanäle, über die Kundeninformationen, Vorfallberichte oder regulatorische Meldungen laufen.

Eine zero trust-Architektur für den Austausch sensibler Daten beginnt mit Identitätsprüfung. Jeder externe Nutzer muss sich mit Multi-Faktor-Authentifizierung authentifizieren, die Identität und Gerätezustand bestätigt. Das System erzwingt bedingte Zugriffspolitiken, die Faktoren wie geografischen Standort, IP-Reputation und Gerätekonformität prüfen, bevor Datei-Uploads oder -Downloads erlaubt werden.

Datenbewusste Zugriffskontrollen erweitern dieses Modell, indem sie Dateimetadaten, Klassifizierungslabels und eingebettete personenbezogene Daten prüfen, bevor Zugriff gewährt wird. Versucht ein Anbieter, eine Datei mit Kundenkontonummern herunterzuladen, kann das System den Transfer blockieren, einen Alarm auslösen und das Ereignis protokollieren. So wird Datenabfluss verhindert und sichergestellt, dass nur autorisierte Nutzer auf Daten zugreifen, die ihrer Rolle und dem Vertrag entsprechen.

Datensouveränität erfordert technische Durchsetzung. Deutsche Banken müssen Infrastruktur einsetzen, die physisch steuert, wo sensible Daten gespeichert, verarbeitet und übertragen werden. Das bedeutet, Plattformen auszuwählen, die dedizierte Rechenzentren in Deutschland oder der EU betreiben, konfigurierbare Residenzrichtlinien bieten und Audit-Logs erzeugen, die Compliance auf Datei- und Transaktionsebene belegen. Geografische Kontrollen müssen für Daten im ruhenden Zustand und während der Übertragung gelten. Teilt eine Bank einen Vorfallbericht mit der BaFin oder tauscht Kundendateien mit einem externen Prüfer aus, muss die Plattform diese Daten über deutsche oder EU-basierte Server routen, ohne Transit durch Drittländer. Der Datenpfad muss nachweisbar sein, und die Bank muss belegen können, dass keine unautorisierte Replikation oder grenzüberschreitende Übertragung stattgefunden hat.

Unveränderliche Audit-Trails für beide regulatorischen Rahmenwerke schaffen

DORA Artikel 17 verlangt von Banken, Logs zu führen, die eine zeitnahe Erkennung, Untersuchung und Wiederherstellung nach ICT-Vorfällen ermöglichen. DSGVO Artikel 30 fordert Verzeichnisse der Verarbeitungstätigkeiten, die dokumentieren, welche personenbezogenen Daten zu welchem Zweck und auf welcher Rechtsgrundlage verarbeitet werden. Deutsche Banken müssen Audit-Trails erzeugen, die beide Anforderungen erfüllen, ohne redundante Logging-Infrastruktur zu schaffen.

Ein effektives Audit-Log erfasst jede Aktion im Zusammenhang mit sensiblen Daten. Dazu gehören Datei-Uploads, Zugriffsanfragen, Richtlinienentscheidungen, Downloads und administrative Änderungen. Jeder Log-Eintrag muss Zeitstempel, Nutzeridentität, Dateimetadaten und das Ergebnis der Aktion enthalten. Die Logs müssen unveränderlich und in einem Format gespeichert sein, das automatisierte Abfragen und Korrelationen mit externen Systemen unterstützt.

Audit-Trails werden zu Compliance-Nachweisen, wenn sie direkt auf regulatorische Anforderungen abgebildet sind. Eine gut konzipierte Plattform versieht jeden Log-Eintrag mit relevanten DORA-Artikeln, DSGVO-Vorgaben und BaFin-Rundschreiben. So können Compliance-Teams Berichte generieren, die alle Dateiaustausche mit personenbezogenen Informationen über einen definierten Zeitraum zeigen – gefiltert nach Drittanbieter und geografischem Standort. Diese Granularität beschleunigt Audit-Zyklen und belegt regulatorische Reife.

Audit-Logs sind am wertvollsten, wenn sie in zentrale Security-Operations-Workflows einfließen. Deutsche Banken betreiben bereits SIEM-Plattformen, die Logs aus Firewalls, Endpoint Detection und Identity Providern aggregieren. Werden Logs sensibler Daten diesem Data Lake hinzugefügt, können Sicherheitsteams Anomalien erkennen, Vorfälle korrelieren und automatisierte Reaktionsworkflows auslösen. Die Integration mit SOAR-Plattformen erweitert diese Fähigkeit durch automatisierte Incident Response. Erkennt das System einen verdächtigen Dateidownload, kann die SOAR-Plattform automatisch den Zugriff entziehen, die Datei isolieren, das Security Operations Center benachrichtigen und ein Ticket im ITSM-System der Bank erstellen. Das verkürzt die Zeit bis zur Erkennung und Behebung.

Drittparteien-ICT-Risiko mit durchsetzbaren Datenkontrollen steuern

DORAs Rahmenwerk für Drittparteien-Risiko ist präskriptiv und umfassend. Banken müssen vor der Beauftragung von ICT-Dienstleistern Sorgfaltsprüfungen durchführen, klare vertragliche Verpflichtungen definieren, die laufende Performance überwachen und Ausstiegsstrategien vorhalten. Doch Sorgfaltsprüfung und Verträge sind keine technischen Kontrollen.

Durchsetzbare Datenkontrollen setzen Richtlinien in die Praxis um. Beim Onboarding eines neuen Drittanbieters erstellt die Bank einen sicheren Arbeitsbereich mit vordefinierten Zugriffsrechten, geografischen Einschränkungen und Aufbewahrungsrichtlinien. Der Anbieter kann nur auf explizit freigegebene Dateien zugreifen, und die Bank kann diesen Zugriff jederzeit entziehen. Die Plattform erzwingt diese Kontrollen auf Dateiebene – selbst wenn die Zugangsdaten des Anbieters kompromittiert werden, kann ein Angreifer keine Daten außerhalb des autorisierten Umfangs einsehen.

Zeitlich begrenzter Zugriff ist eine weitere wichtige Kontrolle. Viele Anbieterbeziehungen sind projektbasiert. Die Bank kann Zugriffsrichtlinien so konfigurieren, dass sie nach einem definierten Zeitraum oder Projektabschluss automatisch ablaufen. Das verhindert, dass veraltete Zugangsdaten zu dauerhaften Angriffsvektoren werden, und stellt sicher, dass Drittparteien-Zugriffe den aktuellen geschäftlichen Anforderungen entsprechen.

DORA Artikel 30 verlangt von Banken, klare Kündigungsrechte zu etablieren und sicherzustellen, dass Daten bei Beendigung einer Drittparteienbeziehung zurückgegeben oder sicher gelöscht werden. Automatisierte Workflows sorgen dafür, dass beim Ende einer Anbieterbeziehung alle Zugriffe sofort entzogen, alle geteilten Dateien gemäß Aufbewahrungsrichtlinie archiviert oder gelöscht und ein Abschlussbericht für die Compliance erstellt wird. Die Plattform muss zudem Aufbewahrungspflichten umsetzen, die sowohl DORA als auch DSGVO erfüllen – mit Richtlinien je nach Dateiklassifizierung, Zweck und regulatorischer Vorgabe.

Compliance operationalisieren mit dem Private Data Network

Das Verständnis von DORA- und Datensouveränitätsanforderungen ist der erste Schritt. Die Abbildung dieser Anforderungen auf Richtlinien und Kontrollen ist der zweite. Aber Compliance ist nur wirksam, wenn Kontrollen aktiv über alle Kommunikationskanäle, Drittparteien-Touchpoints und Vorfallmanagement-Workflows hinweg durchgesetzt werden. Hier bietet das Private Data Network von Kiteworks messbaren Mehrwert.

Kiteworks hilft, sensible Daten Ende-zu-Ende zu sichern – von der Erstellung und dem Austausch über die Zusammenarbeit bis zur Archivierung. Es erzwingt zero trust-Zugriffskontrollen basierend auf Nutzeridentität, Gerätezustand und Datenklassifizierung. Es pflegt unveränderliche Audit-Trails, die direkt auf DORA-Artikel, DSGVO-Vorgaben und BaFin-Rundschreiben abgebildet sind. Und es integriert sich in bestehende SIEM-, SOAR- und ITSM-Plattformen, um Incident Detection, Reaktion und Compliance-Reporting zu automatisieren.

Das Private Data Network fungiert als einheitliche Kontrollschicht für alle sensiblen Datenbewegungen. Ob die Bank Vorfallberichte mit Aufsichtsbehörden teilt, Kundendateien mit externen Prüfern austauscht oder mit Drittanbietern an Resilienztests arbeitet – Kiteworks sorgt dafür, dass Daten in deutscher oder EU-kontrollierter Infrastruktur verbleiben, Zugriffe kontinuierlich geprüft werden und jede Aktion einen Compliance-Nachweis erzeugt.

Kiteworks unterstützt regionale Datenresidenz für deutsche Banken durch flexible, sichere Bereitstellungsoptionen – darunter On-Premises-Infrastruktur, Private Cloud in deutschen oder EU-Rechenzentren und hybride Konfigurationen. Die Plattform bietet konfigurierbare geografische Kontrollen, die sicherstellen, dass sensible Daten in deutschen oder EU-Jurisdiktionen verbleiben. Jeder Dateitransfer erzeugt ein Audit-Log mit Quell- und Ziel-IP, geografischem Routing und Bestätigung, dass keine unautorisierte grenzüberschreitende Übertragung stattfand. Das Private Data Network unterstützt auch On-Premises-Bereitstellung für Institute, die physische Kontrolle über ihre Infrastruktur benötigen – so verlassen sensible Daten nie das eigene Rechenzentrum der Bank.

Kiteworks setzt zero trust-Prinzipien durch datenbewusste Zugriffspolitiken um, die Identität, Gerätekonformität und Datenklassifizierung prüfen, bevor Dateioperationen erlaubt werden. Die Plattform integriert sich in den Identity Provider der Bank, um Multi-Faktor-Authentifizierung, bedingte Zugriffspolitiken und Session-Timeouts zu erzwingen. Sie prüft Dateimetadaten und eingebettete Daten, um personenbezogene Informationen zu erkennen, und wendet Zugriffsbeschränkungen basierend auf Klassifizierungslabels und Nutzerrollen an. Die Plattform erzwingt zudem Gerätezustandsprüfungen, sodass externe Nutzer Daten nur von verwalteten, konformen Geräten aus aufrufen können.

Kiteworks erzeugt unveränderliche Audit-Logs für jede Dateioperation, Zugriffsanfrage und Richtlinienentscheidung. Jeder Log-Eintrag ist mit relevanten regulatorischen Vorgaben getaggt, sodass Compliance-Teams Berichte erstellen können, die die Einhaltung bestimmter DORA-Artikel oder DSGVO-Klauseln belegen. Die Plattform unterstützt automatisierte Reporting-Workflows, die geplante Compliance-Zusammenfassungen an interne Stakeholder oder externe Prüfer liefern – das reduziert manuellen Aufwand und verbessert die Audit-Bereitschaft. Die Audit-Logs integrieren sich über Standard-APIs mit SIEM-Plattformen, sodass Sicherheitsteams Datenzugriffe mit Netzwerkaktivitäten, Identitätsanomalien und Threat-Intelligence-Feeds korrelieren können.

Wichtiger Compliance-Hinweis

Während Kiteworks technische Funktionen zur Unterstützung der DORA-Compliance und der Anforderungen an Datensouveränität für Daten in Bewegung bietet, sollten Unternehmen rechtliche und Compliance-Berater hinzuziehen, um sicherzustellen, dass ihr gesamtes ICT-Risikomanagement allen regulatorischen Anforderungen entspricht. DORA-Compliance erfordert einen ganzheitlichen Ansatz über Governance, Technologie, Prozesse und Drittparteienmanagement hinweg. Die Informationen in diesem Artikel dienen allgemeinen Informationszwecken und stellen keine Rechts- oder Compliance-Beratung dar.

Fazit

Deutsche Banken, die einen einheitlichen Ansatz für DORA-Compliance und Datensouveränität umsetzen, erzielen messbare Ergebnisse. Sie reduzieren die Angriffsfläche, indem sie unsichere Filesharing-Kanäle eliminieren, verkürzen Reaktionszeiten durch automatisierte Richtlinienumsetzung und beschleunigen Audit-Zyklen, indem sie Compliance-Nachweise zentral und abfragebereit vorhalten. Sie stärken zudem das Drittparteien-Risikomanagement, indem sie technische Kontrollen durchsetzen, die mit vertraglichen und regulatorischen Anforderungen übereinstimmen.

Das regulatorische Umfeld wird sich weiterentwickeln. DORAs Anforderungen an Resilienztests, erweiterte Meldepflichten und verstärkte Drittparteien-Überwachung werden die operative Belastung für Finanzinstitute erhöhen. Banken, die flexible, einheitliche Architekturen für den Schutz sensibler Daten schaffen, passen sich schneller an und bleiben regulatorisch belastbar, ohne ihre Sicherheitslage zu fragmentieren.

Kiteworks ermöglicht diesen Ansatz durch ein Private Data Network, das jeden Kommunikationskanal für sensible Daten absichert, zero trust-Zugriffskontrollen durchsetzt, unveränderliche Audit-Trails erstellt, die sowohl DORA- als auch Souveränitätsanforderungen abbilden, und sich nahtlos in bestehende Security-Operations-Workflows integriert. Das Ergebnis ist eine Compliance-bereite Architektur, die Kundendaten schützt, Audit-Zyklen beschleunigt und die operative Komplexität beim Management überlappender regulatorischer Vorgaben reduziert.

Erfahren Sie, wie Kiteworks deutschen Banken hilft, DORA-Compliance zu erreichen und gleichzeitig Datensouveränität zu wahren

Entdecken Sie, wie das Private Data Network sensible Daten schützt, zero trust-Zugriffskontrollen durchsetzt und die Sammlung von Compliance-Nachweisen über alle Drittparteien-Touchpoints hinweg automatisiert.
Fordern Sie jetzt eine individuelle Demo an.