Type I vs. Type II: The difference that matters commercially
SOC 2 comes in two flavors — Type I and Type II — and the difference between them has become commercially significant. Type I is a point-in-time assessment: it tests whether your controls are designed appropriately as of a specific date. Type II tests whether those controls actually operated effectively over a period of time, typically 6-12 months.
Enterprise procurement teams, particularly at US companies, have largely moved to requiring Type II. A Type I report shows you designed your controls correctly. A Type II report shows they actually worked. For buyers who have been burned by vendors with impressive-looking policies but operational gaps, this distinction matters significantly. In competitive enterprise sales situations, a Type II report is increasingly the minimum — not the differentiator.
The Trust Service Criteria: what auditors actually examine
SOC 2 is organized around five Trust Service Criteria (TSC): Security, Availability, Confidentiality, Processing Integrity, and Privacy. Security — formally the Common Criteria, or CC — is mandatory. The others are optional, but increasingly requested by enterprise buyers in regulated industries.
The Common Criteria is where most of the implementation work happens. CC6 (logical and physical access controls), CC7 (system operations), and CC8 (change management) are the criteria with the most technical requirements — and the ones where most companies have gaps when they begin the process.
What CC6 actually requires
CC6 is about logical and physical access — who can get to what, how, and with what controls. In practice, this means MFA enforced on all user-facing systems, SSO covering all applications where technically feasible, access reviews conducted at least quarterly, and privileged access managed with additional controls including approval workflows and audit logging.
For a 50-100 person SaaS company, this is achievable but requires discipline — particularly the quarterly access review cycle. Access reviews are the control that most companies let slip. They're also one of the first things an auditor samples during a Type II observation period. A single quarter where the access review wasn't documented can create a finding that affects your entire report.
The observation period problem
The most commonly misunderstood aspect of SOC 2 Type II is the observation period. Your controls need to have been operating effectively for a minimum of 6 months — some auditors accept 3, but 6 is the standard that most enterprise buyers and their legal teams recognize as credible. This means you cannot decide in January to get SOC 2 Type II and have a report in February.
Common mistake: Assuming that implementing controls now means you can have a Type II report soon. The observation period clock doesn't start until your controls are live and documented. A report covering 3 months of operation is technically valid but practically weak — many buyers will ask for a 6 or 12-month period report.
The practical implication: start the clock as early as possible. Every day your controls are live and operating is a day of observation period you've accumulated. Companies that implement controls in 90 days via a focused sprint and immediately begin the observation period are looking at a credible Type II report in 9-12 months from first conversation. Companies that delay implementation push that timeline out accordingly — and into deals they've already lost.
The evidence burden
SOC 2 Type II audits aren't document reviews. Auditors sample system logs, test access configurations, review change management records, and verify that your stated controls actually match what your systems are doing. This creates a continuous evidence burden that most companies significantly underestimate when they set out to achieve certification independently.
During the observation period, you need to be collecting and retaining evidence across each criterion: access review records, change management tickets, incident response logs, backup test results, vendor assessment outputs, and system configuration exports at multiple points in time. This is operationally significant — it's why pairing SOC 2 preparation with an ongoing managed security function makes sense. The alternative is creating an evidence burden that falls on your engineering or ops team, who will deprioritize it under normal product delivery pressure.
What most companies get wrong
The most common mistake is treating SOC 2 as a documentation project. Companies spend weeks writing policies, then discover during the audit that their documented controls don't match their actual technical implementation. The auditor finds that MFA is documented as required but not enforced in three SaaS tools that were added after the policy was written. Or that the incident response policy exists and was never tested. Or that the change management process requires approvals that the engineering team bypasses under deadline pressure.
The second most common mistake is not starting the observation period early enough. Companies who wait until they have a deal that requires SOC 2 Type II are typically looking at a 12-18 month wait for a credible report — time they don't have, and pressure that produces a rushed program with gaps that create findings. A finding on a first Type II report is a commercial problem. It requires explanation to every buyer who reviews the report.
The right approach
Get the controls implemented first — technically, verifiably. Then document what you've implemented, not what you intend to implement. Start the observation period the day controls are live. Engage an accredited CPA firm for the audit 3-4 months into the observation period, so their scheduling aligns with your readiness and you're not waiting on their calendar when you're ready to close.
Do this with support from a managed security function that collects evidence automatically, conducts quarterly access reviews, and supports your auditor with accurate system data. SOC 2 Type II is a legitimate, valuable certification — when it's built on real controls, not paper. The companies that get the most commercial value from it are the ones that use the certification to accurately reflect what their security program actually does, not to overstate it.
"SOC 2 Type II doesn't test whether your policies are written. It tests whether your systems behave the way your policies say they do."