Vad revisorer ser när de frågar om PII-kontroller
Under en GDPR-tillsynsmyndighetsrevision eller ISO 27001-bedömning är en av standardfrågorna: "Vilka tekniska kontroller har ni för PII-anonymisering?"
Revisorn letar efter ett rent, försvarbart svar: en specifik kontroll, konsekvent tillämpad, med dokumentation av hur den fungerar och bevis på dess effektivitet.
Svaret som skapar efterlevnadsrisk: "Vi använder olika verktyg beroende på kontext. För webbläsning använder vi Chrome-tillägget, för Word-dokument använder vi en makro, för bulkfiler har vårt datateam ett Python-skript de skrev, och för brådskande förfrågningar använder vi webbappen."
Detta svar utlöser en uppföljning: "Vad är skillnaderna i täckning mellan dessa verktyg? Hur säkerställer ni konsekventa resultat mellan verktyg? Var är revisionsspåret som visar konsekvent tillämpning?"
Dessa är frågor som fragmenterade verktyg inte kan svara på på ett klart sätt.
Problemet med täckningskonsekvens
Olika PII-detekteringsverktyg använder olika underliggande detekteringsmetoder:
Regex-endast verktyg: Söker efter specifika mönster (SSN-format, e-postformat, kreditkortsformat). Missar NER-baserade enheter (personnamn, organisationer som inte matchar en känd lista), kontextuella identifierare och icke-US-format.
NER-endast verktyg: Detekterar enhetstyper med hjälp av tränade modeller. Missar mönsterbaserade enheter (IBAN, kontonummer med specifika format), anpassade organisatoriska identifierare och enheter som inte finns i träningsdata.
Verktyg A vs. Verktyg B vs. Verktyg C: Varje har olika enhetstyp täckning, olika förtroendetrösklar, olika hantering av gränsfall. Samma dokument som bearbetas genom Verktyg A och Verktyg C kan ge olika detekteringsresultat.
Problemet med efterlevnad: om Verktyg A (använt för PDF-filer) detekterar födelsedatum men Verktyg B (använt för Excel) inte gör det, då anonymiseras samma datakällas födelsedatum i en PDF medan deras födelsedatum i ett Excel-kalkylblad inte gör det. Den systematiska efterlevnadskontrollen har en lucka som beror på dokumentformat.
För DPA-utredningar är denna lucka upptäckbar. Om en dataintrång inträffar och utredningen visar att Excel-kalkylbladsversionen av en datakällas register inte anonymiserades medan PDF-versionen gjorde det, är inkonsekvensen mellan verktyg en bidragande faktor till exponeringen.
Problemet med revisionsspår
Efterlevnadsdokumentation kräver bevis på att kontroller tillämpas konsekvent. För PII-anonymisering är beviset revisionsspåret: vad som bearbetades, när, av vem, med vilket verktyg, och vad var resultatet.
Fyra olika verktyg producerar fyra olika revisionsspårsformat — eller inget revisionsspår alls. En Word-makro producerar ingen revisionslogg. Ett Python-skript kan skriva till en lokal fil som inte är integrerad med efterlevnadshanteringssystemet. Chrome-tillägget kan producera webbläsarspecifika loggar som inte är tillgängliga för efterlevnadsdokumentation. Endast webbappen kan producera ett centraliserat revisionsspår.
För en DPA-utredning som kräver revisionsspårbevis är svaret "vi bearbetade detta dokument i en Word-makro, de loggarna finns på utvecklarens lokala maskin" inte tillfredsställande. Svaret "här är den centraliserade revisionsloggen som täcker all anonymiseringsbearbetning över alla plattformar för den begärda perioden" är tillfredsställande.
Bearbetning på en enda plattform möjliggör en enda revisionsspårstäckning. Fragmenterade verktyg gör centraliserad revisionsspår omöjlig.
Problemet med konfigurationsdrift
Över tid utvecklar olika verktyg som används av olika teammedlemmar olika konfigurationer:
- Chrome-tillägget är konfigurerat med organisationens anpassade enhetstyper
- Python-skriptet uppdaterades inte när de anpassade enhetstyperna lades till
- Word-makrot konfigurerades av en teammedlem som sedan har slutat, och ingen vet de aktuella inställningarna
- Webbappens förinställning uppdaterades förra månaden för att exkludera kontraktsnamn, men denna uppdatering spreds inte till de andra verktygen
Konfigurationsdrift skapar inkonsekvensproblemet baklänges: även om alla verktyg ursprungligen producerade liknande resultat, skapar underhållsaktivitet på ett verktyg utan att uppdatera andra avvikelser över tid.
För ISO 27001-kontroller gör kravet på konfigurationsdokumentation detta särskilt problematiskt. En ISO-revisor som frågar "visa mig konfigurationen för era PII-anonymiseringskontroller" kan inte besvaras tillfredsställande med "vi har fyra verktyg med fyra olika konfigurationer, och vi är inte säkra på att de alla är aktuella."
ISO 27001-fyndet
Ett efterlevnadskonsultföretags 15-personers team använde fyra olika verktyg: ett web scraping-verktyg för online-data, ett fristående Windows-skrivbordsverktyg för bulkfiler, en Word-makro för juridiska dokument och ett Chrome-tillägg för AI-verktyg.
En ISO 27001-revision producerade ett fynd: "Inkonsekventa dataanonymiseringsprocedurer över plattformar. Olika verktyg används för olika kontexter och ger olika detekteringsresultat och inget centraliserat revisionsspår. Detta skapar en lucka i kontrollen ISO/IEC 27001:2022 Bilaga A 8.11 (Datamaskering) — kontrollen kan inte demonstreras som konsekvent tillämpad."
Revisionsfyndet krävde en korrigerande åtgärdsplan. Den korrigerande åtgärden som genomfördes: konsolidering till en enda anonymiseringsplattform för alla användningsfall.
Resultat efter konsolidering:
- Samma detekteringsmotor över alla plattformar (Webbapp, Skrivbordsapp, Office-tillägg, Chrome-tillägg)
- Samma förinställningar tillämpas över kontexter
- Centraliserat revisionsspår för all bearbetning
- ISO 27001-fynd stängt vid nästa övervakningsrevision
Det 6 veckor långa konsolideringsprojektet eliminerade revisionsfyndet som hade krävt ett 12-sidigt korrigerande åtgärdsvar.
Testet av efterlevnadsberättelsen
Ett användbart test för att utvärdera PII-verktygsfragmentering: kan du tydligt svara på följande frågor?
- Vilka enhetstyper detekteras över alla plattformar som ditt team använder för PII-anonymisering?
- Vad är detekteringströskeln (förtroendenivå) för varje enhetstyp, konsekvent över alla plattformar?
- Var är det centraliserade revisionsspåret för all anonymiseringsbearbetning under de senaste 12 månaderna?
- Hur säkerställer ni att konfigurationsändringar tillämpas konsekvent över alla plattformar?
Om någon av dessa frågor ger ett tveksamt svar, skapar fragmenteringen efterlevnadsrisk. Det rena svaret på alla fyra frågor är uppnåeligt — men endast med en enhetlig motor över plattformar.
Källor: