A knowledge base doesn't seem like a typical data protection risk. It's mostly articles, screenshots and how-to guides. But once you look closer, it handles more personal data than you might think: names and email addresses of your editors, IP addresses of every visitor, feedback that customers leave on articles, and often internal documents that mention employees, clients or processes.
So for companies in the EU, choosing a knowledge base is also a GDPR decision. We at eniston are a German company, and our customers ask about this often. In this article we've put together a practical checklist to help you assess any knowledge base tool, including ours.
Please note: this article is practical guidance, not legal advice. For your specific situation, talk to your data protection officer or legal counsel.
No piece of software is "GDPR-compliant" just because the vendor says so. Compliance comes from how a tool is built and run and how you use it. Under the GDPR, your company is usually the controller of the personal data in your knowledge base, and the software vendor is a processor working on your behalf.
That gives you two jobs:
Choose a processor that offers sufficient guarantees (Art. 28 GDPR).
Set up and use the tool in a way that respects data minimisation, access control and the rights of the people involved.
The checklist below covers both.
If a vendor processes personal data for you, you need a data processing agreement (in German: Auftragsverarbeitungsvertrag, AVV). It should be easy to find, not something you have to fight for over weeks of emails.
Check: Is the DPA public or available on request? Does it list the technical and organisational measures (TOMs)? Does it describe how sub-processors are handled?
Hosting in the EU doesn't make a tool compliant automatically, but it does remove a whole category of questions about transfers to third countries. Many teams also prefer a vendor that is itself based in the EU, so the contract, the jurisdiction and the support all sit under the same legal framework.
Check: Which country are the servers in? Who runs the data center, and is it certified (for example ISO 27001)? Is the vendor's company based in the EU?
Almost every SaaS tool uses other services: hosting, CDN, email delivery, payment, and more and more often AI providers. Each of them may process personal data.
Check: Does the vendor name its sub-processors? Are any outside the EU? If so, what is the legal basis for the transfer (for example the EU-US Data Privacy Framework or standard contractual clauses)?
AI writing assistants are useful, but they are often the one part of a tool that sends text to a provider outside the EU. That isn't a dealbreaker in itself. What matters is that it's transparent and that you can control it.
Check: Which provider powers the AI features? Is your content used to train models? Can you choose not to use AI features at all? Train your editors not to paste personal data into AI prompts.
A public help center is a website, so the usual rules apply. If the knowledge base sets non-essential cookies or loads third-party trackers, you may need a consent banner, and visitors will notice that.
Check: Which cookies does the public knowledge base set? Is there tracking you can't switch off? If you add your own analytics or chat widgets through custom code, you're responsible for those too.
Internal knowledge bases often hold the most sensitive information: HR processes, client details, internal contacts. A "hidden" link is not access control.
Check: Can you restrict a knowledge base to logged-in users, specific IP addresses or a password? Can you restrict individual categories? Are there roles, so not everyone can edit or delete everything?
The GDPR expects you to limit access to what people need. In practice, this means proper roles and clean offboarding when someone leaves.
Check: How many permission levels are there? Can you remove a team member quickly? Does the pricing model encourage shared logins? Per-seat pricing often does, and shared accounts make it impossible to see who changed what. (We look at this in more detail in our article on per-user pricing.)
Integrity and availability are part of data protection too (Art. 32 GDPR). You also need to be able to delete data properly when someone asks.
Check: Are backups made regularly? Can you restore an earlier version of an article? Can you delete individual articles and your whole account, and what happens to the data afterwards?
Data portability and avoiding lock-in are good practice, even beyond the GDPR.
Check: Can you export your content? Can you cancel monthly?
Even the best tool won't help if the content itself is a problem. A few habits make a big difference:
Don't publish personal data that isn't needed. Blur names, emails and customer data in screenshots before uploading them.
Keep internal and public content apart. Use separate workspaces or restricted categories instead of relying on "unlisted" articles.
Assign an owner to every category. Someone should be responsible for reviewing content regularly and deleting what's outdated.
Document the tool in your records of processing activities. Note the vendor, the DPA, the categories of data and the retention rules.
Write down an AI policy. Make clear which content may be processed by AI features and which may not.
We want to be clear and concrete about how eniston fits the checklist above, including the parts where you have to make a decision.
Company and hosting. eniston is a product of ivy.mayhem GmbH, a German company. Our servers are located in Germany in ISO 27001-certified data centers, and we comply with the GDPR. Our hosting provider is Hetzner Online GmbH in Germany. For customers who need more separation, our Business dedicated plan adds a dedicated server location, database instance and CDN.
DPA. Our data processing agreement is public and part of our terms and conditions.
Sub-processors. Our privacy policy lists the services we use, for example Bunny.net (a CDN provider based in Slovenia) and Paddle as our merchant of record for payments.
AI features. Our AI writing tools are part of the optional Enhanced add-on. As stated in our privacy policy, the AI features in the editor use OpenAI (USA). A DPA is in place, and we've configured it so that entered data isn't used for training. If you don't want any text to leave the EU for AI processing, simply don't book the add-on. Everything else in eniston works without it.
Cookies and tracking. We use strictly necessary cookies only. Our marketing pages use cookieless, GDPR-compliant tracking, and once you're logged in, no further tracking takes place.
Access control. You can restrict any workspace to logged-in team members ("frontend authentication"), allow or block specific IPv4 addresses, or protect a workspace or individual categories with a password.
Roles. Five roles, from Read-only to Super-Admin, control who can edit, delete or change settings. And because we don't charge per user, there's no reason to share accounts.
Backups and history. We run regular backups, and our version history keeps the last 20 published versions of each article. Deleted articles can be recovered for 30 days.
Exit. Subscriptions can be cancelled at any time, articles can be exported to Excel, and you can delete your account yourself.
A GDPR-compliant knowledge base comes down to a few concrete questions: Is there a DPA? Where is the data? Who else processes it? And can you control who sees what? If a vendor can answer these clearly and quickly, that's a good sign. If the answers are vague, take that as a warning.
If you're looking for a knowledge base that is made and hosted in Germany, you're welcome to try eniston free for 30 days. No payment information is required, and you can check every point on this list yourself.
Our knowledge base software offers a great variety of features to manage your knowledge articles. Try eniston for free for 30 days. No credit card required.
