Why Confluence is a natural home for SOC 2
A SOC 2 program is mostly writing. You write policies, you write procedures for the controls you run, and every quarter or year you write up the evidence that you ran them. If your team already documents its systems, runbooks and decisions in Confluence, putting the SOC 2 program there too has real advantages over a separate tool nobody opens.
- People already know the editor. Policy owners can draft, comment and revise without learning a new system, and engineers can link a policy to the runbook it describes.
- Every page has a history. Confluence keeps each published version of a page, with who made it and when, and lets you compare versions.
- Permissions are built in. Spaces have their own permissions, and on paid plans individual pages can carry view and edit restrictions.
- Auditors can read it. You can give an auditor access to the space, or export pages (for example to PDF) when they want files.
- It sits next to your other evidence. Access review exports, scan results and meeting notes can be attached to the page that describes the control they prove.
That is why "SOC 2 in Confluence" is such a common setup for startups and small companies. The question is not whether Confluence can hold your program, but how to structure it and what you need to add so it stands up in an audit.
How to structure a Confluence compliance space
Start with one dedicated space for the program rather than scattering policies across team spaces. A single space gives you one place to point the auditor, one set of permissions to manage, and a clean page tree. A structure that works well:
- Space home: what the program covers, who runs it, the security contact, and how to use the space.
- Policies: one child page per policy (Information Security, Acceptable Use, Access Control, Incident Response and so on).
- Recurring activities: one page per control you perform on a schedule, describing the objective, cadence and procedure. Under each, one evidence page per period, such as "User Access Review, 2026 Q3".
- Controls matrix: a page that maps each Trust Services Criterion in scope to the policies and activities that support it.
- Evidence and reports: approval records, acknowledgement records and activity completion summaries, organized by year.
Who should be able to do what
| Section | Who edits | Who reads |
|---|---|---|
| Policies | The policy's owner and the people running the program | All employees |
| Recurring activities and evidence pages | The activity's owner and the people running the program | All employees, or a narrower group if evidence is sensitive |
| Controls matrix | The people running the program | Program admins and auditors |
| Approval and acknowledgement records | Nobody by hand, ideally | Program admins and auditors |
Conventions that save you later
- Use the same section headings in every policy: Purpose, Scope, Roles and Responsibilities, Policy Statements, Exceptions, Enforcement, Related Documents.
- Name evidence pages with the activity and the period, so a search for "User Access Review" lists every quarter in order.
- Write policy statements as testable "must" and "should" sentences. An auditor tests what you wrote, so promise only what you do.
- Keep status out of the page body if you can. Every edit creates a new version, and you want the versions to be about the policy text, not bookkeeping.
Where plain Confluence falls short for a SOC 2 audit
A well-organized space is a good start, but an auditor is not only reading your policies. For a Type 2 report they are testing whether your controls operated over the observation period (commonly 3 to 12 months; your auditor sets yours). That needs records Confluence does not keep on its own.
Page history is not an approval record
Confluence shows who edited a page and when. It does not show that a manager reviewed version 7 and approved it, or that nobody changed the text between the review and the sign-off. A comment saying "approved" or a name typed into a table can be edited later, and it is not tied to a specific version. Auditors commonly expect management to review and approve policies (CC5.3 covers deploying controls through policies and procedures), so you need evidence of who approved which text, and when.
If you stay manual, record each approval in a separate, locked log with the page version number, the approver, the date and a link to that exact version, and re-approve whenever the text changes. More on this in Policy approvals and version control auditors accept.
No way to prove who read which version
Employees reading and accepting key policies, such as Acceptable Use or the Code of Conduct, is a standard SOC 2 expectation. Confluence has no acknowledgement step, and knowing that someone opened a page is not the same as a statement that they read and accepted a particular version. Teams often fall back on a form or a spreadsheet, which then has to be matched against the employee list and against which policy version was current at the time.
If you stay manual, keep one record per person per policy version, with the date, and re-run it when a policy changes in a way that affects what people must do. How to track employee policy acknowledgements covers the details.
No schedule for recurring controls
Many SOC 2 controls are periodic: quarterly user access reviews, monthly vulnerability scan reviews, an annual risk assessment, an annual incident response tabletop. Confluence does not know any of these are due. Nothing creates the page, nobody is reminded, and a missed quarter only shows up when the auditor asks for it.
If you stay manual, keep a calendar of every control with its cadence and owner, and create each period's evidence page ahead of the due date. The SOC 2 compliance calendar shows how to build one.
Evidence per period is hard to show
An auditor typically samples periods, for example "show me the access reviews for Q2 and Q4" (how many and which ones is their call). In a plain space you can find the pages, but proving that each one was completed, reviewed and signed off before its due date means checking page histories and comments one by one. Gaps are easy to miss and hard to explain.
If you stay manual, keep a summary table per year that lists every period, its due date, when it was completed, who signed it off and a link to the evidence page version they signed off.
Permissions drift
You lock a policy so only its owner can edit it. Six months later the owner has changed teams, someone removed a restriction to fix a typo, and a new hire was added to the space with the wrong role. Nothing in Confluence tells you. Since an auditor may ask who can change your policies, drift turns into an awkward conversation.
If you stay manual, review the space permissions and page restrictions on a schedule (it fits naturally into your user access review) and record what you changed.
Running SOC 2 in Confluence with Compliance in a Box
Compliance in a Box is a Confluence Cloud app that keeps the program in Confluence and adds the records that plain pages lack. Policy text is still written with the normal Confluence editor; the app handles the workflow and the evidence around it.
- A dedicated space, set up for you. The app creates one compliance space for your site (or takes over an empty space an admin creates for it) and generates the page tree: policies, recurring activities, a controls matrix and an Evidence & Reports section. With every Trust Services category selected, that is 24 policy templates and 15 recurring activities. Existing policies can be imported.
- Managed, locked pages. Only a page's owner and the Compliance Admins can edit it. The lock follows owner changes, and if someone removes a restriction by hand, the app's daily check puts it back and records it in the audit log. Locking needs Confluence Standard or above.
- Version-bound approvals. An owner submits a policy, and every assigned approver approves that exact page version. The app records the version number and a fingerprint of its content; if the page is edited before the decision, the submission is cancelled. Self-approvals are allowed but flagged on the Dashboard.
- Acknowledgements. When a policy is approved for the first time, or after a material change, everyone in its audience (all employees or specific groups) is asked to click through and acknowledge the approved version, with a due date. The version each person acknowledged is recorded.
- Recurring activities. Each activity runs monthly, quarterly, semi-annually or annually, aligned to your fiscal year, and the app opens a dated evidence page for each period before it is due. The owner fills it in and submits it for approval. Skipping a period needs a written reason.
- Dashboard and My Tasks. Compliance Admins see overdue work, upcoming reviews and acknowledgement completion. Everyone else sees what is waiting on them, and reminders arrive as Confluence task notifications.
- Evidence reports. A Policy Approval Log, Policy Acknowledgement Report, Activity Completion Report, Audit Log and the controls matrix are generated as Confluence pages and refreshed daily, with links to the exact page versions that were approved. They are restricted to Compliance Admins and an optional Auditors group.
The app runs on Atlassian with no external services, and your policies and evidence stay ordinary Confluence pages in your space. To see what setup involves, read Getting started, or start from the user guide overview for the big picture.
The policy templates and control mappings are a starting point, not legal or audit advice. Tailor them to how your company works and have them reviewed by your auditor.
FAQ
Is Confluence enough on its own for a SOC 2 audit?
It can hold everything, but you need disciplined manual records for approvals, acknowledgements, recurring control evidence and permission reviews. Many small teams manage that with locked log pages and a calendar. What your auditor accepts as evidence is their call, so agree the format with them early.
Should the compliance space be a new space or an existing one?
A new, dedicated space is easier to permission and easier for an auditor to navigate. Move or copy existing policies into it rather than adopting a space full of unrelated pages.
Does it matter which Confluence plan we are on?
Page restrictions, which you need to stop people editing policies they don't own, are not available on Confluence Free. Without them, anyone who can edit the space can edit every policy, so plan for Standard or above.
Can auditors work directly in our Confluence space?
Yes, if you give them access, typically as guests or through a dedicated group with view-only rights. Some auditors prefer exported files instead; ask which they want before fieldwork starts.