How to Comply with GDPR in Your Knowledge Base

Why Your Knowledge Base Has a GDPR Problem

Most organizations think of GDPR compliance in terms of customer databases, CRMs, and marketing systems. These are obvious holders of personal data. What organizations frequently overlook is that their internal knowledge base — the team wiki, the shared Notion workspace, the Confluence instance, the internal documentation system — also contains personal data, sometimes significant amounts of it.

Consider what ends up in a typical internal knowledge base:

• Meeting notes that include employee names, opinions, and performance feedback
• Project documentation with client names, contact information, and relationship history
• Process documentation with examples drawn from real customer cases
• Onboarding materials that mention employee details
• Sales playbooks with client research and relationship notes
• Customer support documentation with anonymization-incomplete examples
• HR-related documentation with employee information

Under GDPR (the EU General Data Protection Regulation, applicable to any organization that processes data of EU data subjects), this material constitutes personal data processing that requires a lawful basis, must meet data minimization standards, must be protected against unauthorized access, and must be subject to data subject rights (including the right to erasure).

The fact that this data is in an "internal" system rather than a customer-facing database doesn't exempt it. GDPR's scope is the data subject — the individual whose data is processed — not the system it's processed in.

---

GDPR Basics Applied to a Knowledge Base

Personal data: Any information relating to an identified or identifiable natural person. In a knowledge base, this includes names, email addresses, phone numbers, IP addresses, photographs, job titles (when linked to an identified person), client details, and in some cases opinions or assessments about identifiable individuals (meeting notes: "Sarah from Acme said she prefers X").

Data processing: Any operation on personal data — storage, retrieval, reading, sharing. Storing notes that contain a client's name in your knowledge base is processing.

Data controller: The organization that determines why and how personal data is processed. If your team maintains a knowledge base, your organization is the data controller for personal data in it.

Lawful basis for processing: GDPR requires that every processing activity have one of six lawful bases. For a knowledge base, the most common applicable bases are:

• Legitimate interests: The organization has a legitimate interest in maintaining documentation that outweighs the data subject's privacy interests. Most internal knowledge base use cases involving employee information for operational purposes fall here.
• Contractual necessity: Documentation necessary to perform a contract (client project notes, for example).
• Legal obligation: Documentation required by law or regulation.

Data subject rights: Individuals whose data you process have rights: the right to know their data is being processed (transparency), the right to access their data, the right to correct inaccurate data, the right to erasure ("right to be forgotten"), the right to restrict processing, and the right to object to processing.

---

Step 1: Audit What Personal Data Is in the Knowledge Base

Before implementing controls, understand what personal data exists in the knowledge base and why.

Categories to look for:

Customer/client data:

• Client names, email addresses, phone numbers
• Meeting notes referencing named client contacts
• Sales notes with relationship context
• Case studies or examples drawn from named customers

Employee data:

• Performance notes, feedback, reviews
• HR-related documentation
• Individual meeting notes where employee positions or opinions are attributed
• Onboarding materials with employee details

Third-party contacts:

• Vendor contacts
• Partnership contacts
• Named individuals from press, analyst, or research contexts

The audit format:

