SOC 2 for SaaS companies: scope, hyperscalers and evidence from your own pipeline

Almost every SaaS company arrives at SOC 2 the same way. Not through a strategy session, but through a security questionnaire from a prospect larger than any customer you had before. Somewhere halfway down the list comes the question whether you hold a current SOC 2 Type II report. You answer no, the deal moves to next quarter, and assurance is suddenly a priority.

What SOC 2 is, what sits in the four parts of the report and how Type I relates to Type II is covered in SOC 2 explained. This article is about the choices that work out differently because your service is multi-tenant, runs on someone else's infrastructure and ships to production several times a week.

While the report does not exist yet

A first Type II report will not arrive within a quarter, and the deal will not wait. What does work in the meantime is being precise about where you stand: that the scope has been set, when the observation period starts and when the report is expected. Procurement teams accept a date more often than sales teams expect. What does not work is suggesting that you are "SOC 2 compliant". There is no SOC 2 certificate, and the buyer sending out the questionnaire usually knows that better than the account manager filling it in.

A readiness assessment gives you something you can use straight away in this phase: a substantiated picture of what is in place and what is missing. See audit readiness assessment for what such a review involves.

The system boundary is the most expensive decision

At a traditional service organisation the scope is often self-evident: one service, one processing chain. For SaaS the system boundary is a real choice, and it drives the rest of the engagement.

Three questions do most of the work. Which product is in scope? Companies with one main product and two smaller modules sometimes include everything because it is a single codebase, while customers only ask about the main product. Which environments are in scope? Production always belongs there, but staging and development come along as soon as they hold customer data or production secrets, which happens more often than teams assume. And which supporting systems touch the service? Your CI/CD pipeline, secrets management, logging platform and support tooling are in scope if they give access to customer data, even when they are absent from your architecture diagram.

The scope you choose ends up in the system description and customers can read it. A narrow scope that holds up is more useful than a broad scope where you cannot make the controls stick everywhere. The choice of categories works the same way: security is mandatory, the rest you add when your contracts call for it. What each category costs in controls and evidence is set out in the Trust Services Criteria.

Your cloud provider appears in your report

This is where SaaS companies most often assume something incorrect. Your hosting provider is a subservice organisation, and your report has to make explicit how you deal with that. Under the carve-out method their controls stay outside your report and you refer to their own assurance report. Under the inclusive method their controls are tested within your report, which in practice only works with providers who cooperate. For the large cloud platforms carve-out is the normal route. The trade-off between the two is covered in carve-out or inclusive method.

Carve-out does not close the subject. You have to show that you actually review your provider's report, that you look at the exceptions in it and at the controls they leave to you. The part of the shared responsibility that sits with you remains your own control: the configuration of your accounts, your network design, your key management, who holds console access and how that access is removed. The same applies to the rest of your supply chain, which third party risk management covers in more detail.

What you push back to the customer

The other side of the same coin are the complementary user entity controls: the controls you expect your customers to operate. For SaaS there are usually a handful. The customer manages its own users and removes accounts when people leave. The customer enables multi-factor authentication where you do not enforce it. The customer chooses its own role settings and authorisation model.

Those controls belong in the report, because without them your control environment is incomplete. They are commercially useful too: they make visible where your responsibility ends. What belongs in such a list is set out in complementary user entity controls.

Evidence from your own pipeline

For a Type II the auditor tests whether controls operated throughout the period. For a SaaS organisation the sensitive point is not the evidence itself but the completeness of the population it comes from.

Take change management. Your control is that every change to production goes through an approved pull request. The auditor will not ask for twenty-five approved pull requests. He will ask for the complete list of deployments in the period and draw his own sample from it. If that list comes from a system you administer yourself, he will want to know how it was assembled and whether anything can bypass it. Deployments made through an emergency procedure or by hand have to be in that list. See change management in the IT audit and evidence in an IT audit.

The same holds for access. The population is not the export from your identity provider on the day the auditor asks for it, but everyone who held access during the period, including temporary accounts, service connections and the accounts you cleaned up during the last reorganisation. Short-lived infrastructure makes this harder: containers and instances that are replaced automatically leave few traces when your logs have a short retention period. Retention shorter than the observation period is one of the few problems you genuinely cannot repair afterwards.

Compliance automation does half the job

Tooling that monitors controls continuously has become close to standard in SaaS, and with reason: it saves collection work and surfaces exceptions while the period is still running rather than after it. Two things it does not do. It does not set your scope, which follows from your service and your contracts rather than from a template. And it does not replace the auditor's judgement, because he has to establish for himself that the data he relies on is complete and accurate. A dashboard that is green because an integration quietly stopped is a finding, not evidence.

Growing while the clock runs

At fast-growing companies the observation period coincides with change. You open a second region, you replace a provider, you take over a team. That does not invalidate the report, but it does have to be described, and the controls have to have operated after the change as well. The practical rule is to tell your auditor about changes like these when you plan them.

Expect it not to stop at one report either. Customers expect a new period every year that connects to the previous one without a gap. How to set up that rhythm is covered in the annual audit cycle, and what drives the investment in what a SOC 2 engagement costs.

Where to start

Start with the contract of the customer asking for the report, not with a list of controls. It states which service they buy, what availability you promised and which confidentiality and retention terms apply. Those three things determine your system boundary and your categories, and with that most of the cost. Our approach and lead times are on the page about the SOC 2 audit.