Policy version control and approvals auditors accept

Most teams preparing for a SOC 2 audit write their policies early. Fewer can prove, months later, which version of each policy was approved, by whom, and that nobody changed it afterwards. That proof is what policy version control is for, and it is where policy evidence most often falls apart.

This article covers what auditors check when they test your policies, the one mistake that quietly invalidates approvals, and a practical policy approval workflow you can run with any tool.

What auditors look for in policy version control

In the Trust Services Criteria, policies sit under CC5.3: the organization deploys control activities through policies that establish what is expected. Your auditor will read the policies, but they will also test how you manage them. The exact tests and sample sizes are up to your auditor, but across most audits the same questions come up:

• An owner. Each policy has a named person accountable for keeping it current.
• A documented approval by an appropriate person. Someone with the authority to commit the company signed off, and there is a record of it with a date.
• A version history. You can show what changed, when, and why, not just that the page was edited.
• A periodic review. Policies are reviewed on the schedule they state, which for most companies is annually.
• The approved text is the text in force. The policy employees read today is the same text that was approved.
• Communication. Employees were told about the policy and acknowledged it. That is its own topic, covered in how to track employee policy acknowledgements.

If you are still deciding which policies to write, start with which policies you need for SOC 2. The rest of this article assumes you have them and need to manage them.

The core problem: approving "the policy" instead of a version

Here is how it usually goes. In March, the security lead writes an Access Control Policy in the wiki and emails the CTO, who replies "Approved." In June, someone edits the page to update the offboarding steps. In September, the auditor asks for the approval evidence.

You produce the March email. The auditor opens the page, sees it was last modified in June, and asks the obvious question: who approved the June text? Nobody did. The March approval covered a version of the page that is no longer published. What is in force today was never approved.

The root cause is that the approval was recorded against "the policy" as a concept, not against a specific text. An approval is only meaningful as a statement about exact words. So every approval record needs to identify the version it covers, and any change to that text needs a new approval.

The same problem shows up in other forms: a signed PDF that no longer matches the live page, or an approval recorded in a ticket that links to a page rather than a specific page version. Any setup where the approval and the text can drift apart independently will drift.

A policy approval workflow that holds up

You don't need special software to get this right. You need a few habits, applied consistently to every policy.

Give every policy one owner

One person, not a team. The owner keeps the text current, prepares changes, submits them for approval and runs the periodic review. A policy owned by "Engineering" tends to be reviewed by nobody.

Keep a version history with change summaries

Your wiki or document tool probably records every edit, which tells you what changed. It does not tell you why, or whether the change was approved. Add that with a revision table at the end of each policy, or a change summary attached to each approval:

Make the change summary specific enough that an approver (and later an auditor) can understand the change without diffing the page. "Updated policy" is not a summary.

Separate the draft from the approved text

Employees should never be reading unapproved text without anyone noticing. There are two common ways to handle this:

• Draft copies. Edit a copy, get it approved, then publish it over the live policy. Simple, but easy to get wrong when someone edits the live page directly.
• Visible status. Edit the live page, but make its status obvious ("changes pending approval") until the new version is approved, and keep a link to the last approved version.

Either way, restrict who can edit policy pages to the owner and whoever runs the compliance program. Fewer editors means fewer surprise changes.

Use an independent approver

An approval is stronger when it comes from someone other than the person who wrote the policy. The approver should have the authority to commit the company to what the policy says: a founder, CTO or head of a function, depending on the policy. In a very small company this may not be possible for every policy. If one person writes and approves, document that arrangement and be ready to explain it, because auditors may ask about separation of duties.

Review annually, even when nothing changes

Most policies state an annual review, and whatever cadence your policy states is what your auditor will test. A review where nothing changes still needs evidence: a dated record that the owner reviewed the text and an approver confirmed it is still accurate. A row in the revision table that says "Annual review: no changes" with an approval date is enough for many auditors. Without it, a policy last touched 18 months ago looks forgotten, not stable.

Decide what counts as a material change

Not every change needs every employee to read the policy again. A typo fix should still be approved (the published text changed), but it shouldn't trigger a company-wide re-acknowledgement. A change to what people must actually do should. Agree on that distinction up front and record which kind each approved change was.

Retire policies instead of deleting them

When a policy stops applying, don't delete the page. The approvals and acknowledgements from the period when it was in force are still evidence for that period. Mark it retired, with a date and a reason, and stop asking people to acknowledge or review it.

Policy version control checklist

• Every policy has one named owner.
• Every approval record names the exact version it approves, with a date and the approver.
• Every approved change has a written change summary.
• Any edit to approved text leads to a new approval, or the text is reverted.
• Unapproved edits are visible as such, and the last approved version is easy to find.
• Approvers are independent of the author wherever possible.
• Each policy has a next review date, and reviews with no changes are still recorded.
• Material changes are marked, so you know when to ask for acknowledgement again.
• Retired policies keep their history.

All of this ends up in your audit evidence. For how to organize it, see SOC 2 evidence collection.

Policy version control in Confluence with Compliance in a Box

Confluence already keeps every page version, which makes it a reasonable home for policies. What it doesn't do by itself is tie an approval to a version or notice when approved text changes. Compliance in a Box adds that layer to a Confluence space, and the policies stay ordinary Confluence pages.

• Approvals bound to a page version. When an owner selects Submit for approval, the submission records the exact Confluence page version and a fingerprint (a hash) of its content. An approver's decision is only accepted if the page is still at that version. If anyone publishes an edit after submission, the submission is cancelled automatically and the owner resubmits, so nobody approves text they haven't seen.
• Approved text stays approved. Editing an approved page doesn't change the approval. The approved version stands, the policy shows Changes pending, and the Policies tab links to exactly the version that was approved.
• Change summaries and material changes. Every submission requires a What changed? summary, and the owner ticks Material change when employees must acknowledge again.
• Every approver decides. Each policy has one to ten approvers, fixed when a version is submitted. All of them must approve; one rejection, with a required reason, sends it back.
• Status in the page byline. Each policy page shows its state under the title, such as Approved v7 · 2026-03-01, Changes pending approval or Your approval needed, and people can submit, approve or acknowledge from there.
• Locked pages. Only the policy's owner and Compliance Admins can edit it, using Confluence page restrictions (Confluence Standard or above).
• Review dates. SOC 2 policies are on a 12-month cadence counted from the latest approval. Policies are flagged Review due 30 days ahead and Overdue after, and Mark as reviewed records a no-changes review that still goes to the approvers.
• Self-approval flagged. Approving your own policy is allowed but labeled, and policies approved without an independent approver are listed on the admins' Dashboard.
• A record for the auditor. Every change is written to an append-only audit log, and a generated Policy Approval Log page lists each submission with its linked version, change summary, each approver's decision and the outcome.
• Retiring. Custom policies can be retired with a reason; their approvals, acknowledgements and history stay as evidence. Framework policies stay in the program.

The details are in the user guide: Policies and approvals, the Policy Approval Log and retiring a custom policy.

FAQ

Is Confluence page history enough for policy version control?

Page history shows what changed and who edited it, which is useful. It doesn't show who approved a version or why it changed. Pair it with an approval record that names the specific page version, plus a change summary.

Does a typo fix need a new approval?

If the published text differs from the approved text, the old approval no longer covers it. The safest practice is to approve every published change, keep minor ones quick, and mark them as not material so employees aren't asked to acknowledge again.

How often do policies need to be reviewed for SOC 2?

The criteria don't set a single number. Annual review is the common expectation and what most policies state. Whatever cadence you write into the policy is what your auditor will test, so pick one you will keep.

Who should approve a policy?

Someone with authority over the area the policy governs, and ideally not the person who wrote it. In a small company that is often a founder or the CTO. If the author must also approve, document why.

← All articles