Section/page	Type of personal data	Whose data	Purpose	Necessary?
[Page title]	[Names, contact info, etc.]	[Customers / employees / other]	[Why it's there]	[Yes/No/Partially]

The "Necessary?" column is the most important. Data that isn't necessary for the stated purpose shouldn't be there.

---

Step 2: Data Minimization — Remove What Shouldn't Be There

GDPR's data minimization principle requires that personal data be adequate, relevant, and limited to what is necessary for the purpose.

In knowledge bases, violations of this principle are common because documentation is often written without privacy considerations:

Unnecessarily named examples: Meeting notes like "Marcus from Acme said the pricing is too high" — the name "Marcus from Acme" is probably not necessary for whatever operational purpose the note serves. Anonymized: "A senior contact at Acme said pricing is too high."

Client details in process documentation: Process documentation that uses real client names as examples: "When Acme Corp submits an invoice, the process is..." — the client name adds nothing to the documentation and creates a data processing activity.

Performance feedback in shared wikis: Employee performance notes in a shared team wiki are a significant GDPR concern. Named feedback ("John's presentation skills need improvement") in a document accessible to all team members processes personal data about an employee without a clear minimization rationale.

Action: After the audit, systematically anonymize or pseudonymize examples and references where the named individual's identity isn't necessary for the documentation purpose. Replace names with roles, organizations with industry sectors, or specific details with generalized ones.

---

Step 3: Access Controls — Who Can See What

GDPR's principle of integrity and confidentiality requires that personal data be processed in a manner that ensures appropriate security, including protection against unauthorized access.

An internal knowledge base where all personal data is accessible to all employees may violate this principle:

• HR-related documentation containing employee personal data should not be accessible to all employees — it should be restricted to HR and direct managers
• Client relationship details containing named contact information should be restricted to teams with a legitimate need
• Legal and compliance documentation may contain personal data that needs restricted access

Implementing access controls:

Most knowledge base platforms support permission structures:

Notion: Individual pages and databases can be shared at the workspace level or restricted to specific people and groups. Sensitive content should be in separate pages with restricted sharing, not in the main shared workspace.

Confluence: Page permissions and space permissions allow restricting access to specific groups. Sensitive documentation should be in restricted spaces.

Google Workspace (Docs/Drive): File sharing can be restricted to specific people or groups rather than the entire organization.

Obsidian (self-hosted): If self-hosted with a team setup, access controls depend on the server configuration (Joplin Server, Obsidian Sync team settings) or filesystem-level permissions.

The access control audit: For each category of personal data found in the audit, define who should have access. Implement the appropriate restrictions. Document the access control decision (who has access and why) in your GDPR record of processing activities.

---

Step 4: Retention Policies — When to Delete

GDPR's storage limitation principle requires that personal data not be kept longer than necessary for the purpose it was collected.

Knowledge bases accumulate content indefinitely without explicit retention policies. Documentation from three years ago about a project long completed may still contain client names and details — data that is no longer necessary to retain.

Defining retention periods:

Different categories of personal data have different retention needs:

Data category	Suggested retention period	Rationale
Active client project notes	Duration of project + 1 year	Operational need
Former client meeting notes	2-5 years (varies by jurisdiction/industry)	Legal/contractual reference period
Employee performance documentation	Duration of employment + 5 years	Employment law requirements
General process documentation with named examples	When no longer operationally needed	Anonymize instead of retain
Named vendor/partner contacts	Duration of relationship + 2 years	Relationship reference

Implementing retention:

A practical approach for knowledge bases:

1. Add a "review date" field to documentation pages that contain personal data
2. Schedule a quarterly or annual review where pages past their review date are evaluated: anonymize the personal data, archive the page, or delete it
3. For documentation systems that support it, set automatic archiving for pages not accessed in a defined period

---

Step 5: Data Subject Rights Compliance

GDPR data subjects (EU individuals) have rights that your organization must be able to fulfill. For a knowledge base:

Right of access: If an individual asks what personal data your organization holds about them, the knowledge base is one of the systems that must be searched. Identify that a named individual appears in meeting notes, project documentation, sales notes, etc.

Right to erasure: If an individual requests that their personal data be erased (and there's no overriding legitimate basis to retain it), the knowledge base content containing that data must be addressed. This may mean anonymizing meeting notes that mention the individual, deleting pages that reference them, or removing identifying information.

Right to correction: If personal data in the knowledge base is inaccurate and the individual requests correction, the incorrect data must be updated.

Practical implementation:

Fulfill data subject rights requests that may involve the knowledge base:

1. When a data subject access request (DSAR) is received, include the knowledge base in the search scope
2. Assign someone the responsibility for searching the knowledge base in response to DSARs
3. Use the knowledge base platform's search function to find all pages mentioning the individual's name
4. Assess each result: does it contain personal data about this individual? If so, is it necessary to retain it?

---

Step 6: Records of Processing Activities (RoPA)

GDPR Article 30 requires that organizations (with 250+ employees, or processing that is not occasional or includes special category data) maintain a Record of Processing Activities documenting their data processing.

For a knowledge base, the RoPA entry might look like:

Processing Activity: Internal knowledge base

Controller: [Organization name, contact details]
Purpose: Internal documentation, operational knowledge management
Legal basis: Legitimate interests (operational documentation)
Data subjects: Employees, clients, third-party contacts
Categories of personal data: Names, email addresses, contact information, 
  opinions and assessments in meeting notes
Recipients: Internal staff (varies by access controls)
Retention: Per retention policy (see knowledge base retention schedule)
Security measures: Access controls per platform permissions; 
  vendor security assessment for [platform name]
Transfers outside EU: [Yes/No, and basis if yes]

This record doesn't need to be complex, but it should exist and be kept up to date.

---

Tool-Specific Considerations

Notion:

Notion is operated by US-based Notion Labs. Data may be processed in the US. For EU personal data, Notion relies on Standard Contractual Clauses (SCCs) for data transfers. Review the Notion Data Processing Addendum (DPA) — organizations processing EU personal data should execute the DPA. Notion has GDPR-related documentation and DPA available to Enterprise customers; Teams customers may need to contact Notion for DPA execution.

Confluence (Atlassian):

Atlassian is based in Australia and has EU data residency options (available on Atlassian Cloud Enterprise). For GDPR compliance, execute the Atlassian Data Processing Addendum. Atlassian has GDPR-focused documentation and supports data subject access requests through their privacy program.

Google Workspace (Docs/Sites):

Google offers EU-specific data processing agreements under GDPR. Google Workspace Enterprise agreements include a Data Processing Addendum by default. Google has data residency options for EU data. Review and sign the DPA if using Google Workspace for personal data processing.

Self-hosted solutions:

Self-hosted knowledge bases (Outline, Wiki.js, Joplin Server) give the organization control over where data is processed and stored. This can simplify GDPR compliance (no need to review a vendor's data processing practices), but shifts all responsibility for security and data protection to the organization. For EU-based teams, self-hosting in an EU data center eliminates data transfer complexities.

---

Worked Example: GDPR Compliance Audit for a 30-Person SaaS Company

Setup: A 30-person UK/EU-based SaaS company uses Notion as their internal knowledge base. After a privacy review prompted by a new enterprise customer's vendor assessment questionnaire, their head of operations conducts a GDPR compliance audit.

The audit findings:

• Their CRM export is pasted into a Notion database for client research — client names, email addresses, LinkedIn profiles. This database is accessible to all 30 team members.
• Meeting notes (shared in the team wiki) regularly include client and prospect contact names and opinions: "Emily at Acme said they'd switch if we added Feature X."
• A "lessons learned" document references a customer dispute with the customer's company name, contact names, and internal assessments.

What they do:

1. Data minimization: They remove client names from meeting notes templates and add a note to style guidance: use "a contact at [Company]" not named contacts in shared meeting notes. They anonymize the lessons learned document.

2. Access controls: The CRM-export database is restricted to the sales and account management team (8 people) rather than the full workspace. HR-related pages already had restricted access; they audit these to confirm.

3. Retention: They add a "Review by" date to each knowledge base section. The CRM export database gets a 6-month review cycle.

4. Vendor compliance: They execute Notion's Data Processing Addendum.

5. RoPA: They add the knowledge base as a processing activity to their Records of Processing Activities.

Result: The vendor assessment questionnaire is answered accurately. The client data exposure is reduced. The knowledge base is compliant with documented evidence.

---

Key Takeaways

1. Internal knowledge bases process personal data and are subject to GDPR: client names in meeting notes, employee details in documentation, and vendor contacts are personal data regardless of the system they're in.
2. Data minimization is the most impactful immediate step: systematically anonymizing named examples and removing unnecessary personal data reduces both risk and compliance burden.
3. Access controls must match the sensitivity of the personal data: HR-related documentation and client relationship data should not be accessible to all team members.
4. Retention policies prevent indefinite accumulation of personal data: annual review cycles and "review by" dates prevent outdated personal data from persisting indefinitely.
5. Vendor GDPR compliance (DPA execution) is required for cloud-based knowledge base platforms: execute the Data Processing Addendum with Notion, Confluence, Google Workspace, or equivalent before processing EU personal data in those systems.

---

Conclusion

GDPR compliance in a knowledge base is not primarily a technical challenge — it's a documentation and process challenge. The most impactful actions are organizational: defining what personal data is in the knowledge base, applying data minimization (anonymizing what doesn't need to be named), setting access controls appropriate to the sensitivity of the data, establishing retention policies, and being prepared to respond to data subject rights requests. These practices produce a knowledge base that is both more compliant and, in most cases, more useful — documentation written for its operational purpose rather than as a repository of named examples tends to be cleaner and more transferable. The compliance effort is a byproduct of better documentation practice.

Try WebSnips free — capture and annotate GDPR resources, privacy compliance guides, and data protection frameworks with your own context notes, tag by regulation and data type, and build the organized knowledge base that supports your organization's data privacy compliance practice.