Self-hosted knowledge base for SOC 2

How a self-hosted knowledge base for SOC 2 puts controls into daily use

A self-hosted knowledge base serves two SOC 2 common criteria: CC5.3, which asks the organization to deploy control activities through policies that set expectations and procedures that carry them out, and CC2.2, which asks it to communicate internally the information people need for internal control to function. It does not satisfy either criterion by itself. A SOC 2 is an examination performed by a CPA firm, issued either as a Type 1 report on the design of controls at a date or as a Type 2 report that adds an opinion on operating effectiveness over a period. Security, covered by common criteria CC1 to CC9, applies to every SOC 2, and the auditor will test whether the controls described actually run. The wiki is evidence of design and communication, not the control itself.

For that reason, the design question is what the wiki must show an auditor and what it must do for staff. Start by mapping each control activity in your system description to a named page, owner, approval step and review date, including the escalation path for incident reporting. Confirm with your auditor which points of focus they expect you to address under CC5.3 and CC2.2, since the TSC describes them as characteristics to consider rather than separate requirements. Decide who may approve policy changes, how page history records those approvals, and how superseded versions are kept for the examination period. Ask your implementation partner to show how the platform's page history, revision comparison and permission model produce that record without manual steps.

The wiki also has to be findable under pressure. Staff who handle access requests, change approvals or security incidents need the current procedure within a few clicks, and the same pages must be readable when the main identity provider or the application cluster is unavailable. Test this as part of rollout: confirm search returns the right policy, that single sign-on failure has a documented fallback, and that the on-call group can reach a read-only export. Confirm with your auditor whether they will sample pages from the wiki, and keep the wiki owner, the policy owner and the control owner as clearly separate roles so that evidence of review is attributable to a person.

Which SOC 2 criteria the knowledge base must support and how to configure it

This table maps the SOC 2 criteria a wiki helps evidence to what the wiki must do and how to configure it. Read each row as a control question: what the criterion asks, what the wiki has to hold, and which settings produce that evidence. Points of focus are guidance, not separate requirements, so address the ones that fit your system and document why others do not apply.

Criterion and what it asks	What the wiki must do	How to configure it
CC1 to CC5 (COSO context): the 17 COSO internal control principles restated as criteria, covering control environment, risk assessment, control activities and information and communication	Hold the written control framework so that policies, procedures and control descriptions are findable from one place and traceable to the system description	Create a top-level space for the control framework, one page per policy with an owner field, and links from the system description to each control page. Confirm with your auditor which pages they will sample
CC5.3 (COSO Principle 12): deploy control activities through policies that set expectations and procedures that carry them out	Hold each policy and its matching procedure as separate, approved pages that name the control activity they put into action	Use a policy page for management's expectations and a procedure page for the steps. Each procedure names its control owner and the policy it implements. Require approval before publication
CC5.3 point of focus: management directives in policies and procedures, with responsibility and accountability for executing them	Show who approved each directive and who is accountable for carrying it out	Set a named owner and approver on every policy page. Record approvals in page history or a required approval step. Keep role-based groups for executors, not only individuals
CC5.3 point of focus: timely performance and corrective action	Show when procedures must run and what happens when they are not performed or fail	Add recurring task steps, escalation paths and a corrective action section to procedure templates. Link corrective action pages to the ticket or issue record in your tracker
CC5.3 point of focus: competent personnel and reassessing policies and procedures	Show that readers have access to current versions and that policies are reviewed on a set schedule	Add a review date and review owner field to each policy. Use page history to show revisions. Restrict editing of approved pages to owners and reviewers. Confirm review intervals with your own governance
CC2.2 (COSO Principle 14): communicate internally the objectives and responsibilities for internal control that the control needs to function	Publish control objectives, responsibilities and how to report concerns in a location every in-scope employee can reach	Create a read-only space for objectives, role responsibilities and the reporting method. Grant read access to all in-scope staff through directory groups, not manual lists
CC2.2 points of focus: board communication, separate reporting lines, incident reporting methods and security awareness	Hold board-level summaries, a documented separate reporting channel and incident reporting instructions that employees can find quickly	Create a board summary page with restricted edit rights. Publish incident reporting steps with the channel and contact. Enable search so staff can find the page during an incident. Test that the page loads for a standard user account
CC2.2 points of focus: system objectives, operation, boundaries and changes	Describe the system, its boundaries and planned or completed changes so staff know how controls apply to them	Keep system description and change notice pages under version history. Use a dated change log page with links to the change record. Tag pages by system component to support filtering
Privacy points of focus under CC2.2 (apply only if the privacy category is in scope): communicate information to improve privacy knowledge and awareness	Publish privacy notices and staff privacy guidance, and separate personal data from general wiki content	Include privacy pages only when privacy is in scope. Restrict pages that describe individuals or personal data to named groups. Confirm with counsel which privacy pages are required

Which open-source wiki platforms fit a SOC 2 program

Four platforms cover most knowledge base choices for a SOC 2 program, but they differ in license terms, structure and identity features. The right fit depends on team size, how many formal approval steps policies need, and whether the organization wants a commercial support contract. Each card below names the decision to make before selecting one.

BookStack for simple policy books

BookStack is a wiki platform licensed under MIT, and its book and shelf structure maps well to a small set of policies, standards and operating procedures grouped by control area. Teams with a single administrator and modest page counts often find it the lightest option to run. Check how page history, review dates and approval records are handled in the current version, because a simple structure does not by itself produce evidence of periodic review. Confirm the SSO options against your identity provider before you commit.

Outline and its license limits

Outline is licensed under the Business Source License 1.1, and its additional use grant forbids using it to offer a commercial Document Service. An internal SOC 2 wiki is generally a different use from offering a document service to customers, but that boundary is a legal question. Have counsel review the license against your deployment, especially if the wiki will be shared with customers or partners. Outline fits teams that want a modern editor and have already cleared the license.

XWiki for structured approvals

XWiki is licensed under the LGPL 2.1 and offers structured applications that can model policy objects, owners and review cycles. It suits larger teams and organizations with several control owners who need page-level permissions and more formal content structure. Its stable line, an LTS line and an intermediate LTS line are available as official Docker images, so choose the line that matches your upgrade tolerance. Verify in the current documentation which approval, review reminder and attestation features are included in the free edition.

XWiki Pro for supported identity

XWiki Pro is a commercial offering from XWiki SAS that adds business applications, connectors and support on top of XWiki. It lists Active Directory and Azure Active Directory SSO applications and Office365 and OnlyOffice connectors, which matter when access reviews depend on directory groups. Subscription tiers are sized by user count, so confirm your headcount and the tier that covers it. Ask for the support scope and service levels in writing before you rely on them as part of your control evidence.

Pairing the wiki with a ticketing tool

A policy wiki records what the organization intends to do, but corrective action needs a place where findings are logged, assigned, tracked and closed. Pair the wiki with any ticketing or ITSM tool your organization already runs, and link each finding to the page version it relates to. Define who owns the link between a corrective action and the procedure it changes, and how closure is checked. The choice of ticketing product is separate from the wiki decision and should follow your existing service desk.

Evidence auditors ask for and which component produces it

This table maps each evidence item an auditor commonly requests to the SOC 2 criterion it supports, the wiki feature or adjacent system that produces it, and what the auditor is likely to sample. Read it as a preparation checklist: the auditor decides whether the evidence is sufficient, and for a Type 2 report the sample period determines which records must exist and remain intact.

