By · Last updated 2026-06-05

Tilbage til BlogAI Sikkerhed

Intern Wiki-PII: Confluence med Kundedata

Supportteams dokumenterer processer med screenshots af kundekonti. Over 3 år udgør det tusindvis af GDPR-dataminimeringsovertrædelsesr i din vidensbase.

June 5, 20266 min læsning
Confluence GDPRinternal wiki PIIcustomer datadocumentation privacydata minimization

Screenshot-PII i Interne Vidensbaserer

Interne vidensbaserer — Confluence, Notion, SharePoint, GitBook — har et specifikt PII-problem, som standard overholdelsesværktøjer overser: personlige kundeoplysninger indlejret i screenshots brugt til procesdokumentation.

Mønsteret gentages på tværs af tusindvis af support- og driftsteams.

En supportmedarbejder finder en usædvanlig kontoopsætning. De tager et screenshot af kundens kontoside for at dokumentere problemet. Screenshottet viser kundens navn i UI-overskriften, deres e-mail i kontoindstillinger og deres plandetaljer.

Artiklen offentliggøres i den interne vidensbase. 150 supportmedarbejdere kan nu se den. Tolv entreprenører på den eksterne helpdesk kan også se den. Artiklen er nyttig. Den viser, hvordan man håndterer den pågældende kanttilfælde. Enhver medarbejder, der støder på denne opsætning i fremtiden, vil læse den.

Tre år senere indeholder vidensbasen 847 sådanne artikler. Hver indeholder screenshots af kundekonti. De viste kunder gav ikke samtykke til denne sekundære brug af deres oplysninger. De fleste ved ikke, at deres data er lagret der.

Dette er ikke et lille problem. Det vokser med hver ny artikel.

GDPR-Eksponering: Hvorfor Det Betyder Noget

GDPR-analysen for vidensbasescreenshots er direkte.

Dataminimering (Artikel 5(1)(c)): Personoplysninger skal være "tilstrækkelige, relevante og begrænset til, hvad der er nødvendigt." En vidensbaseartikel om kontoopsætning har ikke brug for den rigtige kundes navn og e-mail. Et sløret screenshot tjener formålet lige så godt. At inkludere live kundedata er ikke nødvendigt.

Formålsbegrænsning (Artikel 5(1)(b)): Data indsamlet til ét formål — kundeservice — kan ikke genbruges til et andet formål — interne procesdokumenter — uden et retsgrundlag. Kontooplysninger blev indsamlet til servicelevering, ikke til intern dokumentation. Det er to forskellige behandlingsformål. Brug af de samme oplysninger til begge kræver et gyldigt retsgrundlag, som de fleste teams ikke har etableret.

Adgangskontrol (Artikel 5(1)(f) og Artikel 32): Passende tekniske foranstaltninger skal beskytte personoplysninger. Kundekontoscreenshots i et værktøj åbent for alle 150 medarbejdere og entreprenører — herunder dem uden adgang til det underliggende kontosystem — skaber unødigt bred adgang.

Ret til sletning (Artikel 17): En registreret, der anmoder om sletning, har ret til at få sine oplysninger fjernet "uden unødig forsinkelse." Hvis deres data optræder i 23 vidensbaseartikler som indlejrede screenshots, kræver anmodningen at finde og opdatere alle 23 artikler. Det er svært uden et system. Vores GDPR-ret-til-sletningsvejledning dækker trinene i detaljer.

Ingen af disse er kanttilfælde-fortolkninger. De er direkte anvendelser af forordningsteksten på en almindelig praksis.

Adgangskontrolomgåelsen

Det mest alvorlige overholdelsesspørgsmål med Confluence-screenshots er den adgangskontroloms gåelse, de skaber.

Supportteams bruger rollebaserede adgangskontroller (RBAC) til at begrænse, hvem der kan se kundekontsystemer. Niveau 1-medarbejdere ser kun grundlæggende kontooplysninger. Niveau 2-medarbejdere ser fakturerings- og tekniske oplysninger. Ledere ser den fulde kontoprofil.

Når en Niveau 2-medarbejder opretter en vidensbaseartikel med et screenshot af den fulde kundekonto, bliver dette screenshot synligt for alle brugere af værktøjet. Niveau 1-medarbejdere, der ikke burde se faktureringsoplysninger, kan nu se dem. Entreprenører uden systemadgang kan se dem. Nye medarbejdere under onboarding kan se dem.

Screenshottet omgår RBAC-kontrollerne på kundekontsystemet. De personoplysninger, som RBAC var designet til at beskytte, er nu åbne for alle med adgang til vidensbasen.

Dette er ikke en teoretisk risiko. Det er det normale resultat af dokumentationsworkflowet. Screenshottet ligger der uden udløbsdato, ingen adgangslog og ingen revisionsspor.

Praktiske Afhjælpningstrin

For teams, der opdager dette problem under en GDPR-revision:

Retroaktiv afhjælpning:

  1. Identificer alle vidensbasesider med billedvedhæftninger
  2. Kør billed-PII-detektion på alle vedhæftninger
  3. Gennemgå markerede billeder: hits med høj konfidence sendes til gennemgangskøen
  4. For hvert markeret billede: erstat med en renset version eller begræns sideadgang
  5. Log afhjælpningshandlinger til GDPR-dokumentation

Omfanget af retroaktivt arbejde afhænger af vidensbasens størrelse. For en tre år gammel vidensbase i et 50-personers supportteam kan billedantallet nå tusinder. Batchbilledbehandling gør dette gennemførligt. Menneskelig gennemgang af markerede billeder er den vigtigste flaskehals.

Fremtidige kontroller:

  1. Træn alt supportpersonale i at rense screenshots inden publicering til vidensbasen
  2. Tilbyd værktøjer: screenshot-annoteringsværktøjer, der slører kundenavne inden indsætning
  3. Tilføj et gennemgangstrin: en udpeget reviewer kontrollerer artikler inden publicering og leder specifikt efter kunde-PII i billeder
  4. Kør en kvartalvis batchbilledscanning af alle Confluence-vedhæftninger

Minimums gennemførlig kontrol: En publiceringst jekliste: "Fjern eller slør alle kundenavne, e-mails og konto-ID'er fra screenshots inden publicering." Lavteknologisk, ikke-automatiseret, men det skaber en dokumenteret kontrol. For små teams er dette udgangspunktet.

Se vores GDPR-overholdelsesoversigt for den bredere juridiske ramme, og hvorfor politik uden tekniske kontroller fejler for, hvorfor tjeklistebaserede tilgange bryder ned i stor skala.

Hvorfor Problemet Vokser Over Tid

Uden systematiske kontroller akkumulerer vidensbase-PII-eksponeringen.

Volumen: Hver ny artikel med et kundescreenshot lægger til den samlede eksponering. Efterhånden som supportteamet vokser og vidensbasen udvides, vokser den akkumulerede PII også. De egenskaber, der gør disse værktøjer nyttige — nem publicering, permanens, bred adgang — er det, der forværrer PII-problemet.

Glemte artikler: Artikler om gamle kanttilfælde, der ikke længere opstår, forbliver tilgængelige. De indeholder PII fra kunder, der siden har indsendt sletningsanmodninger. Ingen kontrollerer en artikel sidst opdateret i 2022.

Tværteam-spredning: Vidensbaserer går ofte på tværs af funktioner. En supportartikel med kundescreenshots kan deles med produktteamet, ingeniørteamet eller eksterne entreprenører for kontekst om en funktionsanmodning eller fejlrapport. Hver deling udvider publikummet for personoplysningerne.

Sletningsefterslæb: Efterhånden som flere kundejournaler hober sig op i vidensbasen, bliver det mere komplekst at besvare sletningsanmodninger. Uden et system er der ingen pålidelig måde at bekræfte, at hvert tilfælde af en registrerets data er fundet og fjernet. Teamet kan ikke afgive en troværdig sletnin gsattest.

Vidensbase-PII er lettere at forebygge end at rette. Kontroller sat i gang nu undgår det akkumulerende afhjælpningsproblem. Hver artikel publiceret uden et sløret screenshot er en afhjælpningsopgave udsat til fremtiden.

Kilder

Klar til at beskytte dine data?

Begynd at anonymisere PII med 285+ enhedstyper på tværs af 48 sprog.

About this page

We update this page when our platform or the law changes.

Read our founder note for how we work.

Each change shows up in the timestamp at the top.

Related reading

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022.
  • NIS2 (EU 2022/2555).
  • HIPAA safe harbor under 45 CFR § 164.514(b)(2).

Our promise

We do not sell your data.

We do not train models on your text.

We store your files in Germany.

You can delete your account at any time.

You own your work.

Where we run

Our servers live in Falkenstein, Germany.

We use Hetzner. They hold ISO 27001 certification.

All data stays in the EU.

Backups run every day.

Need help?

Email support@anonym.legal.

We reply within one business day.

How we test

We run a full check suite on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We track recall and precision on a labelled set.

Bad runs block the deploy.

What we never do

  • We never sell your information to third parties.
  • We never train models on what you upload.
  • We never keep your work after you delete it.
  • We never share keys with any outside firm.
  • We never run ads inside the product.

Plans in plain words

We sell credits, not seats.

One credit covers one short job.

Long jobs use a few credits each.

You can top up at any time.

Unused credits roll over each month.

Read the plans page for current rates.

Who built this

A small team of engineers and lawyers built this.

We ship from Europe and work in the open.

Our founder note spells out why we started.

Where to start

How the parts fit

A browser add-on cleans text inside Chrome.

A Word plug-in handles drafts in Office.

A small desktop tool works on whole folders.

An agent protocol link feeds large models safely.

All four share one core engine and one rule set.

Words from our team

We started this work after a lunch about cookies.

One friend kept getting odd ads on her phone.

We asked why a court file leaked through a draft.

We sketched the first build on a napkin that week.

By month three we had a tiny demo for a friend.

She used it on her first case the next day.

Common questions we hear

Can the tool read scanned PDFs? Yes, with OCR.

Does it work on long files? Yes, in small chunks.

Can I roll my own rule set? Yes, save it as a preset.

Does it run offline? The desktop build runs offline.

Do you keep my files? No, the cloud build wipes after each run.

Will it learn from my work? No, we never train on inputs.

A short tour of the workflow

Upload a file or paste a snippet of prose.

Pick the entities you want gone from the draft.

Choose a method: replace, mask, hash, encrypt, or redact.

Press run and watch the side panel show each hit.

Skim the result and tweak any rule that misfired.

Save the cleaned file or send it to a teammate.