Echtdaten im Softwaretest: Zweckbindung und Testlöschung

Produktive Echtdaten wirken im Softwaretest bequem, weil sie reale Abläufe abbilden. Für die Verarbeitung in Entwicklung, Qualitätssicherung oder Staging braucht das Unternehmen trotzdem einen eigenen Zweck, einen begrenzten Datenumfang und kontrollierte Zugriffe. Die Übernahme aus der Produktionsumgebung darf keine pauschale Routine werden.

Dieser Beitrag erklärt, wie Unternehmen Testdaten auswählen, personenbezogene Angaben reduzieren oder pseudonymisieren, externe Umgebungen prüfen und das Testende dokumentieren. Im Mittelpunkt stehen Zweckbindung, Datenminimierung, Sicherheit und Löschung nach Art. 5, Art. 25 und Art. 32 DSGVO. Allgemeine TOM-Dokumentation, Beschäftigtendaten im Produktivbetrieb und eine eigene DSFA für KI sind davon getrennte Fragen.

Art. 5 Abs. 1 lit. b DSGVO verlangt eine Verarbeitung für festgelegte, eindeutige und legitime Zwecke. Ein Unternehmen muss daher erklären können, welche Funktion getestet wird und warum dafür personenbezogene Echtdaten gebraucht werden. „Für die Entwicklung“ beschreibt den Vorgang allein noch nicht ausreichend. Ein konkreter Fehlerfall, ein Abgleich von Schnittstellen oder ein Migrationstest führt zu unterschiedlichen Datenbedarfen.

Die Übernahme in eine Testumgebung ist ein eigener Verarbeitungsschritt. Die Rechtsgrundlage der Produktion trägt diesen Schritt nicht automatisch, wenn sich Zweck, Empfängerkreis, Schutzmaßnahmen oder Erwartung der betroffenen Personen ändern. Prüfen Sie den Testzweck deshalb zusammen mit der ursprünglichen Verarbeitung und der Information der betroffenen Personen.

Art. 6 DSGVO verlangt eine tragfähige Rechtsgrundlage. Für besondere Kategorien nach Art. 9 DSGVO gelten zusätzliche Anforderungen. Eine technische Bequemlichkeit ersetzt weder Zweckbindung noch Erforderlichkeit. Der bestehende Beitrag zur Prüfung neuer Software vor dem Rollout behandelt die vorgelagerte Risikofrage bei neuen Technologien und bleibt vom konkreten Umgang mit Testdaten abgrenzbar.

Art. 5 Abs. 1 lit. c DSGVO begrenzt personenbezogene Daten auf das für die Zwecke der Verarbeitung notwendige Maß. Für einen Test braucht das Team häufig einzelne realistische Fallkonstellationen, aber keinen vollständigen Produktionsbestand. Prüfen Sie Felder, Datensätze, Zeiträume und Statuswerte einzeln. Entfernen Sie Angaben, die für die konkrete Funktion keine Rolle spielen.

Synthetische Daten können die bessere Lösung sein, wenn sich der Testfall damit zuverlässig nachbilden lässt. Reichen sie nicht aus, kommen Maskierung, Generalisierung oder Pseudonymisierung in Betracht. Pseudonymisierte Daten bleiben personenbezogene Daten, wenn eine Zuordnung mit Zusatzinformationen möglich ist. Die Schutzmaßnahme verbessert die Risikolage, ersetzt aber keine Rechtsgrundlage und keine Zugriffskontrolle.

Dokumentieren Sie, wer die Auswahl getroffen hat, welche Felder entfernt oder verändert wurden und warum einzelne Werte erhalten bleiben. Ein wiederholbarer Export mit festgelegten Regeln ist kontrollierbarer als ein manueller Datenbankabzug. Bei jeder neuen Testversion muss geprüft werden, ob zusätzliche Felder oder Datensätze in die Umgebung gelangen.

