¶ Testdaten, Anonymisierung und Pseudonymisierung
Beispieldokument: Diese Seite ist ein nicht freigegebener Musterprozess für die fiktive „Muster GmbH“. Sie bestätigt weder die Anonymität eines Datenbestands noch die Zulässigkeit realer Test-, Entwicklungs- oder Analyseverfahren.
Vorrang: Synthetische Daten werden bevorzugt. Produktivdaten dürfen nur als begründete, befristete und freigegebene Ausnahme in einer kontrollierten Nichtproduktivumgebung verwendet werden.
Abgrenzung: Pseudonymisierte Daten bleiben personenbezogene Daten. Maskierung oder Entfernung direkter Namen führt nicht automatisch zu anonymen Daten.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | DSGVO-MA-05-06 |
| Dokumentenart | Musterverfahren für Testdaten, Anonymisierung und Pseudonymisierung |
| Wiki.js-Pfad | /DSGVO/05-Risiken-DSFA-und-TOM/Testdaten-Anonymisierung-und-Pseudonymisierung |
| Verantwortlich | festzulegender Entwicklungs-, Test-, Analyse- oder Prozesseigner |
| Fachlich geprüft durch | Datenschutzbeauftragte/r, sofern benannt, Datenschutzkoordination, Informationssicherheit, IT, Entwicklung, Recht und betroffene Fachrollen |
| Freigabe durch | Geschäftsführung beziehungsweise dokumentierte befugte Leitung oder delegierte befugte Rolle |
| Status | Entwurf – Datenklassen, Verfahren, Umgebungen, Prüfmethoden und Freigaben nicht organisationsbezogen umgesetzt |
| Version | 0.1 |
| Stand | 08.08.2026 |
| Gültig ab | Nach Anpassung, technischer Erprobung, fachlicher Prüfung und formaler Freigabe |
| Nächste Prüfung | Mindestens jährlich sowie bei neuen Daten, Angriffsmitteln, Empfängern, Verfahren oder Technikänderungen |
| Schutzklasse | Intern; reale Datensätze, Zuordnungstabellen, Schlüssel, Transformationen und Reidentifizierungstests streng geschützt |
| DSGVO-Bezug | Erwägungsgründe 26, 28, 29, 75 und 78 sowie Artikel 4 Nummer 5, 5, 6, 25, 32, 35 und 89 DSGVO |
| Schnittstellen | Privacy by Design, VVT, DSFA, TOM, sichere Entwicklung, Berechtigungen, Löschung, Lieferanten und Vorfälle |
Testdaten werden nach dem geringstmöglichen Personenbezug ausgewählt, technisch geschützt, kontrolliert genutzt und nach Zweckende gelöscht. Eigene redaktionelle SVG-Grafik. Zum Vergrößern öffnen.
¶ 1. Zweck
Das Verfahren schützt Personen bei Entwicklung, Test, Schulung, Fehleranalyse, Migration, Forschung und Datenanalyse. Es legt fest, wann synthetische, anonymisierte, pseudonymisierte oder ausnahmsweise produktive Daten verwendet werden dürfen und welche Prüfungen dafür notwendig sind.
Die Auswahl orientiert sich an Zweck, Erforderlichkeit, Angriffsmöglichkeiten, Datenumfang, Umgebung, Empfängern, Dauer und Folgen einer Reidentifizierung.
¶ 2. Verbindliche Begriffsabgrenzung
| Datenart | Datenschutzrechtliche Einordnung | Konsequenz |
|---|---|---|
| synthetisch | künstlich erzeugt; nur dann ohne Personenbezug, wenn keine reale Person abgebildet oder rekonstruierbar ist | bevorzugte Testdatenart; Herkunft und Generierung prüfen |
| anonymisiert | Personenbezug ist unter Berücksichtigung aller vernünftigerweise einsetzbaren Mittel dauerhaft aufgehoben | DSGVO findet auf den anonymen Bestand nicht Anwendung; Bewertung und Kontext bleiben zu dokumentieren |
| pseudonymisiert | ohne gesonderte Zusatzinformationen nicht einer Person zuordenbar; Zusatzinformationen getrennt und geschützt | bleibt personenbezogen; alle einschlägigen DSGVO-Pflichten gelten weiter |
| maskiert / verändert | einzelne Werte wurden verborgen, ersetzt, verkürzt oder vertauscht | Einordnung hängt vom Gesamtbestand, Kontext und Reidentifizierungsrisiko ab |
| produktiv | reale, für den Fachzweck erhobene personenbezogene Daten | in Nichtproduktivumgebungen nur begründete und freigegebene Ausnahme |
Eine Methode wird nicht allein aufgrund ihrer Bezeichnung als anonym oder pseudonym eingestuft.
¶ 3. Auswahlhierarchie
Für jeden Bedarf wird in dieser Reihenfolge geprüft:
- Kann ohne personenbezogene Daten getestet oder analysiert werden?
- Können geeignete synthetische Daten erzeugt werden?
- Kann ein nachweislich anonymer Bestand den Zweck erfüllen?
- Reichen pseudonymisierte und minimierte Daten aus?
- Sind reale Produktivdaten ausnahmsweise unverzichtbar und rechtlich wie technisch vertretbar?
Eine niedrigere Stufe wird nur mit dokumentierter Begründung übersprungen.
¶ 4. Auslöser
- neue Entwicklungs-, Test-, Schulungs- oder Analysevorhaben,
- Fehleranalyse mit Export oder Datenbankkopie,
- Migration, Schnittstellen- oder Releaseprüfung,
- Forschung, Statistik, Modelltraining oder Qualitätsbewertung,
- Bereitstellung an externe Entwickler, Dienstleister oder Cloud-Plattformen,
- Änderung von Datenumfang, Transformationsverfahren oder Angriffsmöglichkeiten,
- Verdacht, dass ein bislang als anonym behandelter Bestand reidentifizierbar ist.
¶ 5. Antrag und Registerfelder
| Feld | Mindestinhalt |
|---|---|
| TD-ID | eindeutige Kennung, zum Beispiel TD-YYYY-NNN |
| Zweck / Testfall | konkrete Aufgabe und erforderliche Aussage |
| VVT / Projekt | Verarbeitung, Produkt, System und Änderung |
| Datenbedarf | benötigte Felder, Merkmale, Volumen, Aktualität und Sonderfälle |
| gewählte Datenart | synthetisch, anonym, pseudonym oder begründete Produktivausnahme |
| Herkunft | Quelle, Erhebungszweck und ursprüngliche Rechtsgrundlage |
| Transformation | Methode, Parameter, Ausnahmen und Qualitätsgrenzen |
| Umgebung / Empfänger | Systeme, Standorte, Rollen, Dienstleister und Drittlandzugriffe |
| Schutzmaßnahmen | Trennung, Zugriff, Verschlüsselung, Protokollierung und Exportkontrolle |
| Reidentifizierungsprüfung | Angreifer, Mittel, Kriterien, Ergebnis und Restrisiko |
| Dauer / Löschung | Bereitstellung, Ablauf, Kopien, Nachweis und Owner |
| Freigabe / Review | prüfende Rollen, Entscheidung, Bedingungen und nächste Prüfung |
¶ 6. Synthetische Daten
Synthetische Testdaten werden so erzeugt, dass sie fachliche Grenzfälle, Formate, Beziehungen und Lasten abbilden, ohne reale Personen zu reproduzieren. Zu prüfen sind:
- Herkunft der Trainings-, Muster- oder Seed-Daten,
- unbeabsichtigte Übernahme realer Werte oder seltener Kombinationen,
- Qualität für positive, negative und Grenztests,
- Kennzeichnung, damit synthetische Daten nicht produktiv genutzt werden,
- Generierungslogik, Version und Wiederholbarkeit,
- sichere Löschung temporärer Quell- und Zwischendaten.
Auch synthetisch erzeugte Daten können personenbezogen sein, wenn reale Personen erkennbar rekonstruiert werden.
¶ 7. Anonymisierung bewerten
Die Bewertung betrachtet nicht nur direkte Identifikatoren, sondern den vollständigen Datensatz und den Nutzungskontext. Dokumentiert werden insbesondere:
- mögliche Angreifer und ihr Zusatzwissen,
- verfügbare öffentliche, interne und kommerzielle Datenquellen,
- Kosten, Zeit, Technik und organisatorische Zugänge,
- seltene Merkmalskombinationen und kleine Gruppen,
- Herausgreifen einzelner Personen,
- Verknüpfung mit anderen Datensätzen,
- Ableitung sensibler oder personenbezogener Informationen,
- Veränderungen über Zeit und neue Reidentifizierungsmittel.
Das Ergebnis kann anonym, weiterhin personenbezogen oder Bewertung offen lauten. Bei Unsicherheit wird der Bestand als personenbezogen behandelt.
¶ 8. Status aktueller EDSA-Leitlinien
Die EDSA-Leitlinien 01/2025 zur Pseudonymisierung befinden sich nach der Konsultation noch im Finalisierungsprozess. Die Leitlinien 02/2026 zur Anonymisierung sind zum Seitenstand ein Konsultationsentwurf. Sie sind hilfreiche fachliche Orientierung, werden hier aber nicht als finale verbindliche Vorgabe dargestellt.
Vor einer organisationsbezogenen Freigabe werden Finalstatus, Fassung, zuständige Aufsichtspraxis und technische Entwicklung erneut geprüft.
¶ 9. Pseudonymisierung gestalten
Eine wirksame Pseudonymisierung umfasst mehr als das Ersetzen eines Namens:
- direkte und indirekte Identifikatoren analysieren,
- Pseudonym oder Token mit geeigneter Entropie erzeugen,
- Zuordnungstabelle, Schlüssel oder Zusatzwissen strikt trennen,
- Zugriff auf Zuordnungswissen besonders beschränken und protokollieren,
- Schlüsselverwaltung, Rotation, Sperrung und Wiederherstellung regeln,
- unzulässige Verknüpfung zwischen Zwecken oder Mandanten verhindern,
- Datenminimierung, Aggregation und Bereichsbildung ergänzen,
- Reidentifizierung nur für bestimmte Zwecke, Rollen und Verfahren erlauben,
- Weitergabe, Empfängerwissen und Rückgabe-/Löschpflichten berücksichtigen.
Das Restrisiko hängt auch davon ab, wer auf Daten und Zusatzinformationen zugreifen kann.
¶ 10. Produktivdaten als Ausnahme
Produktivdaten in Test-, Entwicklungs-, Schulungs- oder Demo-Umgebungen erfordern mindestens:
- nachgewiesene fachliche Notwendigkeit und fehlende mildere Alternative,
- bestätigten Zweck und tragfähige Rechtsgrundlage,
- Datenminimierung auf Testfall, Felder, Personen, Zeitraum und Menge,
- Risiko- und gegebenenfalls DSFA-Prüfung,
- dokumentierte Freigabe durch befugte Rollen,
- getrennte, gehärtete Umgebung mit produktionsnahem Schutz,
- eingeschränkte und befristete Berechtigungen,
- Verbot unkontrollierter Exporte, Screenshots und lokaler Kopien,
- Ablaufdatum, Löschung und anschließende Kontrolle.
Zeitdruck, fehlende Testdatengeneratoren oder Bequemlichkeit genügen nicht als Begründung.
¶ 11. Umgebungs- und Zugriffsschutz
- strikte Trennung von Entwicklung, Test, Abnahme und Produktion,
- rollenbasierte Berechtigungen und regelmäßiger Entzug,
- Verschlüsselung bei Übertragung und Speicherung,
- kontrollierte Schnittstellen, Downloads, Zwischenablagen und Exporte,
- Protokollierung von Bereitstellung, Zugriff, Reidentifizierung und Löschung,
- sichere Endgeräte, Remotezugriffe und Administrationswege,
- keine realen personenbezogenen Daten in Tickets, Quellcode, Chat, Screenshots oder Telemetrie,
- sichere Fehlerbehandlung ohne Offenlegung vollständiger Datensätze,
- Vorfall- und Rückrufverfahren für fehlerhaft bereitgestellte Testdaten.
¶ 12. Dienstleister und Cloud
Vor einer Bereitstellung werden Rolle, Vertrag, Weisung, Unterauftragnehmer, Speicher- und Supportorte, Drittlandtransfer, Rückgabe, Löschung und Nachweis geprüft. Eine öffentlich erreichbare Demo oder ein kostenloser Cloud-Dienst ist keine kontrollierte Testumgebung.
Externe Empfänger erhalten nur den minimal erforderlichen Bestand und keinen Zugriff auf Zuordnungswissen, sofern dies nicht ausdrücklich erforderlich, rechtmäßig und geschützt ist.
¶ 13. Test, Abnahme und Reidentifizierungsprüfung
Prüfungen umfassen risikobasiert:
- Erkennen direkter Identifikatoren und versteckter Metadaten,
- Eindeutigkeit, seltene Kombinationen und kleine Gruppen,
- Verknüpfung mit verfügbaren internen und externen Quellen,
- Rückschluss auf Eigenschaften oder Zugehörigkeit,
- Zugriff auf Schlüssel, Mapping und Quellbestände,
- fachliche Aussagekraft und Verfälschungsrisiko der Transformation,
- Wiederholbarkeit, Version und Geltungsbereich der Bewertung.
Prüfungen dürfen selbst keine unnötige Reidentifizierung oder neue unkontrollierte Kopie erzeugen. Kritische Ergebnisse werden geschützt behandelt und eskaliert.
¶ 14. Ablauf, Rückgabe und Löschung
Jede Bereitstellung erhält ein Ablaufdatum. Nach Zweckende werden Datensätze, Exporte, temporäre Dateien, Snapshots, Tickets, lokale Kopien und Dienstleisterbestände gelöscht oder kontrolliert zurückgegeben.
Die Löschung folgt dem Lösch- und Aufbewahrungskonzept. Der Nachweis nennt Umfang, Systeme, Zeitpunkt, Ergebnis und Abweichungen, ohne den gelöschten Bestand erneut zu speichern.
¶ 15. Rollen
| Rolle | Aufgabe |
|---|---|
| Bedarfsträger / Testowner | Zweck, Testfall, Datenbedarf und Laufzeit begründen |
| Daten-/Prozesseigner | Quelle, Qualität, Zweckbindung und Freigabe verantworten |
| Datenschutzkoordination | Einordnung, Register, Rechts- und DSFA-Schnittstellen koordinieren |
| Datenschutzbeauftragte/r | beraten und überwachen, sofern benannt |
| Informationssicherheit | Umgebung, Bedrohungen, Zugriff und Reidentifizierungsrisiko bewerten |
| Entwicklung / Data Engineering | Transformation kontrolliert umsetzen und dokumentieren |
| IT-Betrieb | Bereitstellung, Protokollierung, Ablauf und Löschung durchführen |
| Einkauf / Lieferantenmanagement | Verträge, Empfänger, Transfers und Exit steuern |
¶ 16. Nachweise und Schutz
Geschützt aufbewahrt werden Antrag, Datenprofil, Transformationsparameter, Quell- und Zielsysteme, Schlüsselkonzept, Reidentifizierungsprüfung, Freigabe, Zugriffsprotokolle, Löschung und Abweichungen. Das öffentliche Wiki enthält keine realen Testdaten, Zugangsdaten, Zuordnungstabellen oder Angriffsergebnisse.
¶ 17. Leeres Testdatenregister
| TD-ID | Projekt / VVT | Zweck | Datenart | Umgebung / Empfänger | Transformation / Trennung | Risiko / DSFA | Freigabe | Ablauf / Löschung | Review |
|---|---|---|---|---|---|---|---|---|---|
| – | – | – | – | – | – | – | Kein realer Eintrag im Muster-Wiki | – | – |
¶ 18. Qualitätskontrolle
- Wurde zuerst eine Lösung ohne personenbezogene Daten geprüft?
- Sind synthetische Daten fachlich ausreichend und ohne reale Personenbezüge?
- Ist die Einordnung anonym/pseudonym anhand des Gesamtbestands und Kontextes begründet?
- Werden Zuordnungswissen und Schlüssel wirksam getrennt und geschützt?
- Sind Produktivausnahmen erforderlich, minimal, befristet und befugt genehmigt?
- Sind Umgebungen, Berechtigungen, Exporte und Dienstleister kontrolliert?
- Wurden Reidentifizierungswege und neue Datenquellen berücksichtigt?
- Werden Kopien nach Zweckende vollständig gelöscht und geprüft?
- Löst eine Änderung von Daten, Verfahren oder Empfänger einen Review aus?
¶ 19. Verknüpfte Seiten
| Seite | Funktion |
|---|---|
| Privacy by Design und by Default | frühzeitige Anforderungen und Projekt-Gates |
| Technische und organisatorische Maßnahmen | Schutzmaßnahmen und Wirksamkeitsprüfung |
| Datenschutz-Folgenabschätzung | vertiefte Prüfung hoher Risiken |
| Lösch- und Aufbewahrungskonzept | Ablauf und Löschung der Testbestände |
| Besondere Kategorien und Strafdaten | erhöhte Anforderungen an sensible Daten |
| ISMS Sichere Entwicklung | Entwicklungs-, Test- und Freigabekontrollen |
| ISMS Kryptografie und Schlüssel | Schlüssel- und Geheimnisschutz |
¶ 20. Offizielle Grundlagen
- DSGVO, insbesondere Erwägungsgründe 26, 28 und 29 sowie Artikel 4 Nummer 5, 25, 32 und 89 – EUR-Lex
- EDSA-Leitlinien 01/2025 zur Pseudonymisierung – Konsultationsfassung; Finalstatus vor Nutzung prüfen
- EDSA-Leitlinien 02/2026 zur Anonymisierung – laufende Konsultation bis 30.10.2026
- Datenschutzkonferenz: Standard-Datenschutzmodell Version 3.1
¶ 21. Weiterführende Informationen von SMCT MANAGEMENT
Unterstützung bei Testdatenkonzepten, Pseudonymisierung, Datenschutzrisiken und kontrollierten Nachweisen
Erstgespräch unter info@smct-management.de vereinbaren
¶ 22. Änderungshistorie
| Version | Datum | Änderung | Erstellt/geändert durch | Freigabe |
|---|---|---|---|---|
| 0.1 | 08.08.2026 | Musterverfahren mit Auswahlhierarchie, klarer Datenartabgrenzung, Testdatenregister, Reidentifizierungsprüfung, Produktivausnahme, Umgebungs- und Löschkontrollen erstellt | Datenschutzkoordination / Musterrolle | Ausstehend |