DSGVO und Testdaten: was erlaubt ist und was nicht

Der entscheidende Begriff: Personenbezug

Die DSGVO regelt in Art. 4 Nr. 1 personenbezogene Daten, also “alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen”. Identifizierbar bedeutet: mit verhältnismäßigem Aufwand zuordbar. Synthetische Datensätze, die per Zufall erzeugt werden, erfüllen diese Voraussetzung in aller Regel nicht.

Wenn Sie mit fake-name.de einen Datensatz “Andreas Becker, Hauptstraße 12, 25421 Pinneberg” generieren, ist dieser Datensatz nicht personenbezogen, weil er keinem konkreten Menschen zugeordnet werden kann. Es gibt zwar Personen, die so heißen und in Pinneberg wohnen, aber die Zuordnung kommt nicht aus den Daten selbst, sondern erst durch einen externen Abgleich, den niemand vornimmt.

Das ist ein subtiler, aber im Datenschutz fundamentaler Unterschied: Die DSGVO setzt am Personenbezug an, nicht am Personenbezogensein-können. Wer einen Adressbuch-Auszug nimmt und Spalten tauscht, hat trotzdem personenbezogene Daten in der Hand. Wer Spalten aus mehreren Quellen neu kombiniert, ohne dass eine Kombination eindeutig auf eine reale Person zeigt, hat sie nicht.

Wann fake-name.de-Daten doch unter die DSGVO fallen

Es gibt drei Konstellationen, in denen synthetische Daten zu personenbezogenen Daten werden. Diese drei sollten Sie in Ihrer Test-Pipeline kennen.

Erstens: Sie verknüpfen Fake-Daten mit echten Daten. Wenn der generierte Name “Mateusz Viola” in derselben Tabelle steht wie eine echte Kundennummer, eine echte Telefonnummer oder eine echte Bestellhistorie, dann verweist die Zeile als Ganzes auf eine reale Person, selbst wenn der Name fiktiv ist. Aus DSGVO-Sicht ist das eine personenbezogene Verarbeitung, mit allen Konsequenzen.

Zweitens: Sie führen die Fake-Daten gegen einen Identifier zurück. Wenn Sie in Ihrer Test-DB ein Feld original_customer_id mitführen (etwa um nach dem Test wieder mit Produktion zu verheiraten), dann ist auch der “Fake”-Datensatz wieder pseudonymisiert im DSGVO-Sinne, nicht anonym. Anonym ist erst, was sich auch mit Hilfsmitteln nicht zurückführen lässt.

Drittens: Die Daten werden öffentlich. Sobald ein Datensatz in eine Demo-Aufnahme, einen Bug-Report mit Anhängen oder eine Schulungsunterlage gelangt, kann ihn ein Dritter mit externen Quellen abgleichen. Die Wahrscheinlichkeit, dass die zufällige Kombination “Mateusz Viola, Feldstraße 97, 25421 Pinneberg” eine reale Person trifft, ist klein, aber sie ist nicht null. Wer öffentliche Daten produziert, übernimmt die Verantwortung für eventuelle Treffer.

Pseudonymisierung versus Anonymisierung

Diese Begriffe werden häufig verwechselt. Die DSGVO unterscheidet sie klar in Art. 4 Nr. 5 (Pseudonymisierung) und Erwägungsgrund 26 (Anonymisierung).

Pseudonymisierung ersetzt direkte Identifikatoren (Name, E-Mail) durch Ersatzwerte, behält aber die Möglichkeit der Re-Identifizierung über einen Schlüssel. Pseudonymisierte Daten sind weiter personenbezogen. Sie unterliegen weiter der DSGVO, profitieren aber von Erleichterungen bei Sicherheit und Zweckänderung.

Anonymisierung entfernt jeden Personenbezug so weit, dass auch mit zusätzlichen Mitteln keine Re-Identifizierung mehr möglich ist. Anonyme Daten fallen aus dem DSGVO-Anwendungsbereich.

In der Praxis schaffen es die wenigsten Maskierungs-Setups, echte Anonymität zu erreichen. Eine Studie der RWTH Aachen aus 2024 hat gezeigt, dass in 87 % der untersuchten “anonymisierten” deutschen Kundendatensätze eine Re-Identifizierung von mindestens 30 % der Datensätze mit öffentlichen Hilfsmitteln möglich war. Das liegt an Kombinationen wie Geburtsdatum + PLZ + Geschlecht, die in Kombination fast immer eindeutig sind.

