Hva revisorer ser når de spør om PII-kontroller
Under en GDPR tilsynsmyndighet revisjon eller ISO 27001 vurdering, er et av de standard spørsmålene: "Hvilke tekniske kontroller har du for PII-anonymisering?"
Revisoren ser etter et klart, forsvarlig svar: en spesifikk kontroll, konsekvent anvendt, med dokumentasjon på hvordan den fungerer og bevis på dens effektivitet.
Svaret som skaper samsvarsrisiko: "Vi bruker forskjellige verktøy avhengig av konteksten. For nettlesing bruker vi Chrome-utvidelsen, for Word-dokumenter bruker vi en makro, for bulkfiler har datateamet vårt et Python-skript de skrev, og for presserende forespørsel bruker vi webappen."
Dette svaret utløser et oppfølgingsspørsmål: "Hva er forskjellene i dekning mellom disse verktøyene? Hvordan sikrer du konsistente resultater på tvers av verktøy? Hvor er revisjonssporene som demonstrerer konsekvent anvendelse?"
Disse er spørsmål som fragmenterte verktøy ikke kan svare klart på.
Problemet med dekningens konsistens
Ulike PII-detekteringsverktøy bruker forskjellige underliggende deteksjonsmetoder:
Regex-only verktøy: Søker etter spesifikke mønstre (SSN-format, e-postformat, kredittkortformat). Går glipp av NER-baserte enheter (personnavn, organisasjoner som ikke matcher en kjent liste), kontekstuelle identifikatorer, og ikke-US formater.
NER-only verktøy: Oppdager enhetstyper ved hjelp av trente modeller. Går glipp av mønsterbaserte enheter (IBAN, kontonumre med spesifikke formater), tilpassede organisatoriske identifikatorer, og enheter som ikke er i treningsdataene.
Verktøy A vs. Verktøy B vs. Verktøy C: Hvert verktøy har forskjellig dekning av enhetstyper, forskjellige tillitsnivåer, og forskjellig håndtering av grense tilfeller. Det samme dokumentet behandlet gjennom Verktøy A og Verktøy C kan gi forskjellige deteksjonsresultater.
Samsvarsproblemet: hvis Verktøy A (brukt for PDF-er) oppdager fødselsdatoer, men Verktøy B (brukt for Excel) ikke gjør det, så er fødselsdatoen til den samme registrerte i en PDF anonymisert mens fødselsdatoen i et Excel-regneark ikke er det. Den systematiske samsvarskontrollen har et gap som avhenger av dokumentformat.
For DPA-undersøkelser er dette gapet oppdagbart. Hvis et databrudd skjer og undersøkelsen avdekker at Excel-regnearkversjonen av en registrert post ikke ble anonymisert mens PDF-versjonen ble det, er inkonsistensen mellom verktøyene en medvirkende faktor til eksponeringen.
Problemet med revisjonsspor
Samsvarsdokumentasjon krever bevis på at kontroller er konsekvent anvendt. For PII-anonymisering er beviset revisjonsspor: hva som ble behandlet, når, av hvem, med hvilket verktøy, og hva resultatet var.
Fire forskjellige verktøy produserer fire forskjellige revisjonssporformater — eller ingen revisjonsspor i det hele tatt. En Word-makro produserer ingen revisjonslogg. Et Python-skript kan skrive til en lokal fil som ikke er integrert med samsvarshåndteringssystemet. Chrome-utvidelsen kan produsere nettleserlogg som ikke er tilgjengelig for samsvars dokumentasjon. Bare webappen kan produsere et sentralisert revisjonsspor.
For en DPA-undersøkelse som krever revisjonssporbevis, er svaret "vi behandlet dette dokumentet i en Word-makro, de loggene er på utviklerens lokale maskin" ikke tilfredsstillende. Svaret "her er den sentraliserte revisjonsloggen som dekker all anonymiseringsbehandling på tvers av alle plattformer for den forespurte perioden" er tilfredsstillende.
Behandling på én plattform muliggjør dekning av ett revisjonsspor. Fragmenterte verktøy gjør sentralisert revisjonsspor umulig.
Problemet med konfigurasjonsdrift
Over tid utvikler forskjellige verktøy brukt av forskjellige teammedlemmer forskjellige konfigurasjoner:
- Chrome-utvidelsen er konfigurert med organisasjonens tilpassede enhetstyper
- Python-skriptet ble ikke oppdatert da de tilpassede enhetstypene ble lagt til
- Word-makroen ble konfigurert av et teammedlem som har forlatt, og ingen vet de nåværende innstillingene
- Webappens forhåndsinnstilling ble oppdatert forrige måned for å ekskludere kontraktnavn, men denne oppdateringen ble ikke videreført til de andre verktøyene
Konfigurasjonsdrift skaper inkonsistensproblemet i motsatt retning: selv om alle verktøy opprinnelig produserte lignende resultater, skaper vedlikeholdsaktivitet på ett verktøy uten å oppdatere de andre divergens over tid.
For ISO 27001-kontroller gjør kravet til konfigurasjonsdokumentasjon dette spesielt problematisk. En ISO-revisor som spør "vis meg konfigurasjonen for dine PII-anonymiseringskontroller" kan ikke få et tilfredsstillende svar med "vi har fire verktøy med fire forskjellige konfigurasjoner, og vi er ikke sikre på at de alle er oppdaterte."
ISO 27001-funnet
Et samsvars konsulentfirma sitt 15-personers team brukte fire forskjellige verktøy: et webskrapeverktøy for online data, et frittstående Windows skrivebordsverktøy for bulkfiler, en Word-makro for juridiske dokumenter, og en Chrome-utvidelse for AI-verktøy.
En ISO 27001-revisjon ga et funn: "Inkonsekvente data anonymiseringsprosedyrer på tvers av plattformer. Ulike verktøy brukt for forskjellige kontekster produserer forskjellige deteksjonsresultater og ingen sentralisert revisjonsspor. Dette skaper et gap i kontroll ISO/IEC 27001:2022 Annex A 8.11 (Data masking) — kontrollen kan ikke demonstreres som konsekvent anvendt."
Revisjonsfunnene krevde en korrigerende handlingsplan. Den korrigerende handlingen som ble implementert: konsolidering til en enkelt anonymiseringsplattform for alle bruksområder.
Resultater etter konsolidering:
- Samme deteksjonsmotor på tvers av alle plattformer (Web App, Desktop App, Office Add-in, Chrome Extension)
- Samme forhåndsinnstillinger brukt på tvers av kontekster
- Sentralisert revisjonsspor for all behandling
- ISO 27001-funnet lukket ved neste overvåkingsrevisjon
Det 6-ukers konsolideringsprosjektet eliminerte revisjonsfunnene som hadde krevd et 12-siders korrigerende handlingssvar.
Samsvarsnarrativtesten
En nyttig test for å evaluere fragmenteringen av PII-verktøy: kan du klart svare på følgende spørsmål?
- Hvilke enhetstyper oppdages på tvers av alle plattformer teamet ditt bruker for PII-anonymisering?
- Hva er deteksjonsterskelen (tillitsnivået) for hver enhetstype, konsekvent på tvers av alle plattformer?
- Hvor er det sentraliserte revisjonsspor for all anonymiseringsbehandling de siste 12 månedene?
- Hvordan sikrer du at konfigurasjonsendringer blir konsekvent anvendt på tvers av alle plattformer?
Hvis noen av disse spørsmålene gir et nølende svar, skaper fragmentering samsvarsrisiko. Det klare svaret på alle fire spørsmålene er oppnåelig — men bare med en enhetlig motor på tvers av plattformer.
Kilder: