How to Scope Your First SOC 2 Report

Scope decides how much a SOC 2 report costs, how long it takes and how useful it is to customers. Most first-time mistakes are scope mistakes, made in the first week.

A SOC 2 report covers a system: the service customers buy and everything behind it. Draw that boundary too wide and you'll spend months evidencing controls nobody asked about. Draw it too narrow and the report won't answer the customer's question. Most expensive first-time SOC 2 mistakes are made in the scoping week.

Decision 1: which system

Start from what customers buy and depend on. For most software companies that's the production platform: the application, its infrastructure and data stores, the people who build and run it, and the processes they follow. Usually out of scope: internal corporate IT that never touches customer data, other product lines, and sales systems.

Write the boundary down early, because it becomes the system description in the report, and every control must operate across everything inside it, every day of the observation period.

Decision 2: which criteria

Security, the common criteria CC1 to CC9, is mandatory. Add others only when customers need them:

Availability if customers depend on uptime commitments.
Confidentiality if you hold customer data designated confidential (most B2B services).
Processing Integrity if customers rely on you to process their data correctly: payments, payroll, billing.
Privacy if you process personal information for your own purposes and customers ask for it. Most of its criteria have no equivalent in security frameworks, as our analysis of SOC 2 and ISO 27001 shows.

Photograph of masking tape and a tape measure on a concrete floor where a rectangle has been marked out with tape — Mark the boundary before anything else.

Decision 3: subservice organisations

Your cloud provider, payment processor or managed database provider runs controls you rely on. You choose between:

Carve-out (most common): their controls are excluded; you describe what you rely on them for, and show that you review their own SOC 2 reports.
Inclusive: their controls are tested within your report. This needs their cooperation and is rare for large providers.

Decision 4: complementary user entity controls

List the controls your customers must operate for yours to work: managing their own user accounts, protecting their API keys, configuring their SSO. Keep them realistic and few, because customers read them and their security teams will question an unreasonable list.

Decision 5: Type I or Type II, and the period

A Type I is quicker; a Type II is what most customers want. For a first Type II, a three- to six-month period is common. Start it only when controls have been running for a few weeks, so the early part of the period isn't full of exceptions.

A scoping checklist

Before the kickoff with your CPA firm, have answers to these:

Which product or service is the report about, and what do customers rely on it for?
Which environments are in scope (production only, or staging too)?
Which cloud accounts, regions and data stores?
Which teams and roles operate the system?
Which subservice organisations does the system depend on, and do you have their reports?
Which Trust Services Criteria categories, and why?
Which complementary user entity controls will customers need to operate?
Type I first, or straight to Type II? Which period?
Which existing frameworks or audits can you reuse evidence from?

Written answers become the first draft of your system description and save weeks of back-and-forth. If you already hold ISO 27001, the ISO 27001 → SOC 2 gap report answers the last question.

Scoping mistakes that cost the most

Including corporate IT "to be safe": it doubles the population of systems to evidence.
Adding Privacy or Processing Integrity because they sound good: each adds controls and evidence for the whole period.
A system description that doesn't match reality: auditors test what you wrote.
Starting the period before controls run: exceptions in month one stay in the report.

Our SOC 2 guide covers the full process; the SOC 2 framework page lists every criterion with its mappings; and if you already hold another framework, the gap analysis shows how far it gets you.

Questions

What is the minimum scope for a SOC 2 report?

The Security category (the common criteria, CC1 to CC9) for a defined system. Availability, Confidentiality, Processing Integrity and Privacy are optional.

What is a carve-out in SOC 2?

Excluding a subservice organisation's controls (for example your cloud provider's data-centre controls) from your report, while describing what you rely on it for and how you monitor it.

Data as of 2026-10-27: numbers in this post are computed from the current crosswalk and update when it changes. Crosswalk a published crosswalk (NIST, ENISA, CIS, PCI SSC) makes the link · Editorial ControlMapping's judgement where no crosswalk exists; the reason is shown · only shares a CSF 2.0 outcome: worth checking, not a mapping · No mapping in our data nothing mapped in our data; often new work, but check the coverage notes. Not compliance advice.

Scoping a first SOC 2 report without over-committing