A SOC 2 report demonstrates that your controls meet the AICPA Trust Services Criteria, and it is increasingly the price of entry for selling to US enterprises. This guide is a practical readiness checklist: what auditors ask for, what evidence they accept, and what causes an observation period to be restarted.
Trust Services Criteria
SOC 2 is built on five categories:
- Security
- Availability
- Processing Integrity
- Confidentiality
- Privacy
- Security — protection against unauthorised access. The common criteria, present in every SOC 2 report.
- Availability — the system is available as committed.
- Processing integrity — processing is complete, valid, accurate, timely and authorised.
- Confidentiality — confidential information is protected as committed.
- Privacy — personal information is collected, used, retained, disclosed and disposed of in line with your privacy notice.
Most organisations start with Security alone and add categories when customers demand them. Each added category expands scope and cost, so add them for a reason rather than for completeness.
Crucially, SOC 2 does not prescribe controls. It defines criteria and you design controls to meet them — which means the report describes your control environment, and two SOC 2 reports are not directly comparable.
Type I versus Type II
Type I opines on whether controls are suitably designed at a point in time. Type II opines on whether they operated effectively across an observation period, typically three to twelve months.
This distinction determines your whole evidence strategy. Type II requires evidence that controls operated throughout the period — every access review in the window, every change approval, every incident handled per policy. Evidence assembled retrospectively is the most common reason an observation period has to be extended or restarted.
Most organisations do a Type I first to get something in front of customers, then a Type II covering the following period. A first Type II with a three-month window is a reasonable target; customers increasingly expect twelve.
The Readiness Checklist
Policies and Documentation
- Information security policy and supporting policies documented, versioned, and formally approved.
- Personnel acknowledgement records — see policy management for version control and attestation tracking.
- A documented risk assessment identifying risks and how they are addressed, refreshed at least annually.
- System description: the narrative of your services, infrastructure, people and processes that goes into the report. Auditors test it for accuracy.
Access Control
- Periodic access reviews with evidence of who reviewed, what, and when — the reviewer's name and date is the part usually missing.
- Role-based access with documented approval for grants.
- Timely revocation on termination and role change. Auditors sample leavers and check the interval between termination date and access removal.
- MFA where your controls claim it.
- Privileged access separately controlled and reviewed.
Change and Operations
- Change management with approval, testing and deployment records. Auditors sample changes and trace them back to approvals.
- Incident response covering detection, response, escalation and post-incident review, with a log of incidents and outcomes — including the finding that there were none, if so.
- Backup and recovery with RTO/RPO defined and tested, with test evidence retained.
- Monitoring and alerting, with evidence that alerts are actioned rather than merely generated.
- Vulnerability management with defined remediation SLAs by severity, and evidence they are met.
People
- Background checks where your controls claim them.
- Security awareness training on a defined cadence, with completion records.
- Onboarding and offboarding checklists, completed and retained.
Vendors and Third Parties
- Inventory of vendors handling sensitive data or supporting in-scope services.
- Due diligence at onboarding and periodic re-assessment — see TPRM.
- Sub-service organisation treatment decided: carve-out (excluded from your report, with complementary controls described) or inclusive (in scope). Most reports carve out cloud providers and rely on their SOC 2s.
- Complementary user entity controls documented — what your customers must do for your controls to be effective.
Continuous Evidence
Auditors expect consistent evidence across the observation period, not a spreadsheet assembled the week before fieldwork. Automated collection from your identity provider, cloud platforms, ticketing and HR demonstrates controls operating in the ordinary course. A platform like ActiveERM schedules control testing and retains evidence with timestamps and owners, which is what turns a Type II from an archaeology project into a reporting exercise.
What Auditors Actually Do
Understanding the mechanics removes most of the surprise:
- Walkthroughs — the control owner describes the control and demonstrates it once. Owners who cannot describe their own control are an immediate flag.
- Sampling — a sample sized to control frequency. A quarterly control might yield a sample of two; a daily control, twenty-five or more.
- Evidence inspection — for each sampled item, the artefact showing the control operated on that occasion.
- Exception evaluation — exceptions are not automatically fatal. What matters is whether they indicate the control failed to operate, and how you responded.
An exception you found yourself, documented, and remediated reads very differently from one the auditor found.
Common Reasons Readiness Slips
- Access reviews performed but not evidenced. The review happened in a meeting; nothing records who reviewed what.
- Termination lag. Access removed days or weeks after the leaving date, sampled and found.
- Policies approved once, never reviewed. Version control shows a two-year-old approval against a policy claiming annual review.
- Untested backups. RTO and RPO documented, no restore test evidence.
- System description drift. The narrative describes an architecture you have since changed.
- Population completeness. Auditors test that the population you sampled from is complete. An incomplete change log invalidates the sample drawn from it.
After the Audit
Use the report as the start of a cycle rather than the end of a project. Link SOC 2 controls to your risk register and audit findings so one change updates one place, and map them against ISO 27001 and other frameworks so a single test satisfies several reports.
The next observation period begins the day this one ends. Organisations that keep evidence flowing continuously find the second Type II costs a fraction of the first.
For audit management and evidence in one platform, see Audit Management and GRC Cloud, or request a demo.