How to Set Up a Company Policies Wiki From Scratch

In most organizations, policies are scattered across shared drives, email threads, outdated PDF attachments, and that one Google Doc someone created three years ago that nobody can find anymore. An employee asks about the remote work policy and gets three different answers from three different managers, each referencing a different version of a document that may or may not still exist.

This is not a minor inconvenience. It is a compliance risk and an onboarding bottleneck. It frustrates the people trying to do their jobs correctly.

A policies wiki fixes this. One place. One version. Always current. Always findable.

Here is how to build one from scratch, even if you have never documented a policy in your life.

The real cost of scattered policies

This section matters beyond "it would be nice to be organized."

When policies live in multiple places, enforcement becomes inconsistent. One manager approves expense reports based on an old threshold. Another uses the updated one. Neither knows the other exists. When someone in HR finally catches the discrepancy, it is already a mess.

Employees stop looking for policies entirely. They ask their manager, who asks another manager, who guesses. The answer they get depends on who they ask and what that person remembers. This is how you end up with an entire team working under rules that were changed six months ago.

New hires suffer the most. They show up eager to do things right, and there is no single place to learn how things actually work. The employee handbook they received during onboarding was a 60-page PDF that nobody reads. The real answers live in Slack threads and institutional memory.

There are legal implications too. If you cannot prove that a policy was communicated clearly and made accessible to all employees, good luck enforcing it. Employment disputes often come down to whether the employee had reasonable access to the policy in question.

And then there is the update problem. Someone revises the travel policy, uploads the new version to a shared drive, and forgets to delete the old one. Now both versions coexist. People find the old one first because it ranks higher in search results. The cycle continues.

Choosing the right platform

You need something that is easy to update and easy to search, with access controls. A wiki platform built for documentation is the right fit here, not a file storage system and not a general-purpose project management tool.

Look for a few things specifically. You need a good search function because employees will not browse a table of contents to find the bereavement leave policy. They will type "bereavement" into a search bar and expect the right document to appear.

You need version history. Policies change, and you need to know what changed, when, and who changed it. This is not optional. It is a compliance requirement for many organizations.

You need permissions. Not every policy should be visible to every person. Compensation structures, disciplinary procedures, and certain security policies may need restricted access.

You need something people will actually use to make edits. If updating a policy requires a developer or a specific piece of software, updates will not happen. The platform should let anyone with the right permissions edit content directly.

We built Docmost as an open-source wiki platform with exactly these needs in mind. It gives you nested pages for organizing policies by category, role-based permissions for controlling access, built-in version history, and full-text search. But whatever platform you choose, make sure it checks those boxes.

Organizing your wiki structure

The structure of your policies wiki matters more than people think. A bad structure means people cannot find what they need. A good structure means they can browse even when they do not know the exact name of the policy they are looking for.

Start with broad categories. These will be your top-level sections.

HR and people operations covers everything related to employment: hiring, onboarding, compensation, benefits, leave, performance reviews, termination, code of conduct.

IT and security covers acceptable use of technology, password requirements, data handling, device management, incident response, remote access.

Finance and expenses covers expense reporting, procurement, travel, reimbursement, corporate card use, budget approvals.

Legal and compliance covers data privacy, regulatory requirements, intellectual property, non-disclosure agreements, conflict of interest.

Workplace and facilities covers office protocols, visitor policies, health and safety, parking, building access.

Within each category, create individual pages for each policy. Do not dump multiple policies into a single document. Each policy should be its own page with its own URL. This makes linking, searching, and updating much easier.

Use a consistent naming convention. Something like "Remote work policy" rather than "WFH Guidelines v3 FINAL (updated)." Keep names descriptive and plain.

Create a landing page for each category that lists all policies within it, with one-line descriptions. This gives people a browsable index when they want to explore rather than search.

Writing policies people will actually read

Most policies are written by lawyers or by people who think they need to write like lawyers. The result is dense, jargon-heavy text that nobody reads. This defeats the entire purpose.

Write in plain language. If a sentence would confuse a new employee on their first day, rewrite it. You are not drafting legislation. You are explaining how things work at your company.

Start each policy with a brief purpose statement. One or two sentences explaining why this policy exists. "This policy exists to protect company data when employees work from locations outside the office." That is it. No preamble. No mission statement.

Follow the purpose with a scope statement. Who does this policy apply to? All employees? Only full-time staff? Contractors too? Be specific.

Then get into the actual policy. Use short paragraphs. Use bullet points for lists. Use headers to break up sections. A wall of text is a wall nobody reads.

Include examples where they help. "Expenses over $500 require manager approval" is clear on its own. But "appropriate business attire" might need examples because that phrase means different things to different people.

Avoid weasel words. "Employees should generally try to" is not a policy. "Employees must" is a policy. If something is optional, say it is optional. If it is required, say it is required. Ambiguity in policies creates exactly the kind of inconsistent enforcement you are trying to eliminate.

End each policy with contact information. Who should an employee reach out to if they have questions? Give a specific person or team, not "your manager" unless that is genuinely the right answer for that particular policy.

Including effective dates and version control

Every policy needs an effective date. This is non-negotiable.

At the top of every policy page, include the following details. The date the policy takes effect. The date it was last revised. The person or team responsible for the policy. A brief note about what changed in the most recent revision.

This might look like a small metadata block at the top of the page:

• Effective date: March 1, 2026
• Last revised: March 1, 2026
• Policy owner: People Operations
• Last change: Updated remote work eligibility to include part-time employees

This is useful in a few ways. Employees can immediately see whether they are looking at current information. Auditors can verify policy timelines. When someone asks "when did this change?" you have the answer right there.

Your wiki platform should also track version history at the system level. This gives you a complete audit trail that goes beyond what you put in the metadata block. If someone needs to see exactly what the policy said on a specific date, you can pull that up. Docmost tracks version history automatically, so you get this audit trail without any extra work.

Set a review schedule. Every policy should have a designated review date, typically annually. Some policies, like security policies, may need quarterly reviews. Put these dates in your calendar system. When the review date arrives, the policy owner reads through the current version, makes any needed updates, and marks it as reviewed even if nothing changed. This "reviewed, no changes" notation is itself useful because it confirms the policy was actively evaluated and found to still be accurate.

Making it searchable and discoverable

A policy that people cannot find is a policy that does not exist.

Search is the primary way most people will interact with your policies wiki. They will not browse. They will not memorize the structure. They will type words into a search bar and expect results.

This means you need to write with search in mind. Use the words people actually use, not internal jargon. If employees call it "PTO" but your policy is titled "Paid Time Off and Leave Entitlement," make sure "PTO" appears in the document too.

Add a frequently asked questions section at the bottom of complex policies. These FAQs do two things. They answer common questions without requiring someone to read the entire policy, and they add natural language terms that make the policy easier to find through search.

Cross-link related policies. The travel policy should link to the expense policy. The remote work policy should link to the IT security policy. The code of conduct should link to the disciplinary procedures. These connections help people find related information and understand how policies interact with each other.

Create a single "all policies" index page. This is a list of every policy in the wiki, sorted alphabetically, with one-line descriptions. Some people prefer to browse, and this page gives them a way to do that.

Pin or bookmark the most commonly accessed policies. If your wiki platform supports it, create a quick-access area for the policies people need most often. Time-off requests and expense guidelines are usually at the top of this list.

What to document first

You do not need to document every policy before launching your wiki. Trying to do everything at once is a reliable way to do nothing at all.

Start with the policies that cause the most confusion or generate the most questions. Talk to your HR team. Talk to your IT helpdesk. Talk to your managers. Ask them what questions they answer over and over again. Those are your first policies.

For most companies, the first batch looks something like this.

Your employee code of conduct. This is the document that sets behavioral expectations, and everything else references it.

Time off and leave policies. PTO accrual, sick leave, parental leave, bereavement leave, jury duty. People have questions about these constantly, especially when they are new.

Remote work and flexible work arrangements. If your company allows any form of remote work, the rules around it need to be written down. Who is eligible, what equipment is provided, what are the expectations around availability.

Expense and reimbursement policy. What is covered, what is not, what needs pre-approval, how to submit receipts, how long reimbursement takes.

IT acceptable use policy. What employees can and cannot do with company devices and accounts. This is a security matter and it needs to be documented clearly.

Data and information security. How to handle sensitive data, password requirements, what to do if you suspect a security breach.

That is six policies. Start there. Get them written, reviewed, and published. Then add more over time. A wiki with six well-written policies is far more useful than a planned wiki with forty policies that never gets launched.

Getting people to actually use it

Building the wiki is half the work. The other half is getting people to use it instead of falling back on old habits.

Announce it. Send a company-wide message explaining what the wiki is, where to find it, and why it exists. Keep the announcement short and direct. Link to the wiki.

Make it the canonical answer. When someone asks a policy question on Slack or in email, do not just answer the question. Answer the question and link to the policy wiki page. Every time. This trains people to associate the wiki with getting answers.

Involve managers. Managers are the most common source of policy information for their direct reports. If managers know the wiki exists and link to it regularly, their teams will start using it too. Run a brief orientation for managers showing them how to find and share policies.

Integrate it into onboarding. New hires should be introduced to the policies wiki on day one. Not asked to read every policy on day one, but shown where they live and how to search for them. "If you ever have a question about how something works here, start with the wiki."

Make updating easy. If people see outdated information and have no way to flag it or fix it, they will lose trust in the wiki entirely. Create a simple process for reporting outdated content: an email address, a Slack channel, or a feedback form on each page.

Maintaining it over time

The biggest risk to any policies wiki is decay. It launches with good intentions, gets used for a few months, and then slowly becomes outdated as policies change but the wiki does not.

Prevention is straightforward but requires discipline.

Assign ownership. Every policy needs an owner, a specific person responsible for keeping it current. This is not a vague organizational responsibility. It is a named individual who will be reminded when the review date arrives.

Build policy updates into your existing workflows. When the finance team changes the expense threshold, updating the wiki should be part of that change process, not an afterthought. When HR revises the parental leave policy, the wiki update happens at the same time as the policy change, not three months later.

Track what people search for and do not find. Most wiki platforms can show you search queries that returned no results. These are signals. If people are searching for a "sabbatical policy" and not finding one, either you need to create one or you need to add that term to an existing policy.

Do a quarterly audit. Not a deep review of every policy. Just a quick check that the table of contents matches reality, that there are no obviously outdated pages, and that the structure still makes sense. As your company grows, your policy categories might need to change too.

A policies wiki is not a project. It is a practice.

You will never be "done" with your policies wiki. That is the point. It is a living system that changes with your company. Policies get revised. New ones get added. Old ones get retired.

The goal is not perfection. The goal is having one place where anyone in your company can find out how things work. A place that is current, searchable, and written so that real people can understand it.

Start small. Pick your first six policies. Write them clearly. Put them in a wiki. Tell people where to find them. Then keep going.