Type I vs. Type II: The Critical Difference
SOC 2 Type I is a point-in-time audit: the auditor assesses whether your controls are suitably designed as of a specific date. It is relatively straightforward to prepare for — you document your controls, evidence that they exist on the audit date, and you are done.
SOC 2 Type II is fundamentally different. It tests whether controls were operating effectively over an observation period — typically 3, 6, or 12 months. The auditor samples evidence from across the entire period. A gap in any month is a finding. A control that existed in January but was not followed in July is a finding. This is why the preparation mindset for Type II must be "continuous operation", not "point-in-time readiness".
The Trust Services Criteria (TSC)
SOC 2 audits are conducted under the AICPA Trust Services Criteria (TSC, 2017 edition). The criteria are organised into five categories:
- Security (Common Criteria, CC1–CC9) — mandatory for all SOC 2 reports
- Availability — relevant for firms with uptime SLA commitments
- Confidentiality — relevant for firms processing confidential B2B data
- Processing Integrity — relevant for firms where data processing accuracy is critical (payments, financial calculations)
- Privacy — relevant for firms subject to GDPR, CCPA, or other privacy frameworks and wanting to demonstrate privacy controls
Most B2B SaaS companies start with Security only. Adding criteria increases audit scope and cost — confirm the in-scope criteria with your auditor and customers before starting the observation period.
AICPA Sampling: What Auditors Actually Look For
Understanding how auditors sample is essential to planning your evidence collection strategy.
For a 12-month observation period, typical AICPA sampling approaches are:
- Daily/high-frequency controls (e.g. log monitoring, alert triage): 25 samples across the year
- Weekly controls (e.g. access review for privileged accounts): 15–20 samples
- Monthly controls (e.g. vulnerability scans, user access review): all 12 instances (or a subset of 5–8)
- Quarterly controls (e.g. risk assessment review, pen test): all 4 instances
- Annual controls (e.g. pen test, BCP tabletop, security training): 1 instance, fully evidenced
For a 3-month period, sampling is compressed: auditors may test all instances of monthly and quarterly controls, and 8–12 instances of high-frequency controls.
The key implication: every month of the observation period must have evidence. Auditors will notice if February is missing from your access review record. They will ask. An explanation of "we forgot" is a finding. An explanation of "we use Vanta automation" with a configuration screenshot is not.
Evidence Collection: The Type II Playbook
Evidence collection plan (Day 1 of the observation period)
Before the observation period starts, document your evidence collection plan:
- Control reference (mapping to TSC criterion: CC6.1, CC8.1, etc.)
- Evidence type (screenshot / log export / config file / HR ticket / approval record)
- Collection owner (who is responsible)
- Collection cadence (daily / weekly / monthly / quarterly)
- Storage location (dedicated GDrive folder / Vanta / Drata / Confluence)
- Retention requirement (SOC 2 evidence typically retained 3–5 years)
Population lists: the most overlooked Type II requirement
Auditors do not just test controls — they test controls against complete populations. Before testing whether your access review process works, they need the complete list of employees, systems, and privileged accounts. Before testing your JML (joiners/movers/leavers) process, they need the complete list of all staff who joined or left during the period.
Incomplete or stale population lists are the second most common cause of Type II findings after evidence gaps. Maintain these lists throughout the period:
- Employee population (all active employees + all departures with dates)
- System population (all production systems, cloud accounts, SaaS tools in scope)
- Privileged account inventory (admin accounts, service accounts, API keys)
- Vendor/sub-processor list
- Code release / deployment log
Automated evidence collection
Compliance automation platforms (Vanta, Drata, Secureframe, Tugboat Logic, Thoropass) automate evidence collection for many common controls by connecting to your cloud infrastructure, IdP, MDM, and HRIS. This dramatically reduces audit prep burden and evidence gaps.
Even without a platform, automation is possible: AWS CloudTrail / GCP Audit Logs / Azure Monitor provide timestamped logs that serve as evidence for many CC7 (system operations) controls. CI/CD pipeline run history (GitHub Actions, GitLab CI) is evidence for CC8 (change management). MDM enrollment reports (Jamf, Kandji, Intune) evidence endpoint management.
The key principle: evidence must be timestamped and unambiguous about the date range it covers. A screenshot without a visible date is not evidence. A log export that does not show the date range is not evidence.
Access Controls (CC6): The Most-Tested Domain
CC6 (Logical and Physical Access Controls) consistently generates the most findings in Type II audits. The key requirements:
Quarterly access reviews
Access reviews must happen on a defined cadence (quarterly is standard) and must be evidenced. Evidence requirements: who conducted the review, date, which systems, what access was reviewed, approval of continued access or revocation of unnecessary access, and confirmation of access removals within SLA.
Important: the review must actually happen. An email saying "can you check the user list" without a documented approval decision is not an access review. Auditors will push for the full review record.
JML (joiners, movers, leavers) process
Auditors will pull your HR termination list and test that corresponding access revocation happened within your policy SLA (typically 24–48 hours for production access). They will test a sample of each — joiners (access provisioned appropriately), movers (access adjusted for role change), and leavers (access fully removed).
Any instance where a terminated employee retained production access beyond your policy SLA is a finding, regardless of whether the access was actually misused. The control is the process, not the outcome.
MFA enforcement
MFA must be enforced at the IdP level (Okta, Azure AD, Google Workspace), not just required by policy. Evidence: IdP configuration screenshot showing MFA policy applied; no bypass exceptions in place. Any user or account with an active MFA bypass is a finding.
Privileged access
Production admin access must be restricted, documented, and monitored. Just-in-time (JIT) access or break-glass procedures are best practice. Evidence: session logs showing admin access is time-limited and approved; no standing admin accounts with broad production permissions.
Change Management (CC8): Every Deployment Needs a Ticket
CC8 requires that changes to production systems go through a documented, approved process. For the entire observation period, every production deployment must have a corresponding ticket, PR, or change record with approval evidence.
Emergency or hotfix changes are permissible but must follow an expedited process with retrospective approval. An undocumented hotfix pushed directly to production — even a trivial one — is a finding.
Branch protection rules (requiring pull request review before merge) are both a control and evidence. A GitHub screenshot showing branch protection is configured, combined with PR history showing approvals, is clean CC8 evidence.
Continuous Monitoring (CC7): Configured Is Not Enough
A common mistake: firms configure a SIEM, set up alerts, and consider CC7 evidence "handled". Auditors want to see that alerts were actively triaged and responded to — not just that the tool was running.
Evidence needs to show that security monitoring was operational throughout the period and that alerts were reviewed. This might be SIEM dashboards with date-stamped alert queues, incident tickets showing triage activity, or a documented alert review log.
Vulnerability management
Authenticated vulnerability scans must run at least monthly across the full observation period. High and critical findings must be remediated within your documented SLA (commonly 30 days for critical, 90 days for high). Auditors will check: scan schedule coverage (every month of the period), finding severity, and evidence of remediation for high/critical findings within SLA.
Penetration testing
Annual penetration testing is a standard requirement for SOC 2. The pen test must be conducted by a qualified third party (OSCP/CREST certified tester or reputable firm). Critical findings must be remediated. The pen test report and remediation evidence are submitted to the auditor.
Timing matters: conduct the pen test early enough in your observation period that critical findings can be remediated before the auditor fieldwork begins.
Sub-Service Organisation Reports: The Hidden Requirement
Your cloud infrastructure provider (AWS, GCP, Azure) is a sub-service organisation under your SOC 2. You must obtain their current SOC 2 report and review the Complementary User Entity Controls (CUECs) — controls that the sub-service organisation expects you to implement.
Map each CUEC to a control in your own control set. This mapping must be documented and presented to your auditor. Failure to address CUECs is a Type II finding even if all your own controls are operating effectively.
This applies to all critical sub-processors: Stripe, Twilio, Salesforce, Snowflake, and any other vendor that processes in-scope data. Obtain and review their SOC 2 reports. If they don't have a SOC 2, document your alternative assurance approach (e.g. ISO 27001 certificate, security questionnaire).
Management Letter Points from Type I: Mandatory Closure
If you received a Type I report with management letter points (observations or recommendations that fell short of a formal qualified opinion), those points must be addressed before your Type II observation period ends — ideally before it begins. Auditors will review Type I management letter points and test whether they have been remediated. Unaddressed Type I points in a Type II audit are a finding.
Common Type II Qualification Triggers
- Evidence gap months: Any month of the observation period without evidence for a continuous control
- Access review non-performance: Quarterly access review not conducted or not documented for one or more quarters
- JML exception: Terminated employee access not revoked within policy SLA
- Unevidenced production changes: Deployments without corresponding approval records
- Vulnerability SLA breach: Critical finding not remediated within documented SLA
- MFA bypass: Active user with MFA exception during the period
- Unaddressed Type I points: Prior management letter observations not resolved
- Incomplete population lists: Auditor cannot verify testing covers the full population
Audit Preparation Timeline (12-Month Observation Period)
- T-6 months: Select auditor, execute engagement letter, confirm TSC scope, start observation period, configure evidence collection system
- T-3 months: First quarterly access review evidenced, vulnerability management programme running, policy acknowledgements current
- T-2 months: Internal readiness review, population list audit, evidence gap check across all months
- T-1 month: Pen test completed and critical findings remediated, BCP tabletop conducted, management assertion drafted
- T-0: Auditor fieldwork begins — evidence submitted, population lists provided, systems access granted to auditor
- T+2 months: Draft SOC 2 report reviewed; management responses to findings prepared
- T+3 months: Final Type II report issued
Use the ComplyKit SOC 2 Type II Readiness Assessment to run a 42-item assessment across all six Type II readiness domains — evidence collection, access controls, change management, continuous monitoring, risk management, and policies — and generate a tailored audit preparation report in minutes.