How to Pass SOC 2 Type II in 90 Days: 2026 Cost Breakdown by Company Size

How to pass SOC 2 Type II in 90 days is the first question every SaaS founder asks when their first enterprise deal stalls at procurement — and in 2026, the answer is more structured than it used to be. SOC 2 Type II (System and Organization Controls 2, Type II — a rigorous third-party security attestation governed by the American Institute of Certified Public Accountants (AICPA)) requires a minimum 90-day observation window in which your controls must operate without gaps before a licensed CPA firm can sign off on a report. This guide covers every implementation phase, a granular 2026 cost breakdown across three company sizes, a comparison of the four dominant compliance automation platforms, and the seven audit failures that most often produce qualified opinions and stall enterprise deals.

// 01 What Is SOC 2 Type II and Why Enterprise Sales Demands It

SOC 2 is an attestation framework — not a certification like ISO 27001 — in which a licensed CPA firm evaluates your security controls against the AICPA's Trust Services Criteria (TSC). There are five TSC categories:

• Security (Common Criteria, mandatory for all reports): Logical and physical access controls, risk assessment, system monitoring, change management, and incident response
• Availability (A series, optional): System uptime commitments, disaster recovery capabilities, and recovery time verification
• Confidentiality (C series, optional): How sensitive data — trade secrets, PII under NDA — is identified, stored, and disposed of
• Processing Integrity (PI series, optional): Whether system processing is complete, accurate, and authorized — critical for fintech and payroll applications
• Privacy (P series, optional): Personal information lifecycle management aligned to GDPR and CCPA requirements

Most SaaS companies scope their first report to Security plus Availability, because uptime SLAs appear in nearly every enterprise contract. Adding Confidentiality typically adds minimal incremental cost if your data classification and encryption controls are already solid.

Type I vs. Type II — the critical distinction: A SOC 2 Type I report is a point-in-time snapshot confirming that controls exist on a specific date. A SOC 2 Type II report confirms those controls operated effectively over a continuous observation period — minimum 90 days, commonly 6 or 12 months. Enterprise procurement teams at Fortune 500 companies increasingly reject Type I reports outright in 2026 because they offer no assurance about sustained security operations between the snapshot date and the contract signing date. Getting a Type I when a customer needs a Type II adds months and cost to an already long cycle.

// 02 How to Pass SOC 2 Type II in 90 Days: Phase-by-Phase Playbook

The 90-day number is the observation period minimum, not the total time from zero to a signed report. Before the observation window can open, controls must be in place and operational. A realistic all-in timeline — from scratch to signed Type II report — runs 5–7 months. Companies that arrive at Day 1 of the observation period with engineering security fundamentals already in place (MFA enforced, centralized logging active, access reviews calendared) can compress the pre-observation work to 4–6 weeks.

Phase 1: Scope Decision, Gap Analysis, and Policy Framework (Weeks 1–4)

Weeks 1–2: Scope decisions

Scope is the single largest cost variable. Three decisions define it before you engage an auditor:

• Which Trust Services Criteria will you include? Security is mandatory. Add Availability if customer contracts contain uptime SLAs or downtime penalties. Hold Confidentiality, Processing Integrity, and Privacy unless a customer specifically requires them — each adds audit complexity and cost.
• Which systems are in scope? Name specific AWS accounts, GCP projects, or Azure subscriptions. Auditors charge by environment complexity; a vague "our cloud environment" scope grows unpredictably during fieldwork.
• What data does each in-scope system process? This drives your data classification policy and your sub-processor inventory for vendor risk management.

A narrowly scoped audit — single-region SaaS app, Security plus Availability only, 15 employees — typically runs 40–50% cheaper than a multi-region deployment with all five TSCs.

Weeks 2–4: Gap analysis (readiness assessment)

A gap analysis maps your current controls against AICPA TSC requirements and surfaces what is missing before an auditor finds it. You can run this internally against the AICPA's published criteria or hire a firm to conduct it (typically $5,000–$25,000 depending on scope). The AICPA SOC 2 Trust Services Criteria document is publicly available and maps every control requirement. Investing in an external readiness assessment before the observation period begins recovers its cost many times over by eliminating surprise findings during fieldwork.

Weeks 3–4: Policy framework

Every control in your SOC 2 report must be backed by a written policy. The minimum set for Security plus Availability:

policies/
  information-security-policy.md       # Master policy — references all others
  access-control-policy.md             # RBAC, MFA enforcement, de-provisioning SLAs
  incident-response-plan.md            # Detection, triage, escalation, post-mortem
  change-management-policy.md          # PR approval gates, change approval records
  vendor-risk-management-policy.md     # Vendor tiers, review cadence, sub-processors
  business-continuity-dr-plan.md       # RTO/RPO commitments, DR test cadence
  data-classification-policy.md        # Tier labels and data handling requirements
  vulnerability-management-policy.md   # Scan cadence, remediation SLAs by severity

Policies must be approved by a named officer, version-controlled, and reviewed at least annually. Auditors request the last review date and approver name for every policy in scope.

Phase 2: Control Implementation and Evidence Infrastructure (Weeks 5–8)

This is the engineering-intensive phase. For each gap identified in the readiness assessment, implement the technical control and wire it into your evidence collection system. All 14 controls below must be active and generating evidence before the 90-day observation window opens.

Evidence infrastructure: Manual evidence collection — screenshots emailed to auditors, spreadsheets assembled the week before fieldwork — is the primary reason first-year SOC 2 timelines slip by months. A compliance automation platform (Vanta, Drata, Secureframe, or Sprinto) integrates directly with AWS, GCP, GitHub, Okta, and similar services to pull evidence continuously throughout the observation period. Wire all 14 control integrations in Weeks 5–6 so they accumulate clean data from Day 1. See our guide on automating compliance evidence collection with Drata and Vanta for the platform setup walkthrough.

Phase 3: Observation Period and Auditor Engagement (Days 61–150+)

The 90-day observation period is non-negotiable — no auditor can issue a Type II report covering a period shorter than 90 days. Controls must run from Day 1 of the window to the day your auditor begins fieldwork, with no gaps.

Start selecting an auditor in Week 6–7, concurrent with Phase 2 — not after the observation period ends. Request proposals from at least three firms. Key evaluation criteria:

• AICPA-licensed CPA firm (mandatory — only CPA firms can issue SOC 2 reports)
• SOC 2 specialization — ask what percentage of their engagements are SOC 2
• SaaS/startup experience — boutique firms familiar with AWS and GCP cost 40–60% less than generalist Big 4 firms for identical scope
• Compatibility with your compliance automation platform
• Fieldwork start date commitment in writing in the engagement letter

Pre-audit readiness check (Weeks 11–12): Two weeks before the observation period closes, run a simulated audit. Pull every piece of evidence your auditor will request and verify it is complete, correctly timestamped, and attributable to a named control owner. For the CC6 access controls alone, expect to produce: access review evidence for every quarterly review, provisioning and de-provisioning records for every personnel change, MFA enrollment reports showing 100% production system coverage, and terminated-user access revocation confirmations with timestamps.

Fieldwork and report delivery (Months 5–6): Auditor fieldwork typically takes 3–6 weeks for small companies. The auditor samples your evidence, interviews control owners, and issues a draft report with findings. You have a response window before the final report is signed.

// 03 2026 SOC 2 Type II Cost Breakdown by Company Size

Total first-year SOC 2 spend encompasses four components: auditor fees, readiness assessment, compliance automation platform, and internal staff time. The following ranges are based on market data from 180+ CPA firms and 2026 platform pricing disclosures:

Big 4 auditor premium: Engaging Deloitte, PwC, EY, or KPMG adds a substantial premium — $40,000–$80,000+ for a Type II audit where a boutique startup-specialist firm charges $15,000–$35,000 for identical scope. The Big 4 premium is justified only when a large enterprise customer requires a specific auditor name, or when you are simultaneously pursuing FedRAMP authorization which mandates a Third Party Assessment Organization (3PAO) with specific accreditation.

The hidden cost most founders miss: Internal staff time. A first-year SOC 2 engagement consumes 150–300 hours of engineering, DevOps, and management time that never appears on a vendor invoice. At a $100/hr blended rate, that is $15,000–$30,000 of labor buried in the implementation. Compliance automation platforms reduce this to 50–100 hours by handling evidence collection automatically, but control owner interviews, policy reviews, and auditor Q&A sessions remain manual.

// 04 Compliance Automation Tools: Vanta, Drata, Secureframe, and Sprinto Compared

Compliance automation platforms — also called GRC tools (Governance, Risk, and Compliance platforms) — connect to your cloud infrastructure, identity provider, and source code repositories to collect audit evidence automatically throughout the observation period. In 2026, the four dominant platforms for SOC 2 are:

Pricing caveats: Vanta and Drata typically raise renewal pricing 30–50% above the initial contract price — factor this into your year-2 budget. Drata also charges $10,000–$25,000 for onboarding as a separate line item; confirm whether onboarding is included in any quoted price before signing. All four platforms offer startup programs with 30–60% discounts for companies under $5M ARR or with fewer than 20 employees.

Selection guidance by company size:

• 5–20 employees: Sprinto or Vanta's startup plan — prioritize time-to-value over feature depth
• 20–100 employees: Drata or Vanta — broader integrations and monitoring dashboards justify the higher cost
• 100–500 employees: Secureframe if you plan to add ISO 27001 or HIPAA later; Drata for single-framework depth

For the logging infrastructure underpinning your CC7.2 monitoring controls, see our guide on federal cybersecurity logging requirements and SIEM guidance for 2026 — the same log retention and SIEM standards map directly to SOC 2 evidence requirements.

// 05 The 7 Most Common SOC 2 Type II Audit Failures

Research on SOC 2 audit outcomes shows that 68% of qualified opinions — findings that formally weaken your report and can stall enterprise deals — stem from seven recurring failure patterns. Every one is preventable with advance preparation.

1. Incomplete Access Reviews — CC6.3

Quarterly access reviews are periodic confirmations that each user's system access is still appropriate for their current role. They are the most commonly failed SOC 2 control because companies complete one or two reviews and miss the rest. For a 12-month Type II period, auditors sample all four quarters and require documented evidence for each. Missing even one creates a finding.

Prevention: Calendar four access reviews as recurring events before the observation window opens. Each review must produce timestamped output — a platform export, a signed spreadsheet, or a screenshot confirming who reviewed what and when.

2. Slow or Incomplete Offboarding — CC6.2

Orphaned accounts — active credentials belonging to terminated employees — signal broken access hygiene. Auditors test offboarding by sampling termination dates against de-provisioning timestamps. Any gap exceeding your stated policy SLA (typically 24 hours) is a finding.

Prevention: Automate de-provisioning through your IdP's SCIM provisioning (Okta lifecycle workflows, Azure AD, or Google Workspace Directory Sync). Maintain a termination log with timestamps for every access revocation across every in-scope system. For the insider threat detection controls that support this, see our guide on FBI USB and insider threat DLP detection controls.

3. No Automated Alert History — CC4.1 and CC7.2

The CC4 (Monitoring Activities) controls require positive evidence that your monitoring detected and responded to events during the observation period. If your only monitoring consists of a console that someone checks occasionally, you have no evidence to produce when the auditor asks for it.

Prevention: Configure automated alerting rules before the observation period begins. Every alert that fires during the observation period becomes positive evidence of a functioning monitoring control. Document triage notes in your incident tracking system; they also satisfy the response-to-anomalies requirement in CC7.3.

4. Vulnerability Management Without Tracked Remediation — CC7.1

Running monthly vulnerability scans satisfies half of CC7.1 (Vulnerability Management). Auditors also ask how identified vulnerabilities were remediated and how long each one stayed open. Critical vulnerabilities — those with a CVSS v3.1 score of 9.0 or higher (the "Critical" tier, meaning remotely exploitable without authentication) — with no documented remediation plan are automatic findings.

Prevention: Integrate your vulnerability scanner with your ticketing system so every finding above your severity threshold automatically opens a tracked ticket with an assigned due date. AWS Inspector, Tenable, and Qualys all support native Jira and ServiceNow integrations.

# Export critical and high AWS Inspector findings for ticket creation
aws inspector2 list-findings 
  --filter-criteria '{
    "findingSeverity":[
      {"comparison":"EQUALS","value":"CRITICAL"},
      {"comparison":"EQUALS","value":"HIGH"}
    ]
  }' 
  --query 'findings[*].{
    CVE:packageVulnerabilityDetails.vulnerabilityId,
    CVSS:packageVulnerabilityDetails.cvss[0].baseScore,
    Resource:resources[0].id,
    Status:status
  }' 
  --output table

5. Change Management Without Approval Records — CC8.1

Infrastructure changes that lack a corresponding ticket, pull request, or change approval record are a CC8.1 finding. This is particularly common when infrastructure-as-code (IaC) changes are deployed directly to production without a review workflow.

Prevention: Enforce branch protection rules in GitHub or GitLab requiring pull request approval before merging to the production branch. Link CI/CD pipeline runs to the PR or ticket that triggered the deployment. The audit trail is automatic once the gate exists.

# GitHub branch protection (configure via Settings > Branches > Protection rules)
# required_pull_request_reviews:
#   required_approving_review_count: 1
#   dismiss_stale_reviews: true
#   require_code_owner_reviews: true
# enforce_admins: true
# required_status_checks:
#   strict: true

6. Untested Disaster Recovery Plan — A1.2

A BCDR (Business Continuity and Disaster Recovery) plan that has never been exercised is a common Availability criteria failure. Auditors request DR test results: the date, participants, scenario tested, and whether your RTO (Recovery Time Objective — the maximum acceptable time to restore service after a failure) and RPO (Recovery Point Objective — the maximum acceptable data loss, measured in time) commitments were actually met during the exercise.

Prevention: Run a tabletop DR exercise before the observation period ends. Document the scenario, participants, findings, and outcome. Update the BCDR plan based on test results — auditors look for evidence the plan is maintained and not a static document last touched three years ago.

7. Sub-Processors Without Security Reviews — CC9.2

If your application transmits customer data to third-party services — payment processors, analytics platforms, support tools, infrastructure sub-processors — those vendors must be assessed for security risk. A vendor list without associated security reviews is a CC9.2 finding.

Prevention: Build a vendor inventory with risk tier classifications (critical, high, medium). For critical vendors — those with direct access to customer data — obtain their most recent SOC 2 report or complete a security questionnaire annually. Store results alongside the vendor contract in your evidence repository.

See our SOC 2 Type II compliance checklist for SaaS companies for the full control mapping across all five Trust Services Criteria with exact evidence requirements per control.

// 06 Conclusion

How to pass SOC 2 Type II in 90 days comes down to a single principle: build controls first, then open the observation window. Companies that arrive at Day 1 with MFA enforced, logging centralized, access reviews calendared, and disaster recovery tested move through the observation period without findings. Companies that try to implement controls during the observation period spend 14+ weeks fixing gaps and typically pay for a second audit.

For a 20-person SaaS company, budget $59,000–$128,000 all-in for year one, with year-two renewals in the $30,000–$65,000 range. The enterprise deals that SOC 2 Type II unlocks — contracts typically in the $50,000–$500,000+ ARR range — make this investment straightforward to justify. Every month the certification is delayed costs at least one deal; most Fortune 1000 procurement teams will not move a SaaS contract to legal review without a signed Type II report on file.

Subscribe to our weekly threat and compliance digest for updates to the AICPA Trust Services Criteria, AI governance addendums expected in the 2026 revision cycle, and new guidance on evidence requirements for cloud-native deployments. →