Should your SOC 2 cover the whole company or one product?

A SOC 2 reports on the system you describe.

The question sounds like it has two answers, the whole company or one product. The AICPA frames it another way. Its SOC 2 guide describes a SOC 2 as an examination of a service organization’s description of its system and of the controls in it. The subject is a system: the infrastructure, software, people, procedures and data that deliver a service to your customers. The report names your company, but what it examines is that system, not everything the company does.

So “company-wide”, or “organization-wide”, means less than it sounds. It means every service you sell sits inside one system boundary, or that one report describes several systems side by side. “One product” means the description covers the system behind that product and names the other products as outside it.

The criteria allow both. The AICPA wrote the 2017 Trust Services Criteria for controls over “information and systems used to provide products or services”, whether across an entire entity or in one part of it, such as a subsidiary or a division. Nothing in SOC 2 prefers the wider choice.

Management makes the choice. Your team writes the system description against the AICPA’s description criteria (DC 200), the benchmark for preparing it and for evaluating it. The licensed CPA firm that performs the examination evaluates the description you prepared.

So there are three real choices.

• One product, with the platform it runs on and the controls you run for everyone.
• Every product, in one report.
• Separate reports, or a second product that joins later.

How a description is built is covered in the five components of a system and in writing the system description.

Part of the company is in scope either way.

Founders often picture a one-product SOC 2 as a report about one application. It never is. Every SOC 2 includes the Security category. Its common criteria reach the control environment, communication, risk assessment and monitoring, and in most companies those are run once, for everyone. The control activities that protect the system, such as access, change and operations controls, come in for the system you describe.

Take a company with one cloud organization and one engineering team. Even when the report names only product A, these come into it as they serve A:

• The company-level controls: the risk assessment, the policies, hiring and background screening, security training, vendor management and incident response.
• The shared platform: the cloud organization, the identity provider, the deployment pipeline, logging and monitoring.
• The people who can reach A’s production systems, wherever they sit on the org chart.

What stays out is the other products’ own parts: their code, their data stores, their changes and the people who can reach only them. A product you are retiring can stay out the same way, named as outside, unless it still holds the main product’s data during a migration. The boundary lesson covers excluding a legacy product.

So the narrow choice is never as small as one application, because the platform and the controls you run for everyone come with it. The wide choice is lighter than it sounds when the products share one stack, because the people and the access are already in the report. What it adds is each product’s own changes, data stores and application controls. What drives the effort is the number of separate stacks, teams and change paths, far more than the number of product names on your website.

Figure 1 shows the three choices for one company. Products A and B share a platform. Product C runs on its own stack, with its own team.

If you want the mechanics, the multi-product lesson tests whether a product can stand apart across five dimensions, and the boundary lesson sets out what widening the boundary costs. Your cloud provider sits under all three choices as a subservice organization, and whether it is carved out or included is a separate decision.

Our advice: start with what customers are buying.

On scoping calls, this is the advice I give most companies preparing a first report.

1. Scope the product your customers are buying and asking about, with the platform under it. That is the product named in this year’s questionnaires, RFPs and contract clauses, together with the cloud organization, identity provider, pipeline, logging and data stores it runs on, and the company-level controls above them. The report exists to answer those customers. A first report that answers them early is worth more than a wider one that arrives late.
2. Widen to every product when they share the stack and the team. The products run on that platform, and the same people build and run them, with the same access reviews and change approvals. Bring a product in when its customers are asking for the report, or when it shares one codebase and one database with the first, because its code and data are inside the boundary already. A wider report then adds each product’s own changes and data stores to evidence you already keep, and no customer has to ask whether their product is covered.
3. Keep a product out when its stack, its team or its maturity is different. Bring it in at the next period, or give it its own report if it runs on a stack of its own. A product on a different cloud brings a full second set of evidence. A product on the same stack but run by a different team brings that team’s own access reviews and change approvals, and its engineers are in your access lists anyway wherever they can reach the shared platform. A product whose controls started last month brings a different risk: its early gaps would land in the report your main customers read.

In our experience most first reports land on the first choice. The second fits when the products are one system in all but name: one codebase, one database, one team. It is a poor default when they only share a cloud account. The third suits a product on a stack of its own, and keeps a young product’s gaps out of a strong report.

Six questions settle it.

You can answer every one of these from records you already keep: this year’s security questionnaires and RFPs, the list of cloud accounts, the identity provider’s groups, the production access list and the change log. Start with the product customers ask about. Then put each other product through questions 2 to 6, in order. The first “no” usually decides where that product goes.

Each product ends up in one of three places.

• One product and its platform. Where most first reports land in our experience: the product customers ask about, while the other products stay outside because they run apart from it and their customers are not asking yet (question 2), or they are not ready (question 5).
• Every product, one report. When every other product comes back yes to questions 3 to 5, and its customers are asking or it shares the first product’s code and data. The products make the same promises, or you take the extra category for both (question 6).
• Separate reports, or a later join. When a product’s customers need a report but it runs on its own stack (question 3), or is not ready yet (question 5). A product on the same stack with its own team (question 4) usually joins later, or sits in the same report as a second system.

For the finer variants, such as a Type 1 over the wider system now and a Type 2 next period, the multi-product lesson compares five ways to scope it.

What each choice means for you and your customers.

Figure 3 sets the three choices side by side. A small team preparing its first report usually cares most about effort and time. A company with enterprise customers usually cares most about what those customers see, and where an exception would land.

The price bands are all-in: TCSA quotes a SOC 2 with the CPA firm’s examination included rather than billed on top. A wider system, and above all a second stack, moves the quote up, so we quote it after the scoping call. On the Type 2 path the 12-week minimum window opens after 2 to 4 weeks of readiness, so a company-wide Type 2 keeps to 14 to 16 weeks only if every product is ready within those 2 to 4 weeks. Why SOC 2 quotes vary explains what moves a quote, and the SOC 2 timeline has the weeks in detail.

Three companies, three scopes.

The same six questions land differently depending on how a company is built. The three businesses below are illustrations, not clients.

A new product usually joins at the next period.

A Type 2 report covers a period. A product that sat outside the description during that period is not covered by that report, however good its controls were. There is no backdating.

You can bring a product in partway through, but adding a product is the kind of change to the system that the description discloses. It is usually simpler to line the product up with the start of the next period, with its readiness done and its controls running from the first day. Start its readiness while the main report runs, so it is ready when the next period opens.

When a deal cannot wait and the customer will accept a Type 1, a Type 1 can fill the gap. It covers the wider system and shows the design as of a date, and a Type 2 over the next period follows. That Type 1 is a second engagement, quoted on its own. Moving from Type 1 to Type 2 covers that path, and changes during your observation period covers what can and cannot be absorbed mid-window.

What to tell a customer whose product is outside the report.

Sooner or later a customer of product B receives your product A report. Tell them three things.

1. Say exactly what the report covers: the shared platform and the controls you run for the whole company, as they serve product A.
2. Say plainly what it did not examine: product B’s own application, its data stores and its changes.
3. Give a date: the period in which B joins the report, or when B’s separate report is due if B runs on a stack of its own.

Do not send a letter that reads like assurance over B. Only the auditor’s report gives assurance, and a letter that sounds like one creates the confusion the description was written to prevent. The multi-product lesson covers what a buyer’s security team pushes back on, and how to read a SOC 2 report shows where a reader finds the boundary.

Before your scoping call.

Bring answers to these six, and the call can end with a scope instead of a list of open questions.

1. Your products, and who asks about each one this year.
2. The stack behind each product: cloud accounts, identity provider, pipeline, data stores and logging.
3. Who has production access to what, contractors included.
4. Which controls already run, and since when.
5. What each product promises: uptime, confidentiality terms, and whether it holds personal or payment data.
6. Which customers need a Type 2, and by when.

What a readiness assessment involves explains the first pass, and the SOC 2 readiness assessment is a free download.