Problemet med dokumentation av PII-ackumulering
Interna kunskapsbaser — Confluence, Notion, SharePoint, GitBook — ackumulerar en specifik typ av PII-problem som nästan helt är osynlig för standardverktyg för efterlevnad: kundens personuppgifter inbäddade i skärmdumpar som används för processdokumentation.
Scenariot utspelar sig över tusentals support- och driftteam:
En supportagent upptäcker en ovanlig kontokonfiguration. De tar en skärmdump av kundens kontosida för att dokumentera problemet för den kunskapsbasartikel som skrivs. Skärmdumpen innehåller kundens namn i UI-huvudet, deras e-postadress i kontoinställningarna och deras prenumerationsdetaljer.
Kunskapsbasartikeln publiceras på den interna wikin. 150 supportagenter kan nu få tillgång till den. 12 entreprenörer som arbetar från den externa hjälpdesk kan få tillgång till den. Artikeln är en användbar dokumentation av hur man hanterar det speciella fallet.
Tre år senare har kunskapsbasen 847 sådana artiklar. Varje artikel innehåller skärmdumpar av kundkonton. Kunderna vars kontodata visas i skärmdumparna har inte samtyckt till denna sekundära användning av sina data. De flesta vet inte att deras data finns i den interna wikin.
GDPR-exponering: Varför detta inte är ett litet problem
GDPR-analysen för interna dokumentationsskärmdumpar:
Dataminimering (Artikel 5(1)(c)): Personuppgifter måste vara "tillräckliga, relevanta och begränsade till vad som är nödvändigt." En kunskapsbasartikel om kontokonfigurationens speciella fall kräver inte den verkliga kundens namn och e-postadress. En sanerad skärmdump (kundens namn suddat) skulle tjäna dokumentationssyftet lika bra. Inkluderingen av de verkliga kunduppgifterna är inte nödvändig.
Ändamålsbegränsning (Artikel 5(1)(b)): Personuppgifter som samlats in för ett syfte (kundserviceinteraktion) kan inte återanvändas för ett annat syfte (intern processdokumentation) utan rättslig grund. Kundens kontodata samlades in för tjänsteleverans, inte för att dokumentera interna speciella fall.
Åtkomstkontroll (Artikel 5(1)(f) och Artikel 32): Lämpliga tekniska åtgärder måste skydda personuppgifter. Skärmdumpar av kundkonton i en wiki som är tillgänglig för alla 150 agenter och entreprenörer — inklusive de som kanske inte har tillgång till det underliggande kundkontosystemet — representerar olämplig bred åtkomst till personuppgifter.
Rätt till radering (Artikel 17): En registrerad som begär radering av sina personuppgifter har rätt att få dem raderade "utan onödigt dröjsmål." Om deras data visas i 23 kunskapsbasartiklar som inbäddade skärmdumpar, kräver raderingsbegäran att man hittar och bearbetar alla 23 artiklar — en operativt svår uppgift utan systematisk upptäcktsmetod.
Åtkomstkontrollens omväg
Det mest betydande efterlevnadsproblemet med wiki-skärmdumpar är den åtkomstkontrollomväg de skapar.
Supportorganisationer använder typiskt RBAC för att kontrollera vem som kan få tillgång till kundkontosystem. Tier 1-agenter får tillgång till grundläggande kontoinformation. Tier 2-agenter får tillgång till fakturerings- och tekniska detaljer. Chefer och administratörer får tillgång till hela kontoprofilen.
När en Tier 2-agent skapar en kunskapsbasartikel med en skärmdump av hela kundens kontoprofil, blir den skärmdumpen tillgänglig för alla wiki-användare — inklusive Tier 1-agenter som inte bör ha tillgång till faktureringsdetaljer, entreprenörer som överhuvudtaget inte har systemåtkomst, och nya anställda under introduktionen.
Skärmdumpen kringgår RBAC-kontrollerna på kundkontosystemet. De personuppgifter som RBAC var avsett att skydda är nu tillgängliga för alla med wikiåtkomst.
Praktisk åtgärd: Retroaktiv och prospektiv
För organisationer som upptäcker detta problem under en GDPR-audit:
Retroaktiv åtgärd:
- Identifiera alla interna wiki-sidor som inkluderar bilagor av bilder
- Kör PII-detektering på alla bilagor av bilder
- Triage resultat: bilder med hög säkerhet för PII-detektioner flaggade för granskning
- För flaggade bilder: antingen ersätta med sanerade versioner eller lägga till lämpliga åtkomstkontroller till wikisidan
- Dokumentera åtgärder för GDPR-ansvarighetsregister
Omfattningen av retroaktiv åtgärd beror på kunskapsbasens storlek. För en 3-årig kunskapsbas i ett supportteam med 50 personer kan antalet bilder vara i tusentals. Batchbehandling av bilder gör detta genomförbart; den viktigaste flaskhalsen är mänsklig granskning av flaggade bilder.
Prospektiva kontroller:
- Processdokumentation: alla medlemmar i supportteamet utbildas för att sanera skärmdumpar innan de används i wikin
- Teknisk hjälp: verktyg för skärmdumpsannotering (sudda kundnamn innan klippning)
- Granskningssteg: utsedd granskare godkänner wikiartiklar innan publicering, specifikt kontrollerar för kund-PII i bilder
- Periodisk granskning: kvartalsvis batchbild-PII-skanning av alla wiki-bilagor
Minimalt livskraftig kontroll (för resursbegränsade team): En publiceringschecklista för wikin som inkluderar "Ta bort eller sudda alla kundnamn, e-postadresser och kontonummer från skärmdumpar innan publicering." Lågteknologisk, icke-automatiserad, men skapar dokumentation av kontrollen.
Varför problemet förvärras över tid
Utan systematiska kontroller förvärras det interna wiki PII-problemet över tid:
Volym: Varje ny kunskapsbasartikel med en kundskärmdump lägger till den totala PII-exponeringen. När supportteamet växer och kunskapsbasen expanderar, växer den ackumulerade PII proportionellt.
Glömda artiklar: Artiklar som dokumenterar gamla speciella fall som inte längre inträffar kan glömmas i wikin men fortfarande vara tillgängliga — innehållande PII från kunder som sedan har lämnat in raderingsbegärningar.
Spridning mellan team: Kunskapsbaser blir ofta tvärfunktionella. En supportartikel med kundskärmdumpar kan delas med produktteamet, ingenjörsteamet eller externa entreprenörer som kontext för en funktionsförfrågan eller buggrapport.
Rätt till raderingsbacklog: Ju mer kunddata som ackumuleras i wikin, desto mer komplext blir det att svara på raderingsbegärningar. Utan systematisk upptäcktsmetod finns det inget pålitligt sätt att bekräfta att alla instanser av en registrerads information har identifierats och raderats.
För GDPR-efterlevnad är den konsekventa slutsatsen att kunskapsbas-PII är lättare att förhindra än att åtgärda. Prospektiva kontroller — genomförda nu — undviker det exponentiellt växande åtgärdsproblemet.
Källor: