Was Prüfer sehen, wenn sie nach PII-Kontrollen fragen
Während einer Prüfung durch eine GDPR-Aufsichtsbehörde oder einer ISO 27001-Bewertung ist eine der Standardfragen: "Welche technischen Kontrollen haben Sie für die PII-Anonymisierung?"
Der Prüfer sucht nach einer klaren, verteidigbaren Antwort: einer spezifischen Kontrolle, die konsistent angewendet wird, mit Dokumentation darüber, wie sie funktioniert, und Nachweisen ihrer Wirksamkeit.
Die Antwort, die Compliance-Risiko schafft: "Wir verwenden unterschiedliche Tools, je nach Kontext. Für das Surfen im Internet nutzen wir die Chrome-Erweiterung, für Word-Dokumente verwenden wir ein Makro, für Massendateien hat unser Datenteam ein Python-Skript geschrieben, und für dringende Anfragen nutzen wir die Web-App."
Diese Antwort löst eine Folgefrage aus: "Was sind die Unterschiede in der Abdeckung zwischen diesen Tools? Wie stellen Sie konsistente Ergebnisse über die Tools hinweg sicher? Wo ist der Prüfpfad, der die konsistente Anwendung nachweist?"
Diese Fragen kann fragmentierte Toolnutzung nicht klar beantworten.
Das Problem der Abdeckungs-Konsistenz
Verschiedene PII-Erkennungstools verwenden unterschiedliche zugrunde liegende Erkennungsansätze:
Regex-only Tools: Suchen nach spezifischen Mustern (SSN-Format, E-Mail-Format, Kreditkartenformat). Übersehen NER-basierte Entitäten (Personennamen, Organisationen, die nicht mit einer bekannten Liste übereinstimmen), kontextuelle Identifikatoren und Nicht-US-Formate.
NER-only Tools: Erkennen Entitätstypen mithilfe trainierter Modelle. Übersehen musterbasierte Entitäten (IBANs, Kontonummern mit spezifischen Formaten), benutzerdefinierte organisatorische Identifikatoren und Entitäten, die nicht in den Trainingsdaten enthalten sind.
Tool A vs. Tool B vs. Tool C: Jedes hat unterschiedliche Entitätstyp-Abdeckungen, unterschiedliche Vertrauensschwellen, unterschiedliche Handhabungen von Grenzfällen. Dasselbe Dokument, das durch Tool A und Tool C verarbeitet wird, kann unterschiedliche Erkennungsergebnisse liefern.
Das Compliance-Problem: Wenn Tool A (für PDFs verwendet) Geburtsdaten erkennt, Tool B (für Excel verwendet) jedoch nicht, dann wird das Geburtsdatum derselben betroffenen Person in einem PDF anonymisiert, während ihr Geburtsdatum in einer Excel-Tabelle nicht anonymisiert wird. Die systematische Compliance-Kontrolle hat eine Lücke, die vom Dokumentformat abhängt.
Für DPA-Untersuchungen ist diese Lücke entdeckbar. Wenn ein Datenleck auftritt und die Untersuchung zeigt, dass die Excel-Version der Aufzeichnungen einer betroffenen Person nicht anonymisiert wurde, während die PDF-Version anonymisiert wurde, ist die Inkonsistenz zwischen den Tools ein beitragender Faktor zur Exposition.
Das Prüfpfad-Problem
Compliance-Dokumentation erfordert Nachweise, dass Kontrollen konsistent angewendet werden. Für die PII-Anonymisierung ist der Nachweis der Prüfpfad: was verarbeitet wurde, wann, von wem, mit welchem Tool und was das Ergebnis war.
Vier verschiedene Tools erzeugen vier verschiedene Prüfpfadformate — oder keinen Prüfpfad überhaupt. Ein Word-Makro erzeugt kein Prüfprotokoll. Ein Python-Skript kann in eine lokale Datei schreiben, die nicht in das Compliance-Management-System integriert ist. Die Chrome-Erweiterung kann browserseitige Protokolle erzeugen, die für die Compliance-Dokumentation nicht zugänglich sind. Nur die Web-App kann einen zentralisierten Prüfpfad erzeugen.
Für eine DPA-Untersuchung, die Prüfpfadnachweise erfordert, ist die Antwort "Wir haben dieses Dokument in einem Word-Makro verarbeitet, diese Protokolle befinden sich auf dem lokalen Rechner des Entwicklers" nicht zufriedenstellend. Die Antwort "Hier ist das zentralisierte Prüfprotokoll, das alle Anonymisierungsprozesse über alle Plattformen für den angeforderten Zeitraum abdeckt" ist zufriedenstellend.
Die Verarbeitung auf einer einzigen Plattform ermöglicht eine einheitliche Prüfpfadabdeckung. Fragmentierte Tools machen einen zentralisierten Prüfpfad unmöglich.
Das Problem der Konfigurationsabweichung
Im Laufe der Zeit entwickeln verschiedene Tools, die von verschiedenen Teammitgliedern verwendet werden, unterschiedliche Konfigurationen:
- Die Chrome-Erweiterung ist mit den benutzerdefinierten Entitätstypen der Organisation konfiguriert
- Das Python-Skript wurde nicht aktualisiert, als die benutzerdefinierten Entitätstypen hinzugefügt wurden
- Das Word-Makro wurde von einem Teammitglied konfiguriert, das inzwischen gegangen ist, und niemand kennt die aktuellen Einstellungen
- Die Voreinstellung der Web-App wurde letzten Monat aktualisiert, um die Namen von Auftragnehmern auszuschließen, aber dieses Update wurde nicht auf die anderen Tools übertragen
Die Konfigurationsabweichung schafft das Inkonsistenzproblem umgekehrt: Selbst wenn alle Tools ursprünglich ähnliche Ergebnisse lieferten, führt die Wartungsaktivität an einem Tool ohne Aktualisierung der anderen im Laufe der Zeit zu Divergenz.
Für ISO 27001-Kontrollen macht die Anforderung an die Konfigurationsdokumentation dies besonders problematisch. Ein ISO-Prüfer, der fragt: "Zeigen Sie mir die Konfiguration Ihrer PII-Anonymisierungskontrollen", kann nicht zufriedenstellend mit "Wir haben vier Tools mit vier verschiedenen Konfigurationen, und wir sind uns nicht sicher, ob sie alle aktuell sind" beantwortet werden.
Das ISO 27001-Ergebnis
Ein Team von 15 Personen einer Compliance-Beratungsfirma verwendete vier verschiedene Tools: ein Web-Scraper-Tool für Online-Daten, ein eigenständiges Windows-Desktop-Tool für Massendateien, ein Word-Makro für juristische Dokumente und eine Chrome-Erweiterung für KI-Tools.
Eine ISO 27001-Prüfung ergab einen Befund: "Inkonsequente Datenanonymisierungsverfahren über Plattformen hinweg. Verschiedene Tools, die für unterschiedliche Kontexte verwendet werden, produzieren unterschiedliche Erkennungsergebnisse und keinen zentralisierten Prüfpfad. Dies schafft eine Lücke in der Kontrolle ISO/IEC 27001:2022 Anhang A 8.11 (Datenmaskierung) — die Kontrolle kann nicht als konsistent angewendet nachgewiesen werden."
Der Prüfungsbefund erforderte einen Korrekturmaßnahmenplan. Die umgesetzte Korrekturmaßnahme: Konsolidierung auf eine einzige Anonymisierungsplattform für alle Anwendungsfälle.
Ergebnisse nach der Konsolidierung:
- Dieselbe Erkennungsmaschine über alle Plattformen hinweg (Web-App, Desktop-App, Office-Add-in, Chrome-Erweiterung)
- Dieselben Voreinstellungen, die über Kontexte hinweg angewendet werden
- Zentralisierter Prüfpfad für alle Prozesse
- ISO 27001-Befund bei der nächsten Überwachungsprüfung geschlossen
Das 6-wöchige Konsolidierungsprojekt beseitigte den Prüfungsbefund, der eine 12-seitige Korrekturmaßnahmenantwort erforderlich gemacht hatte.
Der Compliance-Narrativ-Test
Ein nützlicher Test zur Bewertung der Fragmentierung von PII-Tools: Können Sie die folgenden Fragen klar beantworten?
- Welche Entitätstypen werden über alle Plattformen hinweg erkannt, die Ihr Team für die PII-Anonymisierung verwendet?
- Was ist die Erkennungsschwelle (Vertrauensniveau) für jeden Entitätstyp, konsistent über alle Plattformen hinweg?
- Wo ist der zentralisierte Prüfpfad für alle Anonymisierungsprozesse in den letzten 12 Monaten?
- Wie stellen Sie sicher, dass Konfigurationsänderungen konsistent über alle Plattformen hinweg angewendet werden?
Wenn eine dieser Fragen eine zögerliche Antwort hervorbringt, schafft die Fragmentierung Compliance-Risiko. Die saubere Antwort auf alle vier Fragen ist erreichbar — aber nur mit einer einheitlichen Engine über die Plattformen hinweg.
Quellen: