How to Replace Your Cloud Wiki After Your Security Team Bans It

TL;DR

• Get your security team's concerns in writing before you look at any tools.
• Turn those concerns into a one-page requirements list your replacement cloud wiki has to meet.
• Run a test export first to see what comes through cleanly and what needs reformatting. Then export everything and decide what moves and what gets archived.
• Before you ask for approval, show your security team how your new wiki will run: where it's hosted, who can see what, and who looks after it.

Your security team has put your cloud wiki on the blocked list. But the runbooks, onboarding guides, and process docs inside it still need somewhere to be stored, and the notice may not say where.

The ban then leaves you with two jobs: keeping your documentation available while you still have access, and finding a replacement your security team will approve. This guide covers both, from finding out why the wiki was blocked to getting your replacement approved.

What Your Cloud Wiki Ban Means

A ban means your wiki failed a test that matters to your security team. It can be frustrating to lose a tool your team relies on, and a short notice doesn't always say why.

The table below translates what your security team might be saying into what each concern means and what to ask for. It's based on the NIST guidelines on security and privacy in public cloud computing, published by the National Institute of Standards and Technology. The guidelines name several issues to consider before moving data to a public cloud, including where your data is stored, who at the vendor can access it, and how much visibility you have into the vendor's security. NIST wrote them for U.S. federal agencies, and other organizations can use them on a voluntary basis.

Your ban may be due to one or two of these reasons above. Once you know which ones apply to you, you know what your replacement has to fix.

Ask Your Security Team to Put Their Concerns in Writing

Before you look at a single tool, ask security to write down why the wiki was blocked. A written reason tells you exactly what the problem is, so you can pick a replacement that solves it. It also gives you something clear to check the replacement against later.

While you're asking, find out two more things:

• Which parts can't change and which parts can: Some parts of your ban come from company policy and won't change, while others are about something the vendor does, which a different setup could fix.
• Who approves the replacement: Knowing whose sign-off you need from the start saves you from presenting to the wrong person later.

Turn Your Ban Into a Written Requirements List

Now, the written concerns from your security team tell you what went wrong. But a requirements list tells you what a "good replacement" looks like, and that's the document you'll keep checking to see if you're on the right track.

Questions to Ask Your Security Team About Your Cloud Wiki Ban

Book a short meeting and go over these together:

• Where must the data be stored, and who can reach the servers?
• Does the wiki need to work with no internet connection?
• Which sign-in system must it use?
• How long must pages and their history be kept?
• Who needs access to which content?
• Does the replacement need a formal review, and how long does that take?

You may not need perfect answers, just ones that are good enough to write the list, and your security team can always correct it.

What Your One-Page Requirements List Looks Like

Keep the list to one page, with each line naming the requirement, who asked for it, and how you'll check that the replacement meets it.

That last column is very important because a product page can say a tool supports single sign-on, but a test sign-in with your pilot group (one team that tries the new wiki first) shows whether it works in your setup.

Maintaining Your Documentation While the Wiki Is Blocked

Choosing and setting up a replacement takes time, and your team still needs documentation in the meantime. Without a plan, new pages end up scattered across chat threads and personal files, and you'll end up spending time tracking them down later.

A few steps help you stay organized until the new wiki is ready:

• Ask whether read-only access is allowed during the move: If security agrees, your team can keep looking things up while you work on the replacement.
• Pick one approved place for new pages: One place for new documents makes it easy to find and move them out later. Documents spread across five places are much harder to keep track of.
• Don't add sensitive content anywhere until the requirements are set: That way you don't create a second problem while fixing the first.
• Name one person to track what gets written while the wiki is blocked: They'll know exactly what needs to move once the new wiki is ready.
• Set an end date for the temporary setup: A temporary fix without an end date has a way of becoming permanent.

What Your Replacement Needs to Pass

If your ban is mainly about where your data is stored or who can access it, a wiki you host yourself addresses both, because you control the servers it runs on. Before you decide, ask your security team whether a different cloud setup would be acceptable or whether the ban covers all cloud tools.

Why a Self-Hosted Wiki Can Work After a Cloud Ban

Running the wiki on your own infrastructure changes three things:

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

That third point needs an owner on your team, and a later section of this guide covers how to pick one.

How to Use Your Replacement Checklist

Use the table below to see how well each option meets what your security team cares about. Not every row will apply to you, so use your own requirements list to decide which rows to keep, add, or remove.

For each option you're considering:

1. Go through the table and mark each row as met, partly met, or not met.
2. For any row that isn't fully met, ask the vendor about it or test it before you decide.
3. If your security team says a row is a must-have, remove any option that doesn't meet it.

Docmost is fully self-hosted and can run on your network with no internet connection and no outside services it depends on. The paid edition adds single sign-on through SAML and OIDC, sign-in through your company directory with LDAP, and multi-factor authentication. Paid license keys are checked offline, so those features work without an internet connection too.

If you're still building your shortlist, compare the top self-hosted documentation tools.

If your industry has its own rules on where documentation can be stored, see the wiki guides for defense contractors, financial services, and government teams.

How to Move Your Pages Out of the Cloud Wiki

Run a Test Export Before Access Closes

Ask security when access to the old wiki ends, and get your content out before that date. Start with a test so you know what will export and what you'll have to rebuild.

• Export one space as a test: Pick a space with tables, images, attachments, and links between pages, so you can see how your trickiest pages come through.
• Open the files and check what came through: Write down anything that's missing, broken, or formatted differently.
• Decide what needs reformatting: The test shows you how much cleanup to expect before you import anything.
• Then export everything: Save attachments and images separately too. If anything goes missing in an export, you'll still have the originals.
• Note which spaces and pages have restricted access today: You'll need this list when you set up permissions in the new wiki.

Decide What Moves and What Gets Archived

A move is a good time to clear out pages nobody reads. Sort your content before you import anything.

Slow down on that last row. Pages holding customer data, passwords, or contracts are the kind of content your security team will want a say in, so let them decide where it goes.

Import and Check the Result

Import one team's pages first, as a pilot. Your security team can test sign-in and access with real content, and you can fix problems while only one team is affected. Once it works the way they expect, import the rest the same way.

Docmost imports Markdown and HTML files, plus Notion exports, in every edition. The paid edition adds importers for Confluence, Word (DOCX), and PDF files. You'll find the steps in the Docmost import and export guide.

A Confluence import carries over the page tree, links between pages, images, and attachments. Don't count on permissions carrying over, so plan to set up access yourself.

After the import, check:

• Links between pages, attachments, and images: Click through a sample of pages and confirm everything loads.
• Access by space and group: Set up the restrictions you noted during the export, then test them with someone who shouldn't have access.
• Search: Look up a few pages you know exist and confirm they come back.

How to Get Your Security Team to Approve Your Replacement

By now, you know what your security team wants, and you've found a replacement that meets it. Next comes the approval meeting, where you show them the replacement meets what they asked for.

What to Bring to Your Review

Bringing up an exit plan can feel early, but NIST lists data ownership and exit rights among the points to settle in a service agreement with a cloud provider. It also calls the ability to export all of your data in a usable format a vital part of an exit strategy. The same question applies to your new wiki: how does your content leave if you switch?

Who Owns Your Wiki After the Move

Self-hosting means your team now handles the wiki's upkeep. Before you finish the move, name one owner for hosting, backups, upgrades, and patching, and write that name into the hosting plan you give your security team.

Docmost runs with Docker, alongside a PostgreSQL database and Redis, so pick an owner who's comfortable running those on a server. The Docmost installation guide covers setup and upgrades.

The pages need owners too. Assign page owners and review dates so your content stays current after the move.

Frequently Asked Questions

1. How Do I Convince My Security Team to Approve a Self-Hosted Wiki?

Bring your written requirements list, hosting plan, and access model, so your security team can see exactly how your new wiki answers their concerns. Offering a single pilot group first also helps, because it lets them test the setup before anything else moves.

2. What Should I Move First From a Banned Wiki?

Start with current runbooks, onboarding guides, and process pages, since those are what your team uses every day. Check anything holding customer data or passwords with security before you move it.

3. Can a Self-Hosted Wiki Run Without Internet Access?

It depends on the wiki, so check whether the one you're considering needs any outside services. Docmost is fully self-hosted and can run on networks with no internet connection and no outside services it depends on. Paid license keys are checked offline, so paid features work there too.

5. Can Docmost Connect to Our Company Sign-In?

Yes. The paid edition supports single sign-on through SAML and OIDC, sign-in through your company directory with LDAP, and multi-factor authentication.

6. What File Formats Can I Import Into a New Wiki?

It depends on the wiki, so check what each one accepts before you export from your old wiki. Docmost imports Markdown, HTML, and Notion exports in every edition, and the paid edition adds Confluence, Word (DOCX), and PDF imports. To import, open the space you want, click the three-dot menu next to the Pages header, select Import pages, and choose your format. For bulk imports, you can also upload a ZIP file of Markdown and HTML files.

Keep Your Documentation on Infrastructure You Control

A security ban doesn't have to put your team's documentation on hold. Once you have your security team's concerns in writing and a wiki you host yourself, you can give them what they asked for. Your team gets a place to keep writing, too.

To try the paid edition on your own servers, get a free trial license. If you'd like to talk through your hosting setup first, contact our sales team.