SOC 2 by industry
SOC 2 for SaaS: proving one customer's data stays away from the next.
A SaaS company sells the same running system to every customer at once. That is why its SOC 2 report is read for one thing above all: whether each tenant's data is kept apart and whether the people who can reach production are few, known and watched. This guide walks through the buyers, the boundary, the categories, the vendors and the evidence, from a SaaS point of view.
Back to SOC 2 services01 · Who asks
Who asks SaaS companies for a SOC 2 report
The buyer decides the scope and the weight of the report, so start with who is asking.
| Asked by | What they want to see |
|---|---|
| Enterprise procurement and vendor-risk teams | A current Type 2 report, the bridge letter if the period ended months ago, and the list of CUECs they must run on their side. |
| The buyer's security architect | How tenants are separated, who holds production access, and whether customer data ever reaches non-production environments. |
| Mid-market customers with no security team | Something short they can file: often a SOC 3 or a trust page, with the full report under NDA if they ask. |
| Channel partners and marketplaces | Assurance that an integration or listing will not become their weakest link, usually through the Security and Availability sections. |
02 · What is in scope
What sits inside the system boundary
The report covers one system. In this sector the boundary usually takes in:
- The production application and its APIs
- The product the customer logs into and the endpoints their integrations call. Internal admin consoles count too.
- Tenant data stores
- Databases, object storage, search indexes and caches that hold customer records, including backups and replicas.
- The delivery pipeline
- Source control, CI/CD, infrastructure-as-code and the approvals that move a change into production.
- Identity and support tooling
- The identity provider, the support desk and any impersonation or 'log in as customer' feature staff can use.
- Observability and alerting
- Logs, metrics and on-call paging that show the system is watched. Logs that contain customer content are themselves in scope.
03 · Categories
Which Trust Services Categories matter here
Security is always in. The rest depend on what you promise customers.
| Category | Weight in this sector | Why |
|---|---|---|
| Security | Core | Always included. On a shared stack, logical access and change control carry most of the weight. |
| Availability | Common | Added when the contract carries an uptime commitment or service credits. If you promise a number, buyers expect the report to test it. |
| Confidentiality | Common | Customers upload business data they treat as secret. Retention and deletion on contract end are what get examined. |
| Processing Integrity | Rare | Only when the product's output is the promise, such as calculations or billing customers rely on without checking. |
| Privacy | Occasional | Considered when you collect personal information directly from individuals rather than processing it for a business customer. |
04 · Vendors in the report
The vendors that appear in your report
Each one is a subservice organization or a carve-out, and the report has to say which.
- Cloud infrastructure provider
- Almost always a carved-out subservice organization. You rely on its report for physical security and the hypervisor layer.
- Identity provider and email
- Often listed because staff sign-in and alerting depend on them. Treated as a subservice organization if a control relies on them.
- Managed database or search service
- Carved out, with its CSOCs (encryption at rest, patching) named in your description.
- Support and messaging tools
- Usually outside the boundary unless customer data flows into tickets. If it does, say so and review the vendor.
05 · Sector controls
Controls that this sector makes necessary
Examples only. Your own wording is what the auditor tests.
- S.1Tenant context enforced server-sideEvery query is filtered by a tenant identifier taken from the authenticated session, never from a client parameter.
- S.2Cross-tenant tests in the pipelineAutomated tests try to read another tenant's records and must fail before a release can merge.
- S.3Production access is time-boundEngineers request access for a ticket, it expires on its own, and every session is logged.
- S.4Support impersonation is consented and recordedLogging in as a customer needs a ticket reference, shows in the customer's audit log and is reviewed monthly.
- S.5Customer data stays out of test environmentsStaging uses synthetic or masked data. Any exception is approved and time-limited.
- S.6Offboarded tenants are purged on a scheduleData from ended contracts is deleted within the period the contract states, and the deletion job is evidenced.
06 · Traps
Where companies in this sector slip
Predictable, and cheaper to fix before fieldwork.
- Scoping only the app, not the platform under it. The shared Kubernetes cluster, the message queue and the secrets store serve every tenant. Leaving them out makes the report narrower than the product.
- Treating the 'login as customer' button as a feature. To an auditor it is privileged access to customer data. If it is not in the access controls, it is a gap.
- Promising an uptime number you never measure. An SLA in the contract with no monitoring evidence behind it invites an Availability exception.
- Backups forgotten in the deletion story. You delete a churned tenant from the live database, but the snapshot keeps them for a year. Describe the backup retention honestly.
- A free tier on the same stack. Self-serve sign-ups share infrastructure with enterprise tenants. They are inside the boundary whether or not they pay.
07 · Tenant isolation
Showing tenant isolation to an auditor
There are three common isolation models. Each one is evidenced differently.
Pooled
One database, tenant ID on every row
- Evidence: the query layer that injects the tenant filter
- Evidence: automated cross-tenant tests and their results
- Risk the auditor probes: a raw query that skips the filter
Bridged
Shared cluster, schema or database per tenant
- Evidence: provisioning scripts that create the per-tenant store
- Evidence: credentials scoped to one schema
- Risk the auditor probes: shared service accounts with access to all
Siloed
Separate stack per customer
- Evidence: account or project per tenant, with its own keys
- Evidence: the deployment process that keeps every silo patched
- Risk the auditor probes: silos drifting out of configuration
Illustrative. Many products mix models, for example pooled for small tenants and siloed for the largest. Describe each model you actually run.
The report does not grade which model is better. It tests whether the controls you describe for your model operated through the period.
08 · Evidence
Evidence to have ready
What an auditor will ask for, in the order they usually ask.
- The system description and an architecture diagram showing shared and per-tenant components
- The list of people with production access, and the access reviews for the period
- Change tickets sampled against their pull requests, approvals and deployments
- Cross-tenant test results from the pipeline
- Support impersonation logs and their review
- Uptime monitoring records against the contractual commitment
- Deletion records for tenants who left during the period
When the buyer also sends a data processing agreement
Customers in Europe often attach a data processing agreement under GDPR Article 28, which asks a processor to show sufficient guarantees and to allow audits. A SOC 2 report can be offered as part of that evidence, but it is not a GDPR compliance opinion, and the agreement's own terms still apply.
Sources: AICPA Trust Services Criteria (TSP section 100, 2017, revised points of focus 2022); AICPA Description Criteria (DC section 200); AICPA guide, SOC 2 Reporting on an Examination of Controls at a Service Organization; Regulation (EU) 2016/679, Article 28.
More about SOC 2 for SaaS
Do our free users have to be inside the report?
If they share the production stack, yes.
The boundary follows the system, not the price plan. If free users run on the same infrastructure, the controls that protect paying tenants also protect them, and the description should say so. Only a genuinely separate stack can be left out.
We run a single-tenant deployment for one big customer. Is it covered?
Only if you describe it.
A dedicated deployment is a different set of infrastructure. Either include it in the boundary, with its own evidence, or state clearly that the report covers the shared offering only. Do not let the big customer assume coverage.
Our cloud provider has a SOC 2. Does that cover tenant isolation?
No. Isolation inside your app is yours.
The provider's report covers its hardware and virtualisation. How your application keeps one customer's rows away from another's is your design, and only your report can speak to it.
Should the support team's ticket tool be in scope?
Follow the customer data.
If customers paste data, files or screenshots into tickets, the tool holds customer data and should be reviewed as a vendor. If tickets hold only contact details and descriptions, it usually sits outside the boundary.
Scope your SaaS SOC 2 around what buyers ask.
A readiness assessment turns this into your boundary, your categories and your gaps.