SOC 2 policies and evidence: what you need, what you do not, and how to keep it audit-ready

Controls first: what SOC 2 actually asks for

The AICPA's Trust Services Criteria state outcomes, not documents. A criterion expects access to be restricted, or changes to be authorised and tested; none says "keep a change management policy". You choose the controls that meet each criterion, management sets them out in the system description, and the CPA firm tests them. Because the points of focus are illustrative, two companies with quite different document sets can both earn an unmodified opinion.

Policies earn their place through the criteria themselves. Control activities are deployed through policies and procedures (CC5), the information that supports controls has to reach the people who run them (CC2), and staff are expected to know the standards of conduct that apply to them (CC1). A policy is how a control becomes repeatable, not a deliverable in its own right.

It also sets the yardstick. Where a policy fixes a frequency or a deadline, such as quarterly access reviews, the CPA firm normally tests against those words, so commit only to what your team achieves every time.

The ten policies most service organisations end up with

None is mandatory; each recurs because it gives common criteria a home. What counts is what each one commits you to.

• Information security. Management's commitment, the system and teams covered, who owns security, who approves exceptions, and the review cycle for the whole set (CC1, CC2, CC5).
• Access control. Request and approval, least privilege, where multi-factor authentication applies, the deadline for removing leavers, and who reviews access and how often (CC6).
• Change management. What counts as a change, who approves it, testing before release, separation of development from production, and review of emergency changes (CC8).
• Incident response. Severity levels, who leads, how staff and clients report an incident, when clients are told, and the review after each one (CC2, CC7).
• Business continuity and backup. Backup frequency and retention, how often restores and the plan are tested, and the recovery targets promised to clients (CC7, CC9; A if availability is in scope).
• Vendor management. The vendor inventory, risk ratings, checks before onboarding, security terms in contracts, and a yearly review of critical vendors' SOC reports (CC9).
• Risk management. The method, how often it runs, which changes trigger a refresh, how fraud is considered, and who may accept a risk (CC3).
• Data classification and retention. Classification levels, handling rules for each, retention periods and recorded disposal (CC6; C if confidentiality is in scope).
• Acceptable use. What staff may do with company systems, devices and data, the monitoring to expect, and a signed acknowledgement (CC1, CC2).
• HR security. Pre-employment checks where lawful, confidentiality agreements, awareness training at joining and every year, the disciplinary route, and leaver steps that trigger access removal (CC1).

What you do not need: a document per criterion, policies for categories you have left out of scope, or procedures for tools you do not use. Every extra commitment is one more thing to test.

The evidence problem in a Type 2 examination

A Type 1 report looks at design on one date, so one walked-through instance of each control usually suffices. A Type 2 asks whether controls operated throughout a period, typically six to twelve months, and the question changes from "do you have this control?" to "show me every time it ran".

Populations and samples

For each control the CPA firm first asks for the population: every change deployed, every joiner and leaver, every incident, every quarterly review. It checks that the list is complete, usually by seeing how it was produced and comparing it with another source, then samples across the whole period. Rare controls have small populations, so a larger share is inspected; four quarterly reviews leave nowhere for a missed quarter to hide.

What makes evidence credible

System-generated evidence, such as ticket exports, deployment logs and identity-provider reports, carries its own timestamps. Manual evidence, such as a signed review, must show who did what and when. A screenshot needs the date and time, the system and enough context to show what it covers. An access review needs the full user list, a decision on each account and the removal tickets, all dated within the quarter.

Then coverage: a control that started in month four cannot be shown to have run in months one to three. Confirm that every control is operating before the period begins.

Evidence map: what the CPA firm samples, by criterion area

Confidentiality, processing integrity and privacy add their own rows when in scope; the controls shown are examples, not a prescribed list.

Defects that turn working controls into exceptions

• Template policies. Another company's name in a footer, tools you never licensed, job titles you do not have. Worse, an untailored template commits you to controls you do not run.
• Controls on paper only. An annual recovery test that never happened, or "all assets" scanned when only production is. Each becomes an exception; change the policy, or start the control before the period.
• Evidence made the week before fieldwork. Screenshots taken today for a control due months ago, a year of reviews signed in one sitting. File dates and interviews give it away, and a CPA firm that doubts one item widens its testing.
• Populations with holes. A change list drawn from the ticketing system when some releases bypassed it. Set against the deployment log, each unticketed release becomes an exception.

Keeping evidence continuous in Effivity

Evidence survives sampling when it is captured as the control runs, by the person who runs it. In Effivity, policies sit under document control with approvals, version history and change requests, so the review dates the CPA firm asks for already exist. Each recurring control has an owner and a due date on the evidence calendar, reminders and escalations follow a missed date, and the record is attached to that occurrence at the time.

SOC 2 policies and evidence: questions buyers ask