Skip to Content
SOC 2For SaaS companies

SOC 2 for SaaS companies

You build software-as-a-service. Customers trust you with their data. American enterprises ask for SOC 2. This page covers SaaS-specific situations: multi-tenancy, API security, data isolation between customers, and scaling without losing security. The AICPA Trust Services Criteria  are designed for service organisations such as SaaS companies. If you have not started yet, begin with the step-by-step plan.

75% of SOC 2 audits are for SaaS companies. The framework was written with companies like yours in mind. The most important question auditors ask: “How do you isolate customer A’s data from customer B?” The rest follows from that.

Why SaaS companies need SOC 2

Enterprise sales blocker: You are talking to a Fortune 500 company. Procurement sends you a security questionnaire. Question 1: “Do you have SOC 2 Type II?” If the answer is no, 80% of enterprises will not go further. SOC 2 is the entry ticket.

VC due diligence: From Series B onwards, investors ask for SOC 2. It shows that you are mature on security, can grow at scale, and are ready for enterprise. It can increase your valuation.

Competitor comparison: You compete with established SaaS players. They have SOC 2. You don’t. Guess who wins the deal? Security is a competitive moat.

Scaling efficiency: Without SOC 2, every new enterprise customer sends a 200-question security questionnaire. Your sales engineer spends 40 hours filling it in. With SOC 2: “Here’s our report, see section X.” The deal moves faster.

The most important SaaS-specific SOC 2 controls

1. Multi-tenancy and data isolation

This is the heart of SaaS security. How do you make sure customer A’s data is not visible to customer B?

Architecture patterns:

  • Database-level isolation: Each customer has its own database (AWS RDS instances). The most secure option, but more expensive and harder to scale.
  • Schema-level isolation: A shared database, with each customer in its own schema (PostgreSQL schemas). A balance between security and efficiency.
  • Row-level isolation: Shared tables, where each row has a tenant_id. Efficient, but leaves more room for mistakes, because developers must always apply tenant filtering.

The auditor asks:

  • “Show me your data model. How do you prevent tenant A from seeing tenant B’s data?”
  • “Show me a SQL query that retrieves customer data. Is there tenant filtering?”
  • “What happens if a developer forgets the WHERE tenant_id = clause?”
  • “Are there database-level constraints? (RLS policies, views, triggers)”

Evidence:

  • Architecture diagram of the tenancy model
  • Code review process: peer reviews check for tenant filtering
  • Automated tests: every data access query has a test that prevents a cross-tenant leak
  • Penetration test: a tester tries cross-tenant access (it must fail)

Best practice: Use Row-Level Security (RLS) in PostgreSQL, or an equivalent in your database. This is a second layer of defence. Even if a developer forgets the WHERE clause, RLS blocks cross-tenant access at database level.

2. API security and rate limiting

Your SaaS has APIs. Customers use them, but so do malicious actors who try to abuse them.

Controls:

  • Authentication: API keys or OAuth tokens required for all endpoints
  • Authorisation: The token scope determines what you may do (read-only vs full access)
  • Rate limiting: X requests per minute per tenant, to prevent abuse and DDoS
  • Input validation: All input is sanitised (to prevent SQL injection and XSS)
  • API versioning: Old versions are deprecated with a notice period
  • API logging: Every call is logged: who, what, when, and the response code

The auditor asks:

  • “Can I call your API without authentication?” (it must be no)
  • “What happens if I send 10,000 requests in one second?” (the rate limiter must kick in)
  • “Show me API call logs. Can I see any anomalies?”
  • “How do you handle API key rotation?”

Evidence:

  • API documentation with authentication requirements
  • Screenshots of rate limiting configuration
  • Sample API logs
  • Rate limiting triggered events (showing that it works)

SaaS-specific risk: APIs are public-facing, so your attack surface is large. Extra security layers are needed:

  • Web Application Firewall (WAF) for common attacks
  • Bot detection (Cloudflare Bot Management, PerimeterX)
  • Anomaly detection (a sudden spike in API calls from one user)

3. Data export and portability for customers

GDPR and good customer experience both mean customers must be able to export their data.

Controls:

  • Self-service export: a UI button “Download my data”
  • Export formats: JSON, CSV, Excel (machine-readable)
  • Filtered by tenant: the export contains only their data
  • Audit trail: log who exported what and when
  • Throttling: large exports run as an async job (an email link when ready)

The auditor asks:

  • “Show me the export feature.”
  • “Run a test export. Does it contain only that tenant’s data?”
  • “What if tenant B requests tenant A’s data?” (it must be rejected)

Evidence:

  • Demo of the export feature
  • Test export plus verification that only the tenant’s data is included
  • Audit logs of exports

Business continuity angle: Export is also part of Availability. If your platform goes down, can customers get their data from your latest backup? The auditor can link this to DR (Disaster Recovery).

4. Secrets management (for SaaS with integrations)

Your SaaS integrates with Salesforce, Slack, Stripe, and so on. You store customers’ OAuth tokens. How do you protect them?

Controls:

  • Encryption at rest: Tokens are encrypted in the database (at application or database level)
  • Encryption in transit: Tokens always travel over HTTPS
  • Access controls: Only authorised services can decrypt tokens
  • Rotation: Automatic token refresh (OAuth refresh tokens)
  • Audit: Every access to encrypted tokens is logged
  • Secrets manager: Use a vault (HashiCorp Vault, AWS Secrets Manager)

The auditor asks:

  • “Where do you store customers’ OAuth tokens?”
  • “Are they encrypted?” (yes)
  • “Who can decrypt them?” (only authorised microservices, not developers)
  • “Show me the audit trail of token access.”

Evidence:

  • Secrets manager configuration
  • Encryption key management policies
  • Audit logs of secret access
  • Code review: no hardcoded secrets (a linter checks this)

Common mistake: The tokens are encrypted, but the encryption keys are in environment variables in a GitHub repository. The auditor sees this. “So anyone with GitHub access can decrypt the tokens?” Yes. That is a finding.

5. Feature flags and phased rollout

You deploy continuously. New features go out behind feature flags. How do you stop a bug from affecting all customers?

Controls:

  • Feature flag system (LaunchDarkly, Unleash, or custom)
  • Gradual rollout: first internally, then 1% of customers, then 10%, then 100%
  • Kill switch: a feature can be disabled instantly if there are problems
  • Monitoring per feature: error rates and latency, per flag
  • Documentation: which flags exist, what they do, and who may toggle them

The auditor asks:

  • “Show me a recent feature rollout. Was it gradual?”
  • “What happens if a feature causes errors?” (the kill switch)
  • “Who can toggle production feature flags?” (authorised personnel only)

Evidence:

  • Feature flag dashboard
  • Sample gradual rollout (timeline, percentages, metrics)
  • Kill switch event (feature disabled due to an issue)
  • Access logs: who toggled which flags

Why the auditor cares: Processing Integrity (data correctness) and Availability (uptime). A bug that hits 100% of customers is worse than one that hits 1%. Feature flags are risk mitigation.

6. Customer-specific configurations

Enterprise customers ask for custom configurations: SSO, IP allow-listing, custom domains, data residency.

Controls:

  • Configuration management: where configurations are stored (database, config files)
  • Validation: configurations are tested before deployment
  • Access controls: only authorised personnel can change configurations
  • Change log: all configuration changes are logged
  • Customer approval: enterprise configurations are changed only with customer approval

The auditor asks:

  • “Show me customer X’s configuration. How does it differ from the default?”
  • “What happens if you misconfigure customer Y’s SSO?” (they cannot log in)
  • “How do you test configurations before deploying them?”
  • “Show me the change history of configurations.”

Evidence:

  • Configuration management tool (Terraform, or a custom admin panel)
  • Sample configuration change: ticket, approval, test, deployment, verification
  • Change logs
  • Rollback capability (if a configuration breaks something)

7. Secure customer onboarding

A new customer signs up. How do you make sure they start securely?

Controls:

  • Email verification mandatory
  • Password requirements for the initial password (strong password enforced)
  • MFA encouragement (a prompt to enable it)
  • Onboarding checklist: security settings configured
  • Secure defaults: for example, SSO preferred over password

The auditor asks:

  • “Show me the customer signup flow.”
  • “Can I sign up with a weak password?” (no, it is enforced)
  • “What data is collected? Is a privacy policy shown?”
  • “Are customers encouraged to enable MFA?”

Evidence:

  • Signup flow screenshots
  • Password requirements enforced (technical demonstration)
  • Onboarding emails with security tips
  • Analytics: X% of customers enable MFA within 7 days

8. Scaling without giving up security

You grow from 10 to 100 to 1,000 customers. Security must scale with you.

Controls:

  • Automated security checks in CI/CD (code scanning, dependency checks)
  • Infrastructure as Code (Terraform): security configurations are consistent across environments
  • Automated compliance monitoring (Vanta, Drata): continuous control checks
  • Security champions programme: engineers trained in security, with shared ownership
  • Threat modelling: before new features, assess the security implications

The auditor asks:

  • “How do you ensure security at scale?”
  • “Are security checks automated?” (yes, in CI/CD)
  • “What happens if an engineer deploys insecure code?” (CI/CD blocks it)

Evidence:

  • CI/CD pipeline configuration (security scans)
  • Blocked deployments (code with vulnerabilities rejected)
  • IaC templates (Terraform modules with secure defaults)
  • Training records for security champions

Common auditor questions for SaaS

“How do you handle customer churn and data deletion?” You must show:

  • Customer data is deleted after churn (within X days)
  • Hard delete, not soft delete (a GDPR requirement)
  • Backups: the data is also removed from backups (after the retention period)
  • Verification: the customer can request verification that their data is gone

“What if your SaaS gets acquired? What happens to customer data?” You must have:

  • A data ownership clause in your terms of service (the data remains the customer’s)
  • An acquisition scenario in your privacy policy (notification is mandatory)
  • Data portability (customers can take their data with them)

“How do you handle multi-region customers?” The auditor checks:

  • Data residency: can you keep data in the EU for EU customers?
  • Cross-region replication: is data encrypted during transfer?
  • Compliance: GDPR and data protection laws per region

“What about mobile apps? Are those in scope?” If you have a mobile app:

  • App security testing (OWASP Mobile Top 10)
  • API security (the app communicates via the API)
  • Data storage on the device: is it encrypted?
  • MDM for company-owned devices

Tips for SaaS-specific scope

Start with the core product

For your first SOC 2, focus on the core SaaS platform. Exclude:

  • Internal tools (Jira, Slack, HR systems)
  • Marketing website (WordPress blog)
  • Mobile apps (if you have them, add them later)
  • Legacy features (if you are deprecating them)

Why: A smaller scope means faster, cheaper and easier evidence. You gain experience, and next year you expand.

Choose Security + Availability

For SaaS, these two criteria are the most relevant:

  • Security: customer data is protected
  • Availability: your SaaS is available (a 99.9% uptime SLA)

Skip the first time:

  • Processing Integrity (unless you do billing or calculations)
  • Confidentiality (unless you process very sensitive proprietary data)
  • Privacy (unless you are consumer-facing with a lot of personal data)

You can always add criteria later.

Type II is a must-have for enterprise

Type I is fine for SMB customers, but enterprises want Type II. If you target Fortune 500 companies, go straight for Type II. An observation period of 6 months is acceptable (12 months is better, but 6 is OK).

Costs and timeline for SOC 2 at SaaS companies

Small SaaS (1-25 engineers)

Costs:

  • Audit: €30,000-€50,000 (Type II)
  • Tooling: €8,000-€15,000 (Vanta/Drata)
  • Consultant: €10,000-€20,000 (readiness and guidance)
  • Internal: 300-500 hours (CTO or lead engineer)

Total in the first year: €60,000-€100,000

Timeline: 9-12 months

Funding stage: Series A+ (pre-Series A is often too early, unless an enterprise deal is blocked)

Medium SaaS (25-100 engineers)

Costs:

  • Audit: €50,000-€80,000
  • Tooling: €12,000-€20,000
  • Consultant: €15,000-€30,000
  • Internal: 400-600 hours

Total: €90,000-€150,000

Timeline: 10-14 months

Funding stage: Series B+ (enterprise expansion phase)

Large SaaS (100+ engineers)

Costs:

  • Audit: €70,000-€150,000+
  • Tooling: €20,000-€40,000
  • Consultant: often an internal compliance team
  • Internal: 600-1,000 hours

Total: €120,000-€250,000+

Timeline: 12-18 months

Funding stage: Series C+, pre-IPO (compliance is expected)

Checklist for SOC 2 SaaS security readiness

Before you start SOC 2, check these basics:

Infrastructure:

  • Cloud provider (AWS/Azure/GCP) with a SOC 2 report
  • MFA on all cloud accounts
  • Production separated from development
  • Encryption at rest and in transit
  • Backups automated and tested

Application:

  • Multi-tenancy model designed and tested
  • API authentication required
  • Rate limiting implemented
  • Input validation everywhere
  • Security headers (CSP, HSTS, and so on)

Organisational:

  • Security awareness training
  • Incident response plan
  • Vendor management (SOC 2 reports from critical vendors)
  • Quarterly access reviews
  • Change management process

Evidence:

  • Centralised logging (SIEM)
  • Weekly vulnerability scans
  • Annual penetration test
  • Policies documented
  • Compliance tool (Vanta/Drata) collecting evidence

If you have 80% or more, you are ready to start SOC 2. Fewer? Work on the basics first.

More information

ISAE 3402 vs. SOC 2For cloud providers