Hvad revisorer ser, når de spørger om PII-kontroller
Under en GDPR-tilsynsmyndighedsrevision eller ISO 27001-vurdering er et af de standardspørgsmål: "Hvilke tekniske kontroller har du til PII-anonymisering?"
Revisoren leder efter et klart, forsvarligt svar: en specifik kontrol, konsekvent anvendt, med dokumentation for hvordan den fungerer og bevis for dens effektivitet.
Svaret, der skaber overholdelsesrisiko: "Vi bruger forskellige værktøjer afhængigt af konteksten. Til web browsing bruger vi Chrome-udvidelsen, til Word-dokumenter bruger vi en makro, til bulkfiler har vores datateam et Python-script, de har skrevet, og til presserende anmodninger bruger vi webappen."
Dette svar udløser et opfølgende spørgsmål: "Hvad er forskellene i dækning mellem disse værktøjer? Hvordan sikrer du ensartede resultater på tværs af værktøjer? Hvor er revisionssporet, der viser konsekvent anvendelse?"
Disse er spørgsmål, som fragmenterede værktøjer ikke kan besvare klart.
Problemet med dækningens konsistens
Forskellige PII-detekteringsværktøjer bruger forskellige underliggende detektionsmetoder:
Regex-only værktøjer: Søger efter specifikke mønstre (SSN-format, e-mail-format, kreditkortformat). Overser NER-baserede enheder (personnavne, organisationer der ikke matcher en kendt liste), kontekstuelle identifikatorer og ikke-US-formater.
NER-only værktøjer: Detekterer enhedstyper ved hjælp af trænede modeller. Overser mønsterbaserede enheder (IBAN'er, kontonumre med specifikke formater), brugerdefinerede organisatoriske identifikatorer og enheder, der ikke er i træningsdataene.
Værktøj A vs. Værktøj B vs. Værktøj C: Hver har forskellig dækning af enhedstyper, forskellige tillidsgrænser, forskellig håndtering af grænsetilfælde. Det samme dokument behandlet gennem Værktøj A og Værktøj C kan producere forskellige detektionsresultater.
Overholdelsesproblemet: hvis Værktøj A (brugt til PDF'er) detekterer fødselsdatoer, men Værktøj B (brugt til Excel) ikke gør, så anonymiseres den samme datasubjekts fødselsdato i en PDF, mens deres fødselsdato i et Excel-regneark ikke anonymiseres. Den systematiske overholdelseskontrol har et gab, der afhænger af dokumentformatet.
For DPA-undersøgelser er dette gab opdageligt. Hvis der opstår et databrud, og undersøgelsen afslører, at Excel-regnearksversionen af et datasubjekts optegnelser ikke blev anonymiseret, mens PDF-versionen blev, er inkonsistensen mellem værktøjerne en medvirkende faktor til eksponeringen.
Problemet med revisionssporet
Overholdelsesdokumentation kræver bevis for, at kontroller anvendes konsekvent. For PII-anonymisering er beviset revisionssporet: hvad der blev behandlet, hvornår, af hvem, med hvilket værktøj, og hvad resultatet var.
Fire forskellige værktøjer producerer fire forskellige revisionssporformater — eller slet ingen revisionsspor. En Word-makro producerer ingen revisionslog. Et Python-script kan skrive til en lokal fil, der ikke er integreret med overholdelsesstyringssystemet. Chrome-udvidelsen kan producere browser-side logs, der ikke er tilgængelige for overholdelsesdokumentation. Kun webappen kan producere et centraliseret revisionsspor.
For en DPA-undersøgelse, der kræver revisionssporbevis, er svaret "vi behandlede dette dokument i en Word-makro, de logs er på udviklerens lokale maskine" ikke tilfredsstillende. Svaret "her er den centraliserede revisionslog, der dækker al anonymiseringsbehandling på tværs af alle platforme for den anmodede periode" er tilfredsstillende.
Behandling på én platform muliggør dækning af et enkelt revisionsspor. Fragmenterede værktøjer gør centraliseret revisionsspor umuligt.
Problemet med konfigurationsdrift
Over tid udvikler forskellige værktøjer brugt af forskellige teammedlemmer forskellige konfigurationer:
- Chrome-udvidelsen er konfigureret med organisationens brugerdefinerede enhedstyper
- Python-scriptet blev ikke opdateret, da de brugerdefinerede enhedstyper blev tilføjet
- Word-makroen blev konfigureret af et teammedlem, der siden er gået, og ingen ved, hvad de nuværende indstillinger er
- Webappens forudindstilling blev opdateret sidste måned for at udelukke kontraktnavne, men denne opdatering blev ikke videreført til de andre værktøjer
Konfigurationsdrift skaber inkonsistensproblemet i omvendt rækkefølge: selvom alle værktøjer oprindeligt producerede lignende resultater, skaber vedligeholdelsesaktivitet på ét værktøj uden at opdatere andre divergens over tid.
For ISO 27001-kontroller gør kravet om konfigurationsdokumentation dette særligt problematisk. En ISO-revisor, der spørger "vis mig konfigurationen for dine PII-anonymiseringskontroller", kan ikke besvares tilfredsstillende med "vi har fire værktøjer med fire forskellige konfigurationer, og vi er ikke sikre på, at de alle er aktuelle."
ISO 27001-findingen
Et compliance-konsulentfirmas 15-personers team brugte fire forskellige værktøjer: et web-scraper-værktøj til online data, et selvstændigt Windows-desktopværktøj til bulkfiler, en Word-makro til juridiske dokumenter og en Chrome-udvidelse til AI-værktøjer.
En ISO 27001-revision producerede en finding: "Inkonsistente dataanonymiseringsprocedurer på tværs af platforme. Forskellige værktøjer brugt til forskellige kontekster producerer forskellige detektionsresultater og intet centraliseret revisionsspor. Dette skaber et gab i kontrol ISO/IEC 27001:2022 Bilag A 8.11 (Data masking) — kontrollen kan ikke demonstreres som konsekvent anvendt."
Revisionsfindingen krævede en handlingsplan for korrektion. Den implementerede korrigerende handling: konsolidering til en enkelt anonymiseringsplatform for alle anvendelsestilfælde.
Resultater efter konsolidering:
- Samme detektionsmotor på tværs af alle platforme (Web App, Desktop App, Office Add-in, Chrome Extension)
- Samme forudindstillinger anvendt på tværs af kontekster
- Centraliseret revisionsspor for al behandling
- ISO 27001-finding lukket ved næste overvågningsrevision
Det 6-ugers konsolideringsprojekt eliminerede den revisionsfinding, der havde krævet et 12-siders korrigerende handlingssvar.
Compliance Narrative Test
En nyttig test til evaluering af PII-værktøjsfragmentering: kan du klart besvare følgende spørgsmål?
- Hvilke enhedstyper detekteres på tværs af alle platforme, dit team bruger til PII-anonymisering?
- Hvad er detektionsgrænsen (tillidsniveauet) for hver enhedstype, konsekvent på tværs af alle platforme?
- Hvor er det centraliserede revisionsspor for al anonymiseringsbehandling i de sidste 12 måneder?
- Hvordan sikrer du, at konfigurationsændringer anvendes konsekvent på tværs af alle platforme?
Hvis nogen af disse spørgsmål giver et tøvende svar, skaber fragmenteringen overholdelsesrisiko. Det klare svar på alle fire spørgsmål er opnåeligt — men kun med en samlet motor på tværs af platforme.
Kilder: