Testdaten und DSGVO: warum die Kopie der Produktivdatenbank die teuerste Abkürzung ist

Es ist der schnellste Weg zu einem realistischen Testsystem: Man zieht einen Abzug der Produktivdatenbank und spielt ihn in die Testumgebung ein. In zwei Stunden hat man echte Kundendaten, echte Sonderfälle und echte Datenmengen. Kein synthetischer Datensatz kommt da heran.

Und kaum eine andere Routine im Softwareprojekt ist datenschutzrechtlich so angreifbar. Nicht, weil jemand böse Absichten hätte, sondern weil in diesem Moment personenbezogene Daten für einen Zweck verarbeitet werden, für den sie nicht erhoben wurden, in einer Umgebung, die schwächer geschützt ist als die produktive, zugänglich für einen größeren Personenkreis, und in aller Regel ohne Löschfrist.

Warum Testen ein eigener Zweck ist

Die Grundsätze in Artikel 5 der DSGVO sind an dieser Stelle unbequem eindeutig. Personenbezogene Daten dürfen nur für festgelegte, eindeutige und legitime Zwecke erhoben und nicht in einer damit unvereinbaren Weise weiterverarbeitet werden. Sie müssen dem Zweck angemessen und auf das notwendige Maß beschränkt sein. Und sie dürfen nur so lange in identifizierbarer Form gespeichert werden, wie es der Zweck erfordert.

Ein Kunde, der eine Bestellung aufgibt, stellt seine Daten für die Abwicklung dieser Bestellung bereit. Er stellt sie nicht für die Erprobung des nächsten Releases bereit. Softwaretest ist ein anderer Zweck, und dieser Zweck braucht seine eigene Betrachtung, seine eigene Rechtsgrundlage und seine eigenen Schutzmaßnahmen.

Dazu kommt ein praktischer Punkt, der oft schwerer wiegt als der rechtliche: Testsysteme sind strukturell schwächer geschützt. Mehr Personen haben Zugriff, darunter Externe. Berechtigungen werden großzügiger vergeben, weil man arbeiten können muss. Abzüge werden lokal kopiert, in Fehlertickets angehängt und in Backups mitgeschleppt. Ein Datenabfluss aus einem Testsystem ist genauso meldepflichtig wie einer aus dem Produktivsystem, und die betroffenen Personen sind dieselben.

Die Rangfolge des BfDI

Der Bundesbeauftragte für den Datenschutz und die Informationsfreiheit hat im Juni 2025 eine Kurzposition zu genau dieser Frage veröffentlicht. Sie gibt eine Prüffolge in drei Stufen vor:

• Zuerst nicht personenbezogene, anonyme oder synthetische Daten. Sie fallen nicht unter die DSGVO und können ohne Einschränkungen für Entwicklungs- und Testzwecke genutzt werden.
• Dann pseudonymisierte Daten, wenn die erste Stufe nicht ausreicht.
• Zuletzt personenbezogene Daten unverändert, und zwar erst dann, wenn für den konkreten Test die Verwendung von Testdaten ohne Personenbezug nicht in Frage kommt.

Das Entscheidende an dieser Formulierung ist das Wort „konkret“. Die Prüfung ist nicht einmalig für das ganze Projekt zu führen, sondern für den jeweiligen Test. Für die große Mehrheit funktionaler Test Cases lässt sich die Frage mit synthetischen Daten beantworten. Für einen Lasttest mit realistischer Datenverteilung oder eine Migrationsprüfung über historisch gewachsene Bestände sieht die Antwort anders aus, und genau diese Fälle muss man begründen und dokumentieren können.

Der wahre Grund für den Datenbankabzug

Wer ehrlich nachfragt, warum ein Team Produktivdaten will, bekommt selten „aus Bequemlichkeit“ zur Antwort. Der Grund ist fast immer Abdeckung. Produktivdaten enthalten Sonderfälle, die sich niemand ausdenkt: den Kunden mit dem Umlaut im Nachnamen und dem Bindestrich in der Hausnummer, den Vertrag aus einem abgelösten System mit einem Feld, das seit 2011 nicht mehr befüllt wird, die Buchung über den Jahreswechsel mit rückwirkender Stornierung.

Das ist ein berechtigtes fachliches Anliegen, aber es ist ein Testdesign-Problem, kein Datenbeschaffungsproblem. Die Sonderfälle stecken nicht in den Daten, sondern in den Regeln, die diese Daten erzeugt haben. Sie lassen sich systematisch ableiten: aus Grenzwertanalyse und Äquivalenzklassenbildung, aus der Historie der Produktionsfehler, aus den Feldformaten der Altsysteme, aus einer statistischen Auswertung der Produktivdaten, die Verteilungen und Formate beschreibt, ohne einzelne Datensätze zu kopieren.

Der Aufwand dafür entsteht einmal. Danach hat man einen Testdatenbestand, der die Sonderfälle bewusst abdeckt statt zufällig, der reproduzierbar ist, der ohne Genehmigung eingesetzt werden kann und der nicht bei jedem Abzug neu beschafft werden muss. Ein Produktivabzug hingegen ist zufällig: Er enthält die Sonderfälle, die zufällig darin sind, und niemand weiß, welche fehlen.

Anonymisierung ist schwerer, als sie klingt

Anonyme Daten fallen nicht unter die DSGVO. Erwägungsgrund 26 der Verordnung stellt das klar. Genau deshalb ist die Hürde hoch: Anonym ist ein Datensatz erst, wenn eine Zuordnung zu einer Person nicht mehr oder nur mit unverhältnismäßigem Aufwand möglich ist.

Der BfDI weist auf den Punkt hin, an dem die meisten Anonymisierungsversuche scheitern: die Quasi-Identifikatoren. Name und Kundennummer zu ersetzen genügt nicht, wenn Geburtsdatum, Postleitzahl und Vertragsbeginn im Datensatz bleiben. Die Kombination weniger, für sich harmloser Merkmale identifiziert Personen zuverlässig. Und maßgeblich sind nicht nur die Mittel dessen, der die Daten erhält, sondern auch die Mittel, die von außen zur Identifizierung eingesetzt werden könnten.

Ein häufiger Fehler in der Praxis: Man ersetzt Namen durch Zufallsnamen, behält aber die Verknüpfungen bei. Der Datensatz sieht danach anonym aus und ist es nicht.

Pseudonymisierung ist kein Ausstieg aus der DSGVO

Pseudonymisierte Daten bleiben personenbezogene Daten. Artikel 4 Nummer 5 der DSGVO definiert Pseudonymisierung als Verarbeitung, nach der die Daten ohne Hinzuziehung zusätzlicher Informationen nicht mehr einer Person zugeordnet werden können, wobei diese Zusatzinformationen gesondert aufbewahrt werden. Solange der Schlüssel existiert, existiert der Personenbezug.

Was Pseudonymisierung leistet, ist Risikominderung. Sie ist in Artikel 32 ausdrücklich als technische Maßnahme zur Sicherheit der Verarbeitung genannt und in Artikel 25 als Beispiel für Datenschutz durch Technikgestaltung. Der Europäische Datenschutzausschuss hat dazu im Januar 2025 eigene Leitlinien vorgelegt; der Bundesbeauftragte fasst deren praktischen Nutzen so zusammen, dass Pseudonymisierung es Verantwortlichen erleichtern kann, sich auf ein berechtigtes Interesse als Rechtsgrundlage zu berufen.

Für die Testplanung heißt das: Pseudonymisierung ist eine gute Maßnahme und eine schlechte Ausrede. Ein pseudonymisierter Produktivabzug im Testsystem braucht weiterhin eine Rechtsgrundlage, ein Berechtigungskonzept und eine Löschfrist.

Wenn Echtdaten unvermeidbar sind

Es gibt Tests, für die kein Weg an echten Daten vorbeiführt, etwa bestimmte Migrationsprüfungen. Dann verschiebt sich die Aufgabe von „vermeiden“ zu „beherrschen“. Der BfDI nennt als Bedingungen eine tragfähige Rechtsgrundlage, geeignete technische und organisatorische Maßnahmen und die Erfüllung der allgemeinen Zulässigkeitsvoraussetzungen, einschließlich Betroffenenrechten und Transparenzpflichten.

In der Umsetzung heißt das unter anderem: ein enger, namentlich dokumentierter Zugriffskreis statt einer Sammelberechtigung für das Testsystem; eine feste Löschfrist mit einem Mechanismus, der sie durchsetzt, statt eines Vorsatzes; Verschlüsselung im Ruhezustand und im Transport; keine Anhänge mit Echtdaten in Fehlertickets; und ein Auftragsverarbeitungsvertrag nach Artikel 28, sobald ein externer Dienstleister die Daten verarbeitet. Ob zusätzlich eine Datenschutz-Folgenabschätzung nötig ist, hängt vom Einzelfall ab und gehört geprüft, nicht geschätzt.

Was das für die Testplanung bedeutet

Testdaten sind kein Nebenprodukt der Testdurchführung, sondern eine eigene Planungsgröße. Die Norm ISO/IEC/IEEE 29119-3 führt Testdatenanforderungen deshalb als eigenständigen Dokumentationsbestandteil. Praktisch gehören drei Dinge ins Testkonzept:

• Testdatenanforderungen je Test Case oder Testgruppe: Welche Merkmalsausprägungen werden gebraucht, welche Grenzwerte, welche Sonderfälle. Erst diese Liste zeigt, ob synthetische Daten ausreichen.
• Die Herkunftsentscheidung mit Begründung: synthetisch, anonymisiert, pseudonymisiert oder echt, und warum. Das ist zugleich die Dokumentation der Prüffolge, die der BfDI verlangt.
• Das Löschkonzept für die Testumgebung: Wann werden Datenbestände zurückgesetzt, wer stellt das sicher, wie wird es nachgewiesen. Testsysteme sind die Umgebungen, in denen Daten am längsten unbemerkt liegen bleiben.

Wer diese drei Punkte im Testkonzept hat, führt die Diskussion mit dem Datenschutzbeauftragten einmal am Anfang statt jedes Mal aufs Neue kurz vor dem Testbeginn.

Wer was macht

Qelivia spezifiziert die Testdatenanforderungen im Testkonzept und leitet die benötigten Sonderfälle aus dem Risikobild und den Testentwurfsverfahren ab. Dafür brauchen wir keinen Zugriff auf Ihre Produktivdaten, und wir nehmen ihn auch nicht. Die Erzeugung und Bereitstellung der Testdaten erfolgt in Ihrer Umgebung, ebenso wie die Testdurchführung.

Ebenso deutlich: Wir sind keine Datenschutzberatung. Die Bewertung der Rechtsgrundlage, die Datenschutz-Folgenabschätzung und die Freigabe eines Verfahrens gehören zu Ihrem Datenschutzbeauftragten oder zu einer Kanzlei. Was Testmanagement beiträgt, ist die Vorarbeit, die diese Bewertung überhaupt möglich macht: eine belastbare Aussage darüber, welche Daten fachlich wirklich gebraucht werden, und in aller Regel der Nachweis, dass es weniger sind als angenommen.

Fazit

Der Produktivabzug im Testsystem ist eine Abkürzung, die man am Anfang eines Projekts nimmt und am Ende teuer bezahlt: mit einer Diskussion vor dem Go-live, mit einer Umgebung, die man nicht mehr aufräumen kann, im schlechtesten Fall mit einer Meldung nach Artikel 33. Die Alternative ist unbequemer, aber einmalig: Sonderfälle systematisch ableiten, synthetisch erzeugen und die Herkunftsentscheidung dokumentieren. Danach ist der Testdatenbestand ein Vermögenswert statt eines Risikos.

Hinweis: Dieser Artikel gibt den Stand vom 21. August 2026 wieder und fasst öffentlich zugängliche Quellen des Bundesbeauftragten für den Datenschutz, des Europäischen Datenschutzausschusses und den Verordnungstext zusammen. Er ist keine Rechtsberatung. Die Bewertung Ihres konkreten Verfahrens gehört zu Ihrem Datenschutzbeauftragten oder in eine anwaltliche Prüfung.