„Wir brauchen echte Daten, sonst können wir nicht realistisch testen.“

Diesen Satz kann ich aus Entwicklersicht gut nachvollziehen. Trotzdem lohnt sich eine zweite Frage:

Was genau muss an den Daten real sein?

Denn „realistisch testen“ bedeutet nicht automatisch, dass dafür ein vollständiger Produktivbestand benötigt wird.

Bei vielen Tests reicht es vollkommen aus, wenn Testdaten dieselbe Struktur, dieselben Wertebereiche, Beziehungen und fachlich relevanten Sonderfälle abbilden wie die produktiven Daten.

Bei Migrationen gibt es allerdings einen Punkt, an dem genau das nicht mehr genügt.

Wie weit reichen synthetische Testdaten?

Synthetische Daten können erstaunlich weit tragen.

Solange der Test prüfen soll, ob eine Anwendung oder Migration mit einer bestimmten Datenstruktur und bekannten fachlichen Konstellationen umgehen kann, müssen die einzelnen Datensätze nicht real sein.

Damit lassen sich zum Beispiel prüfen:

Auch komplexe Datenbestände können dafür künstlich erzeugt werden.

Entscheidend ist, dass nicht nur „irgendwelche Fake-Daten“ erzeugt werden. Gute synthetische Testdaten müssen die Eigenschaften des realen Datenbestands abbilden, die für den jeweiligen Test relevant sind.

Ein Beispiel:

Wenn ein Altsystem zehn unterschiedliche Varianten einer Kundenbeziehung kennt, hilft ein synthetischer Datenbestand mit ausschließlich idealtypischen Datensätzen wenig. Sind diese zehn Varianten aber bekannt, können sie gezielt nachgebildet werden.

Bis hierhin besteht normalerweise kein technischer Grund, personenbezogene Originaldaten einzusetzen.

Wo synthetische Daten an ihre Grenze kommen

Anders wird es, wenn nicht mehr nur geprüft werden soll, ob das Migrationsverfahren grundsätzlich funktioniert, sondern ob es mit dem konkreten vorhandenen Datenbestand funktioniert.

Produktive Datenbestände haben Geschichte.

Über Jahre entstehen Konstellationen, die niemand bewusst entworfen hat:

Was man nicht kennt, kann man auch nicht gezielt synthetisch erzeugen.

Spätestens wenn genau diese tatsächliche Datenrealität Gegenstand der Prüfung wird, kann die Nutzung des Originalbestands erforderlich sein.

Migrationen brauchen unterschiedliche Teststufen

Deshalb halte ich es für sinnvoll, nicht pauschal zwischen „Testdaten“ und „Produktivdaten“ zu unterscheiden.

Die Teststrategie kann stufenweise aufgebaut werden.

Frühe Entwicklungs- und Mappingtests können vollständig mit synthetischen Daten arbeiten.

Danach können synthetische Daten um gezielt konstruierte Grenz- und Sonderfälle ergänzt werden.

Auch Mengentests benötigen nicht zwingend Originaldaten. Wenn geprüft werden soll, ob zehn Millionen Datensätze innerhalb eines bestimmten Zeitfensters verarbeitet werden können, lässt sich die erforderliche Datenmenge häufig künstlich erzeugen.

Erst danach stellt sich die Frage:

Muss jetzt der konkrete Produktivbestand bewiesen werden, oder weiterhin nur die technische Funktionsfähigkeit?

Das ist für mich der entscheidende Übergang.

Cut-over-Tests können eine andere Datenrealität benötigen

Ein klassischer Fall ist der Cut-over-Test.

Vor einer produktiven Umstellung soll möglichst realitätsnah geprüft werden:

Hier kann der konkrete Originaldatenbestand notwendig werden.

Noch deutlicher wird es, wenn die Migration gegenüber Revision, Wirtschaftsprüfern oder anderen prüfenden Stellen nachweisbar sein muss.

Dann geht es nicht mehr nur um die Frage:

„Kann unsere Software solche Daten migrieren?“

Sondern möglicherweise um:

„Können wir nachweisen, dass genau dieser Bestand vollständig und korrekt migriert wurde?“

Dafür reichen synthetische Daten naturgemäß nicht immer aus.

Privacy by Design heißt nicht: niemals Originaldaten

Genau deshalb halte ich die einfache Regel „Produktivdaten gehören grundsätzlich nicht in Testumgebungen“ für zu pauschal.

Privacy by Design bedeutet vielmehr:

Für jeden Test wird bewusst entschieden, welche Datenrealität tatsächlich benötigt wird.

Wenn synthetische Daten ausreichen, sollten keine personenbezogenen Originaldaten kopiert werden.

Wenn Originaldaten erforderlich sind, muss diese Entscheidung nachvollziehbar begründet werden.

Und dann ändern sich die Anforderungen an die Testumgebung.

Originaldaten machen aus „Test“ keinen rechtsfreien Raum

Sobald reale personenbezogene Daten verwendet werden, ist „das ist doch nur Test“ keine ausreichende Sicherheitsstrategie.

