Skärmdumps-PII i interna kunskapsbaser
Interna kunskapsbaser — Confluence, Notion, SharePoint, GitBook — innehåller en specifik typ av PII-problem som standardverktyg för efterlevnad missar: kundpersonuppgifter inbäddade i skärmdumpar som används i processdokumentation.
Mönstret upprepas i tusentals support- och driftsteam.
En supportagent hittar en ovanlig kontokonfiguration. De tar en skärmdump av kundens kontosida för att dokumentera problemet. Skärmdumpen visar kundens namn i UI-rubriken, deras e-post i kontoinställningarna och deras planinformation.
Artikeln publiceras i den interna kunskapsbasen. Etthundrafemtio supportagenter kan nu se den. Tolv entreprenörer på den externa helpdisken kan också se den. Artikeln är användbar. Den visar hur man hanterar det gränsfall. Varje agent som stöter på den konfigurationen i framtiden kommer att läsa den.
Tre år senare innehåller kunskapsbasen 847 sådana artiklar. Var och en innehåller skärmdumpar av kundkonton. De kunder som visas gav inte samtycke till denna sekundära användning av deras uppgifter. De flesta vet inte att deras data lagras där.
Detta är inte ett litet problem. Det växer med varje ny artikel.
GDPR-exponering: Varför detta spelar roll
GDPR-analysen för kunskapsbasskärmdumpar är direkt.
Dataminimering (Artikel 5(1)(c)): Personuppgifter måste vara "adekvata, relevanta och begränsade till vad som är nödvändigt." En kunskapsbasartikel om kontokonfiguration behöver inte den riktiga kundens namn och e-post. En suddig skärmdump tjänar syftet lika bra. Att inkludera live-kunddata är inte nödvändigt.
Ändamålsbegränsning (Artikel 5(1)(b)): Data som samlats in för ett syfte — kundservice — kan inte återanvändas för ett annat syfte — intern processdokumentation — utan rättslig grund. Kontoposter samlades in för serviceleverans, inte för intern dokumentation. Dessa är två skilda behandlingssyften. Att använda samma poster för båda kräver en giltig rättslig grund som de flesta team inte har etablerat.
Åtkomstkontroll (Artikel 5(1)(f) och Artikel 32): Lämpliga tekniska åtgärder måste skydda personuppgifter. Kundkontoskärmdumpar i ett verktyg öppet för alla 150 agenter och entreprenörer — inklusive de utan åtkomst till det underliggande kontosystemet — skapar alltför bred åtkomst.
Rätten till radering (Artikel 17): En registrerad som begär radering har rätt att få sina uppgifter borttagna "utan onödigt dröjsmål." Om deras data finns i 23 kunskapsbasartiklar som inbäddade skärmdumpar kräver förfrågan att alla 23 artiklarna hittas och uppdateras. Det är svårt utan ett system. Vår GDPR-raderingsguide täcker stegen i detalj.
Inget av detta är kantlästolkningar. De är direkta tillämpningar av förordningstexten på en vanlig praxis.
Åtkomstkontrollkringgåendet
Det allvarligaste efterlevnadsproblemet med Confluence-skärmdumpar är det åtkomstkontrollkringgående de skapar.
Supportteam använder rollbaserad åtkomstkontroll (RBAC) för att begränsa vem som kan se kundkontosystem. Nivå 1-agenter ser grundläggande kontodetaljer. Nivå 2-agenter ser fakturerings- och tekniska uppgifter. Chefer ser hela kontoprofilen.
När en Nivå 2-agent skapar en kunskapsbasartikel med en skärmdump av hela kundkontot, blir den skärmdumpen synlig för varje användare av verktyget. Nivå 1-agenter som inte bör se faktureringsuppgifter kan nu se dem. Entreprenörer utan systemåtkomst kan se dem. Ny personal i introduktion kan se dem.
Skärmdumpen kringgår RBAC-kontrollerna på kundkontosystemet. De personuppgifter som RBAC byggdes för att skydda är nu öppna för alla med åtkomst till kunskapsbasen.
Detta är inte en teoretisk risk. Det är det normala resultatet av dokumentationsarbetsflödet. Skärmdumpen sitter där utan utgångsdatum, åtkomstlogg eller revisionsprotokoll.
Praktiska åtgärdssteg
För team som hittar detta problem under en GDPR-revision:
Retroaktiv åtgärd:
- Identifiera alla kunskapsbasssidor med bildbilagor
- Kör bild-PII-identifiering på varje bilaga
- Granska flaggade bilder: träffar med hög konfidenspoäng går till granskningskön
- För varje flaggad bild: ersätt med en sanerad version eller begränsa sidåtkomst
- Logga åtgärdsåtgärder för GDPR-dokumentation
Omfattningen av retroaktivt arbete beror på kunskapsbasens storlek. För en tre år gammal kunskapsbas på ett 50-personers supportteam kan bildantalet nå tusentals. Batchbildbearbetning gör detta genomförbart. Mänsklig granskning av flaggade bilder är den viktigaste flaskhalsen.
Framåtblickande kontroller:
- Utbilda all supportpersonal att sanera skärmdumpar innan publicering i kunskapsbasen
- Tillhandahåll verktyg: skärmdumpsannoteringverktyg som sudddar kundnamn innan inklistring
- Lägg till ett granskningssteg: en utsedd granskare kontrollerar artiklar innan publicering, specifikt för kund-PII i bilder
- Kör en kvartalvis batchbildskanning av alla Confluence-bilagor
Minimalt genomförbar kontroll: En publiceringschecklista: "Ta bort eller sudda ut alla kundnamn, e-postadresser och konto-ID:n från skärmdumpar innan publicering." Lågteknologisk, icke-automatiserad, men skapar en dokumenterad kontroll. För små team är detta startpunkten.
Se vår GDPR-efterlevnadsöversikt för det bredare juridiska ramverket, och varför policy utan tekniska kontroller misslyckas för varför checklistabaserade tillvägagångssätt bryter ihop i stor skala.
Varför problemet växer med tiden
Utan systematiska kontroller förvärras kunskapsbas-PII-exponering.
Volym: Varje ny artikel med en kundskärmdump ökar den totala exponeringen. I takt med att supportteamet växer och kunskapsbasen expanderar ökar den ackumulerade PII:n också. De egenskaper som gör dessa verktyg användbara — enkel publicering, beständighet, bred åtkomst — är det som förvärrar PII-problemet.
Glömda artiklar: Artiklar om gamla gränsfall som inte längre dyker upp förblir tillgängliga. De innehåller PII från kunder som sedan dess har lämnat in raderingsförfrågningar. Ingen kontrollerar en artikel senast uppdaterad 2022.
Tvärteamsspridning: Kunskapsbaser går ofta tvärfunktionellt. En supportartikel med kundskärmdumpar kan delas med produktteamet, ingenjörsteamet eller externa entreprenörer för sammanhang kring en funktionsförfrågan eller felrapport. Varje delning vidgar publiken för personuppgifterna.
Raderingseftersläpning: I takt med att fler kunduppgifter samlas i kunskapsbasen blir det mer komplext att svara på raderingsförfrågningar. Utan ett system finns det inget tillförlitligt sätt att bekräfta att varje instans av en registrerad persons uppgifter har hittats och tagits bort. Teamet kan inte göra en trovärdig raderingsattest.
Kunskapsbas-PII är lättare att förhindra än att åtgärda. Kontroller som implementeras nu undviker det sammansatta åtgärdsproblemet. Varje artikel som publiceras utan en suddig skärmdump är en åtgärdsuppgift uppskjuten till framtiden.