SOC 2 Type II
Also known as: AICPA SOC 2 Report, Trust Services Criteria (TSC) Audit
An audit report based on the AICPA Trust Services Criteria that evaluates whether a service organization's controls were effective over a specific period, typically six to twelve months. Unlike a point-in-time assessment, it verifies that security and privacy policies were consistently followed in practice. The final document provides an auditor's opinion on the operational effectiveness of these controls.
Why it matters
If controls fail during the review period, an auditor issues a "qualified" opinion or notes specific exceptions, signaling to clients that data is at risk. This failure often results in lost sales because enterprise procurement teams require a clean report as a prerequisite for signing contracts. A breach occurring due to a failed control can lead to legal liabilities and regulatory fines. The Chief Information Security Officer (CISO) or Compliance Manager is typically held accountable for these gaps.
In practice
An external CPA firm conducts the audit by first defining the "lookback period" and sampling evidence from that window. The auditor requests populations—such as a list of all new hires or all firewall changes—and then selects random samples to inspect for proof of execution, like signed onboarding checklists or approved change tickets in Jira. This process produces the SOC 2 Type II Report, which includes the auditor's opinion and a detailed description of the controls tested. In a first-year engagement, the focus is on establishing the control environment; repeat engagements focus on maintaining consistency and addressing previous exceptions.
Worked example
CloudSafe Inc., a SaaS provider, underwent an audit for the period of January 1 to June 30. The auditor focused on the "Logical Access" control, requiring evidence that employee access was revoked within 24 hours of termination. The auditor requested a list of all terminated employees and sampled five specific departures from March and May. They discovered that one engineer's GitHub access remained active for three days after their departure date. Consequently, the final report contained an "exception," noting a failure in the timely revocation of access.
Common mistakes
- Confusing Type I with Type II; practitioners often assume a design audit (Type I) is sufficient when customers actually require proof of operational effectiveness (Type II).
- Failing to collect evidence continuously throughout the year, leaving the team unable to provide logs or approvals for months that have already passed.
- Over-scoping by including all five Trust Services Criteria instead of just "Security," which increases the audit workload and creates more opportunities for failure.
- Treating the report as a certification; it is an attestation report based on specific criteria, not a permanent seal of approval.
Frequently asked questions
What are the Trust Services Criteria?
These are the standards set by the AICPA focusing on Security, Availability, Processing Integrity, Confidentiality, and Privacy. Most organizations start with the "Security" category, as it is the baseline requirement for all other criteria.
How does a Type II differ from a Type I report?
A Type I report describes the controls at a single point in time (a snapshot), whereas a Type II report tests those controls over a duration (e.g., six months). Type II provides higher assurance because it proves the controls actually work consistently.
How long should the review period be?
Most organizations choose a 6-month or 12-month window. A shorter window is common for first-time audits to reach compliance faster, while a 12-month window is preferred by mature enterprises for annual reporting.
What evidence does an auditor typically request?
Auditors ask for "populations" (complete lists) and then "samples" (specific examples). Examples include screenshots of MFA settings, signed NDAs, quarterly access review logs, and ticketed approvals for production changes.
When is the best time to start preparing for the audit?
Preparation should begin 3-6 months before the intended lookback period starts. This ensures that controls are fully implemented and evidence is being captured correctly before the "clock" begins on the testing window.
More terms
High-risk AI system · Readiness assessment · Essential and important entities · Records of processing activities · Remediation · Data Protection Impact Assessment · Products with digital elements · Risk assessment