What auditors actually look for in a SOC 2 policy

The difference between a policy that passes and a policy that fails isn't length — it's truthfulness, evidence, and consistency. Here's what experienced SOC 2 auditors actually check when they review your documents.

There is a persistent myth that SOC 2 auditors care about page count, formatting, or whether you used the "right" template. They don't. An auditor will pass a short, accurate policy and flag a long, eloquent one that doesn't match reality.

Having spent time on both sides of the table — writing policies and sitting across from auditors reviewing them — here's what actually gets checked, and why. If your policy kit clears these tests, your audit will be the business of collecting evidence, not the business of re-writing documents during fieldwork.

They read the header table first

Every well-formed SOC 2 policy has a header table at the top: policy ID, version, effective date, last reviewed, next review date, owner, approver. Experienced auditors look at this before they read anything else. Four checks happen in under thirty seconds:

Is there an effective date, and is it not in the future? A policy effective next month is a policy that isn't effective yet.

Is the "last reviewed" date within the last twelve months? Anything older means you're out of compliance with your own annual-review commitment.

Is "approved by" filled in, with a real name and title? An unsigned policy is treated as a draft.

Does the owner name match the role that would plausibly own it? If the Incident Response Policy is owned by your Head of Marketing, that's going to prompt questions.

If any of those four fail, the auditor already knows the policy kit wasn't maintained. The rest of the review becomes a search for confirming evidence.

They check whether the scope matches reality

Every policy's scope section should name the systems it covers. "All information systems" is not a scope; it's a waffle. The scope should name the cloud provider(s) in use, the identity provider, the office or remote-work posture, and the data types handled.

When an auditor reads "all information systems," the next thing they ask is: what are those systems? They want a list. If your list names three cloud providers and your policy references one, there's a mismatch. If your policy references an office that closed two years ago, same problem.

The fix is to write scope sections that match what you actually run, and update them when the company changes.

They look for quarterly access reviews, and then look for the evidence

The single most-evidenced control in a SOC 2 Type 2 audit is the quarterly privileged access review. Here's what the auditor checks:

Does the policy commit to quarterly? (Most do.)

Is there a review record for each quarter of the audit period? (A twelve-month audit requires four.)

Does each review record name who reviewed, what they reviewed, what they found, and what action was taken?

Are any access removals triggered by a review traceable to a ticket or change record?

Companies fail this test in three ways. Some promise quarterly but do it annually. Some do quarterly but don't save the output in a format the auditor can verify. Some save the output but the review is performed by the same person whose access is under review, which isn't really a review.

A review record doesn't need to be elaborate. A CSV of all privileged accounts, with a "reviewed by" column, a "action taken" column, and a date, is enough. But it has to exist for every quarter.

They compare the policy to the evidence request list

This is where the wheels come off for most unprepared companies. The auditor issues an evidence request list in the first week of fieldwork. It includes things like:

• The last four quarterly access reviews.
• Onboarding records for any employees hired during the audit period.
• Offboarding records for any employees who departed.
• The change log for the last ninety days of production changes.
• The incident log for the audit period.
• The vendor list with tiering and most recent review dates.
• The risk register with most recent review date.
• MFA enforcement evidence for privileged accounts.
• Backup and restore test records.
• The penetration test report from the last twelve months.
• Security awareness training records for all personnel.

The policy kit says each of these things will exist. The evidence request checks whether they do. A finding, in most cases, is the result of a gap between the two.

The first time you go through this is painful. The second time is manageable. The way to make the first time less painful is to pre-run the evidence request on yourself before the audit starts — take a list like the one above, and try to produce every artifact. What you can't produce in half a day is the gap to close.

They look for "aspirational" language

Auditors develop a sixth sense for language that sounds good but isn't operating. Some red flags:

"Where feasible." If the policy says a control happens "where feasible" and the feasibility determination isn't documented anywhere, the auditor assumes it isn't happening.

"The Security Committee meets quarterly to review…" If you don't have a Security Committee — if you're a five-person company where the CTO owns security by default — don't pretend you do. Auditors will ask for meeting minutes.

"Annual penetration testing is performed." If you haven't done one in the past twelve months, this line is a finding on its own.

"A tabletop exercise is conducted annually." Same test. If the tabletop didn't happen, the policy committing to it doesn't help — it hurts.

The auditor isn't trying to punish ambition. They are trying to verify whether the controls the policy describes are the controls the company operates. When the two diverge, the policy has to match reality, not the other way around.

They check internal consistency

Policies in a kit reference each other. Auditors follow the references. Common places things break:

Your Incident Response Policy says incidents involving customer data trigger notification within 72 hours. Your Customer Master Services Agreement commits to 48 hours. That's an inconsistency — the policy should match the shortest commitment across any contract.

Your Data Classification Policy says Restricted data includes payment cardholder information. Your Acceptable Use Policy's list of restricted data types doesn't include payment information. Auditors read both, notice the gap, and ask.

Your Access Control Policy defines "privileged account" one way. Your Logging and Monitoring Policy uses a different definition. The auditor's follow-up is: which definition is controlling? And where is that resolved?

These kinds of inconsistencies are the most common finding in first-time audits. They arise because different policies were edited at different times by different people, often from different templates. The only real fix is to read every policy alongside every other policy at least once a year and harmonize the terminology.

They look for named roles, not team names

"IT" doesn't own anything in the eyes of an auditor. "The security team" doesn't own anything. A named role owns it — CTO, Head of Engineering, Director of Security, whatever your org calls it.

If your policy assigns accountability to "IT," the auditor's next question is: who in IT? And what happens when that person is out? And what happens when IT doesn't exist yet because you're five people and "IT" is one of the CTO's ten hats?

The best-structured policies name a specific role (not a name, because the name can change) and then have a roster elsewhere — in the Information Security Policy's appendix, or in a separate roles-and-responsibilities document — that maps current people to current roles.

They check for a signed, current approval

The last thing on the page — the approval block — matters more than it looks. The auditor checks whether the policy was approved by someone with authority to approve it (the CEO, CISO, or senior equivalent — not an individual contributor); whether the approval date is in the past but within the last review cycle; and, if the policy has been materially revised, whether it was re-approved. Unapproved policies, or policies last approved three years ago, are treated as out-of-date. They don't carry weight in audit.

The shortest reliable test

There's one question an auditor asks, sometimes out loud, sometimes silently, as they work through a policy kit:

"If I had to execute this policy tomorrow using only what's written here, could I?"

If the policy assigns a control to a role that doesn't exist, or references evidence that can't be produced, or commits to a cadence the company doesn't operate on — the answer is no. And the gap between what the policy says and what the company does is where findings come from.

A policy that survives this test isn't necessarily elegant. It often reads like it was written by someone who knows the company's tools, its org chart, and its actual processes. That's because it was. The policies that fail this test tend to read like they were written by someone who had never set foot in the company — because they were downloaded from a template kit with a find-and-replace on the company name.

What this looks like in practice

If you are a small company preparing for your first SOC 2 Type 1 audit, a right-sized policy kit is twelve to fifteen documents, four to eight pages each. The kit should name your cloud provider, your identity provider, and your office posture by specific name; define the roles that own each control using titles that exist at your company; commit to cadences you can actually run (quarterly privileged access review, annual policy review, annual tabletop), and not to cadences you can't; match the commitments in your customer contracts; be internally consistent in its terminology and its definitions; and be signed, dated, and reviewed within the last year.

You do not need the biggest kit. You need the most honest one.