---
title: "Policy review evidence: what auditors check beyond the text"
canonical: "https://auditbadger.com/blog/policy-review-evidence-what-auditors-check-beyond-the-text/"
last-updated: "2026-10-09"
---

# Policy review evidence: what auditors check beyond the text

By Maciej • Published 2026-10-07 • 7 min read • Categories: Policy Management, Compliance Governance, Soc2, ISO

Created with AI assistance. AuditBadger retains editorial control and responsibility.

**TL;DR:** For SOC 2 and ISO 27001, auditors test the governance around a policy rather than its prose: which version was in force and from when, who approved that exact version before publication, the version history, evidence of a periodic review within the interval you committed to (even when nothing changed), workforce acknowledgment of the current version including new hires, and the link from the policy to the controls it supports. ISO 27001 Annex A 5.1 and clause 7.5 and SOC 2 CC5.3 and CC2.2 all point at this. Record a no-change annual review as its own event (version, reviewer, date, outcome, next review date) instead of publishing a cosmetic new version, make approval apply to a frozen version so any later edit sends it back, and check acknowledgment rates before the audit window rather than during fieldwork.

When an auditor looks at your policies, the wording gets less attention than you would expect. What they check is the paperwork around it: [who approved each policy before it went live, when it took effect, whether someone reviewed it on schedule](/blog/policy-contradictions-find-them-before-your-auditor-does/) (even if nothing changed), and whether the people it applies to acknowledged it. A beautifully written policy with no approval record is a finding. A plain one with a clean trail usually is not.

That surprises most teams the first time. You spend a week polishing wording, and then the auditor asks one question you did not prepare for: "Who approved version 3, and when?"

Here is what they actually check, why, and how to record an annual review when the honest answer is "we read it, it's still right".

## Why do auditors care more about the trail than the text?

Because the text is a claim and the trail is proof. A policy says "we do X". The auditor's job is to test whether your organization actually runs the policy as a managed thing: someone with authority owns it, it changes deliberately, and people know it exists.

Both major frameworks say this outright.

- ISO 27001:2022, Annex A 5.1 asks for information security policies that are defined, approved by management, published, communicated to and acknowledged by relevant personnel, and reviewed at planned intervals and when significant changes occur. Every verb in that sentence is something you can be asked to show.
- ISO 27001 clause 7.5 adds the document control side: appropriate review and approval of documented information, plus version control.
- SOC 2® CC5.3 covers deploying control activities through policies and the procedures that put them into action. CC2.2 covers communicating responsibilities internally, which is where acknowledgment comes in.

None of those criteria grade your prose. They grade whether the policy is alive.

## What will a reviewer ask for?

For a sample of your policies (usually the information security policy plus a few others like access control and incident response), expect requests along these lines:

1. The version in force. Which version was effective during the audit period, and its effective date.
2. Approval before publication. Who approved that version, in what role, and on what date. The approval date should not come after the effective date. (Backdated approvals look exactly like what they are.)
3. Version history. What changed between versions, and that each version went through the same approval step.
4. [Periodic review. Evidence the policy was reviewed within the interval you committed to, usually annually.](/blog/compliance-calendar-every-recurring-date-in-one-place/) This applies even when no edits were needed.
5. Acknowledgment. Proof that the people in scope acknowledged the current version, including people who joined mid-period.
6. The link to controls. Which controls the policy supports, so the auditor can follow the thread from policy to practice.

If you can answer all six for every sampled policy in a few minutes, policy testing is a non-event. If any of them involves digging through Slack threads, plan a long afternoon.

## How do you record an annual review when nothing changed?

This is where many teams quietly fail. The policy is fine, so nobody touches it, so there is no evidence anyone looked. Twelve months later, the auditor sees a policy last modified two years ago and writes it up as not reviewed.

The fix is boring and quick. Record the review as its own event, separate from editing. A useful review record has five fields:

- The policy and the version you reviewed
- Who reviewed it (someone with the authority to approve it)
- The date
- The outcome: no changes needed, or changes needed
- The next review date

That's it. "Reviewed version 2.1, still accurate, no changes, next review October 2027" is a perfectly good record. You do not need to publish a version 2.2 with a new date on the cover just to prove someone read it. In fact, please don't: cosmetic new versions muddy your history and make the real changes harder to spot.

If the review finds something that does need to change, the outcome becomes "changes needed" and you open a new draft, which then goes through approval like any other version.

## What about approval before publication?

The weak point in most small-team setups is the gap between "someone said it looks good" and the moment the policy goes live. A thumbs-up in chat on a Google Doc that kept changing afterward is not an approval of a specific version. An auditor cannot tell what was approved.

What you want is:

- A named approver for each policy (often the CEO or CTO in a small company, which is fine)
- Approval of an exact, frozen version of the text
- A record of who approved and when
- Any edit after approval sends it back for another look

The last point matters more than it seems. "Approved, then tweaked one paragraph, then published" means the published text was never approved. Small edit, real finding.

## Acknowledgment: the part that drifts

Acknowledgment looks done the week you roll out a policy. Then people join, people change roles, and a new version gets published. Six months later your acknowledgment rate is quietly lower than you think, and the new hires are the gap.

Three habits keep it honest:

- Ask for acknowledgment of each new version, not just the first one
- Make policy acknowledgment part of onboarding, with a deadline
- Check the numbers before the audit window, not during fieldwork

For more on rolling policies out to a team so people actually read them, see [internal policy management: the complete practical guide](/blog/internal-policy-management-the-complete-practical-guide/).

## Which policies does this apply to?

All of them, but auditors sample. Your information security policy is almost always in the sample. After that it depends on the controls under test. If you are still working out which policies you need in the first place, [the minimum policies you need for SOC 2](/blog/the-minimum-policies-you-need-for-soc-2-compliance-mapped-to-trust-services-criteria/) maps them to the criteria, and [9 internal company policies, with templates](/blog/9-internal-company-policies-examples-you-should-implement-templates/) covers the wider set most growing companies end up with.

A practical rule: the fewer policies you have, the easier the trail is to keep clean. Five policies you actually review beat twenty you wrote once and forgot.

## How we handle it in AuditBadger

This part of AuditBadger follows the checklist above fairly literally.

- **Approval before publication.** You can require a designated approver to sign off before a policy or procedure can be published. The text locks while the request is pending, so the approver reviews an exact version. Editing an approved draft clears the approval. Every request and decision is recorded with who acted and when.
- **Reviews without new versions.** When a policy is due for review and nothing needs to change, you record the review on the current published version: who, when, and the outcome. The next review date moves forward. If changes are needed, the review can open a new draft instead.
- **Policy governance as evidence.** An evidence source generates a snapshot of your policies: the version in force, when it was published and last reviewed, whether a review is overdue, and how much of the workforce has acknowledged it. That is most of the reviewer's checklist in one artifact.
- **Audit readiness knows about approvals.** If a draft is waiting on its approver, the readiness overview says so and shows how many days it has been waiting, rather than a generic "publish the document".

What stays with you: deciding who the right approver is, actually reading the policy at review time, and chasing the people who have not acknowledged it. No tool fixes a review nobody did. It just makes the one you did easy to prove.

For context, our own SOC 2® Type II observation window ran from 27 March to 27 June 2026, on AuditBadger, with no external consultants. You can read about the approvals release in the [changelog](/changelog/2026-09-23/), or see the wider control and evidence setup on the [compliance management](/features/compliance-management/) page.


## Frequently asked questions

### How often should internal policies be reviewed?

At minimum, annually for stable policies. But fast-changing areas—data privacy, AI usage, security—should be reviewed quarterly. Additionally, trigger events should prompt immediate review: regulatory changes, security incidents, new tool adoption, significant team growth, or audit findings. Set calendar reminders or use automated compliance tools that flag policies approaching their review date.

### What evidence do auditors check for policy approval and review?

Auditors verify six key items: the version in force during the audit period, who approved it and when, version history with approval records, evidence of periodic review (even if no changes were made), acknowledgment records from relevant personnel, and links to the controls each policy supports. AuditBadger's policy management workspace helps small teams organize approval workflows, review schedules, and acknowledgment tracking in one place for $250/month.

### How do I document a policy review when nothing changed?

Create a simple review record with five fields: the policy and version reviewed, who reviewed it, the date, the outcome (no changes needed), and the next review date. You don't need to publish a new version—just log that someone with approval authority reviewed it on schedule. AuditBadger's AI-assisted GRC platform helps teams track review dates and generate review records automatically, ensuring SOC 2 and ISO 27001 auditors see a complete trail.

### Why do SOC 2 and ISO 27001 auditors focus on policy approval records?

Auditors care more about approval trails than policy wording because the trail proves your organization manages policies deliberately—someone with authority owns them, changes are controlled, and people acknowledge them. ISO 27001 Annex A 5.1 and SOC 2 CC5.3 both require evidence that policies are approved, reviewed on schedule, and communicated. AuditBadger helps small teams maintain clean audit trails for policies, controls, and evidence without hiring consultants.

### Can AI help automate policy review tracking for compliance?

Yes—AI-assisted GRC tools like AuditBadger can send review reminders, suggest approval workflows, and generate review records that satisfy SOC 2 and ISO 27001 requirements. Instead of digging through Slack threads during an audit, small teams get organized policy version history, approval dates, and acknowledgment tracking in one workspace for $250/month with unlimited users.

### What evidence do auditors check for policy approval and review?

Auditors verify who approved each policy version before it went live, when reviews occurred (even if no changes were made), version history with approval dates, and employee acknowledgment records. A policy with perfect wording but missing approval trails will result in audit findings, while a plainly-written policy with complete documentation typically passes.

### How do I document a policy review when nothing changed?

Record the review as a separate event with five fields: policy name and version, who reviewed it, the date, the outcome (no changes needed), and next review date. You don't need to publish a new version—cosmetic version updates actually muddy your audit trail and make real changes harder to track.

### Can compliance software help automate policy review tracking?

Yes, GRC platforms like AuditBadger centralize policy approval workflows, version control, review schedules, and acknowledgment tracking in one place. This keeps all the evidence auditors need organized and accessible, eliminating the need to dig through email or Slack threads during an audit for $250/month with unlimited users.

### What's the difference between policy approval and policy acknowledgment for SOC 2?

Policy approval means someone with authority (typically management) authorized the policy before it went live, which SOC 2 CC5.3 requires for deploying controls. Policy acknowledgment means employees confirmed they read and understood it, which ties to CC2.2's requirement to communicate internal responsibilities. Both require separate documentation trails that auditors will sample.