Datenmaskierung für Testdaten ersetzt sensible Werte aus der Produktion durch Ersatzwerte, damit Tests mit realistischen Daten laufen und keine Kundin und kein Kunde erkennbar bleibt. Für QA-Leitungen in Banken zählen drei Punkte: Technik pro Feld, konsistente Schlüssel über alle Systeme und der rechtliche Status des Ergebnisses. Der GTB-Lehrplan zählt sensible Informationen, die „unverfälscht aus der Produktion in Testsysteme übernommen wurden“, zu den schlechten Testdaten (GTB-Lehrplan Test Data Specialist V1.1, 2021). Wie Maskierung in Rollen und Prozess passt, beschreibt der Leitartikel zum Testdatenmanagement.

Kurz gefasst: Datenmaskierung verfremdet Produktionswerte für Tests, etwa „Müller“ zu „Mxxxxx“. Ob das Ergebnis pseudonymisiert oder anonym ist, hängt davon ab, ob jemand die Originale wiederherstellen kann. Die meisten EU-Finanzunternehmen dürfen in Nichtproduktionsumgebungen nur anonymisierte, pseudonymisierte oder randomisierte Produktionsdaten speichern (DORA-RTS 2024/1774, Art. 16(5), 2024). Quasi-Identifikatoren wie Geburtsdatum und PLZ gehören in die Maskierung.

Abbildung 1: Maskierung ist eine Technik, Pseudonymisierung und Anonymisierung beschreiben den rechtlichen Zustand des Ergebnisses.

Was ist Datenmaskierung?

Datenmaskierung ist ein Verfahren des Testdatenmanagements, das Originalwerte gezielt verändert, damit Testdaten nutzbar bleiben und keine echten Personen oder Geschäftsinterna preisgeben. Das Glossar des GTB-Lehrplans definiert sie so: „Das Verändern von Originaldaten durch zufällige Zeichen oder Daten so, dass die Originaldaten nicht wiedererkennbar sind.“ (GTB-Lehrplan TDS V1.1, Kap. 7, 2021)

Nach GTB umfasst Datenmaskierung personenbezogene und nicht personenbezogene Daten, etwa interne Konditionen einer Firmenkundin. Die Daten werden verfremdet, nicht verschlüsselt: „ihre Lesbarkeit bleibt in der Regel erhalten“. Ein maskierter Name hat weiterhin die Form eines Namens, eine maskierte IBAN die Form einer IBAN.

Wie unterscheiden sich Datenmaskierung, Pseudonymisierung und Anonymisierung?

Datenmaskierung bezeichnet eine Technik; Pseudonymisierung und Anonymisierung bezeichnen den rechtlichen Zustand, den das Ergebnis erreicht. Pseudonymisiert sind Daten nach Art. 4 Nr. 5 DSGVO, wenn sie „ohne Hinzuziehung zusätzlicher Informationen nicht mehr einer spezifischen betroffenen Person zugeordnet werden können“, sofern diese Informationen gesondert verwahrt werden (DSGVO, EUR-Lex, 2016). Erwägungsgrund 26 behandelt solche Daten weiter „als Informationen über eine identifizierbare natürliche Person“.

Anonym sind Daten erst, wenn die betroffene Person „nicht oder nicht mehr identifiziert werden kann“ (Erwägungsgrund 26). Die Artikel-29-Datenschutzgruppe schreibt dazu: „pseudonymisation is not a method of anonymisation“ (WP216, 2014). Wer Schlüssel oder Zuordnungstabelle besitzt, hält pseudonymisierte Daten, egal wie gründlich die Maskierung aussieht.

Fachkommentare lesen das EuGH-Urteil C-413/23 P vom 4. September 2025 so, dass pseudonymisierte Daten zumindest für die Stelle, die den Schlüssel hält, personenbezogen bleiben (EuGH, Pressemitteilung 107/25, 2025). Die rechtliche Seite behandelt unser Beitrag zu DSGVO-konformen Testdaten.

Was verlangen DORA-RTS und revDSG?

Die meisten EU-Finanzunternehmen dürfen in Nichtproduktionsumgebungen nach Art. 16(5) der delegierten Verordnung (EU) 2024/1774 „nur anonymisierte, pseudonymisierte oder randomisierte Produktionsdaten“ speichern (EUR-Lex, 2024). Die RTS konkretisieren die EU-Verordnung DORA (2022/2554), die seit 17. Januar 2025 gilt.

Die DORA-RTS akzeptieren pseudonymisierte Daten, die DSGVO behandelt sie weiter als personenbezogen. Eine maskierte Testdatenbank kann die DORA-Vorgabe erfüllen und gleichzeitig voll unter die DSGVO fallen.

In der Schweiz gilt seit 1. September 2023 das revidierte Datenschutzgesetz (revDSG). Es definiert Personendaten als „alle Angaben, die sich auf eine bestimmte oder bestimmbare natürliche Person beziehen“ (Art. 5 lit. a, Fedlex, 2023) und enthält keine Definition der Pseudonymisierung. Für Banken und Wertpapierhäuser verlangt das FINMA-Rundschreiben 2023/1 die Trennung von Entwicklungs- und Testumgebungen von der IKT-Produktion (Testautomatisierung in regulierten Banken). Ob Ihr Maskierungskonzept genügt, lassen Sie mit Ihrer Datenschutzstelle prüfen.

Welche Techniken der Datenmaskierung gibt es?

Die gängigen Techniken der Datenmaskierung reichen vom Leeren eines Feldes bis zur formaterhaltenden Verschlüsselung, und jede bewahrt andere Eigenschaften der Daten. Der GTB-Lehrplan trennt Informationsreduktion (Werte weglassen) von Informationsveränderung und nennt Beispiele, etwa Gehälter mit ±20 % Varianz (GTB-Lehrplan TDS V1.1, Kap. 2.4.2, 2021).

Abbildung 2: Vier Maskierungstechniken mit Beispielen aus dem GTB-Lehrplan Test Data Specialist V1.1.

Tokenisierung und FPE liegen außerhalb der GTB-Definition, die Maskierung von Verschlüsselung trennt; viele TDM-Werkzeuge bieten beide unter dem Begriff Maskierung an. NIST SP 800-38G spezifiziert seit 2016 die FPE-Verfahren FF1 und FF3 (NIST, 2016). Der zweite Entwurf von Revision 1 hält fest: „The encryption method FF3 is no longer specified.“ (NIST SP 800-38G Rev. 1, 2025). Eine finale Fassung fanden wir bis Redaktionsschluss nicht. Planen Sie FPE mit FF1.

Statisch oder zur Laufzeit maskieren?

Statische Maskierung schreibt eine verfremdete Kopie in die Testdatenbank. Maskierung zur Laufzeit (on the fly) verändert Werte erst beim Lesen oder Anzeigen; die gespeicherten Daten bleiben Klartext.

• Statisch: passt für Testumgebungen, der Datenstand ist reproduzierbar, der Abzug muss regelmäßig neu laufen.

• Zur Laufzeit: passt für Ansichten in der Produktion, etwa Support-Masken. Die Datenbank darunter enthält weiterhin Originale; Art. 16(5) der DORA-RTS knüpft an das Gespeicherte an.

Was bedeutet Maskierung bei Kartennummern?

PCI DSS v4.0 und v4.0.1 (Anforderung 3.4.1) begrenzen die Anzeige einer Kartennummer (PAN) auf die BIN und die letzten vier Ziffern; mehr Stellen sieht nur Personal mit dokumentiertem geschäftlichem Bedarf. Das PCI Security Standards Council formuliert: „no more than the BIN and last four digits of the PAN are displayed“ (PCI SSC FAQ). „Erste sechs, letzte vier“ ist nicht die Formulierung von v4.0 und passt nicht zu 8-stelligen BINs.

Eine maskiert angezeigte PAN darf laut PCI SSC FAQ 1146 vollständig gespeichert sein und fällt dann unter Anforderung 3.5.1. Anzeige-Maskierung schützt keinen Testdatenbestand.

Wie hoch ist das Re-Identifikationsrisiko maskierter Testdaten?

Das Re-Identifikationsrisiko ist hoch, sobald unveränderte Quasi-Identifikatoren wie Postleitzahl, Geschlecht und Geburtsdatum im Datensatz bleiben. Latanya Sweeney fand, dass 87 % der US-Bevölkerung (216 von 248 Millionen) über fünfstelligen ZIP-Code, Geschlecht und Geburtsdatum wahrscheinlich eindeutig waren, auf Basis der US-Volkszählung 1990 (Sweeney, Data Privacy Lab, 2000).

Abbildung 3: Wenige Quasi-Identifikatoren reichen für eine Re-Identifikation (US-Daten; Sweeney, Golle, Rocher et al.).