Eine Testumgebung ist kein rechtsfreier Zwischenbereich. Art. 25 DSGVO verlangt Datenschutz durch Gestaltung und durch datenschutzfreundliche Voreinstellungen. Art. 32 DSGVO fordert ein dem Risiko angemessenes Sicherheitsniveau. Trennen Sie Test und Produktion technisch, organisatorisch und bei den Administrationskonten. Ein Entwickler braucht für die Fehlersuche nicht automatisch Zugriff auf alle Felder.

Erfassen Sie die Rollen von Entwicklung, Qualitätssicherung, Fachabteilung, externem Support und Systemadministration. Legen Sie fest, welche Angaben jede Rolle sehen darf, wie lange der Zugriff besteht und ob Aktivitäten protokolliert werden. Prüfen Sie auch unbemerkte Kopien in lokalen Arbeitsplätzen, Tickets, Screenshots, Logs und Exportordnern.

Besonders sensibel sind Testdaten mit Gesundheitsangaben, Finanzinformationen, Zugangsdaten oder Daten von Kindern. Für diese Daten kann ein reduzierter und stärker geschützter Testbestand erforderlich sein. Die Dokumentation technischer und organisatorischer Maßnahmen ist dabei eine Ergänzung. Sie ersetzt nicht die konkrete Prüfung der Testumgebung.

Viele Tests laufen bei einem Cloud- oder Softwareanbieter. Klären Sie, ob der Anbieter als Auftragsverarbeiter nach Art. 28 DSGVO handelt oder für einzelne Zwecke selbst entscheidet. Der Vertrag sollte Testdaten, Support, Unterauftragnehmer, Speicherorte, Zugriffsmöglichkeiten und Löschung ausdrücklich abbilden. Eine allgemeine Zusage zur Sicherheit beantwortet die konkrete Testkonstellation nicht.

Erfassen Sie Datenflüsse vom Produktionssystem über den Export bis zur Testinstanz. Dazu gehören Zwischenspeicher, Backups, Monitoring, Fehlermeldungen, Supporttickets und Kopien beim Anbieter. Ein Supportzugriff aus einem Drittland kann zusätzlich eine Prüfung nach Kapitel V DSGVO auslösen. Standortangaben allein zeigen noch nicht, wer auf die Daten zugreifen kann.

Die Rollenprüfung bei SaaS-Verträgen hilft bei der Zuordnung von Verantwortlichem und Auftragsverarbeiter. Für den Softwaretest bleibt außerdem entscheidend, ob die vertraglich zugesagten Lösch- und Zugriffsbeschränkungen praktisch eingerichtet und überprüft werden.

Art. 5 Abs. 1 lit. e DSGVO verlangt eine Speicherbegrenzung. Ein Test darf deshalb nicht auf unbestimmte Zeit weiterlaufen, nur weil die Umgebung technisch bestehen bleibt. Legen Sie vor dem Export ein Testende oder ein auslösendes Ereignis fest. Bei einem mehrstufigen Projekt braucht jeder Testbestand einen eigenen Verantwortlichen und eine nachvollziehbare Löschentscheidung.

Die Löschung muss alle relevanten Kopien erfassen: Datenbank, Dateisystem, Exporte, lokale Arbeitskopien, Tickets, Screenshots, Protokolle und Anbieterumgebungen. Für Backups gelten je nach System und Wiederherstellungslogik besondere Fragen. Sie dürfen die Prüfung der aktiven Testumgebung nicht ersetzen. Art. 17 DSGVO ist zu berücksichtigen, wenn ein Löschbegehren oder ein Wegfall des Zwecks die weitere Speicherung betrifft.

Ein belastbarer Nachweis nennt Bestand, Löschmethode, Zeitpunkt, verantwortliche Person und Ergebnis. Der Nachweis selbst soll nur jene Informationen enthalten, die für Rechenschaft und Kontrolle erforderlich sind. Testen Sie den Rückbau regelmäßig mit einer ungefährlichen Kopie oder einem kontrollierten Testfall, damit die Löschroutine nicht erst im Ernstfall auffällt.

