SOC 2 compliance: what it requires and what auditors sample

What SOC 2 is — and what it is not

SOC 2 is an attestation engagement defined by the AICPA. A licensed CPA firm examines a service organization's controls against the Trust Services Criteria and issues a report containing the auditor's opinion. The criteria cover five categories; security — the common criteria — is required in every SOC 2 examination, and the other four are included only when they are relevant to the commitments you make to customers. The common criteria are aligned to the COSO 2013 internal-control framework, extended with criteria for logical and physical access, system operations, change management, and risk mitigation.

SOC 2 is not a certification. There is no certificate and no pass/fail stamp: the deliverable is a report, and sophisticated buyers read the auditor's opinion, the scope, and the listed exceptions rather than the cover page. Software can prepare and organize your side of the engagement; the opinion itself is the auditor's independent work.

• Security (common criteria): required in every SOC 2 report.
• Availability: the system is available for operation as committed.
• Processing integrity: processing is complete, valid, accurate, timely, and authorized.
• Confidentiality: information designated confidential is protected as committed.
• Privacy: personal information is handled per the entity's privacy commitments.

Type I vs Type II

A Type I report examines whether controls are suitably designed and implemented at a point in time. A Type II report examines design plus operating effectiveness over a period, which means the auditor tests whether each control actually operated throughout the window — not just that it existed on the day of the audit.

The practical difference is evidence volume and evidence dating. For Type II, samples are drawn from across the period: an access review from month one, terminations from month four, changes from month six. Evidence that cannot be tied to a date inside the window does not support the control. Most buyer security reviews ask for Type II, so teams typically treat Type I as a milestone on the way there — the audit period itself is agreed with your auditor.

What evidence auditors actually sample

SOC 2 evidence requests are more mechanical than teams expect. The auditor asks for a complete population — all hires, all terminations, all changes to production in the period — then selects a sample and asks you to prove each item followed the control. Two things fail here: evidence that exists but cannot be dated to the period, and populations you cannot show are complete.

• Access: provisioning and deprovisioning tied to start and end dates, privileged-access grants, and periodic access reviews with recorded dispositions.
• Change management: production changes with approval, testing evidence, and separation between the person making the change and the person approving it.
• Operations: monitoring alerts and their follow-up, incident records with resolution, backup configuration and restoration evidence.
• Vulnerability management: scan results and the disposition of findings within your stated remediation windows.
• People and vendors: security-awareness training completion, policy acknowledgments, and periodic reviews of critical vendors.

Why manual SOC 2 programs fail at scale

A screenshot-and-spreadsheet program can pass a first audit. It degrades from there: every evidence artifact is stale the moment it is captured, so each audit period restarts the collection cycle by hand; screenshots lack the metadata that ties them to a system, a date, and a collector; and when the person who assembled last year's folder leaves, the institutional knowledge of where everything came from leaves with them.

The quiet killer is population completeness. An auditor who samples ten terminations first needs the list of all terminations, and a manually maintained list invites the question of what it missed. A program that scales inverts the model: evidence flows continuously from the systems of record over read-only connections, each artifact carries its origin and period, and the audit becomes a review of standing evidence rather than an annual reconstruction.

What continuous SOC 2 evidence looks like

Teams that stop dreading audits share a pattern: they treat evidence as something that accumulates continuously, not something they rebuild each period. Instead of screenshots captured by hand, artifacts flow from the systems of record — identity providers, source control, cloud platforms, ticketing — carrying the metadata that ties each one to a source, a date, and a control. The audit then becomes a review of standing evidence rather than an annual scramble.

A handful of capabilities separate a program that scales from one that does not, regardless of which tool provides them:

• One control model, mapped across frameworks: a control defined once and cross-mapped to SOC 2, ISO 27001, and SOX ITGC, so overlapping access, change, and operations evidence is collected once and reused.
• Read-only collection from systems of record, so evidence is complete and current rather than curated by hand.
• Named human sign-off: a passing automated check should record who accepted the evidence, not silently close a control on its own.
• Chain of custody: an append-only trail showing where each artifact came from and when — ideally hash-anchored and re-verified on a schedule.
• Continuous monitoring between audits, so control drift surfaces when it happens instead of at the next examination.
• An export your audit firm will actually work from — organized the way auditors review evidence, with a manifest they can verify independently.

The honesty principle — and how to evaluate any tool

Many compliance dashboards will render a readiness percentage even when the underlying data is missing. Treat that as a warning sign. A control without accepted evidence is a gap, and anything a tool cannot actually measure should read as not measured — never estimated. An optimistic dashboard fails at the worst possible moment: mid-audit, when the auditor asks for the population behind the green number. And no tool produces the report itself — SOC 2 is an attestation, and the opinion belongs to your CPA firm.

Whatever platform you are considering, put it through a trial against the failure modes above:

• Can it show where each artifact came from, when it was collected, and who accepted it?
• Can it produce the full population behind a sample, not just the artifacts you curated?
• Does a passing automated check close the control by itself, or does a human have to accept it?
• Does evidence carry period coverage, so Type II sampling holds up across the window?
• Does it export evidence in a form your audit firm will actually work from?
• Does it tell you what it cannot measure — or does every dashboard read green?

Frequently asked questions