Philippe Golle kam mit Daten der Volkszählung 2000 auf 63 % (Golle, Stanford). Rocher, Hendrickx und de Montjoye schätzten mit einem generativen Modell, dass 99,98 % der Amerikaner mit 15 demografischen Merkmalen in jedem Datensatz korrekt re-identifizierbar wären (Nature Communications, 2019). Alle drei Zahlen beruhen auf US-Daten. Vergleichbare Zahlen für die Schweiz oder Deutschland liegen uns nicht vor.

WP216 nennt drei Risiken, gegen die eine Anonymisierung schützen muss (WP216, 2014):

• Singling out: „the possibility to isolate some or all records which identify an individual in the dataset“

• Linkability: „the ability to link, at least, two records concerning the same data subject or a group of data subjects“

• Inference: „the possibility to deduce, with significant probability, the value of an attribute from the values of a set of other attributes“

Der GTB-Lehrplan nennt ein Testbeispiel: „den einzigen 97-jährigen Versicherungsnehmer“ im Bestand zu lassen, macht ihn identifizierbar, egal ob sein Name maskiert ist.

Wie gehen Sie bei der Datenmaskierung Schritt für Schritt vor?

Datenmaskierung für Testdaten läuft in sieben Schritten: Felder inventarisieren, Technik wählen, Schlüssel konsistent halten, außerhalb der Testumgebung maskieren, Restrisiko prüfen, mit der Regressionssuite testen, dokumentieren.

Abbildung 4: Die sieben Schritte der Datenmaskierung für Testdaten.

1. Sensible Felder inventarisieren. Direkte Identifikatoren (Name, IBAN, Kartennummer, E-Mail), Quasi-Identifikatoren (PLZ, Geburtsdatum, Geschlecht, Beruf) und Freitextfelder mit Kundendaten.

2. Technik pro Feld wählen. Schwärzen, was kein Test braucht. Generalisieren, was nur grob stimmen muss. Substitution oder FPE, wo Format und Joins zählen.

3. Formate und Schlüssel konsistent halten. Dieselbe Kundin bekommt in jedem System denselben Ersatzwert.

4. Außerhalb der Testumgebung maskieren. Maskiert wird in einer abgesicherten Zone; in die Testumgebung gelangt nur das Ergebnis. Schlüssel und Zuordnungstabellen bleiben getrennt verwahrt.

5. Restrisiko prüfen. Suchen Sie nach eindeutigen Kombinationen und seltenen Werten. Bleibt das Risiko hoch, ist es oft sauberer, synthetische Testdaten zu generieren.

6. Maskierte Daten mit der Regressionssuite testen. Rote Tests auf dem maskierten Bestand zeigen, wo die Maskierung Formate oder Fachlogik gebrochen hat. Teilen sich mehrere Läufe denselben Bestand, hilft die Isolation von Testdaten gegen Kollisionen.

7. Dokumentieren. Regeln pro Feld, Version des Maskierungsjobs, Datum des Abzugs und Freigabe gehören ins Testdatenkonzept, das der GTB als Anlage zum Testkonzept vorsieht. Ein lückenloser Audit-Trail im Testen zeigt der Revision später, welche Daten wann in welcher Umgebung lagen.

Wie bleibt die referentielle Integrität über mehrere Systeme erhalten?

Referentielle Integrität bleibt erhalten, wenn derselbe Originalwert in jeder Tabelle und jedem System denselben Ersatzwert bekommt. Der GTB-Lehrplan nennt die „Beibehaltung der referentiellen Integrität“ als zentrale Herausforderung bei Teilabzügen (GTB-Lehrplan TDS V1.1, Kap. 2.4.1, 2021). Eine Kundin mit Konto im Kernbankensystem, Karte im Kartensystem und Kontakt im CRM braucht nach der Maskierung überall dieselbe Kundennummer. Sonst brechen E2E-Tests an der ersten Schnittstelle.

Konsistenz erreichen Sie über eine zentrale Zuordnungstabelle (Original zu Ersatz) oder eine deterministische Funktion mit geheimem Schlüssel, die für denselben Eingabewert immer denselben Ersatz liefert. Beide Wege erzeugen genau die „zusätzlichen Informationen“, die Art. 4 Nr. 5 DSGVO beschreibt. Konsistente Datenmaskierung über mehrere Systeme führt damit fast immer zu pseudonymisierten Daten, nicht zu anonymen. Prüfen Sie nach jedem Lauf:

