SOC 2 Type I vs Type II
SOC 2 Type I evaluates whether your controls are designed correctly and implemented at a single point in time. SOC 2 Type II evaluates whether those same controls operated effectively over a specified observation period, typically six to twelve months.
What it means
Type I is essentially a "design audit." The auditor verifies that you have defined the necessary controls to meet the chosen Trust Services Criteria (TSC) and that these controls are in place on the date of the assessment. It proves your system is built according to your specifications, but not necessarily that it has functioned consistently over time.
Type II is an "effectiveness audit." It requires a look-back period where the auditor tests samples of evidence from across the entire window (e.g., January 1st through June 30th). The goal is to prove that controls are not just documented, but are applied rigorously in daily operations without failure.
Most organizations begin with Type I to identify and remediate gaps before committing to a Type II observation period, as any failure during the Type II window results in an "exception" in the final report.
How to meet it
- Define which Trust Services Criteria apply to your organization (Security is mandatory; Availability, Confidentiality, Processing Integrity, and Privacy are optional).
- Draft formal policies and procedures that map directly to those criteria and have them approved by management.
- Implement technical controls such as Multi-Factor Authentication (MFA), encryption at rest/transit, and centralized logging.
- Establish a cadence for recurring reviews, including quarterly access audits and annual risk assessments.
- Maintain an immutable trail of activity logs for all critical system changes and administrative actions.
- Ensure all employees sign off on policies and complete security training before gaining production environment access.
Evidence an auditor asks for
- Current versions of signed security policies and employee handbooks.
- Configuration screenshots proving active security settings (e.g., firewall rules, IAM permissions).
- A "population list" of all changes or new hires during the Type II window, from which the auditor will select a random sample for testing.
- Dated evidence of recurring tasks, such as meeting minutes from risk committee reviews or signed quarterly access review logs.
Common pitfalls
- Point-in-time thinking: Implementing a control immediately before an audit but failing to maintain it consistently throughout the Type II window.
- Evidence gaps: Failing to keep records for every single instance of a process (e.g., missing one month of access reviews), which leads to a qualified opinion or "exception."
- Policy misalignment: Having technical controls in place that contradict written policies, or having policies that describe processes not actually being performed.