Self-hosted knowledge base for ISO 27001 documentation

How a self-hosted knowledge base supports ISO 27001 documentation

An ISMS owner needs to show that information security policies and documented operating procedures are approved, published, reviewed and reachable by the people who use them. A self-hosted wiki answers the distribution part of that job: it gives each policy and procedure a single controlled home, a version history and an audience. It does not make a policy approved, and it does not prove that anyone read it. Those remain the organization's responsibility, backed by a management system that defines who approves, how acknowledgments are collected and when each document is reviewed. ISO/IEC 27001 is not a product requirement. It is a set of requirements for the management system as a whole. The 2022 edition of ISO/IEC 27001 restructured the Annex A controls, and the two 2013 policy controls, A.5.1.1 Policies for information security and A.5.1.2 Review of the policies for information security, now sit together in A.5.1. The wiki should reflect that: one top-level policy page, topic-specific policy pages beneath it and a review date and owner on each. A.5.37 Documented operating procedures, which carries forward the 2013 control A.12.1.1, asks that procedures for information processing facilities be documented and available to the personnel who need them. Confirm with your certification body which of your procedures they will sample, because that list determines which pages need reader-level access logs and which can simply be listed. ISO does not certify organizations. Accredited certification bodies assess conformity to the standard, and the wiki is one of the sources they will examine. Before you commit to a platform, check whether the certification body expects approval records, acknowledgment evidence or page history in a particular form, and whether your chosen wiki can export that history in a format they accept. Ask the implementation partner to show how page revisions, review dates and read permissions are recorded in the actual version you deploy.

Which ISO 27001:2022 documentation requirements the wiki must meet

This table maps the ISO 27001:2022 requirements that touch policies and procedures to concrete wiki functions on BookStack, Outline and XWiki. Read each row as a requirement, the wiki feature that supports it, and where the platform needs an add-on or a manual process. The main takeaway is that the wiki stores and shows evidence well, but approval, acknowledgment and review discipline still need to be designed into the process.

Requirement	Wiki function that supports it	BookStack, Outline and XWiki configuration	Gap to confirm or close
A.5.1 approval and publication of the information security policy	Controlled approval of a policy page before it becomes the published version	BookStack: restrict edit rights to a policy owner group and record approval in a page tag. Outline: publish only after a designated editor signs off. XWiki: use a validated workflow or a page approval extension.	Approval evidence (who approved, when) is not a native sign-off record on every platform. Confirm with the vendor and document a manual approval step.
A.5.1 communication and acknowledgment by relevant personnel	Tracked acknowledgment that each person has read the current version	Usually handled through a form, survey or extension linked from the policy page. XWiki offers more structured options; BookStack and Outline generally need an external form or a manual register.	Acknowledgment tracking is typically an add-on or a separate process. Confirm the mechanism and retention of acknowledgment records before go-live.
A.5.1 review at planned intervals and after significant change	Review dates and reminders tied to each policy page	Store a review date and owner in page metadata or a tag, then run a periodic report of overdue pages. Reminders usually come from a scheduled export, a script or the identity or ITSM platform.	No platform sends review reminders out of the box in a way an assessor would accept as control evidence. Plan the reminder process explicitly.
A.5.37 documented operating procedures available to people who need them	Procedures organized in shelves, spaces or books with read access for the right groups	Map roles to shelves or spaces in BookStack, collections in Outline, or spaces and page rights in XWiki. Confirm that read access can be limited to specific groups.	Fine-grained page-level rights vary by platform and edition. Test with real role accounts before relying on them.
Clause 5.2 and A.5.4 top-level policy and management responsibilities	Clear ownership of the policy set and visible approval by management	Assign a named owner per policy page and place the top-level policy at the root of the knowledge base with restricted edit rights.	Management approval happens outside the wiki. Record it in meeting minutes or a signed approval and link that evidence from the page.
A.5.36 compliance with policies and A.8.9 configuration management	Procedures that describe how compliance and configuration baselines are checked	Link each procedure to the configuration baseline or checklist it governs. Use page history to show when a baseline changed.	Linking to external configuration tools is usually manual. Confirm integrations with the configuration management system you use.
A.8.32 change management	Version history and change records on operating procedures	All three platforms keep page revision history. Add a change summary field or template to record the reason for each revision and the approver.	Revision history does not replace a formal change record. Confirm that change tickets in your ITSM tool reference the wiki version.
SSO-backed group access and access reviews	Permissions driven by directory groups instead of individual accounts	BookStack and Outline support SSO through OIDC or SAML. XWiki supports LDAP, SAML and OIDC through its extensions, with some SSO applications listed in XWiki Pro.	Group mapping and periodic access reviews need confirmation for your identity provider and platform edition.

Which open-source wiki fits an ISO 27001 documentation set

BookStack is a wiki platform licensed under MIT, with v26.09.1 published on September 29, 2026. It organizes content as shelves, books, chapters and pages, which suits a documentation set that is mostly readable reference material with a clear folder-like hierarchy. For a small ISMS, where policies and procedures are few and owned by one or two people, that simplicity lowers the training burden and the number of settings to review.

Hierarchy: Shelves, books and chapters map well to policy, standard, procedure and work instruction layers.
Page history: Confirm that version history and revision comparison meet your need to show what changed and when.
Permissions: Check whether role and book-level permissions can restrict drafts to approvers while publishing to all staff.
Approval workflow: Expect no native multi-step approval. Your approval record may need to live in a register or ticket that links to the page.
License: MIT places no commercial hosting restriction, so the license rarely becomes the deciding factor.

Before deciding, confirm the current approval, permission and SSO options against the BookStack release notes for the version you plan to deploy.

How the wiki controls the policy lifecycle

The core requirement is that every information security policy and operating procedure moves through a visible lifecycle: drafted by its owner, reviewed by the people who depend on it, approved by management, published, acknowledged by the staff it applies to, and reviewed again at planned intervals or after significant change. A wiki does not make those decisions for you, but it can hold the state of each page so an auditor can see where a document sits at any moment. In practice, use a page status or a label such as draft, in review, approved and retired, and restrict who can move a page into approved. Record the approving manager's name and the approval date on the page itself, and set a review date that the owner can see. Confirm whether your chosen platform (XWiki, BookStack or Outline) supports approval workflows natively, or whether you must enforce them through a separate step such as a documented sign-off in your ticketing tool.

Keep one authoritative version per document. Publish the approved version in a single location, and treat drafts as separate pages or revisions that cannot be mistaken for policy. When a procedure is superseded, retire it by marking it as withdrawn, adding a pointer to its replacement and removing it from navigation and search defaults, rather than deleting it. Version history and access logs are what let you show what each version said and who changed it, so confirm that the platform keeps page history for the retention period your policy requires and that deletions are logged. Export retired versions periodically if your evidence store lives elsewhere.

Link each procedure to the change records that alter it. When a change request in your ITSM or ticketing tool (for example, GLPI or iTop) modifies a procedure, the change ticket should reference the wiki page and version, and the page should reference the ticket that approved the change. This gives you a traceable chain for controls such as A.8.32 Change management. The tooling records the trail: who drafted, who reviewed, when the page was published and what changed. The decision to approve a policy, however, remains with management, and the wiki should show that decision rather than replace it. Ask your implementation partner to document this split in the approval procedure itself.

How to move policies and procedures into the wiki

This sequence turns scattered policy and procedure files into a controlled wiki where each document has an owner, an approval record, a review date and read access that matches who needs it. The result is a documented set that auditors and staff can both trace back to the Annex A controls it supports.

Inventory documents and the controls they support
Collect every policy, standard, procedure and work instruction that touches information security, wherever it lives today, including shared drives, Confluence spaces and email attachments. For each item, record the owner, the current version, the last review date and the Annex A control or clause it supports, such as A.5.1 or A.5.37. The step is complete when every document has one row in a register and the team has agreed which items are retired rather than migrated.
Define the page hierarchy and document owners
Design the space and page structure around the policy set, typically one space for the information security policy and topic-specific policies, and separate spaces for operating procedures grouped by function or system. Assign a named owner and a backup owner to each page, and decide which pages are read-only for most staff. The step is complete when the hierarchy is approved by the ISMS owner and every page in the register has an owner recorded in the wiki.
Set approval, review and version rules
Write the rules for how a document becomes approved: who signs off for each class of document, what triggers an out-of-cycle review after a significant change, and how the approval is recorded on the page. Agree the review interval with management and state it on each page. The step is complete when the rules are written as a short document controlled in the wiki itself and the approver for each policy is named.
Migrate content and confirm what history survives
Move content into the wiki, using a tool only after testing it. If the source is Confluence, XWiki's Confluence Migrator Pro is one option: it migrates spaces, pages, users, groups, permissions and attachments, and keeps page history but not attachment history. Run the tool on a sample set first and compare page counts, permissions, links and version history against the source. The step is complete when the sample results are documented, any gaps are recorded as accepted or fixed, and the audit trail for the policy set is kept in a location you can still reach.
Configure SSO and group-based read access
Connect the wiki to the directory through the supported SSO method, then map directory groups to wiki roles so that read access follows job function and editing is limited to named owners. Confirm which features your chosen edition needs for the integration, since SSO support varies by product and edition. The step is complete when test accounts from each group see only the spaces they should, and the mapping is written down for the next access review.
Run a pilot with control owners before publishing
Ask each control owner to review their pages in the wiki, check that the content matches how the control actually operates, and confirm that the approval record is correct. Collect corrections and resolve them with the document owner. Ask a sample of staff to find a procedure from a search and report anything they cannot locate. The step is complete when every control owner has signed off their pages in the pilot and the open issues are logged.
Publish, communicate and collect acknowledgments
Publish the approved set and tell relevant personnel where it is and what changed. Record acknowledgments from the people who need each policy, using a method your ISMS already accepts, and make retrieving those records part of the process. Retire the old copies with a clear pointer to the wiki so that nobody works from a stale file. The step is complete when the published set matches the register, acknowledgment records exist for each target group, and the old locations are closed to editing.
Set the ongoing review cycle
Schedule review reminders from the page owners, track overdue documents in the register and run a periodic check that access groups still match current roles. Connect change requests to the affected procedures so that changes to systems such as configuration or change management prompt an update. Ask your certification body early which evidence it expects from this cycle. The step is complete when the first review cycle runs with the register as the single source, and the overdue list is reviewed by management.

Evidence auditors ask for from the documentation system

A certification body samples the documentation system to confirm that policies and procedures are approved, distributed, reviewed and linked to real operations. Each card below covers one kind of evidence, and each depends on the wiki keeping records as work happens, because ISO/IEC 17021-1 certification cycles include at least one audit in every calendar year.

Approved policy with date and approver

For A.5.1, auditors look for an information security policy and topic-specific policies that management has approved, with a visible approval date and the name or role of the approver. Keep the approval record on the page itself, either as a front-matter block or a locked template field, so the approved version cannot be confused with a draft. Check that a page cannot be marked approved by its own author and that the approval date matches the version that was published.

Version history and change trail

Auditors compare the policy in force on a given date with what was in force before and after a change. Page revisions in the wiki should show who edited the content, when, and what changed, and old revisions must remain retrievable instead of being overwritten. Confirm that the platform keeps full revision history on every page type you use, and that revision deletion is restricted to a named administrator with its own log entry.

Distribution and acknowledgment records

A.5.1 expects policies to be communicated to relevant personnel and acknowledged by them. A wiki page alone does not prove receipt, so pair each policy with a defined audience, usually a group synced from the directory, and a recorded acknowledgment, either in the wiki or in the identity or HR system. Ask how the wiki reports who has viewed a page and who has not acknowledged the latest version, and whether that report can be exported.

Review logs at planned intervals

The standard requires policies to be reviewed at planned intervals and after significant changes. Record the review date, the reviewer, and the outcome (confirmed, revised or retired) on each controlled page, even when the content does not change. Set review due dates as a field or tag that can be filtered, so the team can show a list of overdue reviews rather than reconstructing them before an audit.

Procedure access records

For A.5.37, operating procedures must be available to the personnel who need them, so auditors ask who could read a procedure and who actually did. Confirm that the platform's audit log records page views or exports for restricted spaces, retains those entries for a period your policy sets, and that logs can be shipped to central logging. Access by administrators to restricted spaces should be logged as well.

Procedures linked to change and operational records

A.8.32 and A.8.9 expect procedures to tie back to how changes and configurations are actually controlled. In the wiki, link each procedure to the change ticket, runbook or configuration item it governs, and record the procedure version that was in use for a given change. A link that breaks when a page is renamed or moved becomes a gap, so test link integrity after structural changes and keep permanent identifiers on controlled pages.

What a wiki alone does not satisfy

A wiki stores and publishes the ISMS documents, but the ISO/IEC 27001:2022 requirements behind them are decisions, reviews and evidence that a platform cannot make on its own. The cards below set out where those gaps sit, so the project plan assigns each one to a named owner and process before the wiki goes live.

Scope and risk decisions

The wiki can hold the ISMS scope statement and the risk assessment method, but it cannot decide what falls inside the scope or which risks are accepted. Those decisions need documented approval by top management and a record of who made them. Check that the scope page carries an approver, an approval date and a link to the risk register, and that the wiki does not present a draft as the approved version.

Policy content and ownership

Clause 5.2 and control A.5.1 require a policy that management approves, publishes and communicates. The wiki displays that policy, but the content, the owner and the review trigger come from people. Confirm that every policy page names an accountable owner, a review interval and the change that prompted the last update, and that someone outside the authoring team checks the text before approval.

Management reviews and inputs

A wiki has no concept of a management review meeting. Management reviews must take inputs such as audit results, incidents and changes, and must produce recorded decisions. Store the minutes and action list in controlled pages, and confirm that the review schedule, attendees and outputs are recorded outside the wiki's edit history where auditors can trace them.

Acknowledgment collection

Control A.5.1 expects relevant personnel to acknowledge policies, but a wiki page view is not an acknowledgment. Someone must define who must acknowledge each policy, send the request, chase exceptions and keep the record. Ask whether your HR or identity system can trigger the request, and whether the evidence (name, version, date, method) can be exported for the auditor.

Proof that procedures were followed

Control A.5.37 requires that operating procedures are documented and available. It does not make people follow them, and a wiki cannot show that a procedure was executed. Pair each procedure page with the records the work produces, such as change tickets, access approvals or backup logs, and check that the ticketing or ITSM tool links back to the procedure version in force on that date.

Certification status is confirmed externally

ISO does not certify organizations; accredited certification bodies do, and ISO points to the IAF CertSearch database for checking accredited certificates. A wiki page that says the organization is certified is only a claim. Confirm the certificate scope, the issuing body and its accreditation status directly from the certificate and the public database before publishing any compliance statement.

What ISO 27001 wiki projects cost and require

What drives the cost of a self-hosted ISO 27001 wiki project?

The cost is driven by the platform licensing choice, the hosting model, the volume of content to migrate, the identity integration, the approval and acknowledgment workflow you design, and the number of consulting days. The software itself is often free to download, so most of the budget goes to people and infrastructure. Licensing differs by platform: BookStack is licensed under MIT, Outline is under the Business Source License 1.1 whose additional use grant forbids offering a commercial Document Service, and XWiki Standard is free while XWiki Pro and support subscriptions are paid. Ask any partner to split the quote into one-time build work and recurring hosting, upgrades and support.

