Warum Testen mit Echtdaten für Finanzinstitute heute keine Option mehr ist

Stellen Sie sich vor, Sie verwahren Ihre Wertsachen im Gartenhaus, während Haus und Wohnung bestens gesichert sind. Genau so arbeiten viele Finanzinstitute heute noch mit Testdaten: Die produktiven Systeme sind stark geschützt, doch in den weniger abgesicherten Testumgebungen liegen oft echte Kundendaten. Trotz hoher Sicherheitsinvestitionen entsteht ausgerechnet dort das größte Risiko, wo es am wenigsten erwartet wird.

Ein Datenleck kostet deutsche Unternehmen laut IBM durchschnittlich 3,87 Mio. Euro. Unternehmen investieren daher viel, um produktive Umgebungen ausreichend zu schützen. Diese Investition lohnt sich jedoch nicht, wenn produktive Daten zum Testen auf weniger gut gesicherte Entwicklungs- und Testumgebungen kopiert werden. Abseits des Informationssicherheitsrisikos machen sich Finanzinstitute gegenüber Behörden verletzlich. Eine fehlende Anonymisierung ist ein Compliance-Risiko, denn das Speichern und Verarbeiten von Echtdaten auf nichtproduktiven Umgebungen ist für Finanzinstitute explizit verboten.

DORA schreibt klar vor: In nichtproduktiven Umgebungen dürfen nur anonymisierte, pseudonymisierte oder randomisierte Produktionsdaten gespeichert und verarbeitet werden. Die Nutzung echter Kundendaten wird nur in eng definierten Ausnahmen, für begrenzte Zeiträume und nach interner Genehmigung erlaubt.

Dies spiegelt die Logik der DSGVO wider, die gemäß EuGH-Urteil (C-77/21) die parallele Speicherung von Echtdaten in Test-Datenbanken als Weiterverarbeitung ansieht. Eine solche Weiterverarbeitung ist im Sinne der Kompatibilitätsprüfung nur zulässig, wenn eine „konkrete, kohärente und ausreichend enge Verbindung“ zum Erhebungszweck besteht, beispielsweise bei der Fehlerbehebung.

Der EuGH macht klar: Echtdaten dürfen nur genutzt werden, wenn die Erforderlichkeit nachgewiesen ist und strenge Regeln eingehalten werden.

Laut Erhebung von Perforce Software, eines bekannten Toolherstellers zur Datenanonymisierung, hat mehr als die Hälfte befragter Unternehmen schon Angriffe auf nichtproduktive Umgebungen erlebt. Das liegt daran, dass nichtproduktive Umgebungen oft weniger gut abgesichert sind. Obendrauf haben Entwickler:innen und Tester:innen häufig ausgiebige Berechtigungen auf Entwicklungs- und Testumgebungen. Dadurch entsteht ein Risiko des Datenmissbrauchs.

Abgesehen davon, dass es für Finanzdienstleister regulatorisch nicht zugelassen ist, Echtdaten auf nichtproduktiven Umgebungen zu speichern und zu verarbeiten, verbietet die DSGVO das pauschale Testen und Entwickeln mit Kundendaten. Wenn hier zusätzlich noch veraltete Stände der produktiven Daten abliegen, entsteht das Risiko, dass Daten ehemaliger Kunden rechtswidrig gespeichert und weiterverarbeitet werden. Eine Auskunft nach Art. 15 Abs. 1 DSGVO zu geben, ist in diesem Szenario nahezu unmöglich.

Der Unterschied zwischen den Techniken ist fundamental und betrifft die Re-Identifizierbarkeit und damit die Anwendbarkeit der DSGVO:

Während die Theorie eine simple Differenzierung von Pseudonymisierung und Anonymisierung bietet, verschwimmt diese Grenze in der Praxis.

Von einem schlecht anonymisierten Datensatz können durch Re-Identifizierungsangriffe die ursprünglichen Daten rekonstruiert werden. Methoden wie K-Anonymität schützen vor direkter Identifikation, indem jede Kombination identifizierender Merkmale mindestens k-mal im Datensatz vorkommt. Verknüpfungs- und Inferenzangriffe können dadurch jedoch nicht verhindert werden. Methoden wie l-Diversität und T-Geschlossenheit adressieren diese Schwäche, indem sie eine ausreichende Vielfalt bzw. eine an die Gesamtdaten angenäherte Verteilung sensibler Attribute innerhalb von Gruppen sicherstellen, bleiben jedoch weiterhin anfällig für Verknüpfungsangriffe.

Einfaches Pseudonymisieren bleibt im Kontext von DORA unklar. Die DSGVO stuft pseudonymisierte Daten weiterhin als personenbezogene Daten ein, denn Tester:innen könnten mit wenig Aufwand solche Datensätze de-pseudonymisieren.

In der Praxis gibt es keine klare Antwort: Die Wahl der passenden Datenschutztechnik hängt vom jeweiligen Kontext ab.

Datenschutztechniken (wie Anonymisierung, Pseudonymisierung und Datenmaskierung) für Test- und Entwicklungsumgebungen zu implementieren, entpuppt sich schnell als Herausforderung. Die größte technische Hürde stellt die häufig komplexe, stark vernetzte IT-Landschaft innerhalb eines Finanzinstituts dar. Ein Umsetzungsprojekt für Datenschutztechniken umfasst schnell über hundert Anwendungen, die über diverse Fachbereiche und Prozesse verteilt sind. Das erschwert Pilotumsetzungen.

Organisatorisch fehlen teilweise ausgeprägte Datenkulturen und testende Mitarbeitende sind den Luxus gewohnt, Testfälle mit der Produktionsumgebung abgleichen zu können. Gleichzeitig darf das Einführen von Datenschutztechniken die Testqualität nicht verringern.

Die Umsetzung erfordert eine korrekte und vollständige Erfassung und Kategorisierung aller sensiblen Datenfelder auf Datenbankebene, auch in unstrukturierten Freitextfeldern. Das verursacht zu Beginn einen hohen Aufwand.

Für eine erfolgreiche Umsetzung der späteren Datenanonymisierung, empfehlen wir folgende grundlegende organisatorische und technische Schritte:

Der erste und entscheidende Schritt ist die Schaffung voller Transparenz. Je besser ein Unternehmen den Kontext (hier: Anwendungen, Datenbanken, Testfälle und -häufigkeit, Teststrecken, automatisiertes Testen, Batch-Verarbeitungen, etc.) kennt, desto besser kann eine maßgeschneiderte Lösung entwickelt werden, die Sicherheit und Praktikabilität vereint.

Erfahrungsgemäß muss ein Kompromiss zwischen Zielbild und Umsetzung getroffen werden. Während technische und fachliche Anwendungsverantwortliche ein klares Verständnis ihrer Anwendung(en) haben, ist für die Konzeptentwicklung eine zentrale Aufarbeitung über alle Anwendungen hinweg zu empfehlen. Das ist aufwendig, erleichtert die nachfolgende Arbeit aber insgemein.

Zwingend notwendig ist eine strategische Einbindung aller Verantwortlichen, insbesondere Bereichsleitenden und technischen und fachlichen Anwendungsverantwortlichen. Nur wenn die Fachbereiche die Notwendigkeit von Datenschutztechniken akzeptieren und technische Teams ihr Wissen über granulare Datenfelder und Datenflüsse einbringen, kann eine tragfähige Lösung zwischen voller Anonymisierung und sinnvoller Testvorgehensweise gefunden werden.

Es ist wichtig, früh darzulegen, warum Datenschutztechniken nötig sind und mögliche Probleme offen anzusprechen. Wenn Mitarbeitende verstehen, weshalb Anonymisierung oder Pseudonymisierung unverzichtbar sind, steigt auch ihre Bereitschaft, den zusätzlichen Aufwand mitzutragen und gemeinsam auf das Ziel hinzuarbeiten.

Eine große Herausforderung, zugleich methodisch als auch aufwandstechnisch, ist das Erfassen sensitiver Datenfelder. Felder, die anonymisiert werden sollen, müssen auf Tabellen- bzw. Feldebene identifiziert werden, damit für den entsprechenden Datentypen anschließend eine Pseudonymisierung bzw. Anonymisierung erfolgen kann. Über alle Anwendungen hinweg sind das potenziell mehr als eine Million Felder. Während moderne Anonymisierungstools automatisierte Lösungen anpreisen, ermöglichen diese meist nur die regelbasierte Identifizierung von Feldern. Bei Freitextfeldern und unscheinbaren, jedoch sensitiven Feldern stoßen sie an Ihre Grenzen.

Unternehmen fürchten hier falsche Negative, also Felder, die als nicht schützenswert bewertet und nicht anonymisiert werden, jedoch sensitive Daten enthalten. Es ist kaum möglich nachzuweisen, dass es keine falschen Negativen gibt. In der Praxis bleibt nur ein Vergleich mit den bereits geprüften Feldern – und daraus abzuleiten, wie vollständig die gesamte Datenbasis abgedeckt ist.

Testen spielt eine wesentliche Rolle im Qualitätsmanagement für Anwendungen. Unternehmen können Tests nicht reduzieren, nur weil anonymisierte Daten die Tests erschweren. Vor der Einführung von Datenschutztechniken muss deshalb sichergestellt werden, dass das neue Datenmodell Tests weiterhin zuverlässig ermöglicht.

Es ist zu beachten, dass Anwendungen häufig im Verbund getestet werden, – ein Konzept zur Anonymisierung ist daher nicht auf Anwendungsebene möglich, sondern muss über eine gesamte Teststrecke konzipiert werden. Da sich aus vielen Teststrecken schnell ein Netzwerk bildet, empfehlen wir die Abbildung von Schnittstellen beim Testen als Netzwerkgraph, von dem eine Distanzmatrix abgeleitet werden kann. Anforderungen an Datenbestände können innerhalb des Netzwerkgraphs repräsentiert werden. Diese Bearbeitung stellt sicher, dass notwendige Daten innerhalb der Teststrecke weder verloren gehen noch, dass ihre referenzielle Integrität gebrochen wird.

DORA erlaubt das Speichern von Echtdaten auf nichtproduktiven Umgebungen nur für bestimmte Testanlässe (siehe Regulatory Technical Standard C(2024) 1532 final Art 16 Abs. 5) – etwa für begrenzte Zeiträume und nach Genehmigung durch die betreffende Funktion sowie nach Meldung solcher Anlässe an die IKT-Risikomanagement-Funktion. Dieser Genehmigungsprozess ermöglicht das Testen im Abgleich mit der produktiven Umgebung, beispielsweise für Bugfixing. Hier ist zu beachten, dass die DSGVO für das Testen mit Echtdaten nach Rechtsprechung eine Kompatibilitätsprüfung (nach Art. 6 (4) DSGVO) erfordert.

Diesen Genehmigungsprozess sehen wir insbesondere für das schnelle Bugfixing im Falle von aktiven Fehlern auf der Produktion als essenziell. Für diesen Fall muss ein Genehmigungsprozess schnell durchlaufen werden können, da es keine Zeit zu verlieren gibt. Eine Implementierung aller automatisierbaren Aspekte (beispielsweise der Meldung an die IKT-Risikomanagement-Funktion, LLM-unterstützte Darlegung der Notwendigkeit, schlanke Kompatibilitätsprüfungen) ist hier sinnvoll, damit ein Insitut im Notfall compliant und handlungsfähig bleibt.

Es gibt keine pauschal beste Lösung, diese ist immer abhängig von der Komplexität der Anwendungslandschaft, dem Ambitionsniveau und der Kapazitäten zur Umsetzung. Nichtsdestotrotz ergeben sich zwei lokale Optima.

1. Zum einen kann statt einer komplizierten Pseudonymisierung und Anonymisierung von Daten ein synthetischer Datenhaushalt aufgebaut und gepflegt werden. Hierbei ist es allerdings schwierig, zu gewährleisten, dass die synthetischen Daten repräsentativ sind.
2. Zum anderen kann ein Konzept zur Pseudonymisierung und Anonymisierung inkl. Genehmigungsprozess für Ausnahmen erstellt und implementiert werden. Die Herausforderung dabei: Die Umstellung darf bestehende Testfälle nicht unbrauchbar machen. Eine umfassende Absicherung nichtproduktiver Umgebungen ermöglicht dabei in Ausnahmefällen ein umfassenderes Testen mit Echtdaten.

Finanzinstitute stehen wegen DORA und DSGVO klar in der Pflicht: In Test- und Entwicklungsumgebungen dürfen nur pseudonymisierte, anonymisierte oder synthetische Daten genutzt werden. Der Einsatz echter Daten birgt ein hohes Risiko für Datenlecks und Compliance-Verstöße – zumal Testumgebungen deutlich schlechter geschützt sind.

Die größte Herausforderung liegt in der Komplexität vernetzter IT-Landschaften, die die technische Umsetzung von Datenschutztechniken sowie die Fehlerreproduktion erschwert. Weil einfaches Pseudonymisieren rechtlich unsicher bleibt, braucht es einen ganzheitlichen, strategischen Ansatz. Dieser muss eine zentrale Transparenz über Datenbestände und Teststrecken schaffen, alle Fachbereiche, IT und Compliance einbinden und einen effizienten Genehmigungsprozess für die streng limitierten Ausnahmen beim Einsatz von Echtdaten etablieren.

Welche Lösung am besten passt, hängt stets vom jeweiligen Kontext ab. Entscheidend ist, Sicherheit und eine praxistaugliche Testqualität in Einklang zu bringen – sei es durch synthetische Datensätze oder durch ein belastbares Konzept für Anonymisierung und Pseudonymisierung.

Dieser Artikel ist unter Mitwirkung von Yannik Glatthaar und Tjard Hellmich entstanden.