SOC 2 by industry
SOC 2 for SaaS and technology: what enterprise security reviews expect of a cloud-native company
What changes when the service organisation is a B2B SaaS, platform or API company: why vendor risk teams ask, what belongs in scope, where examiners sample in a CI/CD world, and how the report sits beside questionnaires, ISO/IEC 27001 and CSA STAR.
Key points
- For a B2B SaaS, platform or API company, the SOC 2 report usually arrives as a line in an enterprise security review: the prospect's vendor risk team wants it before legal will sign.
- The system in scope is the production service customers log into or call, plus the pipeline that ships code to it.
- Examiners spend most of their sampling on access to production, the deployment pipeline, monitoring and alerting, and how you oversee your hyperscaler and other subprocessors.
- Availability and Confidentiality are the categories SaaS customers ask about most, because uptime SLAs and tenant data isolation are already in the contract.
Why SaaS buyers ask for a SOC 2 report
The request rarely comes from a regulator. It comes from the customer's procurement and third-party risk teams, often after a successful pilot, with a security questionnaire of several hundred rows waiting before the order form moves. A current report lets the security reviewer replace most of those rows with one document they already know how to read.
Three kinds of buyer drive the demand. Enterprise customers in North America treat the report as a standard item on vendor onboarding. Regulated customers such as banks, insurers and healthcare organisations need it to show their own examiners how they oversee outsourced technology. And other software companies ask because your platform or API has become one of their subservice organisations, so your report feeds theirs.
What changes in this sector is the pace. Releases ship daily, infrastructure is defined in code and rebuilt constantly, and the people operating controls are engineers. The programme works when evidence comes out of the tools those teams already use. Very small teams should start with SOC 2 for start-ups and small teams: a right-sized control set.
What sits inside the scope for a SaaS or platform company
The system description names the application and its APIs, the production accounts on your cloud provider, the data stores holding customer content, the CI/CD pipeline and repositories that change production, and the identity provider that decides who gets in. Support tooling that can see customer data belongs inside too.
Your hyperscaler is almost always a subservice organisation. Its data-centre and hardware controls sit in its own SOC reports; you show that you review them and operate the controls it expects of its customers. The mechanics are in SOC 2 vendor management and subservice organisations.
Three scope mistakes recur here: leaving out the deployment pipeline, the most direct route to changing production; describing one production environment when customers are served from several regions or a dedicated-tenant stack; and naming only the flagship product when the buyer is purchasing an add-on on different infrastructure. The general rules are in SOC 2 scope: system boundaries, trust services categories and carve-outs.
Where the criteria bite for SaaS and technology
| Criteria area | What it means in a SaaS company | Evidence the examiner samples |
|---|---|---|
| CC6 Logical and physical access | Who can reach production consoles, databases, secrets and customer tenants, and how that access is granted, elevated and removed | Identity provider group changes, break-glass access logs, periodic reviews of cloud roles and database users, leaver removal times, multi-factor authentication enforcement |
| CC8 Change management | Application code, infrastructure as code and configuration all reach production through a controlled pipeline | Pull requests with peer approval, branch protection settings, passing tests before merge, deployment records, emergency fixes reviewed afterwards |
| CC7 System operations | Detecting and responding to anomalies, vulnerabilities and incidents in a live multi-tenant service | Alert rules and on-call records, vulnerability scans with fix dates against policy, incident tickets and post-incident reviews, restore tests |
| CC3 and CC9 Risk and vendor management | Risks to the commitments in your contracts and SLAs, including dependence on the hyperscaler and other subprocessors | Risk register tied to service commitments, subprocessor list, review of providers' SOC reports and the user-entity controls they require |
| A Availability and C Confidentiality, if in scope | Meeting the uptime you promise and keeping each customer's data separate, retained and deleted as agreed | Uptime and capacity monitoring against the SLA, recovery tests, tenant isolation testing, deletion records at contract end |
The full criteria set is explained in SOC 2 Trust Services Criteria explained, criterion by criterion.
Working alongside questionnaires, ISO/IEC 27001 and CSA STAR
Enterprise buyers still send questionnaires. The Cloud Security Alliance's Consensus Assessments Initiative Questionnaire (CAIQ) and the Shared Assessments SIG questionnaire are two formats procurement teams use. A tested SOC 2 control set gives you one consistent answer to reuse across them, with the report attached as evidence.
Customers in Europe and Asia often ask for ISO/IEC 27001 certification beside the report. One set of policies, one risk assessment and one evidence calendar can serve both; see SOC 2 vs ISO/IEC 27001: which one, or both?
CSA STAR Level 1 is a published CAIQ self-assessment. Its Level 2 attestation is a SOC 2 examination in which the service auditor, a CPA firm, also uses criteria from the Cloud Controls Matrix, under guidelines agreed between the Cloud Security Alliance and the AICPA.
What a SaaS engagement looks like
Duration depends less on headcount than on how much infrastructure is already in code, whether production access already runs through an identity provider, and when the first enterprise customer needs the report. The platform or DevOps lead, engineering leadership, support and whoever owns vendor contracts must be involved, with a sponsor who can protect engineering time. With Design™, Sterling guides your engineers to own the controls; with Drive™, Sterling carries more of the documentation, evidence and readiness testing so product teams keep shipping.
How Sterling works with SaaS and technology companies
Controls that live in your pipeline, not in a folder.
Our expert and experienced consultants map the criteria to your identity provider, repositories, cloud accounts and ticketing tools, test the controls the way the CPA firm will before the period starts, and keep the evidence in Effivity, included with the engagement, at no additional cost. Sterling does not issue the report; an independent, licensed CPA firm examines and opines. We ensure a successful SOC 2 examination for our clients.
Book a free discovery callSOC 2 for SaaS and technology: questions buyers ask
Our whole stack runs on a major cloud provider. Does their SOC 2 report cover us?
No. It covers the platform controls they operate. How you configure accounts, grant access, change code and protect customer data is yours to evidence.
Can our CI/CD pipeline and infrastructure as code count as change management evidence?
Yes, and they are usually the strongest evidence, provided branch protection, required approvals and test gates were enforced throughout the period and any bypass was recorded and reviewed.
Should Availability be in scope if our contracts include an uptime SLA?
Often, because customers already rely on that commitment. Include it once you can show capacity monitoring and tested recovery; defer it if recovery has never been tested.
Does the report replace a prospect's security questionnaire?
Rarely in full. Many reviewers accept the report for most sections and ask only what it does not cover, such as data residency. An answer library mapped to your controls keeps responses consistent.
SOC 2 by industry
Every guide in the SOC 2 series is written for one question and links back to the hub for the whole picture.
- SOC 2 for accounting and professional services
- SOC 2 for BPO and shared services
- SOC 2 for fintech and payments
- SOC 2 for healthcare IT and health BPO
- SOC 2 for HR, payroll and staffing
- SOC 2 for managed service providers and data centres
- SOC 2 policies and evidence
- SOC 2 readiness review checklist
- How to read a SOC 2 report
- SOC 2 for SaaS and technology
- SOC 2 scope
- SOC 2 in Singapore and South East Asia
- SOC 2 for start-ups and small teams
Keep exploring
Explore more about SOC 2
Watch a video on how to implement SOC 2 here.
Watch a video on SOC 2 requirements here.
SOC 2 resources
Services for SOC 2
Industries
Talk to a consultant
Plan a SOC 2 programme that runs on your engineering tools.
Tell us your goals, locations and target date. We’ll help you define the scope, timeline and next steps.
hello@sterling-grc.com+1 201 263 4443 (global headquarters) · your nearest office and its number are at the top of this page
What would you like to achieve?
Choose a starting point. The enquiry form takes about a minute.
Book my free discovery callContinue to the enquiry form to share your details. Please do not include passwords, sensitive personal information or confidential files. A Sterling consultant replies within one working day. Privacy notice