Evidence item	Criterion supported	Produced by	What the auditor samples
Approved policy versions with dates and approver	CC5.3	Wiki page with version history and an approval record or sign-off page	Current policy and prior versions, with approver name and approval date matching the change log
Procedure pages linked to named owners	CC5.3	Wiki procedure pages with an owner field or template banner and links from the control matrix	Procedures for sampled controls, confirming the owner is accountable for execution
Review and reassessment records	CC5.3	Review checklist page, scheduled review tasks and page history showing review edits	Evidence that each policy was reassessed on the stated cycle and that gaps led to updates
Page history showing who changed what and when	CC5.3, CC2.2	Built-in page revision history, with retention settings kept at their default or longer	Edits made during the sample period, including authors, timestamps and any deleted or reverted revisions
Communication records such as announcements and onboarding acknowledgments	CC2.2	Announcement pages or posts, plus acknowledgment forms or pages that record each user's confirmation	Announcements issued in the period and acknowledgment records for a sample of new and existing staff
Board or management reporting pages	CC2.2, CC1 governance criteria	Dedicated space or page for management reports, with restricted edit rights and a dated history	Reports delivered to the board or management, showing security objectives, incidents and control status
Incident reporting instructions	CC2.2	Published incident procedure page with reporting channels and contacts, linked from the staff home page	Current instructions, prior versions in the period and evidence that staff could find them
Security awareness content	CC2.2	Training pages or course modules with completion tracking in the identity or learning system	Content published in the period and completion records for a sample of personnel
System description and boundary pages referenced by the system description	CC2.2, CC5.3	Controlled system description page that management maintains alongside the SOC 2 description	Consistency between the wiki page, the system description and the systems in scope, including changes dated in the period

What a wiki alone does not satisfy

Does publishing policies in a wiki satisfy SOC 2 control activities?

No. A wiki holds the written expectations, but CC5.3 is about deploying control activities through policies and procedures that carry them out. The policies must be designed, approved, assigned to named owners and followed in daily operation. Auditors look for evidence that people performed the procedures, not only that the text exists. Treat the wiki as the place where control design lives, and plan separately for the people, tools and records that make the controls work. Confirm with your SOC 2 auditor which policies and procedures are in scope for your system before you decide what the wiki must hold.

Where does SOC 2 control operation evidence actually live?

Operation evidence usually sits in other systems, not in the wiki. Examples include access review records in your identity provider, change tickets in your service desk, system and audit logs in a log platform, and training completion records in an HR or learning system. The wiki can link to these sources and describe how they are produced, but it rarely proves that a control ran. Before you design the knowledge base, list each control activity, the system that records it, who can export that record, and how long it is kept. Gaps in this map are a common reason controls fail to show operation during an examination.

What happens to wiki policies without a review cadence?

They drift. Without an enforced review cycle, policies describe systems, roles and vendors that no longer exist, and staff stop trusting the content. Set a documented review frequency for each policy, assign an owner, and record the approval date and approver on the page. Configure reminders or a periodic report of overdue pages, and keep the prior versions so reviewers can see what changed. The review cycle itself becomes evidence that the reassessment of policies and procedures happens, which is one of the points of focus under CC5.3. Ask your implementation partner how the chosen wiki exposes page ownership and review dates.

Does a SOC 2 Type 2 report need more than a current wiki?

Yes. A SOC 2 Type 1 report covers the description of the system and the suitability of control design as of a specific date. A Type 2 report adds an opinion on operating effectiveness over a period, so the auditor must see controls operate consistently across that window. A wiki that was correct on the examination date does not show that procedures were followed in the months before it. Plan for continuous evidence collection from the start of the observation period, including page history, approval records and the operational records listed elsewhere in your control map. Confirm the observation period and evidence expectations with your auditor.

Can a SOC 2 report be shared with customers and the public?

A SOC 2 report is generally restricted use, which means it is intended for specified parties such as management, existing customers and certain business partners under agreed terms. A SOC 3 report covers the same trust services categories in less detail and is a general use report that can be freely distributed. Organizations that need a public-facing assurance statement often consider SOC 3, while keeping the full SOC 2 report under controlled access. Your knowledge base can help manage who receives which report, but the distribution decision belongs to management and should be reviewed with your auditor and legal team.

Will the proposed attestation standard changes affect our SOC 2 work?

Possibly, and the timing matters. The AICPA Auditing Standards Board exposed proposed revisions to its baseline attestation standards in February 2026. If adopted, they would apply to engagements beginning on or after June 15, 2029. The proposal is not final, so no change should be assumed. Assign someone to track the outcome, ask your auditor how any adopted revisions would affect your examination and document the decision in your governance records. Keep your policy and procedure structure flexible enough that updated requirements can be mapped to existing pages without rebuilding the whole knowledge base.

How to roll out SOC 2 policy pages in order

This sequence moves policies from scattered files into one controlled, owned and acknowledged set of pages that auditors can trace back to the criteria they support. Each step ends with a check that shows the work is done before the next step begins.

Inventory existing policies and their locations
Collect every policy, standard, procedure and runbook that touches security, availability or other in-scope categories, including files on shared drives, email attachments, the current wiki and printed binders. Record the owner, current version, last review date and location for each item. The step is done when the list covers every document that staff are told to follow, and the management team has signed off that nothing known is missing.
Map each policy to supporting criteria
For each inventoried item, identify the SOC 2 common criteria it supports, such as the control environment (CC1), communication (CC2), risk assessment (CC3), monitoring (CC4), control activities (CC5) and the access, operations and change criteria in CC6 to CC9. Mark gaps where a criterion has no policy or procedure behind it, and mark duplicates that need merging. The output is a traceability matrix that the compliance lead and the external auditor can read without help.
Choose the platform and configure SSO and permissions
Select the wiki platform against the requirements gathered so far, including page history, approval workflow needs, export and search. Connect it to the corporate identity provider through SAML or OIDC, then map directory groups to spaces so that policy owners can edit, staff can read and external parties have no access by default. Test the setup with a small set of accounts from each group and confirm that a removed user loses access. Your partner should document the configuration and the permission model in the wiki itself.
Migrate content and assign owners and review dates
Move the inventoried content into the platform, keeping the version history where the source system allows it and noting where it does not. Give each policy a named owner, an approver, an effective date, a review interval set by the organization and a link to the criteria it supports. Retire the old copies and set a redirect or notice at the old location. The step is complete when every live policy has an owner and review date, and no approved policy remains only in an unmanaged location.
Publish with acknowledgment and a communication plan
Publish approved policies and announce them with a plain summary of what changed, who must read them and how to report an incident or raise a concern. Require staff to record an acknowledgment, and use the platform or a linked form to track completion by role. Include system objectives, boundaries and responsibilities in the communication plan so that new hires and contractors receive the same information. The output is an acknowledgment report by person and policy, and a log of the announcements sent.
Run periodic reassessment and keep evidence
Set a recurring review cycle in which each owner confirms the policy is accurate, records any change and triggers re-acknowledgment when content changes materially. Review the traceability matrix when systems, vendors or scope change, and log corrective actions raised from incidents or audits. Confirm with the auditor which evidence format and retention period they expect, because the requirements depend on the engagement. The step is done when the review log, change history and acknowledgment records can be produced on request.

What drives the cost of a SOC 2 knowledge base

The platform licence is usually the smallest line item. BookStack (MIT) and XWiki Standard (LGPL 2.1) can be deployed without a licence fee, and Outline's Business Source License 1.1 also carries no per-seat fee for internal use, though its additional use grant limits some commercial uses, so confirm that terms fit your model. The recurring costs sit elsewhere: the people who host, patch, back up and administer the wiki, the identity integration that controls who can read and edit policies, and the owners who keep procedures current. A subscription only enters the picture if you choose XWiki Pro or an XWiki support plan, whose tiers are priced by user band (Starter, Basic, Business and Enterprise) and where cloud and on-premises pricing is the same, according to XWiki SAS. One-time costs cluster around setup and migration. If you are moving from Confluence, XWiki SAS lists Confluence Migrator Pro from 2000 EUR, and its trial is limited to 30 pages per migration. Check whether the licence covers attachments and history, since the tool keeps page history but not attachment history. XWiki SAS also lists consulting at 1200 EUR per day, which requires a Business or Enterprise support plan, and training at 1500 EUR per day. Tell any implementation partner which of these items you need, because a fixed-scope quote can separate SSO setup, policy template design, content migration and staff training.

Content work is the cost most often underestimated. Each policy that supports a control activity under CC5.3 needs a named owner, an approval step, a review date and a link to the procedure it governs. Writing and restructuring that material is paid for in staff hours, whether internal or contracted, and it recurs every review cycle. Ask a partner to quote the template and approval workflow separately from the bulk content import, and to state whether the quote assumes your owners write the content or the partner drafts it. Recurring costs also include upgrades: confirm the release cadence, the security patch process and who performs testing against your identity provider before each change.

Before you sign, ask for a written, fixed-scope quote that lists each deliverable, the named exclusions, the hosting model, the support hours and the handover format. Confirm which items are one-time and which are annual, and how user counts change the subscription band. Ask what happens to the quote if the migration sample reveals more permission exceptions than expected. Quotes that are vague about these points usually shift cost into later change requests.

How the knowledge base scope changes by organization type

A small team preparing for its first SOC 2 Type 1 usually needs a wiki that holds a complete, approved set of policies and procedures before the system description is finalized. The priority is a clean structure with one owner per policy, a short approval path and enough page history to show what was approved and when. Permissions can stay simple, because the people who write and approve policies are usually the same few leaders who run the service.

Permissions: A small number of editors, with most staff in a read-only role. Avoid per-page exceptions until there is a real need for them.
Review cadence: Set a documented review date for each policy and record the approver on the page, so the first review cycle is not improvised.
Platform tier: A community edition of a lightweight wiki such as BookStack is often sufficient at this stage. Confirm current license terms and features with the vendor before committing.
Evidence: Keep page history and exports of approved versions so the auditor can see the policy as it stood on the date the description was prepared.
Scope limit: Do not publish more policies than the team can operate. Every page that describes a control becomes something the auditor may test.

Before starting, confirm with your auditor which policies and procedures they expect for the chosen criteria and whether the wiki's history is accepted as evidence of approval.

What buyers ask before hiring help for a SOC 2 knowledge base

Does a self-hosted wiki satisfy SOC 2 on its own?

No. A wiki does not satisfy SOC 2 by itself. SOC 2 examines whether the control environment works as described, and a wiki is one place where policies, procedures and control information live and are kept current. The auditor still needs evidence that people read the content, that owners approved it, that reviews happened on schedule and that the process matches what is written. Those points depend on your policies, staff behavior and monitoring, and an independent CPA firm decides whether the controls meet the criteria. DeployOpen can configure the wiki, access model, review workflow and evidence exports so the controls are easier to demonstrate, but the wiki is a supporting system, not the control itself.

How much does a self-hosted wiki cost compared with a SaaS workspace?

The software license is not the main cost driver. Open-source wikis such as BookStack (MIT) and XWiki Standard (free, LGPL 2.1 for the Docker images) have no license fee, so cost comes from hosting, administration, identity integration, migration and any support you buy. XWiki SAS lists consulting at 1200 EUR per day for Business or Enterprise support plans, and XWiki Pro and support subscriptions are tiered by user count, with cloud and on-premises pricing stated as the same. A SaaS workspace bills per member on a recurring basis. Ask any partner for a fixed-scope quote that separates one-time setup from recurring hosting, upgrades and support, and compare it with your current per-seat invoice over the same period.

How long does a SOC 2 knowledge base setup take?

The duration depends on the number of spaces, the state of your existing policies, the identity provider and the migration scope. Teams with clean policies in Markdown or Word, one identity provider and no legacy wiki usually move faster than organizations that must rebuild a policy library, map groups to spaces and reconcile permissions. A migration from Confluence adds time for permission mapping and validation. DeployOpen does not publish a fixed timeline; the duration is set in the written scope before work starts, and you should ask for milestones tied to access reviews, approval workflows and evidence exports.

What does the work need from our staff?

Your staff must own the content and decisions, even when a partner builds the platform. Expect to name a policy owner for each policy and procedure, a reviewer who approves changes, a group owner who approves access and someone who answers for the identity provider. Security, compliance and operations leads typically confirm control descriptions, the system boundary and review cycles. Engineers handle hosting, SSO and backups. Without these named roles, the wiki will hold content that nobody maintains, and that is the finding an auditor is most likely to raise.

Can our own team run a SOC 2 knowledge base without a partner?

Many teams can run a wiki internally if they have administration skills, time for upgrades and a clear owner for security configuration. The risks are usually operational rather than technical: missed security updates, unreviewed access grants, backups that were never restored and policy reviews that slip. Ask whether your team can sustain patching, identity configuration, permission audits and documented procedures for the life of the platform. A partner can implement, harden, document and support the platform on a fixed-scope or retainer basis, and you keep ownership of the content and the decisions.

How do we handle Confluence migration history and permissions?

Start by deciding what history must be preserved and why. The Confluence Migrator Pro from XWiki SAS migrates spaces, pages, users, groups, permissions, attachments and metadata, and keeps page history but not attachment history, so attachment version evidence needs a separate plan. Its trial is limited to 30 pages per migration, and the tool is priced from 2000 EUR according to the XWiki Store listing. Map Confluence groups to your identity provider before migration, validate permissions on sample pages and export the migration log as evidence that the move was controlled. Confirm each limit with the vendor before you commit.

Which SOC 2 criteria apply beyond security?

Security is covered by the common criteria CC1 to CC9, and these apply to every SOC 2 report. The other four categories, availability, processing integrity, confidentiality and privacy, add criteria only when your scope includes them. For a policy and communication wiki, CC5.3 covers policies and procedures that put control activities into action, and CC2.2 covers internal communication of control information such as responsibilities, incident reporting methods and system changes. If your report includes privacy, the privacy points of focus under CC2.2 add communication about privacy knowledge and awareness. Confirm the category list with your auditor before scoping the wiki.

Does DeployOpen issue SOC 2 audit reports?

No. DeployOpen does not issue audit reports, attestations or certifications. A SOC 2 examination is performed by an independent CPA firm, which evaluates management's system description and the controls against the Trust Services Criteria. DeployOpen prepares the systems, controls and evidence that support that assessment, such as access configuration, review workflows, backups, hardening and documentation. Before engaging anyone, ask your auditor which evidence they expect from the wiki and confirm it in the written scope.

Where the criteria and platform licenses are documented

Before you map a knowledge base to SOC 2, pull the source text for the criteria yourself rather than relying on a summary, including this page. The AICPA publishes the *2017 Trust Services Criteria with revised points of focus (2022)*, which sets out the wording of CC2.2 and CC5.3 and the points of focus your auditor will read against. Keep a dated copy in the compliance repository and record which version your examination period uses, because the points of focus are guidance and not separate requirements. For the broader framing of what a SOC 2 examination covers and how the categories are scoped, the AICPA overview of SOC 2 for service organizations is the natural next read. Ask your auditor which version of the criteria they will test against before you write any policy text.

Next, decide whether the report you need is SOC 2 or SOC 3. A SOC 2 report is generally restricted in use, while a SOC 3 general use report covers the same categories in less detail and can be freely distributed. If you plan to publish a trust summary to customers, confirm with your auditor and legal team that the wiki pages you link to will not contradict the scope of the report. For the platform side, read the license terms of each candidate before you commit: BookStack is MIT licensed, Outline is licensed under the Business Source License 1.1 with an additional use grant that forbids offering a commercial Document Service, and XWiki is licensed under the LGPL 2.1. Your legal team should confirm how each license applies to your deployment and to any modifications or extensions you plan to build.

How DeployOpen scopes and delivers a SOC 2 knowledge base

DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a SOC 2 knowledge base, we start from the control activities and communication evidence your auditor will ask to see, then build the wiki around them.

How we scope

We map which policies, procedures and staff communications the wiki must hold for your in-scope Trust Services Criteria.
We agree on the page structure, owners, review cycles and approval steps for each control-related document in writing.
We document who can read, edit and approve each space, and how directory groups map to those roles before work starts.

How we build

We deploy the chosen wiki platform in your environment and connect it to your existing identity provider for single sign-on.
We configure space and page permissions, templates, page history and approval workflows so policy changes leave a traceable record.
We test access rules and version history against the written scope, and document the results for your compliance team.

How we hand over

We deliver architecture notes, configuration records, admin runbooks and the access matrix as documented handover materials.
We train policy owners and administrators on publishing, reviewing and retiring documents, and on recording acknowledgments.
We prepare control evidence exports and an index that maps wiki content to the criteria in scope, for your auditor to review.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover, agreed in writing.
We apply platform upgrades and security updates in a staging copy first, then document what changed in your environment.
We reassess permissions and content structure when your system boundary, staff or in-scope categories change.