SOC 2 for SaaS companies
The compliance standard enterprise customers require before buying your software. Here is what it means for SaaS products, what evidence you need, and how to collect it.
For SaaS companies, SOC 2 is primarily a sales enablement tool. Enterprise procurement teams use it to vet vendors before approving data access. Without a SOC 2 report, your product gets stuck in security review queues indefinitely.
SOC 2 was designed with cloud software in mind. The Trust Services Criteria map directly onto how SaaS products operate: who has access to what data, how changes are deployed, how incidents are handled, and how vendors you rely on are assessed. A well-run SaaS engineering team often has most of the controls already implemented, they just need to be documented and consistently evidenced.
SOC 2 controls that apply specifically to SaaS
Cloud infrastructure configuration
AWS, GCP, or Azure settings need to be documented and continuously monitored. Misconfigured S3 buckets, open security groups, and public RDS instances are common findings that halt audits.
CI/CD pipeline security
Code review requirements, branch protections, deployment approvals, and SAST scanning need to be in place and evidenced before every release.
API access and authentication
API key management, OAuth scopes, and service account permissions are all in scope. MFA for developer and admin access is a hard requirement.
Data classification and encryption
Customer data must be classified and encrypted at rest and in transit. TLS versions, key rotation schedules, and data retention periods need to be documented.
SaaS vendor security
Every third-party service with access to customer data (Stripe, SendGrid, Datadog) needs to be inventoried and assessed as part of your vendor risk program.
Uptime and availability evidence
If you offer SLAs, status page data, PagerDuty incident history, and infrastructure health metrics all become audit evidence under the Availability category.
How SaaS companies collect SOC 2 evidence
GitHub
Branch protection rules, pull request review logs, and deployment history as evidence for change management controls.
Okta or your IdP
MFA enforcement rates, access provisioning logs, and deprovisioning records for CC6.1, CC6.2, and CC6.3.
AWS, GCP, or Azure
CloudTrail logs, security group configurations, IAM policies, and encryption settings for infrastructure controls.
Vulnerability scanners
Snyk, Dependabot, or similar tools provide evidence that vulnerabilities are tracked and remediated within defined SLAs.
Frequently asked
Do SaaS companies need SOC 2?
Yes, when selling to enterprise customers. It is the standard security certification for cloud software and is required by most procurement teams at companies with 500 or more employees.
Which SOC 2 categories apply to SaaS?
Security (Common Criteria) is mandatory. Availability is relevant if you offer uptime SLAs. Confidentiality and Privacy apply if you handle sensitive customer or personal data.
What evidence does a SaaS company need for SOC 2?
Infrastructure configs, access logs from your IdP, code review records from GitHub, vulnerability scan results, incident logs, and employee policy acknowledgments. Collecting and keeping it current is ongoing work, whether that is in-house, with a tool, or with a fractional CISO who runs the process for you.
How does SOC 2 affect product development?
Adds process requirements: mandatory code review, documented change approvals, and security testing. These integrate naturally into modern CI/CD workflows and are good engineering practices regardless.
See also: SOC 2 overview and SOC 2 for startups