The Internal Wiki PII Problem: Why Your Confluence and Notion Pages Are Full of Customer Data

The Documentation PII Accumulation Problem

Internal knowledge bases — Confluence, Notion, SharePoint, GitBook — accumulate a specific type of PII problem that is almost entirely invisible to standard compliance tools: customer personal data embedded in screenshots used for process documentation.

The scenario plays out across thousands of support and operations teams:

A support agent discovers an unusual account configuration. They screenshot the customer's account page to document the issue for the knowledge base article being written. The screenshot contains the customer's name in the UI header, their email address in the account settings, and their subscription details.

The knowledge base article is published to the internal wiki. 150 support agents can now access it. 12 contractors working from the external helpdesk can access it. The article is useful documentation of how to handle the edge case.

Three years later, the knowledge base has 847 such articles. Each contains screenshots of customer accounts. The customers whose account data appears in the screenshots have not consented to this secondary use of their data. Most do not know their data is in the internal wiki.

GDPR Exposure: Why This Is Not a Minor Issue

The GDPR analysis for internal documentation screenshots:

Data minimization (Article 5(1)(c)): Personal data must be "adequate, relevant and limited to what is necessary." A knowledge base article about account configuration edge cases does not require the real customer's name and email address. A sanitized screenshot (customer name blurred) would serve the documentation purpose equally well. The inclusion of the real customer data is not necessary.

Purpose limitation (Article 5(1)(b)): Personal data collected for one purpose (customer service interaction) cannot be repurposed for another purpose (internal process documentation) without legal basis. The customer's account data was collected for service provision, not for documenting internal edge cases.

Access control (Article 5(1)(f) and Article 32): Appropriate technical measures must protect personal data. Customer account screenshots in a wiki accessible to all 150 agents and contractors — including those who may not have access to the underlying customer account system — represent inappropriate broad access to personal data.

Right to erasure (Article 17): A data subject requesting erasure of their personal data has the right to have it erased "without undue delay." If their data appears in 23 knowledge base articles as embedded screenshots, the erasure request requires finding and processing all 23 articles — an operationally difficult task without systematic detection.

The Access Control Bypass

The most significant compliance issue with wiki screenshots is the access control bypass they create.

Support organizations typically use RBAC to control who can access customer account systems. Tier 1 agents access basic account information. Tier 2 agents access billing and technical details. Managers and administrators access the full account profile.

When a Tier 2 agent creates a knowledge base article with a screenshot of the full customer account profile, that screenshot becomes accessible to all wiki users — including Tier 1 agents who should not have access to billing details, contractors who do not have system access at all, and new employees during onboarding.

The screenshot bypasses the RBAC controls on the customer account system. The personal data that the RBAC was designed to protect is now accessible to everyone with wiki access.

Practical Remediation: Retroactive and Prospective

For organizations discovering this problem during a GDPR audit:

Retroactive remediation:

1. Identify all internal wiki pages that include image attachments
2. Run image PII detection on all image attachments
3. Triage results: images with high-confidence PII detections flagged for review
4. For flagged images: either replace with sanitized versions or add appropriate access controls to the wiki page
5. Document remediation actions for GDPR accountability records

The scale of retroactive remediation depends on knowledge base size. For a 3-year-old knowledge base at a 50-person support team, the image count may be in the thousands. Batch image processing makes this feasible; the key bottleneck is human review of flagged images.

Prospective controls:

1. Process documentation: all support team members trained to sanitize screenshots before wiki use
2. Technical assistance: screenshot annotation tools (blurring customer names before paste)
3. Review step: designated reviewer approves wiki articles before publication, specifically checking for customer PII in images
4. Periodic audit: quarterly batch image PII scan of all wiki attachments

Minimum viable control (for resource-constrained teams): A wiki publication checklist that includes "Remove or blur all customer names, emails, and account IDs from screenshots before publishing." Low-tech, non-automated, but creates documentation of the control.

Why the Problem Gets Worse Over Time

Without systematic controls, the internal wiki PII problem compounds over time:

Volume: Each new knowledge base article with a customer screenshot adds to the total PII exposure. As the support team grows and the knowledge base expands, the accumulated PII grows proportionally.

Forgotten articles: Articles documenting old edge cases that no longer occur may be forgotten in the wiki but still accessible — containing PII from customers who have since submitted erasure requests.

Cross-team spread: Knowledge bases frequently become cross-functional. A support article with customer screenshots may be shared with the product team, the engineering team, or external contractors as context for a feature request or bug report.

Right to erasure backlog: As more customer data accumulates in the wiki, responding to erasure requests becomes more complex. Without systematic detection, there is no reliable way to confirm that all instances of a data subject's information have been identified and erased.

For GDPR compliance, the consistent finding is that knowledge base PII is easier to prevent than to remediate. Prospective controls — implemented now — avoid the exponentially growing remediation problem.

Sources:

• GDPR Article 5: Principles for Data Processing
• ICO: Data Minimisation Guidance
• GDPR Article 17: Right to Erasure