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

Reicht es, wenn Echtdaten pseudonymisiert sind?

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.

Herausforderungen bei der Umsetzung von Datenschutztechniken

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:

1. Transparenz als Ausgangspunkt

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.

2. Gezieltes Stakeholdermanagement

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.

3. Identifizierung von sensitiven Datenfeldern

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.

4. Berücksichtigung von Teststrecken

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.

5. Genehmigungsprozess für vollständige Testabbildung

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.