Art. 5 Abs. 2 DSGVO verlangt, dass der Verantwortliche die Einhaltung der Grundsätze nachweisen kann. Art. 24 DSGVO verbindet diese Verantwortung mit geeigneten Maßnahmen und einer Überprüfung ihrer Wirksamkeit. Die Freigabeakte sollte deshalb Zweck, Rechtsgrundlage, Datenkategorien, Auswahlregel, Empfänger, Umgebung, Rollen, Schutzmaßnahmen, Testende und Löschprüfung zusammenführen.

Ergänzen Sie die einschlägigen Aufzeichnungen im Verzeichnis der Verarbeitungstätigkeiten nach Art. 30 DSGVO, wenn der Test einen eigenen Verarbeitungsvorgang oder eine relevante Änderung darstellt. Änderungen am Datenumfang, ein neuer Anbieter, ein längerer Zeitraum oder zusätzliche Nutzer lösen eine neuerliche Prüfung aus.

Eine Datenschutz-Folgenabschätzung nach Art. 35 DSGVO kann bei voraussichtlich hohem Risiko erforderlich sein. Dieser Beitrag beantwortet die engere Frage, wie Echtdaten in einem Softwaretest begrenzt und gelöscht werden. Die Risikoprüfung bleibt daneben bestehen und darf durch eine kurze Testfreigabe nicht ersetzt werden.

Der Produktionsabzug wird vollständig übernommen: Für einen einzelnen Testfall gelangen unnötige Felder, alte Datensätze und sensible Anhänge in die Testumgebung.

Der Testzweck bleibt allgemein: „Entwicklung“ oder „Qualitätssicherung“ erklärt nicht, welche Funktion geprüft wird und warum Personenbezug erforderlich ist.

Pseudonymisierung wird mit Anonymisierung verwechselt: Eine Zuordnung über Schlüssel oder Zusatzinformationen bleibt möglich, die DSGVO gilt weiter.

Entwicklerkonten werden pauschal freigeschaltet: Test-, Produktions- und Administrationszugriffe sind nicht sauber getrennt.

Der Anbieter wird nur nach seinem Standort beurteilt: Support, Unterauftragnehmer, Logs und Fernzugriffe bleiben ungeprüft.

Das Testende ist ein Kalendervermerk ohne Löschkontrolle: Kopien, Exporte und Backups werden nicht erfasst oder der Nachweis bleibt unklar.

Beginnen Sie mit einer kurzen Prozessbeschreibung. Welche Funktion wird geprüft, welche Fehlerkonstellation soll reproduziert werden und welche Datenfelder sind dafür zwingend nötig? Entscheiden Sie danach zwischen synthetischen Daten, reduzierten Echtdaten und einer pseudonymisierten Auswahl. Begründen Sie den verbleibenden Personenbezug.

Prüfen Sie vor dem Export die Rechtsgrundlage, die Information der betroffenen Personen, die Empfänger und die Anbieterrolle. Legen Sie Rollen, Zugriffsrechte, Protokollierung, Speicherort und Übertragungsweg fest. Kontrollieren Sie, dass die Testumgebung keine Verbindung mit der Produktionsumgebung öffnet, die über den vorgesehenen Zweck hinausgeht.

Vor dem Start müssen Testende, Löschung und Verantwortlichkeit feststehen. Nach dem Rückbau kontrollieren Sie aktive Systeme und bekannte Kopien. Bewahren Sie nur einen schlanken Nachweis auf. Bei einer Änderung des Tests wiederholen Sie die Prüfung, bevor zusätzliche Daten kopiert werden.

Wir prüfen Testzweck, Datenumfang, Rechtsgrundlage, Pseudonymisierung, Rollen, Anbieter, Zugriffe, Testende und Löschkontrolle gemeinsam. Für die erste Einschätzung helfen die Beschreibung der zu prüfenden Funktion, der geplante Export, die Systemübersicht, Anbieterunterlagen und der Löschplan. So lässt sich entscheiden, welche Daten für den Test wirklich erforderlich sind und wie der Rückbau nachweisbar gelingt.