Dann sollte unter anderem geklärt sein:

Datenminimierung bedeutet dabei auch, nicht reflexartig den kompletten Bestand bereitzustellen, wenn nur ein Teil davon benötigt wird.

Besonders wichtig: Dienstleister bei Migrationen

Migrationen werden häufig nicht ausschließlich intern durchgeführt.

Softwarehersteller, Implementierungspartner, Cloud-Anbieter, Datenbankspezialisten oder externe Migrationsteams erhalten unter Umständen Zugriff auf produktive Daten.

Spätestens dann reicht eine rein technische Betrachtung nicht mehr.

Vor der Bereitstellung sollte geklärt sein, in welcher Rolle der jeweilige Dienstleister handelt und welche vertragliche Grundlage dafür erforderlich ist.

Handelt ein Dienstleister als Auftragsverarbeiter, gehören insbesondere die Anforderungen an die Auftragsverarbeitung in die Vertragsstruktur. Bei anderen Rollen kann die rechtliche Einordnung anders aussehen. Ein Vertrag zur Auftragsverarbeitung ist deshalb nicht automatisch für jeden beteiligten Dienstleister die richtige Lösung.

Unabhängig von der konkreten Rollenverteilung sollten jedenfalls Fragen geregelt sein wie:

Gerade bei Migrationsprojekten darf diese Vertragsstruktur nicht erst diskutiert werden, nachdem der erste Datenbankdump bereits beim Dienstleister liegt.

Eine Migration muss auditierbar bleiben

Wenn Originaldaten eingesetzt werden, reicht es außerdem nicht, die Umgebung lediglich „abzusichern“.

Die Entscheidung und der Umgang mit den Daten sollten nachvollziehbar und prüfbar sein.

Dazu sollte beispielsweise dokumentiert werden:

Bei prüfungsrelevanten Migrationen kommen technische Nachweise hinzu.

Kontrollsummen, Datensatzanzahlen, Abstimmprotokolle oder definierte Reconciliation-Verfahren können beispielsweise zeigen, dass Ausgangs- und Zielbestand nachvollziehbar miteinander abgeglichen wurden.

Auditierbarkeit ist damit selbst eine Anforderung an das Migrationsdesign.

Zugriff ist nicht gleich Berechtigung für alles

Ein weiterer Klassiker: Das Migrationsteam benötigt Zugriff auf die Datenbank.

Daraus folgt nicht automatisch, dass jede beteiligte Person während der gesamten Projektlaufzeit Zugriff auf sämtliche Daten benötigt.

Berechtigungen können zeitlich, organisatorisch und technisch begrenzt werden.

Gerade bei Dienstleistern sollte nachvollziehbar sein:

Wer konnte wann auf welchen Bestand zugreifen – und warum?

Die Testumgebung sollte damit nicht zur dauerhaft weniger geschützten Kopie der Produktion werden.

Und nach der Migration?

Dieser Punkt wird erstaunlich leicht vergessen.

Für Cut-over-Tests oder prüfungsrelevante Nachweise werden Datenbestände bereitgestellt. Das Projekt geht produktiv. Die Migration ist abgeschlossen.

Und Monate später existiert der damalige Datenbestand immer noch:

Deshalb sollte bereits vor der Bereitstellung festgelegt werden, wann, von wem und wie diese Daten wieder gelöscht werden. Ebenso muss dies dokumentiert werden.

Bestehen Aufbewahrungs- oder Nachweispflichten, kann eine weitere Speicherung erforderlich sein. Dann sollte aber klar definiert sein, welche Daten für welchen Nachweis tatsächlich aufbewahrt werden müssen und wer darauf zugreifen darf.

Entfallen Zweck und gegebenenfalls bestehende Aufbewahrungserfordernisse, muss auch der Testbestand verschwinden.

Und das sollte im Idealfall nicht nur passieren, sondern nachweisbar passieren. Insbesondere dann, wenn Dienstleister Kopien erhalten haben.

Die eigentliche Frage lautet deshalb nicht „echt oder künstlich?“

Synthetische Daten sind kein Selbstzweck.

Originaldaten sind aber auch kein Qualitätsmerkmal für einen besonders realistischen Test.

Die richtige Datenrealität hängt vom Testziel ab.

Für Struktur, Logik, bekannte Sonderfälle und vielfach auch Performance können synthetische Daten sehr weit reichen.

Wenn dagegen der konkrete historische Bestand, seine Vollständigkeit oder seine nachweisbare Überführung geprüft werden muss, können Originaldaten erforderlich sein.

Privacy by Design beginnt deshalb nicht mit einem Verbot.

Es beginnt mit drei Fragen:

1. Welche Realität muss dieser Test tatsächlich abbilden?

2. Welche Daten benötigen wir dafür wirklich?

3. Und wie stellen wir sicher, dass diese Daten nach dem Test nicht einfach bleiben?

Genau dort wird Privacy by Design zur Engineering- und Governance-Aufgabe“