The GRC industry sells SOC 2 as a 200-control mountain requiring six-figure consulting engagements and 18-month implementation timelines. The consulting firms profit from complexity. The reality: a seed-stage B2B SaaS hosted on a major cloud provider passes SOC 2 with roughly 45 well-designed controls across four domains [AICPA TSC 2017]. Every control beyond that minimum adds audit scope, evidence collection burden, and cost without improving the report opinion or the security posture.
Enterprise buyers reading SOC 2 reports do not count controls. They count exceptions. A company with 200 controls operating at 95% effectiveness has 10 exceptions in its report. A company with 45 controls operating at 100% effectiveness receives a clean opinion with zero exceptions [AICPA AT-C Section 205]. The procurement team reviewing both reports chooses the clean one. Healthcare SaaS companies face higher scrutiny because their reports are reviewed by compliance teams with regulatory enforcement experience.
The SOC 2 compliance checklist strips the framework to its structural minimum: the specific evidence items auditors request, organized by the phase in which you build them. Governance, people, technology, and operations. Four domains. Forty-five controls. One clean report.
A SOC 2 compliance checklist for a standard B2B SaaS requires roughly 45 controls across four domains: 10 governance, 10 people, 15 technology, and 10 operations [AICPA TSC 2017]. Only the Security Trust Service Category is mandatory. Adding Privacy, Availability, or Processing Integrity increases audit scope and cost without improving report quality. Focus on MFA enforcement, 24-hour access revocation, and complete evidence trails.
The Complexity Tax: Why Fewer Controls Win
Auditors do not grade on volume. They grade on consistency. A company with 200 controls operating at 95% effectiveness has 10 exceptions in its report. A company with 45 controls operating at 100% effectiveness receives a clean opinion with zero exceptions [AICPA AT-C Section 205].
Enterprise buyers read SOC 2 reports. They do not count controls. They count exceptions. Every exception triggers a follow-up question from the prospect’s security team. Three or more exceptions in a single domain (access controls, change management, incident response) signal systemic weakness and stall deals. Healthcare SaaS companies face higher scrutiny because their reports are reviewed by compliance teams with regulatory enforcement experience. The difference between bloated scope and minimum viable scope shows up directly in audit outcomes.
| Approach | Controls | Typical Result |
|---|---|---|
| Bloated Checklist | 150-200 | 5-15 exceptions, $80K-$150K audit cost, 6+ month prep |
| Minimum Viable Audit | 45-50 | 0-2 exceptions, $30K-$60K audit cost, 8-12 week prep |
The minimum viable approach works because SOC 2 is a principles-based framework, not a prescriptive checklist. For a step-by-step timeline covering readiness activities before the audit begins, see the SOC 2 audit preparation checklist. The AICPA Trust Service Criteria define outcomes (e.g., “logical access is restricted to authorized users”), not specific technologies. Your auditor tests whether your controls achieve the stated outcome consistently, not whether you implemented a specific tool [AICPA TSC CC6.1].
1. Inventory your current control set. If you have more than 60 controls for a seed-to-Series B SaaS company, you have scope creep.
2. Map each control to its AICPA Trust Service Criteria reference. Any control without a direct TSC mapping is a candidate for removal.
3. Calculate your current exception rate (exceptions / total controls). If it exceeds 5%, reduce scope before your next audit period.
Phase 1: Governance (10 Controls)
10 governance controls covering risk assessment, AI policy, and vendor oversight prove leadership owns security as a business function, not a technical afterthought. Auditors test for three things: documented risk awareness, defined roles, and vendor oversight [AICPA TSC CC1.1, CC1.2, CC1.3].
Annual Risk Assessment
Conduct one annual meeting with leadership participation. Identify key risks (data breach, cloud outage, insider threat, third-party compromise). Document likelihood, impact, and mitigation for each risk. Produce signed meeting minutes with attendee names, date, and risk register updates.
The auditor requests three artifacts: the risk register, the meeting minutes, and evidence of leadership attendance (calendar invite with acceptances or sign-in sheet). A 90-minute meeting with a five-page output satisfies the requirement [AICPA TSC CC3.1, CC3.2].
AI Acceptable Use Policy
This is the 2026 control auditors now expect. The question is specific: “Do you control what data employees paste into AI tools?” You do not need an AI Ethics Committee or a model validation framework. You need a one-page policy defining which AI tools are approved for company data, which are banned, and what data classifications prohibit AI processing [AICPA TSC CC1.4].
The three minimum policy statements:
- Approved tools: list specific tools (e.g., GitHub Copilot, internal GPT instance) with data classification restrictions.
- Prohibited actions: pasting customer data, source code, or credentials into unapproved AI tools.
- Enforcement: DLP rules or browser extensions blocking uploads to unauthorized AI endpoints.
Vendor Risk Management
Download SOC 2 Type 2 reports for your critical vendors (AWS, Azure, GCP, Stripe, Twilio). Review them annually. Document the review date, reviewer name, and any findings noted. The auditor requests evidence of vendor oversight, not a 50-page vendor risk assessment [AICPA TSC CC9.2].
1. Schedule the annual risk assessment meeting in Q1. Add it to the executive calendar now with a recurring annual invite.
2. Draft an AI Acceptable Use Policy. One page. Three sections: approved tools, prohibited actions, enforcement mechanism. Distribute to all employees with acknowledgment signature.
3. Create a vendor review tracker (spreadsheet is sufficient). Columns: vendor name, service provided, SOC 2 report date, review date, reviewer, findings. Update annually.
4. Store all governance artifacts in a single folder (SharePoint, Google Drive, or Confluence). The auditor requests evidence by control domain. A disorganized evidence repository extends audit fieldwork by weeks.
Phase 2: People Controls (10 Controls)
People controls cause more SOC 2 audit exceptions than any other domain, with late access revocation for terminated employees accounting for the majority of findings [AICPA TSC CC6.2]. Technical controls are automated and consistent. Human processes are manual and error-prone. The auditor tests two specific areas: onboarding completeness and offboarding timeliness [AICPA TSC CC1.4, CC6.2].
The 24-Hour Offboarding Rule
This is the single most common reason for control exceptions. When an employee leaves, their access to every system (AWS, GitHub, Slack, Google Workspace, VPN, MDM) must be revoked within 24 hours of their termination date.
The auditor’s test is straightforward. They pull a sample of 5 to 25 employees who left during the audit period. They compare the “Termination Date” in your HRIS with the “Last Login Date” in each system’s access log. If any terminated employee logged in after their termination date, you receive an exception.
The trap: you revoke email but forget GitHub. Or you disable the Active Directory account but leave the AWS IAM user active. The test covers every system in scope, not the single sign-on provider.
Background Checks and Onboarding
Conduct background checks for all employees with access to customer data or production systems before their start date. Document the check completion date, provider, and result (pass/fail) in your HRIS. The auditor samples onboarding records and verifies background check completion preceded system access provisioning [AICPA TSC CC1.4].
The Ghost Developer Problem
Auditors cross-reference your GitHub organization members against your current employee roster. Users appearing in GitHub who do not appear on the payroll are “ghost developers”: former contractors, interns, or consultants whose access was never revoked. One ghost developer triggers a full access review of your entire population.
The fix: quarterly access reviews covering every identity with a login, including contractors, consultants, and service accounts. Document the reviewer, review date, and action taken for each identity [AICPA TSC CC6.2, CC6.3].
1. Build an offboarding checklist covering every system in your SOC 2 scope. Assign a single owner responsible for completing all revocations within 24 hours.
2. Automate offboarding where possible. SCIM provisioning through your identity provider (Okta, Azure AD, Google Workspace) revokes access across integrated applications automatically.
3. Run quarterly access reviews. Export user lists from every in-scope system. Compare against current HRIS roster. Document and revoke any orphaned accounts immediately.
4. Include contractors and service accounts in every access review cycle. The auditor does not distinguish between employee and contractor accounts [AICPA TSC CC6.2].
Phase 3: Technology Controls (15 Controls)
Technology controls are the most auditable domain because they produce automated evidence. The auditor requests exports and screenshots, not narratives. The three non-negotiable areas: identity and access management, vulnerability management, and logging [AICPA TSC CC6.1, CC7.1, CC7.2].
MFA Enforcement
Multi-factor authentication on every system touching customer data is non-negotiable. AWS console, GitHub, Google Workspace, Slack, CI/CD pipelines, and production database access all require MFA. The auditor requests a CSV export of all users with their MFA enrollment status. One user without MFA is an exception [AICPA TSC CC6.1].
The evidence strategy: do not give the auditor direct login access to your AWS console. Export a CSV of IAM users with columns for username, MFA status, and last login date. This keeps the auditor focused on the specific control being tested and prevents scope expansion into areas they were not examining.
Endpoint Protection (MDM)
Deploy a Mobile Device Management solution (Microsoft Intune, Jamf, Kandji) across all company-managed devices. The MDM proves three things: full disk encryption is enabled, screen lock is enforced, and OS updates are current. The auditor requests a single MDM compliance report showing 100% enrollment and policy adherence [AICPA TSC CC6.7].
Vulnerability Management
Run regular vulnerability scans against your infrastructure and application layer. The auditor requests two artifacts: the scan results and the remediation log proving you fixed critical findings within your stated SLA. A scan without remediation evidence is worse than no scan at all because it proves you knew about vulnerabilities and did not act [AICPA TSC CC7.1].
Annual penetration testing complements scanning. The auditor requests the penetration test report and evidence that critical findings were remediated before the next test cycle.
Cloud Audit Logging
Enable AWS CloudTrail (or Azure Monitor, GCP Cloud Audit Logs) across all accounts and regions. Retain logs for at least one year with 90 days immediately searchable. The auditor verifies logging is enabled, covers all in-scope services, and cannot be disabled by non-administrative users [AICPA TSC CC7.2, CC7.3].
1. Export your IAM user list with MFA status today. If any user lacks MFA, enforce it before your audit period begins.
2. Verify MDM enrollment covers 100% of company-managed devices. A single unenrolled laptop creates an exception.
3. Establish vulnerability remediation SLAs (critical: 7 days, high: 30 days, medium: 90 days). Document these SLAs in your vulnerability management policy and track adherence.
4. Confirm CloudTrail (or equivalent) is enabled in all regions, including regions you do not actively use. Attackers target unused regions specifically because logging is often disabled there.
How Does Trust Service Category Selection Create the Most Expensive SOC 2 Scope Trap?
Operations controls cover change management, incident response, and business continuity. This phase is also where the most expensive scoping mistake occurs: adding optional Trust Service Categories that your customers did not request.
Change Management
Every code deployment to production requires a documented approval trail. The auditor samples pull requests from the audit period and verifies each one has a reviewer approval, passes automated tests (CI pipeline), and was merged by someone other than the author. Direct commits to the main branch without review are exceptions [AICPA TSC CC8.1].
Incident Response
Document an incident response plan and test it at least annually. The auditor requests the plan document and evidence of the most recent test (tabletop exercise report, after-action review). An untested plan does not satisfy the control [AICPA TSC CC7.4].
The Trust Service Category Trap
The AICPA SOC 2 framework defines five Trust Service Categories. Only Security (Common Criteria) is mandatory. Each additional category adds scope, cost, and preparation time to your audit.
| Category | Required? | Impact on Scope |
|---|---|---|
| Security (CC) | Yes | Baseline. 35-45 controls for most SaaS companies. |
| Availability (A) | No | Adds uptime monitoring, DR testing, capacity planning. +5-10 controls. |
| Confidentiality (C) | No | Adds data classification, encryption validation, disposal procedures. +5-8 controls. |
| Processing Integrity (PI) | No | Adds data accuracy validation, reconciliation, error handling. +5-10 controls. |
| Privacy (P) | No | Triggers GDPR-level requirements: consent, deletion, notice. +15-25 controls. Adds ~$10K+ to audit cost. |
Unless your enterprise customers specifically require Availability or Confidentiality in their vendor security questionnaire, start with Security only. Adding Privacy for a B2B SaaS that does not handle consumer PII directly is the most expensive unnecessary decision in SOC 2 scoping. Ask your top five customers what they need in the report before selecting categories [AICPA TSC Overview].
1. Verify all production deployments require pull request approval from a reviewer other than the author. Audit your GitHub branch protection rules to confirm this is enforced, not suggested.
2. Schedule your next tabletop exercise if you have not conducted one in the past 12 months. Document participants, scenario, findings, and remediation actions.
3. Survey your top five enterprise customers (or prospects). Ask which Trust Service Categories they require in a SOC 2 report. Start with Security only unless customers explicitly request additional categories.
4. Define your system boundary (the “system description”) before engaging an auditor. The boundary determines scope. Every system, process, and person inside the boundary becomes auditable.
The Evidence Stack: What the Auditor Actually Requests
Auditors request structured exports (CSV files, PDF reports) across four evidence domains, and pre-exporting all artifacts before fieldwork begins reduces audit duration by 30-40%. They request exports. The faster you produce clean evidence, the shorter (and cheaper) your audit fieldwork becomes. Organize your evidence repository by control domain before the auditor arrives. The following table maps each domain to its primary evidence artifact and source system.
| Domain | Evidence Artifact | Source System |
|---|---|---|
| Governance | Signed risk assessment minutes, AI policy with acknowledgments | SharePoint/Google Drive |
| People | HRIS termination dates vs. system last-login dates | HRIS + IdP logs |
| Technology | IAM user list with MFA status, vulnerability scan + remediation log | AWS IAM, scanner |
| Operations | PR approval history, incident response test report | GitHub, IR documentation |
The CSV proof method protects your organization during fieldwork. Export the specific data the auditor requested into a structured format (CSV, PDF report). Do not provide direct console access to production systems. Direct access invites scope creep: auditors see configuration details they were not testing and raise additional inquiries that extend fieldwork.
1. Create a shared evidence folder organized by control domain (Governance, People, Technology, Operations) before fieldwork begins.
2. Pre-export all evidence artifacts during the first week of fieldwork preparation. Do not wait for the auditor to request each item individually.
3. Use CSV exports and PDF reports instead of live console access. This prevents scope expansion and reduces fieldwork duration.
SOC 2 is an exercise in evidence, not excellence. You do not earn a better report by implementing 200 controls. You earn a clean opinion by implementing 45 controls that operate consistently across the entire audit period. Scope your Trust Service Categories to what customers actually request. Automate offboarding. Enforce MFA everywhere. Pre-export your evidence. The minimum viable audit is not a shortcut. It is the strategy that produces the strongest report with the fewest exceptions.
Frequently Asked Questions
How many controls does SOC 2 require?
SOC 2 does not prescribe a specific number of controls. The AICPA Trust Service Criteria define outcomes, not implementations. Most B2B SaaS companies pass with 45 to 50 well-designed controls covering Security (mandatory) and one or two optional categories. Adding controls beyond what your business operations support increases exception risk without improving your report opinion [AICPA TSC 2017].
Should I include the Privacy criteria in my first SOC 2 audit?
Most B2B SaaS companies should exclude Privacy criteria from their first SOC 2 audit unless enterprise customers specifically require it in their vendor security questionnaire. Privacy triggers GDPR-level requirements for data deletion, consent management, and privacy notices. It adds approximately $10,000 to audit fees and weeks of preparation. B2B SaaS companies processing business data (not consumer PII) rarely need Privacy in their first report. Ask your top customers what categories they require before deciding.
What is the most common SOC 2 exception?
Late access revocation for terminated employees is the single most common SOC 2 audit exception, occurring when system access persists after the termination date recorded in the HRIS. The auditor compares termination dates in your HRIS against last-login dates across all in-scope systems. If a terminated employee accessed any system after their termination date, you receive an exception. The fix: automate offboarding through SCIM provisioning and verify revocation across all systems, not the identity provider alone [AICPA TSC CC6.2].
How long does SOC 2 preparation take?
A well-organized seed-to-Series B SaaS company pursuing Security-only scope typically completes SOC 2 preparation in eight to twelve weeks pursuing Security-only scope. Companies adding Availability and Confidentiality should plan for 12 to 16 weeks. The timeline depends on three factors: how many controls you already operate informally, how quickly you produce evidence, and whether your auditor is available when you are ready.
What is the difference between SOC 2 Type 1 and Type 2?
Type 1 tests control design at a single point in time: “Do these controls exist on this date?” Type 2 tests operating effectiveness over a period (typically 6 to 12 months): “Did these controls work consistently throughout the period?” Enterprise customers almost always require Type 2 because it proves sustained operation, not a snapshot. Start with Type 1 to validate your control design, then transition to Type 2 for the next audit cycle.
Do I need a GRC platform for SOC 2?
Not for your first audit. A shared drive with organized folders (by control domain), a spreadsheet tracking evidence collection status, and automated exports from your cloud provider and identity platform produce sufficient evidence. GRC platforms (Vanta, Drata, Secureframe) automate evidence collection and reduce manual effort for Type 2 audits, but they add $15,000 to $50,000 annually. Invest in a GRC platform after your first Type 2 audit confirms your control framework is stable.
What does a “qualified opinion” mean in a SOC 2 report?
A qualified opinion means the auditor found material exceptions: controls that did not operate effectively during the audit period. Enterprise buyers interpret a qualified opinion as a systemic security weakness, not an isolated finding. A qualified opinion stalls enterprise deals, triggers additional due diligence requirements, and requires remediation before the next audit. The threshold for qualification varies by auditor, but multiple exceptions in a single control domain (e.g., three access control failures) significantly increases the risk [AICPA AT-C Section 205].
How much does a SOC 2 audit cost?
Audit fees for a seed-to-Series B SaaS company range from $30,000 to $60,000 for Security-only scope with a regional CPA firm. Adding Trust Service Categories increases fees by $5,000 to $15,000 per category. Big 4 and national firms charge $80,000 to $150,000 for the same scope. The total cost includes preparation (internal time or consultant fees), the audit itself, and remediation of any findings. Read the full SOC 2 audit cost breakdown for detailed pricing by company stage.
Get The Authority Brief
Weekly compliance intelligence for security leaders and technology executives. Frameworks decoded. Audit strategies explained. Regulatory updates analyzed.
