Problemet med akkumulering av PII i dokumentasjonen
Interne kunnskapsbaser — Confluence, Notion, SharePoint, GitBook — akkumulerer en spesifikk type PII-problem som er nesten helt usynlig for standard samsvarsverktøy: kundens personlige data innebygd i skjermbilder brukt til prosessdokumentasjon.
Scenariet utspiller seg på tvers av tusenvis av support- og driftsteam:
En supportagent oppdager en uvanlig kontokonfigurasjon. De tar et skjermbilde av kundens kontoside for å dokumentere problemet for artikkelen i kunnskapsbasen som skrives. Skjermbildet inneholder kundens navn i UI-headeren, e-postadressen deres i kontoinnstillingene, og abonnementsdetaljene deres.
Kunnskapsbaseartikkelen publiseres til det interne wikisystemet. 150 supportagenter kan nå få tilgang til den. 12 kontraktører som jobber fra det eksterne hjelpesenteret kan få tilgang til den. Artikkelen er nyttig dokumentasjon om hvordan man håndterer dette spesielle tilfellet.
Tre år senere har kunnskapsbasen 847 slike artikler. Hver inneholder skjermbilder av kundekontoer. Kundene hvis kontodata vises i skjermbildene har ikke samtykket til denne sekundære bruken av dataene sine. De fleste vet ikke at dataene deres er i det interne wikisystemet.
GDPR-eksponering: Hvorfor dette ikke er et mindre problem
GDPR-analysen for interne dokumentasjonsskjermbilder:
Dataminimering (Artikkel 5(1)(c)): Personopplysninger må være "tilstrekkelige, relevante og begrenset til det som er nødvendig." En kunnskapsbaseartikkel om kontokonfigurasjonens spesielle tilfeller krever ikke det virkelige kundens navn og e-postadresse. Et sanitert skjermbilde (kundens navn uskarpt) ville tjene dokumentasjonsformålet like godt. Inkluderingen av de virkelige kundedataene er ikke nødvendig.
Formålsbegrensning (Artikkel 5(1)(b)): Personopplysninger samlet inn for ett formål (kundeserviceinteraksjon) kan ikke gjenbrukes for et annet formål (intern prosessdokumentasjon) uten juridisk grunnlag. Kundens kontodata ble samlet inn for tjenesteyting, ikke for å dokumentere interne spesielle tilfeller.
Tilgangskontroll (Artikkel 5(1)(f) og Artikkel 32): Passende tekniske tiltak må beskytte personopplysninger. Skjermbilder av kundekontoer i et wiki som er tilgjengelig for alle 150 agenter og kontraktører — inkludert de som kanskje ikke har tilgang til det underliggende kundekontosystemet — representerer upassende bred tilgang til personopplysninger.
Retten til sletting (Artikkel 17): En registrert som ber om sletting av sine personopplysninger har rett til å få dem slettet "uten unødig forsinkelse." Hvis dataene deres vises i 23 kunnskapsbaseartikler som innebygde skjermbilder, krever slettingsforespørselen å finne og behandle alle 23 artiklene — en operasjonelt vanskelig oppgave uten systematisk deteksjon.
Omgåelse av tilgangskontroll
Det mest betydningsfulle samsvarsproblemet med wiki-skjermbilder er omgåelsen av tilgangskontrollen de skaper.
Supportorganisasjoner bruker typisk RBAC for å kontrollere hvem som kan få tilgang til kundekontosystemer. Tier 1-agenter får tilgang til grunnleggende kontoinformasjon. Tier 2-agenter får tilgang til fakturerings- og tekniske detaljer. Ledere og administratorer får tilgang til hele kontoens profil.
Når en Tier 2-agent oppretter en kunnskapsbaseartikkel med et skjermbilde av hele kundens konto-profil, blir det skjermbildet tilgjengelig for alle wiki-brukere — inkludert Tier 1-agenter som ikke skal ha tilgang til faktureringsdetaljer, kontraktører som ikke har systemtilgang i det hele tatt, og nye ansatte under onboarding.
Skjermbildet omgår RBAC-kontrollene på kundekontosystemet. Personopplysningene som RBAC ble designet for å beskytte er nå tilgjengelige for alle med wiki-tilgang.
Praktisk utbedring: Retrospektiv og fremadskuende
For organisasjoner som oppdager dette problemet under en GDPR-revisjon:
Retrospektiv utbedring:
- Identifiser alle interne wiki-sider som inkluderer bildevedlegg
- Kjør bilde-PII-detektering på alle bildevedlegg
- Triage resultater: bilder med høy tillit til PII-detektering flagget for gjennomgang
- For flaggede bilder: enten erstatte med sanitert versjoner eller legge til passende tilgangskontroller til wiki-siden
- Dokumenter utbedringshandlinger for GDPR-ansvarlighetsregistre
Omfanget av retrospektiv utbedring avhenger av størrelsen på kunnskapsbasen. For en 3 år gammel kunnskapsbase i et supportteam på 50 personer, kan antallet bilder være i tusenvis. Batch bildebehandling gjør dette gjennomførbart; den viktigste flaskehalsen er menneskelig gjennomgang av flaggede bilder.
Fremadskuende kontroller:
- Prosessdokumentasjon: alle medlemmer av supportteamet opplært til å sanitere skjermbilder før bruk i wiki
- Teknisk assistanse: skjermbildeannotasjonsverktøy (uskarpe kunders navn før liming)
- Gjennomgangstrinn: utpekt gjennomgangsperson godkjenner wiki-artikler før publisering, spesifikt sjekker for kundens PII i bilder
- Periodisk revisjon: kvartalsvis batch bilde PII-skanning av alle wiki-vedlegg
Minimum levedyktig kontroll (for ressursbegrensede team): En sjekkliste for publisering av wiki som inkluderer "Fjern eller uskarp alle kunders navn, e-poster og kontonumre fra skjermbilder før publisering." Lavteknologisk, ikke-automatisert, men skaper dokumentasjon av kontrollen.
Hvorfor problemet blir verre over tid
Uten systematiske kontroller, forverres det interne wiki PII-problemet over tid:
Volum: Hver ny kunnskapsbaseartikkel med et kundes skjermbilde legger til den totale PII-eksponeringen. Etter hvert som supportteamet vokser og kunnskapsbasen utvides, vokser den akkumulerte PII proporsjonalt.
Glemte artikler: Artikler som dokumenterer gamle spesielle tilfeller som ikke lenger forekommer kan bli glemt i wikisystemet, men fortsatt være tilgjengelige — inneholdende PII fra kunder som siden har sendt slettingsforespørsel.
Tverrfaglig spredning: Kunnskapsbaser blir ofte tverrfaglige. En supportartikkel med kundes skjermbilder kan bli delt med produktteamet, ingeniørteamet eller eksterne kontraktører som kontekst for en funksjonsforespørsel eller feilrapport.
Retten til sletting backlog: Etter hvert som mer kundedata akkumuleres i wikisystemet, blir det mer komplekst å svare på slettingsforespørsel. Uten systematisk deteksjon er det ingen pålitelig måte å bekrefte at alle tilfeller av en registrert informasjon har blitt identifisert og slettet.
For GDPR-samsvar er den konsistente konklusjonen at PII i kunnskapsbasen er lettere å forhindre enn å utbedre. Fremadskuende kontroller — implementert nå — unngår det eksponentielt voksende utbedringsproblemet.
Kilder: