Datenschutzfördernde Technologien für ISO 27701 und GDPR

Sarah, CISO eines schnell wachsenden Fintech-Unternehmens, wusste bereits vor Beginn der Besprechung, welche Anfrage kommen würde.

Das Produktteam wollte eine KI-gestützte Finanzberatungsfunktion einführen. Das Modell benötigte realistisches Kundenverhalten, Transaktionsmuster, Supportereignisse und Abonnementhistorien. Das Data-Science-Team argumentierte, dass das Modell mit Produktionsdaten bessere Ergebnisse liefern würde. Das Qualitätssicherungsteam wollte produktionsnahe Zahlungsdatensätze, um Randfälle nachstellen zu können. Ein Cloud-Analytics-Anbieter benötigte einen Beispieldatenbestand zur Validierung der Log-Ingestion. Niemand wollte Datenschutzrecht verletzen. Niemand wollte Kunden exponieren. Alle wollten schnell vorankommen.

Dann stellte Sarah die Frage, die die Besprechung veränderte.

„Warum benötigt ihr identifizierbare PII?“

Der Raum wurde still.

Genau hier scheitern viele Datenschutzmanagementsysteme in der Praxis. Die Organisation verfügt möglicherweise über einen Datenschutzhinweis, eine Datenschutzrichtlinie, eine DPIA-Vorlage und einen rechtlichen Prüfprozess, aber die tatsächliche Entscheidung fällt in einem Slack-Thread, einem Jira-Ticket, einem Analytics-Export oder einem Datenbankklon. Wenn die einzige Datenschutzkontrolle „Legal fragen“ lautet, kommt das Geschäft entweder zum Stillstand oder es werden Abkürzungen genommen.

Datenschutzfördernde Technologien, meist PETs genannt, schließen diese Lücke, wenn sie als operatives Kontrollset behandelt werden und nicht als Forschungsthema. Unter den PIMS-Erwartungen nach ISO/IEC 27701:2025 und den Verpflichtungen aus GDPR reduzieren PETs wie Datenmaskierung, Pseudonymisierung, Anonymisierung, Aggregation, Tokenisierung, Verschlüsselung und synthetische Daten die Identifizierbarkeit, ohne den geschäftlichen Nutzen zu verlieren. Sie machen aus „Nein, diese Daten dürfen nicht verwendet werden“ ein „Ja, wenn ihr die sichere Version nutzt und dokumentierte Nachweise vorliegen“.

Der Ansatz von Clarysec ist genau für diesen Moment konzipiert. Die Zenith Blueprint: 30-Schritte-Roadmap für Auditoren verankert Datenmaskierung in der Phase Controls in Action, Schritt 19: Technologische Maßnahmen I, und Testinformationen in Schritt 21: Kontrollen 8.27 bis 8.34. PETs sind keine kosmetischen Datenschutzfunktionen. Sie sind Kontrollen, die Auditoren prüfen, Entwickler umsetzen und das Management steuern kann.

Wie es der Zenith Blueprint formuliert:

Bei Datenmaskierung geht es nicht darum, Informationen vor Angreifern zu verstecken, sondern darum, unnötige Exponierung innerhalb der Organisation zu verhindern. In Szenarien wie Entwicklung, Tests, Schulung oder Analytics werden echte Produktionsdaten häufig in Umgebungen kopiert, denen die vollständigen Sicherheitskontrollen der Produktion fehlen.

Dieser eine Satz beschreibt die betriebliche Realität moderner Datenschutzrisiken. Die gefährlichste Exponierung von PII ist häufig keine dramatische externe Datenschutzverletzung. Es ist die interne Kopie, die Testdatenbank, der KI-Trainingsextrakt, das Lieferantenbeispiel, das vergessene Debug-Protokoll und das Analytics-Dashboard, das mehr offenlegt, als irgendjemand beabsichtigt hatte.

PETs machen Datenschutz durch Technikgestaltung zu operativen Nachweisen

GDPR Article 25 verlangt Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen. GDPR Article 32 verlangt geeignete technische und organisatorische Maßnahmen, einschließlich Pseudonymisierung und Verschlüsselung, soweit angemessen. GDPR Article 5 verlangt Rechtmäßigkeit, Fairness, Transparenz, Zweckbindung, Datenminimierung, Richtigkeit, Speicherbegrenzung, Integrität, Vertraulichkeit und Rechenschaftspflicht.

PETs sind der Punkt, an dem diese rechtlichen Grundsätze zu technischen Entscheidungen werden.

Eine datenschutzfördernde Technologie ist jeder technische oder organisatorische Mechanismus, der Datenschutzrisiken reduziert, indem er Exponierung, Identifizierbarkeit, Verknüpfbarkeit oder missbräuchliche Nutzung personenbezogener Daten begrenzt. In einem an ISO/IEC 27701:2025 ausgerichteten PIMS sollten PETs mit klaren Rollen, Datenschutz-Risikobehandlung, Verarbeitungsaufzeichnungen, Lieferantenkontrollen, Zugriffsbeschränkungen, Aufbewahrungsentscheidungen und Nachweisen verknüpft sein.

Für Verantwortliche helfen PETs nachzuweisen, dass die Organisation Datenminimierung, datenschutzfreundliche Voreinstellungen und Schutzmaßnahmen für Weiterverarbeitungen berücksichtigt hat. Für Auftragsverarbeiter helfen PETs darzulegen, dass Kundenweisungen sicher umgesetzt, die Exponierung gegenüber Unterauftragsverarbeitern reduziert und die Cloud-Verarbeitung von PII geschützt wird. Für gemeinsam Verantwortliche und Unterauftragsverarbeiter helfen PETs zu klären, wer Re-Identifizierungsschlüssel kontrolliert, wer Annahmen zur De-Identifizierung genehmigt und wer nutzbare Datenbestände erhalten darf.

Die Richtlinie zu Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen von Clarysec macht dies sowohl für Verantwortliche als auch für Auftragsverarbeiter operativ:

[Beide] Der Prozessverantwortliche / Geschäftsinhaber MUSS die Machbarkeit von De-Identifizierung, Pseudonymisierung, Aggregation oder nicht identifizierbarer Verarbeitung in REG04 dokumentieren, bevor identifizierbare PII für Tests, Analytics, Reporting oder sekundäre betriebliche Nutzung genehmigt wird.

Diese Klausel verändert das Gespräch. Der Geschäftsinhaber beginnt nicht mit der Anfrage nach einer Datenbankkopie. Er beginnt damit, den Geschäftszweck, die minimal benötigten Daten und die Begründung zu dokumentieren, warum eine risikoärmere Form funktioniert oder nicht funktioniert.

Das ist der Managementschritt, der PETs belastbar macht. Bevor identifizierbare PII genehmigt wird, muss die Organisation darlegen, warum Aggregation, synthetische Daten, Maskierung, Pseudonymisierung oder Anonymisierung nicht ausreichen.

Die PETs, die in Audits am wichtigsten sind

Nicht jede PET passt zu jedem Szenario. Ein wirksames Programm für Privacy Engineering benötigt eine praxistaugliche Taxonomie, die Fachbereiche, Engineering, Datenschutz, Informationssicherheit und Audit gleichermaßen verstehen.

Die P16 – Richtlinie zur Datenmaskierung und Pseudonymisierung definiert PETs unmittelbar anhand des Datenschutzrisikos:

Diese Richtlinie legt den Ansatz der Organisation zur Umsetzung von Datenmaskierung und Pseudonymisierung als datenschutzfördernde Technologien (PETs) fest, um die Identifizierbarkeit und Exponierung personenbezogener oder sensibler Daten zu reduzieren.

Für kleinere Organisationen bildet Clarysec denselben Kontrollzweck in einem schlankeren Betriebsmodell ab. Die P16S – Richtlinie zur Datenmaskierung und Pseudonymisierung – KMU stellt fest:

Diese Richtlinie legt verbindliche Anforderungen für den Einsatz von Datenmaskierung und Pseudonymisierung zum Schutz sensibler, personenbezogener und vertraulicher Daten in kleinen und mittleren Unternehmen (KMU) fest.

Das Prinzip ist Verhältnismäßigkeit. Ein multinationales Unternehmen kann Enterprise-Tokenisierung, Data Loss Prevention (DLP), getrennte Schlüsselablagen und Prüfungsgremien für Privacy Engineering einsetzen. Ein KMU kann mit freigegebenen Maskierungsskripten, eingeschränkten Token-Tabellen und dokumentierten Genehmigungen beginnen. Beide müssen nachweisen können, dass Datenschutzrisiken berücksichtigt, behandelt und belegt wurden.

Warum ISO/IEC 27701:2025 ein ISO/IEC 27001:2022-Fundament benötigt

ISO/IEC 27701:2025 erweitert Datenschutz-Governance zu einem Datenschutz-Informationsmanagementsystem, aber Datenschutzkontrollen funktionieren nicht isoliert. Sie hängen vom darunterliegenden Informationssicherheitsmanagementsystem ab.

ISO/IEC 27001:2022 verlangt, dass Organisationen Kontext, Anforderungen interessierter Parteien, Geltungsbereich, Schnittstellen und Abhängigkeiten verstehen und anschließend das ISMS einrichten und kontinuierlich verbessern. Die Planungsanforderungen schaffen wiederholbare Risikobeurteilung, Risikobehandlung, eine Anwendbarkeitserklärung und Restrisikoakzeptanz. Für PETs bedeutet das: Kontrollen sollten nicht ausgewählt werden, weil „Datenschutz sie will“. Sie sollten ausgewählt werden, weil die Risikobeurteilung zeigt, dass sie Vertraulichkeits-, Datenschutz-, Test-, Analytics-, Lieferanten- oder Cloud-Exponierung reduzieren.

Der Zenith Blueprint macht dies in Schritt 23 praktisch, in dem Datenschutz und Schutz von PII als Lebenszykluskontrolle erklärt werden:

Grundlage dieser Kontrolle ist Datenbewusstsein. Die Organisation muss wissen, welche PII sie erhebt, wo sie gespeichert ist, warum sie verarbeitet wird und wer darauf zugreifen kann. Ohne diese Basis sind alle Datenschutzversprechen leer.

Das ist die Brücke zwischen ISO/IEC 27701:2025 und GDPR. PETs setzen Datenbewusstsein voraus. Man kann nicht maskieren, was nicht klassifiziert wurde. Man kann nicht verantwortungsvoll pseudonymisieren, wenn unklar ist, wer den Schlüssel hält. Man kann nicht sicher anonymisieren, wenn das Re-Identifizierungsrisiko nicht bewertet wurde. Man kann einen Analytics- oder KI-Anwendungsfall nicht verteidigen, wenn er nicht mit einer Rechtsgrundlage, einem Zweck, einer Aufbewahrungsregel und einer Genehmigungsaufzeichnung verknüpft werden kann.

Zuordnung von PETs zu ISO/IEC 27002:2022 und Clarysec-Leitlinien

Reife PET-Governance hängt von integrierten Kontrollen ab. Zenith Controls: Der Leitfaden für Cross-Compliance behandelt Datenschutz und Schutz von PII, Datenmaskierung, Kryptografie und Testinformationen als zusammenhängende Kontrollfamilie. Das ist wichtig, weil Auditoren PETs selten isoliert prüfen. Wenn ein Datenbestand maskiert ist, werden sie fragen, wie er klassifiziert wurde, wer darauf zugreifen kann, ob kryptografische Tokenisierung beteiligt ist und ob dieselbe Regel in Testumgebungen gilt.

Zenith Controls ordnet ISO/IEC 27002:2022-Kontrolle 5.34, Datenschutz und Schutz von PII, als präventive Kontrolle ein, die Vertraulichkeit, Integrität und Verfügbarkeit unterstützt und operative Fähigkeiten im Informationsschutz sowie bei der Einhaltung gesetzlicher Anforderungen bereitstellt. Außerdem verknüpft es 5.34 mit dem Asset-Inventar, Datenmaskierung und Kryptografie. PETs setzen voraus, dass bekannt ist, wo PII gespeichert ist, wie ihre Exponierung eingeschränkt wird und wo sie bei Bedarf kryptografisch geschützt wird.

Für Kontrolle 8.11, Datenmaskierung, identifiziert Zenith Controls Maskierung als präventiv, auf Vertraulichkeit ausgerichtet und als Teil des Informationsschutzes. Es verknüpft Maskierung mit Informationsklassifizierung, Datenschutz und Schutz von PII, Beschränkung des Informationszugriffs, Kryptografie und Testinformationen.

Für Kontrolle 8.24, Einsatz von Kryptografie, verknüpft Zenith Controls Kryptografie mit Klassifizierung, PII-Schutz, Informationsübertragung, Schwachstellenmanagement und sicherem Entwicklungslebenszyklus. Außerdem verknüpft es die Kontrolle mit ISO/IEC 27018:2020 für den Schutz von Cloud-PII und mit NIST SP 800-53 Rev. 5-Kontrollen für kryptografischen Schutz, Schutz ruhender Daten und Vertraulichkeit bei der Übertragung.

Diese integrierte Sicht ist der Grund, warum PETs einen Cross-Compliance-Nutzen schaffen. Ein maskierter Testdatenbestand kann gleichzeitig GDPR-Datenminimierung, Schutz von Testinformationen nach ISO/IEC 27002:2022, Reduzierung von IKT-Risiken nach DORA, Cyberhygiene nach NIS2 und Ergebnisse zur Datensicherheit nach NIST CSF 2.0 unterstützen.

In Testumgebungen scheitern Datenschutzversprechen häufig

In vielen Audits ist der schnellste Weg zu einer wesentlichen Feststellung die Nicht-Produktivumgebung.

Produktion verfügt möglicherweise über MFA, Privileged Access Management (PAM), Verschlüsselung, Überwachung und striktes Änderungsmanagement. Test-, Entwicklungs- und Staging-Umgebungen können gemeinsame Konten, breiteren Entwicklerzugriff, kopierte Produktionsdaten, schwächere Protokollierung und vergessene Backups enthalten. Clarysec behandelt Testdaten genau deshalb als PET-Priorität.

Die P16 – Richtlinie zur Datenmaskierung und Pseudonymisierung ist eindeutig:

Echte personenbezogene Daten dürfen nicht in Entwicklungs-, Test- oder Staging-Umgebungen verwendet werden. Stattdessen müssen maskierte oder pseudonymisierte Daten verwendet werden, die aus vorab genehmigten Transformationsvorlagen erzeugt wurden.

Die Richtlinie zu Testdaten und Testumgebungen – KMU formuliert dieselbe Erwartung praxisnah:

Die Daten müssen mit geeigneten Werkzeugen anonymisiert oder pseudonymisiert werden.

Der Zenith Blueprint erklärt in Schritt 21, warum dies relevant ist:

Letztlich erinnert uns Control 8.33 daran, dass Informationen ihren Wert nicht verlieren, nur weil sie sich in einer Sandbox befinden. Wenn Testdaten mit derselben Sorgfalt wie Produktionsdaten behandelt werden, reduzieren Organisationen die Wahrscheinlichkeit unbeabsichtigter Exponierung, missbräuchlicher Nutzung durch Insider oder eines Scheiterns bei der Einhaltung.

Ein starkes PET-Programm beginnt daher mit einer einfachen Regel: Produktions-PII wird nicht in Umgebungen mit geringerem Sicherheitsniveau verschoben, es sei denn, eine dokumentierte Ausnahme weist die technische Notwendigkeit nach, wendet gleichwertige Schutzmaßnahmen an und dokumentiert die Genehmigung.

Die Richtlinie zu Testdaten und Testumgebungen unterstützt dies durch kontrollierte Anforderungen an Testdaten, während die KMU-Version kleineren Teams eine praktikable Basis bietet. Zusammen sollten sie Folgendes bewirken:

• Eine Standardanforderung für synthetische, anonymisierte oder maskierte Daten
• Einen formellen Ausnahmeweg für Produktions-PII
• Vorab genehmigte Transformationsvorlagen
• Zugriffskontrolle und Protokollierung für Testdatenbestände
• Zeitlich begrenzte Aufbewahrung und Bereinigung
• Nachweise, dass Maskierung angewendet wurde, bevor der Datenbestand freigegeben wurde
• Regelmäßige Prüfung des Re-Identifizierungsrisikos für pseudonymisierte Daten

Pseudonymisierung ist keine Anonymisierung

Ein häufiger Fehler besteht darin, pseudonymisierte Daten so zu behandeln, als wären sie anonym. Das sind sie nicht.

Pseudonymisierung reduziert die Identifizierbarkeit, indem direkte Identifikatoren durch Token, Hashes oder alternative Werte ersetzt werden. Wenn ein Schlüssel, eine Zuordnungstabelle, ein Salt oder ein zusätzlicher Datenbestand die Identität wiederherstellen kann, unterliegen die Daten weiterhin der Governance. Deshalb behandelt GDPR Pseudonymisierung als Schutzmaßnahme und nicht als automatischen Ausstieg aus Datenschutzpflichten.

Die P16S – Richtlinie zur Datenmaskierung und Pseudonymisierung – KMU stellt fest:

Pseudonymisierung muss verwendet werden, wenn Datenverknüpfung erforderlich ist, ohne Identitäten offenzulegen:

Diese Formulierung definiert den Anwendungsfall: Verknüpfung ohne direkte Identität. Pseudonymisierung eignet sich ideal für Churn-Analytics, Betrugsmusteranalysen, Korrelation von Supportfällen, Längsschnittberichte und KI-Modelltraining, bei denen dieselbe Person über Ereignisse hinweg erkannt werden muss, ihre tatsächliche Identität aber für den Modellnutzer nicht erforderlich ist.

Die Kontrolle ist jedoch nur so stark wie das Schlüsselmanagement. Die P16S – Richtlinie zur Datenmaskierung und Pseudonymisierung – KMU stellt außerdem fest:

Der Zugriff auf Schlüssel muss verschlüsselt, zugriffskontrolliert und protokolliert sein.

Dies entspricht unmittelbar ISO/IEC 27002:2022-Kontrolle 8.24. In Schritt 20 zum Einsatz von Kryptografie warnt der Zenith Blueprint:

Starke Verschlüsselung bedeutet nichts, wenn die Schlüssel offengelegt, unsachgemäß gehandhabt oder vergessen werden. Schlüssel sollten sicher generiert, in verschlüsselten Schlüsselablagen oder Hardware Security Modules gespeichert, nach einem Zeitplan rotiert und widerrufen werden, wenn sie kompromittiert oder nicht mehr benötigt werden.

Für einen CISO oder Datenschutzmanager ist die praktische Regel klar: Wenn Pseudonymisierung reversibel ist, ist der Schlüsselzugriff das Kronjuwel. Token-Tabelle, Salt, Berechtigungen für die Schlüsselablage, Re-Identifizierungs-Workflow und Protokolle müssen als Hochrisiko-Assets behandelt werden.

Die P16 – Richtlinie zur Datenmaskierung und Pseudonymisierung ergänzt eine weitere auditkritische Anforderung:

Regelmäßige Bewertungen des Re-Identifizierungsrisikos müssen für pseudonymisierte Datenbestände durchgeführt werden.

Dies verhindert, dass Pseudonymisierung veraltet. Ein Datenbestand, der im letzten Jahr ein geringes Risiko hatte, kann nach dem Hinzufügen neuer Attribute, nach Erhalt weiterer Daten durch einen Lieferanten oder durch leichter verknüpfbare externe Datenbestände ein höheres Risiko aufweisen.

Ein praktischer PET-Workflow für KI und Analytics

Zurück zu Sarahs Fintech-KI-Funktion. Das Geschäft benötigt Kundendaten für das Modelltraining, aber Sarah braucht einen belastbaren Weg, der Kunden schützt, die Rechtsabteilung zufriedenstellt und Innovation nicht blockiert.

Schritt 1: Entscheidungsaufzeichnung für Datenschutz durch Technikgestaltung erstellen

Der Geschäftsinhaber öffnet REG04, die Entscheidungsaufzeichnung, auf die in der Richtlinie zu Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen verwiesen wird. Die Anfrage dokumentiert:

• Geschäftszweck: KI-gestützte Beratungsfunktion und Churn- oder Engagement-Modellierung
• Angeforderter Datenbestand: Kundenprofil, Abonnementereignisse, Transaktionskategorien, Nutzungsprotokolle und Supportereignisse
• Rolle als Verantwortlicher oder Auftragsverarbeiter sowie Rechtsgrundlage oder Verarbeitungsweisung
• Ob identifizierbare PII erforderlich ist
• PET-Machbarkeit: Aggregation, Pseudonymisierung, Anonymisierung, synthetische Daten oder Maskierung
• Empfänger: internes Analytics-Team, Anwendungsteam und Cloud-Analytics-Plattform
• Aufbewahrungsfrist und Löschtrigger
• Genehmigender Verantwortlicher und Restrisiko

Die Richtlinie verlangt, dass die PET-Machbarkeit dokumentiert wird, bevor identifizierbare PII genehmigt wird. Dadurch wird De-Identifizierung zum Standardweg und nicht zu einem nachträglichen Zusatz.

Schritt 2: Felder klassifizieren und minimieren

Der Dateneigentümer entfernt direkte Identifikatoren wie Name, E-Mail-Adresse, Telefonnummer, staatliche Kennung und vollständige Kontonummer aus dem Trainingsextrakt. Die Kundenkennung wird durch ein pseudonymes Token ersetzt. Der Standort wird verallgemeinert. Freitext-Supportnotizen werden ausgeschlossen oder geschwärzt. Zahlungsdetails werden entfernt, sofern sie nicht für eine bestimmte genehmigte Funktion erforderlich sind.

Die Richtlinie zu Datenschutz und Privatsphäre – KMU bekräftigt dieses Gestaltungsprinzip:

Standardsystemeinstellungen müssen die Exponierung personenbezogener Daten minimieren (z. B. maskierte Ansichten, eingeschränkte Berichte).

Die Richtlinie zu Datenschutz und Privatsphäre legt die umfassendere Systemanforderung fest:

Systeme müssen Anonymisierung oder Pseudonymisierung unterstützen, soweit angemessen.

Schritt 3: Pseudonymisierung anwenden und Schlüssel schützen

Engineering nutzt eine freigegebene Transformationsvorlage aus der Maskierungsrichtlinie. Token werden mit einem zugelassenen Verfahren generiert. Der Schlüssel oder die Zuordnungstabelle wird getrennt in einer eingeschränkten Schlüsselablage gespeichert. Nur eine kleine Re-Identifizierungsrolle darf darauf zugreifen, und jeder Zugriff wird protokolliert.

Wenn der Datenbestand an einen Cloud-Analytics-Anbieter übermittelt wird, wird Verschlüsselung während der Übertragung und für ruhende Daten verifiziert. Die Richtlinie zu PII-Sicherheit und Zugriffskontrolle verlangt:

[Beide] Der Informationssicherheitsverantwortliche MUSS in REG12 Anforderungen an Verschlüsselung oder genehmigte kompensierende Schutzmaßnahmen definieren, bevor PII mit hoher Tragweite, sensible PII oder extern übermittelte PII gespeichert, übertragen oder zugänglich gemacht wird.

Schritt 4: Re-Identifizierungsrisiko prüfen

Der DPO oder Datenschutzberater prüft, ob die verbleibenden Attribute Personen durch Einzigartigkeit, seltene Verhaltensmuster oder Verknüpfung mit externen Daten identifizieren könnten.

Die Richtlinie zur PII-Aufbewahrung, Löschung und Entsorgung stellt fest:

[Beide] Der Datenschutzbeauftragte (DPO) / Datenschutzberater MUSS Annahmen zum Re-Identifizierungsrisiko in REG12 prüfen, bevor Anonymisierung oder De-Identifizierung für Hochrisiko- oder extern weitergegebene Datenbestände genehmigt wird.

Diese Prüfung ist besonders wichtig, wenn Daten die Organisation verlassen, in eine Umgebung eines Auftragsverarbeiters gelangen oder im KI-Training verwendet werden.

Schritt 5: KI-spezifisches Datenrisiko steuern

KI schafft besondere PET-Herausforderungen, weil Modellteams häufig große, realistische und wiederverwendbare Datenbestände benötigen. Die Datenschutzrichtlinie zu KI und automatisierter Entscheidungsfindung macht die operative Erwartung klar:

[Beide] Bevor Produktions-PII für KI-Tests, Training, Tuning, Validierung oder Überwachung verwendet wird, muss der Systemverantwortliche / Anwendungsverantwortliche genehmigte Maßnahmen zur Datenminimierung, Trennung, Zugriffskontrolle oder De-Identifizierung umsetzen und Umsetzungsnachweise in REG04 oder REG12 dokumentieren.

Für KI-Projekte umfassen praktikable PET-Optionen synthetische Daten für frühe Tests, Feature-Minimierung, pseudonymisierte Kennungen, Schwärzung von Freitext, Aggregation, differenzierten Zugriff auf sensitive Attribute und Trennung zwischen Trainings-, Validierungs- und Produktionsüberwachungsdaten.

Die Prüfung sollte folgende Fragen stellen:

• Kann das Modellziel ohne direkte Identifikatoren erreicht werden?
• Sind Freitextfelder erforderlich, und wurden sie geschwärzt?
• Werden sensible Daten als Eingabe, Label oder Proxy verwendet?
• Können synthetische Daten Tests unterstützen, bevor Echtdaten genehmigt werden?
• Werden Modellausgaben auf Memorization- oder Re-Identifizierungsrisiken geprüft?
• Gibt es einen Löschplan für Trainingsextrakte?
• Werden Nachweise in REG04 oder REG12 erfasst?

Schritt 6: Aufbewahrung und Entsorgung dokumentieren

Wenn die KI-Ausgabe nach Training oder Validierung keine Daten auf Zeilenebene mehr benötigt, sollte der rohe pseudonymisierte Datenbestand nach einem definierten Zeitraum gelöscht werden. Wenn die finale Ausgabe aggregiert ist, kann für sie eine andere Aufbewahrungsregel gelten.

Die Richtlinie zur PII-Aufbewahrung, Löschung und Entsorgung verlangt:

[Beide] Der Prozessverantwortliche / Geschäftsinhaber MUSS Anonymisierung, De-Identifizierung oder Pseudonymisierung als risikomindernde Maßnahme bei der Aufbewahrung oder als endgültiges Dispositionsergebnis in REG02 dokumentieren, bevor identifizierbare PII transformiert wird.

Schritt 7: Prüfpfad sichern

Das Nachweispaket sollte REG04, REG12, REG02, DPIA oder PIA, soweit erforderlich, Maskierungskonfiguration, Token-Design, Schlüsselzugriffsprotokolle, Cloud-Sicherheitseinstellungen, Lieferantengenehmigungen, Löschprotokolle und Screenshots eingeschränkter Berichte enthalten.

So werden PETs auditierbar. Sarah kann nicht nur zeigen, dass Pseudonymisierung verwendet wurde, sondern auch, warum sie ausgewählt wurde, wer sie genehmigt hat, wie sie umgesetzt wurde, wie Schlüssel geschützt wurden und wie das Restrisiko geprüft wurde.

Cross-Compliance-Zuordnung: GDPR, ISO 27701, NIS2, DORA, NIST und COBIT

PETs reduzieren Druck in der breiteren regulatorischen Landschaft, weil sie dasselbe Kernziel unterstützen: unnötige Exponierung sensibler Daten reduzieren und zugleich Rechenschaftspflicht sowie operative Resilienz erhalten.

Unter GDPR unterstützen PETs Rechenschaftspflicht, Datenminimierung, Datenschutz durch Technikgestaltung und Sicherheit der Verarbeitung. GDPR kann extraterritorial für nicht in der EU ansässige Verantwortliche oder Auftragsverarbeiter gelten, die Personen in der Union Dienste anbieten oder deren Verhalten beobachten. SaaS-, Fintech- und Cloud-Analytics-Anbieter benötigen häufig an GDPR ausgerichtete PETs, selbst wenn sie ihren Hauptsitz anderswo haben.

Unter NIS2 müssen wesentliche und wichtige Einrichtungen geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen umsetzen. Article 21 umfasst Risikoanalyse, Umgang mit Informationssicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs, Sicherheit der Lieferkette, sichere Entwicklung, Wirksamkeitsbewertung, Cyberhygiene, Kryptografie, Zugriffskontrolle und Asset-Management.

Unter DORA benötigen Finanzunternehmen ein dokumentiertes Rahmenwerk für das Management von IKT-Risiken und einen starken Schutz der Vertraulichkeit, Integrität und Verfügbarkeit von Daten. Drittparteienanforderungen in Articles 28 bis 30 machen PETs besonders wertvoll, wenn Daten durch IKT-Anbieter, Cloud-Plattformen, ausgelagerte Entwickler oder Testpartner bewegt werden.

NIST CSF 2.0 ergänzt eine operative Perspektive. GOVERN-Ergebnisse verlangen gesetzliche, regulatorische und vertragliche Anforderungen, Datenschutzverpflichtungen, Risikobereitschaft und Richtlinienaufsicht. PROTECT umfasst Datensicherheit für ruhende Daten, Daten während der Übertragung und Daten während der Verarbeitung. DETECT, RESPOND und RECOVER ergänzen Überwachung, Vorfallmeldung, Benachrichtigung von Interessenträgern, Integrität von Untersuchungen und Verifikation der Wiederherstellung.

Wie Auditoren Ihr PET-Programm prüfen werden

Eine Richtlinie ist nur Papier und ein Werkzeug nur Code, bis ein Auditor Nachweise anfordert. Unterschiedliche Prüfer betrachten PETs aus unterschiedlichen Blickwinkeln, aber die Nachweise überschneiden sich.

Zenith Controls enthält eine Auditmethodik-Sicht, die hier besonders nützlich ist. Für Datenschutz und Schutz von PII verweist sie Auditoren auf Datenschutzrichtlinien, Dateninventare, DPIAs oder PIAs, Schulungsprotokolle, Verschlüsselungsnachweise, Zugriffskontrollen und logische Schutzmaßnahmen. Für Datenmaskierung hebt sie Maskierungsrichtlinien, Klassifizierungsschemata, Systembeispiele, Dashboards, Protokolle, Nicht-Produktiv-Datenbestände und Nachweise hervor, dass Maskierung korrekt angewendet wird. Für Kryptografie nennt sie genehmigte Algorithmen, Schlüssellängen, Schlüsselmanagement-Verfahren, Verwahrerrollen und Nachweise, dass schwache Chiffren vermieden werden.

Die Lehre ist einfach: PET-Nachweise müssen technisch und managementbezogen sein. Screenshots allein reichen nicht aus. Richtlinien allein reichen nicht aus. Erforderlich ist die vollständige Kette von Anforderung zu Risiko, Umsetzung, Überwachung, Prüfung und Verbesserung.

Häufige PET-Mängel, die vor dem Audit behoben werden sollten

Die meisten Organisationen scheitern nicht, weil ihnen Werkzeuge fehlen. Sie scheitern, weil PETs uneinheitlich gesteuert werden.

Häufige Feststellungen sind:

• Maskierung wird auf Datenbanken angewendet, aber nicht auf Exporte, Protokolle oder BI-Dashboards
• Pseudonymisierungsschlüssel sind für zu viele Administratoren zugänglich
• Testumgebungen enthalten alte Produktionskopien ohne Verantwortlichen für die Aufbewahrung
• Analytics-Teams verwenden E-Mail-Adressen als bequeme Join-Schlüssel
• Lieferanten erhalten Beispieldaten vor der Datenschutzprüfung
• Anonymisierung wird behauptet, ohne das Re-Identifizierungsrisiko zu bewerten
• Datenminimierung ist in einer DPIA dokumentiert, aber nicht in Abfragen umgesetzt
• Verschlüsselung ist aktiviert, aber Schlüsselverantwortung und Schlüsselrotation sind unklar
• KI-Teams speichern Trainingsextrakte außerhalb genehmigter Repositories
• Ausnahmen werden mündlich genehmigt und laufen nie ab

Die Lösung ist kein umfangreicheres Richtliniendokument. Die Lösung ist ein Workflow, der den sicheren Weg zum einfachsten Weg macht.

Bauen Sie Ihr PET-Betriebsmodell in 30 Tagen auf

Ein praktisches PET-Programm kann schnell beginnen, wenn Sie sich zuerst auf die Datenbewegungen mit dem höchsten Risiko konzentrieren.

Dies ist auch der richtige Zeitpunkt, um PETs mit der breiteren Clarysec-Roadmap zu verknüpfen. Im Zenith Blueprint behandelt Schritt 19 Maskierung, Schritt 20 Kryptografie, Schritt 21 Testinformationen und Schritt 23 Datenschutz und Schutz von PII. Zusammen schaffen diese Schritte eine umsetzbare Implementierungssequenz für ISO/IEC 27701:2025 und an GDPR ausgerichtetes Privacy Engineering.

Machen Sie PETs auditierbar, bevor der Auditor fragt

Sarahs Geschichte endet nicht mit einem einfachen Ja oder Nein. Sie endet mit einer besseren Frage: Wie kann die Organisation Daten sicher nutzen?

Durch einen governancegeführten Ansatz für datenschutzfördernde Technologien kann sie die Rechtsabteilung zufriedenstellen, das Produktteam befähigen, Kunden schützen und zugleich die Einhaltung stärken. Die KI-Funktion kann mit pseudonymisierten, minimierten und zugriffskontrollierten Daten fortfahren. Der Cloud-Analytics-Anbieter kann nur den sicheren Datenbestand erhalten. Der Schlüssel kann eingeschränkt bleiben. Die Aufbewahrungsregel kann dokumentiert werden. Die Nachweise können einer Prüfung nach ISO, GDPR, DORA, NIS2 und zur Vertrauensbildung bei Kunden standhalten.

PETs sind mehr als eine technische Korrektur für ein Compliance-Problem. Wenn sie in ein Managementsystem integriert werden, das von klaren Richtlinien, dem Zenith Blueprint und der rahmenwerkübergreifenden Zuordnung aus Zenith Controls gesteuert wird, werden sie zu einem strategischen Ermöglicher. Sie ermöglichen Organisationen, Wert aus Daten zu ziehen und gleichzeitig Exponierung zu reduzieren, Vertrauen aufzubauen und Rechenschaftspflicht nachzuweisen.

Clarysec kann Ihnen helfen, daraus ein Betriebsmodell zu machen.

Beginnen Sie mit dem Zenith Blueprint, um Ihre Umsetzung zu sequenzieren. Nutzen Sie Zenith Controls, um PETs über ISO/IEC 27002:2022, GDPR, NIS2, DORA, NIST und unterstützende ISO-Standards hinweg zuzuordnen. Führen Sie anschließend die relevanten Clarysec-Richtlinien ein, einschließlich der P16 – Richtlinie zur Datenmaskierung und Pseudonymisierung, der Richtlinie zu Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen, der Richtlinie zur PII-Aufbewahrung, Löschung und Entsorgung, der Richtlinie zu PII-Sicherheit und Zugriffskontrolle, der Richtlinie zu Testdaten und Testumgebungen und der Datenschutzrichtlinie zu KI und automatisierter Entscheidungsfindung.

Ihre unmittelbare Maßnahme ist einfach: Wählen Sie diese Woche einen Hochrisiko-Datenbestand aus und fragen Sie: „Kann das Geschäftsergebnis ohne identifizierbare PII erreicht werden?“ Wenn die Antwort ja lautet, setzen Sie die PET um. Wenn die Antwort nein lautet, dokumentieren Sie die Gründe, schützen Sie die Daten angemessen und bewahren Sie die Nachweise auf.

Das ist Datenschutz durch Technikgestaltung in der Praxis.