SOC 2 Type 1 vs Type 2: What the Difference Actually Means for Your Audit
TL;DR
- A SOC 2 Type 1 report covers control design on a single date. A SOC 2 Type 2 report covers whether those controls actually ran during a defined period, typically 3, 6, or 12 months.
- The AICPA governs both report types under its Trust Services Criteria framework; a licensed CPA firm issues the opinion in both cases.
- Most B2B SaaS companies complete a Type 1 first to have something to share with prospects quickly, then build toward Type 2 during the observation window.
- Enterprise procurement teams handling larger SaaS contracts typically require Type 2; Type 1 is accepted as a bridge at earlier-stage deal sizes if you commit to a Type 2 completion date. The specific deal-size thresholds in this article are editorial estimates based on published compliance program surveys (see Sources); exact buyer requirements vary by industry, risk tier, and internal policy.
- Audit fee ranges differ meaningfully: Type 1 fieldwork runs narrower and shorter than Type 2, though total program cost in year one depends heavily on how much readiness work you need before either engagement starts.
Who this is for
This article is for founders, engineering leads, and compliance managers who are deciding whether to pursue a SOC 2 Type 1 or Type 2, and when. It assumes you already know what SOC 2 is at a basic level. If you need the foundation first, start with our SOC 2 compliance guide.
The governing framework: AICPA and the Trust Services Criteria

Both report types are SOC 2 examinations, meaning both are governed by the AICPA's System and Organization Controls framework and conducted under SSAE 18 (Statements on Standards for Attestation Engagements), specifically AT-C sections 105 (Concepts Common to All Attestation Engagements) and 205 (Examination Engagements). A licensed CPA firm issues an opinion; neither report type produces a "certificate." There is no such thing as "SOC 2 certified": ISO 27001 grants certification; SOC 2 produces an auditor's report.
The audit evaluates your controls against the AICPA Trust Services Criteria (TSC), last substantively revised in 2022. The five TSC categories are: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is the only mandatory category. All others are scoped in based on your system description and the commitments you make to customers.
The structural difference between Type 1 and Type 2 sits in AT-C 205: a Type 1 report covers the suitability of the design of controls as of a specified date; a Type 2 report covers both the suitability of the design and the operating effectiveness of controls over a specified period.
When evaluating the security controls that SOC 2 auditors test, many organizations also reference the NIST Special Publication 800-53 Rev. 5 catalog as a benchmark framework. While NIST SP 800-53 is a federal standard, its control families (AC, AU, CA, CM, IA, IR, SI, and others) map closely to the AICPA Trust Services Criteria categories, and auditors frequently use it as a reference when assessing control design completeness.
SOC 2 Type 1: control design, one date
A Type 1 engagement produces a report that says: on this specific date, your controls were designed appropriately to meet the applicable Trust Services Criteria.
The auditor reviews your policies, your technical configurations, your access reviews, your monitoring setup. They confirm that each control is present and designed to work. They do not test whether the control ran yesterday, last quarter, or last year.
What the auditor does: reviews design evidence (policies, system architecture, configurations) as of the report date.
What the auditor does not do: pull samples across a period, test logs, verify that alerts fired consistently, or check that access reviews happened on schedule.
Preparation time: typically 6 to 12 weeks for a SaaS company starting from a partial security program. Companies starting from near-zero can take longer.
Fieldwork duration: 2 to 6 weeks, depending on scope and auditor.
Time from kickoff to report: most companies reach a signed Type 1 report within 3 to 5 months of starting readiness work.
What a Type 1 proves to a customer: your controls exist, are documented, and are configured the way they should be, as of the report date.
What a Type 1 does not prove: that those controls operated reliably before or after that date.
One practical consequence: if a control was broken for six months and you fixed it the week before the audit, a Type 1 would likely pass. A Type 2 covering that same six months would not.
SOC 2 Type 2: control design plus operating effectiveness
A Type 2 engagement produces a report covering both control design and operating effectiveness over a defined observation window.
The auditor samples evidence from across the entire window: access review logs, security alert records, change management tickets, vendor review meeting notes, background check completions. For each control, they are answering: did this control run every time it was supposed to, across the whole period?
Observation window options: the minimum that produces a credible result is 3 months, but most enterprise buyers consider a 3-month Type 2 too short to be meaningful. Six months is the standard minimum for a first Type 2 engagement. Twelve months is the standard for annual renewals and is what most enterprise procurement teams treat as the floor for new vendors.
Fieldwork duration: 4 to 8 weeks after the observation window closes.
Time from kickoff to report: 9 to 18 months, depending on how long the observation window runs and how much readiness work was needed before the window started.
What a Type 2 proves to a customer: your controls existed, were properly designed, and actually operated consistently across the period covered by the report.
What a Type 2 does not prove: anything about periods before the window, or anything about future periods (which is why annual renewal exists).
The "exceptions" section of a Type 2 report is what sophisticated buyers actually read. A small number of exceptions with documented remediation is normal and does not kill a deal. Multiple high-severity exceptions, or any exception that was not remediated, can produce a qualified opinion, which materially weakens the report's credibility.
Side-by-side comparison

| Dimension | SOC 2 Type 1 | SOC 2 Type 2 |
|---|---|---|
| What it evaluates | Control design, one date | Control design + operating effectiveness over a period |
| Audit window | None (point-in-time) | 3, 6, or 12 months (6+ preferred by buyers) |
| Time to first report | 3 to 5 months from kickoff | 9 to 18 months from kickoff |
| Fieldwork duration | 2 to 6 weeks | 4 to 8 weeks (after window closes) |
| Governing standard | AT-C 205 (design opinion) | AT-C 205 (design + operating effectiveness opinion) |
| Enterprise acceptance | Bridge document; accepted at earlier-stage deal sizes (editorial estimate, see Sources) | Standard requirement at larger enterprise deal sizes (editorial estimate, see Sources) |
| Renewal cadence | Once; then move to Type 2 | Annual |
| Best use case | Speed, early pipeline, staged path | Active enterprise pipeline, regulated industry buyers |
For audit fee ranges by firm tier and scope, see our SOC 2 audit cost guide.
The staged path most companies take
The most common sequence:
Months 0 to 3: readiness. Adopt a compliance program, write policies, configure technical controls, train staff, close gaps the pre-audit assessment surfaces.
Month 3 or 4: Type 1 fieldwork. Report issued within 30 days of fieldwork completion. You now have something to share with prospects under NDA.
Months 4 to 10: observation window runs. Controls operate; you collect evidence; your compliance team documents exceptions and remediation as they arise.
Months 10 to 12: Type 2 fieldwork. Auditor samples across the 6-month window. Report issued 30 to 60 days after fieldwork.
Year 2 onward: annual Type 2 renewals, each covering a fresh 12-month window.
This sequence lets you put a Type 1 in front of customers within four to five months of starting the program, while the longer Type 2 path runs in parallel. The Type 1 is not wasted: it satisfies deals closing during the window and functions as an internal quality gate before the Type 2 observation period starts.
What this means for compliance managers: the observation window is not idle time. Use it actively. Every access review, every change management ticket, every vendor review meeting is evidence the auditor will sample. Teams that treat the window as a documentation sprint at month 9 consistently produce more exceptions than teams that operate as if fieldwork is already underway from day one. Build your evidence collection cadence before the window opens, not after it closes.
When a Type 1 is the right choice
Type 1 makes sense when:
- You are pre-revenue or early-stage and need a security signal for buyers who are not yet enterprise procurement teams.
- Your initial customers are SMB or mid-market and explicitly accept Type 1.
- You have a 90-day sales cycle with a named customer who will sign on Type 1 with a committed Type 2 date.
- A fundraise or hiring milestone requires "we have a SOC 2 report" rather than requiring a specific type.
- Your security program has material gaps you want to fix before a Type 2 observation window starts. A Type 1 finding here is far less damaging than a Type 2 exception.
The cost-benefit risk of Type 1: you spend the audit fee on a report that enterprise buyers will treat as a bridge document. That fee does not apply toward a future Type 2. If your pipeline is already enterprise-heavy, that spend may not return full value.
When to go directly to Type 2

Skip Type 1 when:
- Every active deal in your pipeline requires Type 2 before signature.
- Your security program is already mature and a Type 1 would not surface any design issues worth fixing before the observation window.
- Your timeline can absorb 9 to 12 months without a reportable security posture.
- You sell into healthcare, financial services, or government, where buyers often expect operating effectiveness from the first report.
The economic case is straightforward: a Type 1 audit costs audit fees that are not refunded against a future Type 2. Skipping Type 1 saves those fees, but leaves you without any SOC 2 report to share for the first 6 to 12 months.
For startups deciding which direction fits their stage, see our guide on whether startups need SOC 2.
What buyers actually require by deal size
Procurement teams interpret these reports differently depending on deal size and vendor risk category. The deal-size thresholds below are editorial estimates synthesized from published compliance program surveys, including Vanta's State of Trust Report (2023) and Drata's State of Compliance (2023), and from public enterprise vendor-assessment documentation. They are patterns, not guarantees: actual buyer requirements vary by industry, risk tier, and internal policy.
Smaller deal sizes (roughly sub-$25K contract value): Type 1, a security questionnaire, or a self-attested security overview is usually sufficient. Many buyers at this size do not formally review audit reports.
Mid-market deal sizes (roughly $25K-$250K contract value, editorial estimate): Type 2 is preferred; Type 1 is accepted as a bridge if it is recent (within 12 months) and you can provide a committed Type 2 completion date. These thresholds are approximate, the actual trigger depends on the buyer's vendor risk tier, not your ARR.
Larger enterprise deal sizes (above roughly $250K contract value, editorial estimate): Type 2 is the baseline expectation. Some buyers will sign with a contractual obligation to provide Type 2 within a defined timeframe, but they will follow up.
Fortune 500 and regulated-industry buyers: Type 2 with a 12-month window is the standard floor observed in enterprise vendor assessments. Many require the full report (not a summary), plus a Trust Center or security portal. Some add penetration test results and vendor due diligence questionnaire responses on top.
Since the AICPA's 2022 revision of the Trust Services Criteria, Type 2 has become the standard expectation for enterprise SaaS vendors at meaningful deal sizes. Type 1 has been repositioned as the path's first step, not the destination for most companies.
Common mistakes that cost real money
Starting a Type 2 observation window before controls are stable. A Type 2 audit that covers a period when your controls were immature produces exceptions in the report. Those exceptions get read in deal calls. Better to let a Type 1 cover the stabilization period, then start the Type 2 window with confidence.
Letting a Type 1 go stale. Type 1 reports have no formal expiry in AICPA guidance, but procurement teams treat anything older than 12 months as dated. If you are not actively working toward Type 2, the Type 1 stops carrying weight faster than you expect.
Creating gaps between Type 2 renewals. Once you are on an annual Type 2 cadence, consecutive audit windows should be contiguous or close to it. A gap longer than 60 days between report periods is visible to sophisticated buyers and raises questions about what happened during the gap. This is a practitioner-consensus threshold, not an AICPA-mandated rule: no attestation standard requires continuity, but security-conscious procurement teams reviewing report dates regularly flag unexplained gaps. In practice, the question a buyer's vendor-risk team asks is simple: "What were your controls doing during this period that wasn't covered?" If you cannot answer cleanly, the gap becomes a deal issue.
What this means for compliance managers: if your audit firm's schedule, staffing changes, or budget cycles created a window gap, prepare a written explanation before the procurement question arrives. Buyers who flag gaps are not looking to disqualify you, they are checking whether you have a story. An unexplained gap is far more damaging than a gap with a documented reason.
Commissioning a 3-month Type 2. Auditors can issue a Type 2 over a 3-month window. Most enterprise buyers treat a 3-month Type 2 as not credible; the sample size is too small for them to rely on it. Six months is the practical minimum.
Conflating design exceptions with operating exceptions. A Type 1 exception means the control was not designed correctly. A Type 2 exception can mean the control was designed correctly but did not run consistently. These are different findings with different remediation paths, and buyers read them differently.
Mini-FAQ
Can I share a Type 1 report while my Type 2 is in progress? Yes. Type 1 is the standard bridge document. Share it under NDA alongside a note stating the Type 2 observation window dates and expected report delivery. Most enterprise procurement teams accept this if the Type 1 is current.
How often do I renew a Type 2? Annually. Each report covers a new period. A lapse of more than 60 days between report periods is visible in the report dates and is flagged by buyers who check.
Is a Type 1 worthless if I plan to do Type 2? No. It satisfies deals that close during the observation window. It also functions as an internal milestone: design issues caught at Type 1 are fixed before they cost you on the Type 2.
Can I skip Type 1 entirely? Yes. Going directly to Type 2 is common for companies whose pipeline can wait out the observation window. The trade-off is no reportable security posture for the first 6 to 12 months.
What observation window length should I choose for a first Type 2? Six months is the standard for a first Type 2 audit. It is the shortest window that enterprise buyers treat as credible. Twelve months becomes the standard for annual renewals.
What happens when a control fails during a Type 2 window? The auditor records it as an exception. A small number of exceptions with documented remediation is normal and does not kill a deal. High severity exceptions or exceptions you did not remediate can produce a qualified opinion, which materially weakens the report.
Are these reports public? No. Both Type 1 and Type 2 are confidential and shared only under NDA. Buyers expect the full report, not a summary. For what auditors test inside the report, see our SOC 2 compliance checklist.
Per-persona recommendation
Early-stage SaaS (pre-Series A, roughly sub-$2M ARR): pursue Type 1 first. Your customers are unlikely to require Type 2, and speed to having any report matters more than report depth at this stage. Budget for the staged path from day one so Type 2 is not a surprise project 12 months later. (The $2M ARR marker is an editorial approximation of stage, not a regulatory threshold.)
Growth-stage SaaS (roughly $2M to $20M ARR, active enterprise pipeline): start the Type 1 + Type 2 staged path immediately. Aim to have Type 2 in hand within 12 months of starting the program. Enterprise security reviews at this deal scale, a contract in the low-to-mid six figures, for instance, routinely stall on SOC 2 Type 2 as a procurement gate. (The ARR range is an editorial approximation of growth stage, not a sourced threshold.)
Mid-market SaaS with regulated-industry customers (healthcare, fintech, government): go directly to Type 2 if your pipeline can absorb the timeline. Regulated buyers expect operating effectiveness and may not accept Type 1 regardless of how recent it is. In healthcare and fintech contexts, auditors often use NIST SP 800-53 control families alongside the AICPA TSC as a completeness reference.
Company already holding a Type 1, enterprise deals stalling: start your Type 2 observation window now. The Type 1 should bridge deals closing in the next 6 months while the Type 2 runs. Identify which controls produced the most questions during your Type 1 fieldwork and prioritize evidence collection for those in the Type 2 window.
For audit firm selection, see our guide on how to choose a SOC 2 auditor. For the official framework, see the AICPA SOC suite of services.
Sources
- AICPA, "System and Organization Controls (SOC) Suite of Services," AICPA & CIMA, accessed 2026-05-12. https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services
- AICPA, "SOC 2 Examinations, Topic Overview," AICPA & CIMA, accessed 2026-05-12. https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2
- AICPA, "2017 Trust Services Criteria (With Revised Points of Focus - 2022)," AICPA & CIMA publication, accessed 2026-05-12. https://www.aicpa-cima.com/resources/download/aicpa-ssaes-currently-effective
- AICPA, "Statements on Standards for Attestation Engagements (SSAEs), Currently Effective," AICPA & CIMA, accessed 2026-06-24. https://www.aicpa-cima.com/resources/download/aicpa-ssaes-currently-effective (SSAE No. 18, the controlling attestation standard under which both Type 1 and Type 2 SOC 2 examinations are performed)
- NIST, "Security and Privacy Controls for Information Systems and Organizations," Special Publication 800-53 Rev. 5, National Institute of Standards and Technology, September 2020. https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final
- Vanta, "State of Trust Report 2023," Vanta Inc., 2023. https://www.vanta.com/resources/state-of-trust-report (Industry survey of enterprise buyer compliance requirements; cited as a source for deal-size-related SOC 2 expectations observed among enterprise SaaS vendors.)
- Drata, "State of Compliance 2023," Drata Inc., 2023. https://drata.com/resources/state-of-compliance-report (Compliance program survey cited as supporting context for enterprise procurement patterns described in the buyer-tier section of this article.)
Last reviewed: 2026-06-25 by the Security Compliance Guide Editorial Team. This article was prepared by the Security Compliance Guide Editorial Team. We use AI to draft initial summaries of publicly available cybersecurity compliance documentation, then verify every claim against primary sources before publication. We are not licensed auditors, attorneys, or compliance consultants. For binding decisions, consult a qualified professional. See our editorial standards for full sourcing rules.
