What SOC 2 Type 1 actually requires for a sub-20-person SaaS

SOC 2 is a small framework wrapped in a large industry. The actual scope of a Type 1 examination for a typical sub-20-person SaaS is knowable, finite, and considerably smaller than the consultant-led version of it that costs $40,000. This article is the unembellished inventory: what's in scope, what the artifacts look like, and what the CPA actually does.

Scope decisions you make before anything else

The five Trust Services Criteria categories

AICPA's Trust Services Criteria (TSC) define five categories:

• Security: always in scope; the foundation. The "Common Criteria" CC1 through CC9 live here.
• Availability: uptime, capacity, business continuity. Add this if your customers care about SLAs in their contracts.
• Processing Integrity: system processing is complete, valid, accurate, timely. Adds work for transactional and analytics systems.
• Confidentiality: protection of confidential data (a different concept from "private" data). Add if you handle customer NDAs or trade secrets.
• Privacy: collection, use, retention, disclosure of personal information. Add only if you process PII at scale; the evidence burden is materially higher.

Default recommendation for a sub-20-person SaaS: Security only. Add Availability if a customer contract requires it. Skip the others until they become a customer demand.

Subservice organizations and the carve-out method

If you run on AWS, GCP, Azure, or a managed Kubernetes service, those providers are subservice organizations. SOC 2 lets you "carve out" their controls. You don't have to audit their datacenters, but you have to disclose the carve-out and reference their SOC 2 report in your own. The carve-out language goes in your System Description (more on that below).

The artifacts a Type 1 examination produces

A SOC 2 Type 1 report is a single PDF, typically 30-60 pages. Its sections, in order:

1. Independent Service Auditor's Report: the CPA's opinion. Two paragraphs: scope, opinion.
2. Management's Assertion: your statement that the description is fair and the controls were suitably designed as of the as-of date.
3. Description of the System: narrative covering infrastructure, software, people, processes, data, and third-party relationships. ~10-20 pages of prose.
4. Trust Services Criteria, Related Controls, and Tests of Controls: a matrix mapping each TSC criterion to your implemented controls and the auditor's test results.

The 12 minimum policies most CPAs expect to see

There's no AICPA-mandated list, but the controls under CC1-CC9 collectively require documented policies on:

1. Information Security Policy: overarching governance
2. Access Control Policy: provisioning, authentication, MFA, reviews
3. Asset Management Policy: what we have and who owns it
4. Risk Management Policy: how risks are identified, rated, treated
5. Vendor / Third-Party Management Policy: vendor due diligence
6. Incident Response Policy: detection, response, communication
7. Business Continuity / Disaster Recovery Policy
8. Secure Development Policy / SDLC: code review, testing, deploy gates
9. Operations Security Policy: monitoring, logging, vulnerability management
10. Cryptography Policy: encryption standards, key management
11. Data Management Policy: classification, handling, retention
12. HR Security Policy: onboarding, background checks, offboarding

Plus, often, a Code of Conduct and an Executive Summary. cybersoftware generates all 14 of these tailored to your stack on the software plan. The free assessment includes one free AI sample policy.

The evidence the CPA actually asks for

For a Type 1 examination, the CPA tests design, not operating effectiveness. They want to see that controls are implemented as of the as-of date. Typical evidence:

• Screenshots of access control configurations (Okta SSO enabled, MFA enforced, branch protection settings)
• Exports of access lists (IAM users, GitHub seats, Okta-federated apps)
• Sample of a vulnerability scan from your tool of choice
• One sample change ticket showing the SDLC flow end-to-end
• Each of the 12 policies, with a signature/approval timestamp
• Your most recent vendor risk register
• One sample onboarding and one sample offboarding showing the checklist was followed

For Type 2, the same evidence categories repeat, but the CPA samples them across the observation window to test operating effectiveness. So for Type 2 you need multiple instances of each, not just one.

What a CPA does NOT do

This matters because most founders' mental model of "audit" comes from financial audits, which involve substantive testing of transactions. A SOC 2 examination does not:

• Pen-test your application
• Review your source code
• Validate the technical correctness of your security controls (they validate that the control exists and is operating, not that it's the optimal control)
• Issue a "security score" or graded result. The only outcomes are an unqualified opinion (clean), qualified opinion (issues scoped to specific controls), adverse opinion (control framework fails the TSC), or disclaimer (insufficient evidence)

The minimum-viable timeline

1. Day 0: Run intake. Identify gaps.
2. Days 1-5: Generate policies. Remediate the biggest gaps (typically the offboarding runbook, the cryptography policy, and the missing IR tabletop).
3. Days 6-10: Collect evidence per control point. Resolve any blockers.
4. Days 11-21: CPA examination. Q&A with the auditor on edge cases. Receive draft opinion.
5. Days 22-28: Final report issued. Send to the prospect.

Three to four weeks end-to-end. Faster than that and you're cutting corners; slower than that and you're paying for consulting overhead you don't need.

Further reading

• AICPA Trust Service Criteria, explained
• Five SOC 2 control failures we see in almost every startup pre-audit
• AICPA Trust Services hub