SOC 2 Type II vs Type I — Which Audit Do You Need?

Published April 26, 2026 · 11 min read

SOC 2 reports come in two flavours — Type I and Type II — and choosing the wrong one wastes 6-12 months of audit-prep work. This guide explains the AICPA SSAE 18 difference between the two, when each is the right answer, and exactly what your auditor will sample during fieldwork.

The 30-second answer

SOC 2 Type I attests that your controls were designed correctly on a specific date. SOC 2 Type II attests that those controls operated effectivelyover a period (typically 6-12 months). Most enterprise procurement teams (Salesforce, Microsoft, Google) require a Type II report before signing an MSA. Type I is a stepping stone.

Side-by-side comparison

Trust Services Criteria — what gets audited

Both Type I and Type II audits are scoped against one or more Trust Services Criteria (TSC):

• Security (CC1-CC9) — the only mandatory category. ~64 control objectives.
• Availability — uptime SLAs, BCP/DR testing.
• Confidentiality — data classification + retention.
• Processing Integrity — data integrity in transit and processing pipelines.
• Privacy — GDPR-aligned PII handling, only relevant if you process consumer data.

Most B2B SaaS vendors scope Security + Availability + Confidentiality. Adding more criteria multiplies audit fees by 1.3-1.6x.

CC7.1 — the penetration-testing requirement

Common Criterion 7.1 requires you to detect and respond to threats. Auditors interpret this as: quarterly vulnerability scans + at least one annual third-party penetration test with a written report and remediation evidence. A third-party VAPT with retest after fixes is the cleanest way to satisfy this control.

When Type I makes sense

• You're a 10-30 person startup that just landed an enterprise deal contingent on SOC 2.
• Your prospect agreed to a Type I now + Type II within 12 months in a side letter.
• You need something for the data room before fundraising due diligence.
• Your controls are brand-new — auditing 6 months of evidence isn't possible yet.

When Type II is the only acceptable answer

• You're selling to financial services, healthcare, or regulated industries.
• Your prospect's vendor-risk team uses standardised SIG/CAIQ questionnaires.
• You have an existing Type I and the bridge period is closing.
• You need to comply with downstream audits (e.g. your customer's PCI DSS).

Realistic 9-month timeline to Type II

1. Month 0-1 — Readiness assessment, gap analysis, pick auditor (Big 4 vs boutique).
2. Month 1-3 — Remediate gaps, document policies (16-22 docs typical).
3. Month 3-9 — Observation period — controls must operate continuously, evidence collected automatically (Drata, Vanta, Secureframe).
4. Month 9-10 — Auditor fieldwork, evidence sampling, control testing.
5. Month 10-11 — Draft report, management responses, final report issued.

Common gotchas during fieldwork

• Missing evidence for a control during one week of the observation period = exception in the report.
• Off-boarded employees with active GitHub access > 24h after termination = CC6.2 exception.
• No annual access review = CC6.3 exception, the most common SOC 2 finding.
• Vendor SOC 2 reports not on file for sub-processors = CC9.2 exception.
• Penetration test > 13 months old = CC7.1 exception.

Bridge letters and continuous compliance

Between annual Type II reports, a bridge letter from your CTO/CISO certifies no material changes to controls. This buys 90-120 days of customer-facing coverage. Beyond that, your prospect will demand the new Type II. Continuous compliance platforms (Drata, Vanta, Secureframe, Sprinto) automate evidence collection so the next audit is cheaper than the first.

Choosing an auditor — Big 4 vs boutique

The audit firm signs the report. Choice of firm determines how much customers trust the report at face value. Big 4 (Deloitte, PwC, EY, KPMG) signatures clear procurement faster in regulated verticals — banking, insurance, federal — but cost USD 60-120k for a Type II and run on the firm's calendar, not yours. Boutique CPA firms (A-LIGN, Schellman, Prescient, BARR Advisory) deliver the same SSAE 18 attestation for USD 30-50k and are usually willing to scope tighter and move faster. For Series A/B SaaS with US enterprise customers, a recognised boutique is almost always the right economic answer; you can re-tier to Big 4 once your ARR justifies it.

What never changes is what the auditor needs to see. Whatever firm you pick, line up: organisational charts, vendor SOC 2 reports for every sub-processor, your information security policy set, evidence of access reviews, change-management tickets, incident-response runbooks, and the most recent third-party penetration test report with remediation evidence. Ninety percent of the audit hours are spent reviewing those artefacts.

Common procurement asks beyond the report

• Customer-specific letters — large buyers often ask for a letter from your auditor confirming the SOC 2 covers the system serving their workload. Build the relationship for this in advance.
• SIG / CAIQ questionnaires — Shared Assessments SIG-Lite and Cloud Security Alliance CAIQ. Both map line-by-line to SOC 2 controls; pre-filled answers speed deal cycles by weeks.
• Sub-service organisation carve-out — if you run on AWS or GCP, you can carve their controls out of your report and reference their SOC 2 directly. Document the boundary clearly.
• SOC 2 + HIPAA combined — health-tech buyers will ask. Boutique auditors handle this as a single fieldwork.

Mapping SOC 2 controls to engineering work

None of these are net-new for a competent engineering organisation. SOC 2 readiness is about documenting and evidencing what you already do, not building net-new controls. Teams that treat the audit as an evidence-collection problem from day one ship to Type II inside nine months. Teams that treat it as a security-posture overhaul drift to fifteen.

Reading a SOC 2 report you receive from a vendor

When your own vendor risk team reviews an inbound SOC 2 from one of your sub-processors, scan four sections in order: (1) the auditor's opinion paragraph — anything other than "unqualified" is a flag; (2) the system description — confirm the system audited is the same product you consume; (3) the trust services criteria scoped — Security must be present, Availability matters for any SaaS in your critical path; (4) the exceptions section — every exception explains a control that did not operate as designed during the period. A clean Type II will have zero or only minor exceptions; treat anything else as material until proven otherwise.

FAQ