What does XWiki SAS charge for consulting and training?

XWiki SAS lists consulting at 1200 EUR per day and training at 1500 EUR per day on its pricing page. Consulting at that rate requires a Business or Enterprise support plan. Those daily rates are list figures from XWiki SAS and are separate from any engagement with DeployOpen, which quotes from a written scope. If you migrate from Confluence, XWiki SAS also lists Confluence Migrator Pro from 2000 EUR, with a trial limited to 30 pages per migration. Confirm with the vendor whether the current rates and plan terms apply to your contract.

How long does a self-hosted ISO 27001 wiki take to set up?

Setup time depends mainly on how many policies and procedures you already have, how clean that content is, and how many approval paths and identity groups must be configured. A minimal wiki with a small set of pages can be stood up quickly, while a controlled document set with version approval, acknowledgment tracking and migrated history takes longer. Timelines are fixed in the written scope before work starts, so ask for the phases, the dependencies on your identity team and the points where your control owners must review content.

What must our internal team provide for the project?

Three groups of people are needed. Control owners must supply and validate the policy text and the operating procedures for their areas, and they must agree the review cycle. Approvers, usually management or the ISMS owner, must confirm who signs off each version. Identity administrators must provide directory groups, SSO settings and access rules. Someone must also own the wiki after go-live for upgrades, backups and user administration. Without these named owners, projects tend to stall at content review rather than at installation.

Can we run an ISO 27001 wiki in-house without a partner?

Yes, many teams install and run open-source wikis with internal staff, and the platforms are free to deploy. The questions to answer honestly are whether you have people who can operate the platform securely, apply upgrades on schedule, configure SSO and audit who can read what, and keep records that an auditor can review. A partner is most useful when the team lacks those skills, when migration volume is large, or when the content must be tied to approval and acknowledgment evidence. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms in your own infrastructure, so the choice between building internally and engaging a partner can be made against your own capacity.

How do we ask a partner for a fixed-scope quote?

Send a written description of the platform choice, the number of policies and procedures in scope, the migration source and volume, the identity provider, the approval roles and the hosting location. Ask the partner to list deliverables, acceptance criteria, exclusions and assumptions, and to name what your staff must provide. Request one-time and recurring costs separately, plus the terms for upgrades and support. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and quotes follow from that written scope, so a clear brief produces a more accurate quote.

Does the wiki itself make us ISO 27001 certified?

No. A wiki is a tool that helps keep Annex A controls such as A.5.1 Policies for information security and A.5.37 Documented operating procedures current, approved and available. ISO does not certify organizations, and accredited certification bodies perform the assessment against ISO/IEC 27001:2022. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports or certifications. Ask your certification body early which evidence it will sample, such as approval history, acknowledgment records and review dates.

How DeployOpen delivers ISO 27001 documentation wikis

DeployOpen plans, implements, customizes, hardens, documents and supports self-hosted open-source wikis inside your own infrastructure. For ISO 27001 documentation, we set up the wiki so that policy and procedure owners can approve, publish and review controlled content, and so that the evidence an auditor will ask for can be pulled from the platform itself.

How we scope

Agree which policies, topic-specific policies and operating procedures will live in the wiki, mapped to the controls they support
Define approval roles, review intervals and who acknowledges each published document
Record the chosen platform, hosting location and identity source in the written scope before work starts

How we build

Configure spaces, page templates and permissions so each policy has one owner and one approved version
Connect the wiki to your directory for single sign-on and group-based read and edit rights
Test page history, access restrictions, search and export against the scoped document-control requirements

How we hand over

Document the administration, backup, upgrade and restore procedures in your own wiki as controlled content
Deliver a register that links each controlled document to its owner, approver, review date and acknowledgement record
Train document owners and administrators on publishing, approving and retiring documents

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
Ongoing support, upgrades and continuous testing are available as a retainer
Confirm with your certification body which document evidence it will sample, since DeployOpen prepares evidence but does not issue audit reports or certifications