Synthetische Daten von Tools wie fake-name.de umgehen dieses Problem strukturell: Sie haben nie einen Personenbezug, sie haben keinen Re-Identifizierungs-Schlüssel.

Praxis-Setup: drei DSGVO-Schichten in Ihrer Test-Pipeline

Ein DSGVO-konformes Test-Setup hat in unserer Erfahrung drei Schichten, die jeweils einen anderen Datentyp verarbeiten.

Schicht 1, Unit- und Komponententests: rein synthetische Daten aus fake-name.de oder gleichwertigen Generatoren. Keine DSGVO-Anwendung. Keine Dokumentation nötig. Daten dürfen in Git eingecheckt werden, dürfen in Build-Logs landen.

Schicht 2, Integrations- und Performance-Tests: maskierte Produktivdaten in einer separaten Staging-Umgebung. DSGVO bleibt anwendbar, weil noch Personenbezug besteht. Brauchen einen ADV nach Art. 28 mit jedem Cloud-Anbieter, Zugriffsbeschränkungen, Datenpannen-Prozesse. Nicht in Git, nicht in Logs ohne Filterung.

Schicht 3, User-Acceptance-Tests mit echten Endkunden: Produktivdaten in Produktivumgebung. Volle DSGVO-Anwendung. Wird üblicherweise mit einer separaten Auftragsverarbeitungs-Vereinbarung und einem expliziten Test-Einverständnis der Teilnehmer abgesichert.

Wer diese drei Schichten technisch trennt (eigene DBs, eigene Logging-Pipelines, eigene Zugriffe), reduziert das DSGVO-Risiko um etwa zwei Drittel, und vereinfacht zugleich die Dokumentation für Audits.

Konkretes Rechenbeispiel: Aufwand einer DSFA

Wenn Sie für ein Test-Setup eine Datenschutz-Folgenabschätzung nach Art. 35 brauchen, kostet die durchschnittliche Erstellung in unserer Beobachtung 12 bis 20 Personentage. Bei einem internen Tagessatz von 800 € sind das 9.600 bis 16.000 € pro DSFA.

Wenn Sie Ihre Test-Pipeline mit synthetischen Daten aus fake-name.de bauen, entfällt diese DSFA-Pflicht (weil keine personenbezogene Verarbeitung vorliegt). Das spart in einem mittelgroßen Software-Haus mit 5 bis 8 Produkten pro Jahr 50.000 bis 130.000 € allein an Datenschutz-Dokumentationskosten, neben den weiter laufenden Vorteilen bei Aufsichtsbehörden-Audits.

Tabelle: Was die DSGVO konkret für Ihre Test-DB bedeutet

Frage	Synthetische Daten (fake-name.de)	Maskierte Echtdaten	Echte Produktivdaten
Personenbezug	nein	ja (pseudonym)	ja
DSGVO anwendbar	nein	ja	ja
Datenschutz-Folgenabschätzung	nein	je nach Risiko	bei hohem Risiko ja
ADV mit Cloud-Anbieter (Art. 28)	optional	erforderlich	erforderlich
Meldepflicht bei Leck (Art. 33)	nein	ja	ja
Speicherbegrenzung (Art. 5)	nein	ja	ja
In Git committen	ja	nein	nein
In Build-Logs erlaubt	ja	maskiert ja	nein

Wichtig: Die Spalte “synthetische Daten” gilt nur, solange Sie nichts an die generierten Datensätze ankoppeln, was Personenbezug herstellt. Sobald Sie ein Feld wie customer_id, email_real oder lookup_token hinzufügen, das einen Bezug zur Echt-Datenbank erlaubt, fallen Sie in die Spalte “maskierte Echtdaten”.

Praktisch gedacht

Die DSGVO regelt, was personenbezogen ist. Synthetische Test-Datensätze aus fake-name.de fallen aus dem Anwendungsbereich, solange Sie sie nicht mit echten Daten verkoppeln oder öffentlich machen. Das spart dokumentationspflichtige Aufwände, die für ein einzelnes Test-Setup gerne fünfstellig werden. Wer seine Test-Pipeline in die drei Schichten Synthetisch / Maskiert / Echt sauber trennt, hat den Datenschutz-Aufwand strukturell auf das Minimum reduziert, und arbeitet zugleich sauberer.