A Practical Guide to Compliance for On-Prem Wikis

TL;DR

• An on-prem wiki lets you control where your data lives and who can see it, but setting it up for compliance is still your job.
• Start by listing what your regulators and auditors will ask to see.
• You'll set it up in seven steps: scope, hosting, sign-in and permissions, spaces, backups, owners and review dates, and a mock audit.
• Your IT team owns hosting, backups, upgrades, and security patching after launch.
• Docmost, an open source wiki, runs on your own servers, including air-gapped networks that have no internet connection (listed under its Business edition).

If your team works in a regulated industry, your policies, procedures, and records may live in a wiki. An auditor may ask about that content: who can see a page, what changed on it, how long it's kept, and whether it can be recovered. 

An on-prem (on-premise) wiki runs on servers you control, so your data stays on infrastructure you manage. But the wiki doesn't answer those questions on its own: you still have to set up access, retention, and backups, and use page history.

This guide walks you through that setup in seven steps, from deciding what goes into your wiki to running a mock audit. The examples use Docmost, so some steps name its menus and editions.

What Auditors May Ask Your Wiki to Show

Auditors may ask questions like these about your documentation, and if your wiki can answer each of them quickly, you're in good shape. 

In the table below, each row pairs a question with the setting that answers it and the step where you'll set it up.

This guide doesn't assume any specific compliance framework. Your own regulations decide the details, so check each step against the rules that apply to your team.

Why Use an On-Prem Wiki for Compliance?

When you run the wiki yourself, a few things change about how compliance works for your documentation:

• Your data never leaves the infrastructure you control.
• You define your own compliance posture (access controls, encryption, retention) instead of inheriting a vendor's.
• Hosting, backups, upgrades, and security patching become your IT team's responsibility.

Because hosting, backups, upgrades, and patching fall to your team, the setup below includes backups and a restore test. For upgrades, the Docmost installation guide covers how to update. 

For the full case, see our guide to self-hosted wiki software or read about the best wiki software for government and public sector teams.

On-Prem Wiki Setup Checklist: 7 Steps

Step 1: Decide Which Content Is in Scope

Before you install anything, decide what content belongs in your wiki. That decision drives how you set up your spaces, your permissions, and how long you keep things.

• List the regulations that apply to your team, and note what each one expects you to document.
• Group your documents into policies, procedures, and records, since each type may have its own review and storage rules.
• Mark which content is sensitive and which is general reference, so you know where tight access matters most.

Step 2: Choose Your Hosting Environment

"On-prem" can mean a few different setups. Pick the one your security policy allows, then decide who looks after each part.

If you need the air-gapped option, Docmost can run on a network with no internet connection, and its pricing page lists air-gapped deployment under the Business edition. 

Paid license keys are checked offline, so your wiki doesn't need to contact an outside server to keep its paid features working.

Whichever option you pick, ask your IT team about Docmost's telemetry (anonymous usage reporting). By default, Docmost sends anonymous counts, such as its version number and how many users, pages, and spaces you have. 

That matters if your policy says no data can leave your network, because one setting (DISABLE_TELEMETRY=true) turns it off. The Docmost configuration guide shows you where to put it.

Step 3: Set Up Sign-In and Permissions

Set up access before anyone adds content, so nothing ends up in your wiki where the wrong people can see it.

• Connect your company's sign-in system, so your people sign in with the work accounts they already have. This is called single sign-on (SSO). Docmost's Business and Enterprise editions support SAML 2.0, OIDC, and LDAP, which are three ways to connect Docmost to that system. They also work with sign-in providers like Microsoft Entra, Okta, and Google.
• Ask everyone on your team to turn on two-step verification (MFA) from their profile settings. It's a Business and Enterprise feature and works with authenticator apps like Google Authenticator and Microsoft Authenticator.
• Give access through groups instead of to one person at a time. That way, when someone changes teams, you update one group instead of every space they use.
• Check the built-in "Everyone" group before you add it to one of your spaces. Every user belongs to it automatically, so adding it gives everyone in your wiki access to that space. When someone has access through more than one route, Docmost gives them the highest level of access they've been granted.

Next, set roles. Docmost uses two layers: workspace roles cover your whole wiki, and space roles cover one space at a time.

The person who completes your first setup becomes the workspace owner and gets full admin control of the wiki. So, pick someone who can stay in that role long term.

Sometimes one page needs tighter access than the rest of its space. And luckily, the Business and Enterprise editions let you restrict that page so only the people and groups you choose can access it. Its sub-pages get the same restriction, and restricted pages stay out of search results for anyone without access.

Step 4: Organize Content by Regulation or Department

Spaces are where your structure and your permissions come together, so how you set them up affects how quickly you can find things when an audit comes around.

• Create one space per regulation or per department, whichever matches how you'd look things up during an audit.
• Keep your regulated content in its own spaces, apart from general documentation, so you can lock those spaces down without slowing everyone else.
• Use consistent page titles, so searching for something like "data handling policy" is more likely to turn up the right page.
• Public sharing lets anyone with the link open a page, even people outside your workspace, so turn it off for any space that holds regulated content. If you're an admin, you can switch it off for your whole wiki, and if you're a space admin, you can switch it off for one space. Once it's off, any page that was already shared publicly goes back to being private.

Step 5: Set Retention and Test Your Backups

Retention means how long you keep each type of content, and it starts with a written policy. Write your timeframes down in your wiki, and give that page an owner like any other policy.

From there, a few settings and habits back your policy up:

• Use page history to show how a page changed over time. Docmost saves versions automatically as people edit, highlights what changed between versions, and lets you restore an older one.
• Back up both the database and the stored files on a schedule. Docmost uses a PostgreSQL database. Your uploaded files are stored separately, in a folder on the server by default, or in S3-compatible or Azure Blob file storage if you set that up. A backup that covers only one of them isn't complete.
• Export a whole space as Markdown or HTML, with attachments, when you need a copy you can open outside the wiki or hand to an auditor.
• If you're on the Enterprise edition, use audit logs, which record sign-ins, membership changes, permissions, and sharing activity. You can set how long Docmost keeps them.

Until you've restored a backup, you don't know it works, so test the restore. Then, when someone asks whether you can recover, you can say yes and point to the test.

Step 6: Assign Page Owners and Review Dates

Every policy page in your wiki needs one named person who's responsible for keeping it accurate.

• Name an owner on every policy and procedure page.
• Record the next review date on the page itself, so anyone reading it can see when it's due.
• On the Enterprise edition, use page verification to name who confirms a page and set its review date. Docmost doesn't send reminders when a page is due, so keep the review dates in a shared calendar or your ticketing tool as well.

For a fuller walkthrough, see our guide to assigning page owners and review dates in a wiki.

Step 7: Run a Mock Audit

And finally, before the real audit, test your setup with the kind of requests an auditor might send you. Ask someone outside your compliance team to play the auditor, and note how long each answer takes you to find.

Fix every gap your mock audit turns up.

On-Prem Wiki Features by Edition

Docmost is an open source wiki you can host on your own servers. It comes in three editions for self-hosted and on-premises deployments: Open Source, Business, and Enterprise. This table shows which edition Docmost's pricing page and docs list each feature under.

You can see the full breakdown on the Docmost pricing page. If you're moving off another tool, see how Docmost compares to Confluence. Then use the Docmost import and export guide to bring your existing pages across.

Frequently Asked Questions

1. What Should an On-Prem Wiki Include to Support a Compliance Review?

At minimum, you'll want role-based access, page history on every page, a written retention policy, tested backups, and a named owner on each policy page. Together, those cover the questions in this guide: who can see a page, what changed, how long you keep it, and whether you can get it back.

2. How Do I See How a Policy Page Changed Over Time?

Open the page menu and choose Page history. You'll see a list of saved versions, and picking one highlights what changed compared with the current page. You can restore an older version from there too.

3. Can a Wiki Run on a Network With No Internet Access?

Yes, if the wiki software supports offline deployment. Docmost supports air-gapped deployment, and its pricing page lists it under the Business edition. License keys are checked offline, so nothing needs to connect to an outside server.

4. Can I Move My Existing Documentation Into a New Wiki?

In most cases, yes. Docmost imports Markdown, HTML, and Word (DOCX) files, plus exports from some other wiki tools, and its Business edition includes a Confluence importer. The import and export guide covers the steps.

5. Should Regulated and General Content Share One Wiki?

They can share one wiki as long as they're kept in separate spaces with separate permissions. That way your general staff can use the wiki every day without seeing content they shouldn't, and you only lock down what needs it.

6. How Often Should Compliance Pages Be Reviewed?

Follow the review cycle your own policy or regulation sets. Beyond that, review a page whenever the rule it covers changes or the process it describes changes.

Get Your On-Prem Wiki Ready for Audit Day

Want to try the setup on your own servers? Get a free trial license and test the Business and Enterprise features from this guide. If you'd like to discuss trial options or find the right edition, contact sales.