SOC 2 Compliance Checklist for SaaS Startups (2025)
SOC 2 has become the de facto enterprise security standard for B2B SaaS. Enterprise security reviews increasingly require a Type II report before contracts are signed. This guide explains what SOC 2 actually requires, what auditors test, how long the process takes, and what to have in place before starting.
What SOC 2 Is — and What It Is Not
SOC 2 is an attestation, not a certification. A certified public accountant (CPA) who is licensed by the AICPA reviews your controls and issues an opinion — a "report" — rather than issuing a certificate or badge. This distinction matters: there is no "SOC 2 certified" status. There are companies that have received an unqualified opinion (no significant exceptions) in a SOC 2 audit.
SOC 2 is not a legal requirement. Unlike HIPAA (US healthcare) or GDPR (EU data), no law requires SOC 2. The pressure comes from enterprise customers, not regulators. But that makes it practically mandatory for B2B SaaS companies selling to security-conscious buyers — financial services, healthcare tech, legal tech, HR tech, and government contractors.
SOC 2 is not ISO 27001. ISO 27001 is a certification of an information security management system (ISMS) issued by an accredited certification body. SOC 2 is an attestation by a CPA firm. Many companies pursue both — SOC 2 for US enterprise sales, ISO 27001 for EU and international enterprise sales.
The Five Trust Service Criteria
SOC 2 is organized around five categories of control. Only Security is required for every report.
| Criterion | Required? | What It Covers | Who Needs It |
|---|---|---|---|
| Security | Always required | Access controls, encryption, vulnerability management, incident response, change management | All SaaS companies |
| Availability | Optional | System uptime, performance monitoring, disaster recovery, business continuity | SaaS with SLA commitments |
| Processing Integrity | Optional | Complete, accurate, timely processing — inputs match outputs | Payment processors, financial systems |
| Confidentiality | Optional | Protection of designated confidential information throughout its lifecycle | SaaS handling trade secrets, legal data |
| Privacy | Optional | Collection, use, retention, disclosure of personal information per privacy notice | SaaS processing personal data under regulations |
Most B2B SaaS companies start with Security + Availability. Adding Confidentiality is recommended for companies handling sensitive business data (legal documents, financial data, HR data).
SOC 2 Type I vs Type II: What You Actually Need
Type I: A point-in-time assessment. The auditor reviews your control design and confirms that controls are suitably designed to meet the relevant Trust Service Criteria as of a specific date. Type I does not test whether controls operated effectively.
Type II: An assessment over a period — typically 6 to 12 months. The auditor tests whether controls actually operated effectively throughout the observation period. This is the standard required for enterprise procurement.
Practical path for most SaaS companies: implement controls → get a Type I report (useful for early enterprise deals while the observation period runs) → complete Type II after 6–12 months of operating controls.
Core Controls: The SOC 2 Security Checklist
The Security criterion is organized under the COSO framework into categories called Common Criteria (CC). The following areas are where most SaaS companies have gaps:
- Access control: Role-based access to production systems; periodic access reviews (quarterly is the standard); immediate deprovisioning when employees leave; MFA enforced on all systems with customer data access
- Change management: All code changes reviewed before merging; separate environments (dev/staging/prod); change approval workflow documented; no direct commits to production by individuals
- Vulnerability management: Regular vulnerability scans of infrastructure; penetration test (annual minimum); documented remediation process with SLA tiers by severity; patch management policy
- Incident response: Documented incident response plan; incident logging and classification; post-incident reviews; customer notification procedures and SLAs
- Encryption: Data at rest encrypted (AES-256 or equivalent); data in transit encrypted (TLS 1.2+ minimum); key management policy; encryption of backups
- Vendor management: Third-party vendor security assessments before contracting; vendor inventory with risk classification; BAA/DPA agreements in place for relevant vendors
- Background checks: Employment background verification for employees with production access (required for SOC 2, not optional)
- Security training: Annual security awareness training with completion tracking; phishing simulations for employees with privileged access
- Monitoring and logging: Centralized log collection; alerts on anomalous access patterns; log retention policy (minimum 1 year is typical)
Evidence Collection: What Auditors Actually Ask For
SOC 2 auditors do not take your word for it — they review evidence. Common evidence requests include:
- Access control lists showing who has access to each production system, with provisioning/deprovisioning dates
- Pull request logs for the observation period showing code review approvals
- Vulnerability scan results and remediation tracking tickets
- Incident log for the observation period
- Employee onboarding records showing background check completion and security training completion
- Third-party vendor list with signed DPAs/security questionnaire responses
- Penetration test report with remediation evidence
- System configuration screenshots showing encryption settings, MFA enforcement, and logging configuration
- Backup and recovery test results
Compliance automation platforms (Vanta, Drata, Thoropass, Secureframe) connect to your cloud provider, code repository, HR system, and identity provider to collect this evidence automatically, which significantly reduces the manual effort during the audit.
SOC 2 Audit Timeline
Know your compliance posture before the auditor arrives
LexAudit generates a Compliance Health Score across SOC 2, ISO 27001, GDPR, HIPAA, PCI DSS, and CCPA — 60 signals evaluated monthly. Identify control gaps before your auditor does. $99/month, cancel anytime.
Get Your Compliance Health Score — $99/moContract Risk — $97
Review Your Vendor Agreements Before Your SOC 2 Audit
SOC 2 auditors test whether your vendor contracts require breach notification, data handling standards, and subprocessor controls under CC9.2. BizLegal AI scans your vendor MSAs and DPAs for the exact contractual gaps auditors flag — before the audit clock starts.
Scan Your Vendor Agreements →Frequently Asked Questions
What is SOC 2 and why do enterprise customers require it?
SOC 2 (Service Organization Control 2) is a voluntary audit standard developed by the American Institute of CPAs (AICPA) that evaluates how a SaaS company manages customer data. Enterprise buyers, particularly in financial services, healthcare, and regulated industries, require SOC 2 Type II reports before signing contracts because it provides independent evidence that your security and availability controls actually operate as described — not just that you have policies on paper. Without SOC 2, many enterprise deals stall or fail at the vendor security review stage.
What is the difference between SOC 2 Type I and Type II?
SOC 2 Type I evaluates whether your controls are designed appropriately at a single point in time. Type II evaluates whether those controls operated effectively over an observation period — typically 6 to 12 months. Enterprise customers almost universally require Type II because it demonstrates operational effectiveness, not just design intent. The path is typically: implement controls → get a Type I report (which can take 2–4 months) → run your controls for 6–12 months → complete a Type II audit.
Which of the five Trust Service Criteria are required for SOC 2?
Only Security (the "common criteria") is required for all SOC 2 reports. The other four criteria — Availability, Processing Integrity, Confidentiality, and Privacy — are optional and included based on what your customers need and what services you provide. Most SaaS companies include Security + Availability (because SLAs matter to customers) and often Confidentiality. Privacy is increasingly included for SaaS products that process personal data in regulated contexts. Processing Integrity is more relevant for transactional systems like payment processors.
How long does a SOC 2 audit take and what does it cost?
For most early-stage SaaS companies: 3–6 months to implement controls from scratch, 2–3 months observation for a compressed Type II (some auditors accept 3-month observation periods), plus 4–8 weeks for the auditor to issue the report. Total from zero to Type II report: 9–18 months. Cost varies significantly: readiness assessments $5–15K, Type I audit $15–30K, Type II audit $30–80K for a mid-size auditor. Automation platforms (Vanta, Drata, Thoropass, Secureframe) reduce cost by automating evidence collection and typically run $10–25K per year.
What evidence do SOC 2 auditors actually collect?
Auditors test your stated controls by reviewing evidence — policy documents, screenshots, system logs, vendor agreements, access reviews, and configuration exports. Common evidence types: access control reviews showing who has access to production systems and when access was provisioned/deprovisioned; change management logs showing code was reviewed and approved before deployment; vulnerability scan results and remediation tickets; incident response records; vendor security assessments; penetration test reports; encryption configuration screenshots; and background check records for employees with production access.
Can you share a SOC 2 report under NDA — or is it public?
SOC 2 reports are confidential and intended for distribution to specific parties — typically prospective enterprise customers under NDA, existing customers at annual review, and occasionally investors during due diligence. They are not public documents. Sharing a report with a prospective customer is standard practice and is not a security risk — the report describes control design and operating effectiveness, not your actual security vulnerabilities. A well-written SOC 2 report is a sales asset.
Related: Compliance Health Score for SaaS → what the score measures and how to improve it before your auditor arrives
Related compliance resources