• Formate und Prüfziffern (IBAN, Kartennummer, AHV- oder Steuernummer), damit Eingabeprüfungen im Test nicht anschlagen

• Fremdschlüssel und eindeutige Indizes

• Zeitbezüge: Für Systemketten verlangt der GTB-Lehrplan einen „einheitlichen Zeitstempel im Datenabzug“

Wo passt Autemos und wo nicht?

Autemos ist eine KI-gestützte Software für funktionale Testautomatisierung über Web, Mobile, API und Desktop. Autemos ist kein Werkzeug für Datenmaskierung oder Testdatengenerierung. Es anonymisiert und pseudonymisiert keine Produktionsdaten und erstellt keine Teilabzüge von Datenbanken.

Autemos arbeitet mit Testdaten, die Ihr TDM-Prozess vorher maskiert hat. Ob sie maskiert sind, prüft Autemos nicht. Test Data Handling in Autemos bindet externe Quellen an: REST-APIs, Datenbanken, Excel, JSON-Dateien und die Datenquelle iSynth. Runtime Bindings laden Werte zur Laufzeit als Variablen, getrennt pro Umgebung (DEV, TEST, STAGING, PROD).

So legen Sie fest, dass die TEST-Bindung auf die maskierte Kopie zeigt. One-Time Use markiert verbrauchte Testbenutzer, Voucher oder Tokens, damit parallele Läufe sie nicht doppelt ziehen.

Häufig gestellte Fragen

Sind maskierte Testdaten noch personenbezogene Daten?

Ja, solange jemand die Originale über Schlüssel, Token-Tresor oder Zuordnungstabelle wiederherstellen kann. Dann sind sie pseudonymisiert, und Erwägungsgrund 26 DSGVO behandelt sie als Informationen über eine identifizierbare Person (EUR-Lex, 2016). Anonym sind sie erst, wenn niemand die Person mit vernünftigerweise einsetzbaren Mitteln identifizieren kann.

Reicht es, Namen und IBAN zu maskieren?

Nein, Quasi-Identifikatoren genügen oft für eine Re-Identifikation. Nach Sweeney machten Postleitzahl, Geschlecht und Geburtsdatum 87 % der US-Bevölkerung von 1990 wahrscheinlich eindeutig (Data Privacy Lab, 2000). Generalisieren oder verändern Sie diese Felder mit, und prüfen Sie Freitextfelder.

Darf eine EU-Bank unmaskierte Produktionsdaten im Test verwenden?

Nur als Ausnahme nach Art. 16(6) der DORA-RTS 2024/1774: für bestimmte Testanlässe, befristet, nach Freigabe und mit Meldung an die IKT-Risikomanagementfunktion (EUR-Lex, 2024). Der Regelfall ist Art. 16(5) mit anonymisierten, pseudonymisierten oder randomisierten Produktionsdaten.

Ist formaterhaltende Verschlüsselung eine Anonymisierung?

Nein, FPE ist mit dem Schlüssel umkehrbar und erzeugt pseudonymisierte Daten. Verwahren Sie den Schlüssel getrennt von der Testumgebung.

Maskiert Autemos Testdaten?

Nein, Autemos maskiert, anonymisiert und generiert keine Testdaten. Es liest vorher maskierte Testdaten aus REST-APIs, Datenbanken, Excel, JSON oder iSynth über Runtime Bindings pro Umgebung ein (Test Data Handling).

Fazit

Datenmaskierung macht Produktionsdaten für Tests nutzbar, wenn Sie sie Feld für Feld planen. Keine Technik macht Daten automatisch anonym: Sobald Schlüssel oder Zuordnungstabellen existieren, sind sie pseudonymisiert und bleiben unter der DSGVO. Für EU-Banken setzt Art. 16(5) der DORA-RTS die Untergrenze; für Schweizer Banken gelten das revDSG und die FINMA-Vorgabe, Test und Produktion zu trennen. Prüfen Sie Quasi-Identifikatoren, halten Sie Ersatzwerte über alle Systeme konsistent, lassen Sie die Regressionssuite über den maskierten Bestand laufen und dokumentieren Sie die Regeln pro Feld im Testdatenkonzept. Wenn Sie sehen möchten, wie automatisierte Tests vorher maskierte Testdaten pro Umgebung einbinden, sprechen Sie mit dem Autemos-Team.