Priya Nandakumar had eleven days to answer one question, and two very confident people had already given her two contradictory answers.
Priya was VP of Compliance and Risk at Ledgerlight, Inc., a 120-person Series B fintech company that sold expense-management software to mid-market finance teams. Ledgerlight's biggest customer, a logistics conglomerate worth roughly $1.2 million in annual recurring revenue, had a renewal sitting in legal review — pending one condition. Their vendor security team wanted a current SOC 2 Type II report, "scope covering the platform our data flows through," on file within the quarter.
Sales had one answer: scope everything. "We can't afford to explain gaps to a Fortune 500 procurement team," the VP of Sales argued in the Monday leadership sync. "If the auditor's report says 'excludes X,' the customer's security reviewer is going to ask why, and I don't want to be the one answering that email." Engineering had the opposite answer, delivered with equal conviction: scoping the internal data warehouse, the marketing website, the legacy reporting microservice nobody had touched since 2022, and the three regional office networks would add four months and — based on the quote Priya had already gotten from a second CPA firm — roughly $47,000 to the audit budget, for systems the customer's security questionnaire never actually asked about.
Priya had two quotes on her desk. Marcus Feld, a partner at the assurance firm Hollis & Feld, had scoped a "narrow" engagement — the core Ledgerlight platform, its production AWS environment, and the people and procedures directly touching customer data — at $48,000 with a 4-month readiness runway. A second firm, working from Engineering's expansive systems list, had quoted $95,000 and a 7-month runway to cover everything from the corporate Wi-Fi network to a defunct reporting tool three customers still technically had access to. Same company. Same Trust Services Criteria. Double the cost, because of one decision made in a single afternoon: where the scope line gets drawn.
This is the decision most first-time SOC 2 programs get wrong — not because it's technically hard, but because nobody owns it clearly enough, early enough, to keep sales, engineering, and the auditor pointed at the same boundary. Get scope right and you produce a report that answers exactly the questions your customers are asking, at a cost and timeline that make sense for a company your size. Get it wrong in either direction — too broad or too narrow — and you either burn budget testing controls nobody asked about, or hand a customer's security team a report with a hole in it that becomes the reason the deal stalls.
Who this is for, and what you'll walk away with
This is for the compliance lead, founder, or engineering leader who has been told "we need SOC 2" and is now staring at a blank system description wondering what actually belongs in it. You'll walk away knowing which Trust Services Criteria apply to your business (Security always does; the other four are a judgment call tied to your commitments), how to draw the system boundary around products, environments, and teams without either padding it or leaving gaps, and how to classify every subservice organization you depend on as carve-out or inclusive. By the end, you'll have a framework for writing a scope statement you can defend to an auditor, a customer, and your own CFO — in that order.
Why scope is the highest-leverage decision in the entire program
Every other decision in a SOC 2 program is downstream of scope. The number of controls you design, the evidence you collect, the systems your engineering team has to instrument, the length of the readiness assessment, the auditor's fee, and ultimately what the finished report says about your company — all of it traces back to a scope statement that, in most companies, gets written in a matter of days by two or three people in a room.
I've watched companies spend six figures more than they needed to because nobody challenged an instinct to "scope broad, just to be safe." I've also watched companies hand a customer a report that quietly excluded the exact subservice organization that customer's own security team was worried about, triggering a re-scope, a re-audit, and a deal that slipped two quarters. Scope isn't a formality you fill in before the real work starts. Scope is the real work — everything after it is execution against a boundary you already chose.
The three dimensions of SOC 2 scope
Scope isn't one decision. It's three, and treating them as one is where most of the confusion starts.
1. Which Trust Services Criteria apply. Security is mandatory in every SOC 2 engagement. Availability, Processing Integrity, Confidentiality, and Privacy are optional, added based on what you've actually committed to your customers.
2. Where the system boundary sits. This is the "in scope" universe of products, infrastructure, environments, locations, data, and teams described in Section III of the report — the system description.
3. How subservice organizations are treated. Every vendor you depend on to deliver your service — cloud hosting, identity providers, payment processors, background-check vendors — has to be classified as either carve-out (excluded, with their controls assumed) or inclusive (their controls tested as part of your report).
Get all three dimensions written down, reviewed, and signed off before you touch a single control, and the rest of the engagement runs in a straight line. Skip that step, and you'll be re-litigating scope in month three, mid-readiness assessment, which is the single most common reason SOC 2 timelines blow past their original estimate.
Choosing your Trust Services Criteria
Every SOC 2 audit scope starts from the same non-negotiable baseline and builds outward from there.
Security: always in scope
The Common Criteria — CC1 through CC9, mapped to the COSO internal-control framework's 17 principles — form the required foundation of every SOC 2 report, Type I or Type II, regardless of industry. There is no version of SOC 2 without Security. If a vendor tells you they're "doing a SOC 2 for just Availability," they've either misunderstood the framework or you've misunderstood them. Security covers the access controls, change management, risk assessment, monitoring, and incident response practices that every other criterion assumes are already in place.
Availability: add it when uptime is a stated commitment
Availability belongs in scope when your contracts, SLAs, or marketing materials make explicit commitments about uptime, performance, or disaster recovery — "99.9% uptime," "RTO of 4 hours," "24/7 availability." If your customers depend on your platform being up during business hours to run their own operations, and you've made a commitment about that, Availability criteria (the A-series, covering capacity planning, environmental protections, and business continuity/disaster recovery) are the natural next addition.
Processing Integrity: add it when you process transactions or calculations customers rely on
Processing Integrity applies when your system's core value is that it processes something — a payment, a calculation, an order, a report — completely, accurately, and on time. Payment processors, billing platforms, trading systems, and data-transformation pipelines are classic candidates. If a customer would suffer real financial or operational harm from your system silently processing something wrong (not disclosing it, actually getting it wrong), Processing Integrity earns its place in scope. If your product is closer to "we store and retrieve records the customer entered themselves," Processing Integrity often isn't worth the additional testing burden.
Confidentiality: add it when you hold sensitive business data under contractual or NDA protection
Confidentiality is about protecting information that isn't necessarily personal but is sensitive by agreement — trade secrets, financial models, proprietary source code, M&A data rooms, or any customer data your contracts specifically label as confidential. If your customer contracts include confidentiality or non-disclosure clauses that go beyond "don't share personal data," and your service exists to store or process that category of information, Confidentiality belongs in scope.
Privacy: add it when personal information handling is core to what you do
Privacy (TSC) is the least commonly included criterion, and for good reason — it's also the most operationally demanding, covering notice, choice, consent, collection, retention, disclosure, and disposal of personal information against your own published privacy commitments. Most B2B SaaS companies that merely store personal information on behalf of their customers (an HR platform holding employee records, for instance) find that Security and Confidentiality already cover the relevant risk, and add Privacy only if their own product's core function is processing consumers' personal information directly — an ad-tech platform, a consumer health app, a direct-to-consumer data broker.
Trust Services Criteria | Add it when... | Skip it when... | Typical adopters |
|---|---|---|---|
Security (required) | Always — every SOC 2 report includes it | Never optional | Every service organization |
Availability | You commit to uptime/SLA/DR terms in contracts | You have no stated uptime commitments | Infrastructure, hosting, SaaS platforms with SLAs |
Processing Integrity | Your system processes transactions/calculations customers rely on being accurate | You mainly store/retrieve customer-entered data unchanged | Payment processors, billing platforms, trading systems |
Confidentiality | You hold sensitive business data under NDA/contractual confidentiality terms | Data you hold isn't contractually sensitive beyond normal privacy | Data rooms, legal tech, professional services platforms |
Privacy (TSC) | Processing personal information is your core product function | You store PI on a customer's behalf but it isn't your core function | Ad-tech, consumer health apps, data brokers, direct-to-consumer platforms |
"The question I ask every prospective client isn't 'what are you afraid of' — it's 'what have you already promised your customers in writing.' Your Trust Services Criteria should mirror your contracts, not your anxieties. I've seen companies add Privacy because it sounded thorough, and then spend six extra weeks documenting a consent framework nobody asked them for." — Marcus Feld, CPA, Partner, Hollis & Feld Assurance Partners
TSC selection by company type
The "which criteria do I need" question gets easier once you stop asking it in the abstract and start asking it against your actual business model. Here's how it typically shakes out across the company archetypes I see most often.
Company type | Security | Availability | Processing Integrity | Confidentiality | Privacy | Typical rationale |
|---|---|---|---|---|---|---|
B2B SaaS (workflow/productivity tool) | Required | Usually | Rarely | Often | Rarely | Uptime SLAs common; data is business records, not core PI processing |
Cloud infrastructure/hosting provider | Required | Almost always | Rarely | Sometimes | Rarely | Uptime is the entire value proposition |
Payments/fintech processor | Required | Usually | Almost always | Often | Sometimes | Transaction accuracy is the product |
Healthcare data platform (B2B, not consumer-facing) | Required | Often | Sometimes | Almost always | Sometimes | Sensitive data, contractual confidentiality obligations |
HR/payroll SaaS | Required | Usually | Sometimes | Often | Sometimes | Employee PI at volume, though the customer (employer) is not the data subject |
Ad-tech/martech platform | Required | Sometimes | Rarely | Sometimes | Often | Core function is processing personal data for targeting/analytics |
Managed security/MSSP | Required | Usually | Sometimes | Almost always | Rarely | Client security data is highly sensitive, contractually protected |
Data analytics/BI platform | Required | Usually | Often | Often | Sometimes | Processing integrity matters if outputs drive customer decisions |
Notice the pattern: Security anchors every row, and the rest of the row is a direct reflection of what the company promises and processes — not a generic checklist. This is also the table I'd hand a sales leader who insists "we should just include everything" — it's a useful way to show that criteria are a business-fit decision, not a completeness contest.
Let the data drive it, not the instinct
Beyond company archetype, the fastest sanity check for TSC selection is to classify the data actually flowing through the in-scope system and ask which criteria that data category implicates. This is the same discipline a mature risk assessment applies to any other control decision — start from what could go wrong with a specific asset, not from a generic list.
Data type in your system | Security | Availability | Processing Integrity | Confidentiality | Privacy |
|---|---|---|---|---|---|
Authentication credentials/access tokens | Yes | — | — | Often | — |
Customer business records (non-PII) | Yes | If SLA-bound | If accuracy-critical | Often | — |
Payment/card transaction data | Yes | Usually | Yes | Yes | — |
Employee/consumer PII | Yes | — | — | Often | If core function |
Health information (B2B context) | Yes | Often | Sometimes | Yes | Sometimes |
Proprietary source code/trade secrets | Yes | — | — | Yes | — |
Marketing/behavioral data for targeting | Yes | — | — | Sometimes | Usually |
Aggregate/anonymized analytics output | Yes | Often | Often | Rarely | — |
If you can't point to a data category that justifies a criterion, don't include it. Auditors will test whatever criteria you select against the full Common Criteria baseline plus the specific points of focus for that category — every additional criterion is additional audit evidence to produce, not a free box to check.
What "Security" actually tests, before you add anything else
It's worth being concrete about what's already inside scope the moment you commit to a SOC 2 engagement, because the Common Criteria alone cover more ground than most first-time founders expect. Each additional criterion you select gets layered on top of this baseline — it doesn't replace or narrow it.
Common Criteria series | COSO principle area | What it examines |
|---|---|---|
CC1 | Control environment | Governance, tone at the top, organizational structure, ISO 27001-style commitment to security as a management responsibility |
CC2 | Communication and information | Internal/external communication of security responsibilities and incidents |
CC3 | Risk assessment | How the organization identifies and analyzes risk to its objectives |
CC4 | Monitoring activities | Ongoing evaluation of whether controls are present and functioning |
CC5 | Control activities | Policies and procedures that help ensure management directives are carried out |
CC6 | Logical and physical access controls | Access control, authentication, encryption, physical security |
CC7 | System operations | Vulnerability management, monitoring, incident response |
CC8 | Change management | Change management processes for system modifications |
CC9 | Risk mitigation | Vendor and business-disruption risk mitigation, including vendor risk management practices |
I keep this table on hand for a specific reason: clients frequently propose adding a criterion to "cover" something that CC6 or CC7 already covers under the required baseline. Encryption, access control, vulnerability management, and incident response are all already in scope the moment Security is selected — you don't need Confidentiality to get encryption at rest or encryption in transit tested; those live inside the Common Criteria. Knowing what the baseline already buys you is often the fastest way to talk a stakeholder out of an unnecessary criterion.
Defining the system boundary: what goes into the system description
Once your Trust Services Criteria are set, the harder and more consequential work starts: drawing the line around what "the system" actually is. This boundary becomes Section III of your finished report — the system description — and it's built from five components the AICPA description criteria expect every service organization to address.
System description component | What it covers | Common scoping question |
|---|---|---|
Infrastructure | Physical and virtual computing resources — servers, containers, networks, cloud accounts, data centers | Which environments (prod/staging/dev), which cloud accounts, which regions? |
Software | Applications, systems software, utilities that support the service | Which products/modules? Does the marketing site or admin tooling count? |
People | Roles and functions involved in operating and securing the system | Which teams — engineering, SRE, support, security — vs which don't touch the system (finance, sales)? |
Procedures | The automated and manual processes that operate the system | Onboarding/offboarding, change management, incident response — scoped to in-scope systems only |
Data | The types of data used or processed by the system | Which datasets, which classifications, which flows in and out |
A useful mental model: the system boundary is not "everything the company owns" — it's everything that materially participates in delivering the specific service your customer is buying and that your Trust Services Criteria apply to. A company can have dozens of internal systems and only two or three of them ever appear in the system description.
"The biggest tell that a company hasn't thought through scope is when the system description reads like an IT asset inventory. A good boundary is a business boundary first — what service are we promising, what does it take to deliver that promise — and an infrastructure diagram second." — Sam Whitfield, Senior SOC 2 Auditor, Ferris Lane Assurance
In/out decisions: products
Multi-product companies face the first hard boundary question immediately: does the SOC 2 cover the whole company, or one product line? The answer should follow the customer commitment, not corporate convenience. If your enterprise customers only buy Product A, scoping Product B (which they've never touched and never will) adds cost with zero customer-facing benefit. Conversely, if your sales motion increasingly bundles Product A and Product B together, or your roadmap is converging the two onto shared infrastructure, a combined scope may be cheaper long-term than two separate engagements.
In/out decisions: environments
Production is almost always in scope — it's where customer data lives and where the service is actually delivered. Staging and development environments are more nuanced: if they contain real (even masked) customer data, or if a control failure there could plausibly propagate to production, auditors will often expect them in scope, or expect you to document why they're excluded (e.g., synthetic data only, fully isolated network, no production credentials). Disaster recovery environments should be in scope if you've made Availability commitments that depend on them. Sandbox or demo environments with no real customer data are a common, defensible exclusion.
In/out decisions: supporting functions
This is where the "scope everything" instinct usually breaks the budget. Corporate IT, HR systems, finance/accounting platforms, and marketing infrastructure are typically out of scope unless they materially participate in delivering or securing the in-scope system — for example, if your HRIS is also your source of truth for provisioning production access (a common integration point), the identity-provisioning workflow belongs in scope even if the HRIS itself doesn't. The test isn't "does the company use this system" — it's "does this system's failure or compromise create a path to the in-scope environment or data."
Category | In scope | Out of scope | Deciding question |
|---|---|---|---|
Production application & infrastructure | Yes | — | Where the service is delivered |
Staging/dev with real or masked customer data | Usually | Sometimes, with documented rationale | Does a failure here propagate to prod? |
Disaster recovery environment | Yes, if Availability is in scope | — | Does it back an SLA commitment? |
Demo/sandbox with synthetic data only | — | Usually | Any real customer data present? |
Corporate IT (laptops, email, SSO used for prod access) | Often, partially | Rarely fully out | Does it gate access to the in-scope system? |
HR systems (as HR systems) | — | Usually | Do they touch in-scope data or provisioning? |
HR-to-access-provisioning workflow | Yes | — | Directly controls who gets production access |
Finance/accounting platforms | — | Usually | Rarely touches the in-scope system |
Marketing website (no app functionality) | — | Usually | No customer data or service delivery function |
Regional/branch offices with no infrastructure role | — | Usually | Physical security only matters if servers/data live there |
Customer support tooling with access to customer data | Yes | — | Direct access to in-scope data |
"I tell clients: draw the boundary around the promise, not the org chart. If finance can't see production data and doesn't operate a control that protects it, finance doesn't belong in your system description — no matter how proud you are of your expense-approval workflow." — Renata Okafor, CISO, Bramwell Health Analytics
Scope in multi-region and multi-entity companies
Companies operating across multiple regions or legal entities face a boundary question that's easy to underestimate: does "the system" mean one global deployment, or does each region's infrastructure and data residency requirements need to be treated separately? The answer usually depends on whether your regions run genuinely separate infrastructure (different cloud accounts, different data stores, different operating teams) or a single global deployment with regional data-residency controls layered on top.
Scenario | Scope approach | Rationale |
|---|---|---|
Single global platform, all customers on shared infrastructure | One report covering the full deployment, noting regional data-residency controls as part of the boundary | Infrastructure and control ownership are unified; splitting scope would just duplicate testing |
Separate regional deployments with independent infrastructure (e.g., EU and US environments run separately) | Consider whether a single report can describe both, or whether region-specific customers need a region-scoped report | Different infrastructure often means different control owners and different evidence sets |
Acquired entity running on its own stack, not yet integrated | Exclude until integrated, or scope separately with its own system description | Testing a not-yet-integrated stack under the parent's controls misrepresents who actually operates them |
Regional subsidiary using parent company's platform under a reseller model | Typically included if the subsidiary has no independent infrastructure of its own | The "system" delivering the service is still the parent's platform |
Contracted regional data centers with local control requirements | Document as a subservice organization (carve-out or inclusive per its own attestation) | Local data center operators are vendors, not part of your operated system |
The underlying principle doesn't change from the rest of this article: scope follows infrastructure and control ownership, not the legal org chart or the sales map. A company selling into five regions from one shared platform generally needs one well-described boundary, not five redundant ones.
Multi-product and multi-tenant companies: scoping strategies
Companies running several products, or a single multi-tenant platform serving very different customer segments, generally choose one of three strategies.
Strategy | How it works | Best for | Trade-off |
|---|---|---|---|
Single product, single report | Whole company scoped as one system around the flagship product | Companies where one product drives nearly all revenue | Simplest to manage, but growing product lines get left out until re-scoped |
Product-specific report | Only the product(s) under active customer scrutiny are scoped; others excluded entirely | Multi-product companies where customers only buy specific products | Cheapest and fastest, but requires a second report if another product later needs one |
Shared-infrastructure combined report | All products scoped together because they share the same underlying platform/infrastructure/team | Products built on common infrastructure with overlapping engineering teams | One audit covers more ground, but a control failure anywhere affects the whole report |
Multi-tenant segmented scope | Only the tenant-facing layer and shared control plane are scoped; tenant-specific customizations excluded | SaaS platforms with heavy per-customer configuration | Keeps scope stable even as individual tenants change, but requires very clear boundary documentation |
Ledgerlight, in Priya's case, went with the second option: a product-specific report covering only the core Ledgerlight platform, deliberately excluding a legacy reporting tool used by fewer than five customers and slated for deprecation. That single decision — documented in a one-page scope memo Priya circulated to sales, engineering, and the auditor — was what separated the $48,000 quote from the $95,000 one.
Subservice organizations: carve-out vs inclusive
Almost no service organization delivers its product entirely on its own infrastructure. You use a cloud provider, maybe an identity provider, maybe a payment processor, maybe a background-check vendor for hiring. Each of these is a subservice organization — a vendor whose own controls matter to the security of your system — and each one has to be explicitly classified in your system description using one of two methods.
The carve-out method excludes the subservice organization's controls from your report. You describe that the vendor performs certain functions (say, "physical and environmental security of data center infrastructure is managed by AWS"), but their controls aren't tested as part of your audit. Instead, your system description lists complementary subservice organization controls — the controls you're assuming the vendor has in place — and you typically point to that vendor's own SOC 2 or equivalent attestation as evidence you've validated that assumption through vendor due diligence.
The inclusive method brings the subservice organization's controls into your report. The auditor tests those controls directly, either by visiting the subservice organization or by relying on that vendor's own attestation as a sub-report folded into yours. This is far less common — it's operationally heavy for both parties — and it's typically reserved for situations where the subservice organization is small, doesn't have its own SOC 2, and is critical enough to your service that a carve-out with unverified CSOCs wouldn't satisfy customers.
Dimension | Carve-out method | Inclusive method |
|---|---|---|
Whose controls get tested | Only yours; vendor's controls assumed via CSOCs | Yours and the subservice organization's, together |
Typical use case | Vendor has its own current SOC 2/ISO 27001 (e.g., AWS, Google Cloud, Azure) | Vendor is small, critical, and has no independent attestation |
Auditor's work | Reviews vendor's own attestation report as evidence of CSOC operation | Directly tests vendor's controls or incorporates vendor's own sub-scope report |
Cost/complexity | Lower — leverages vendor's existing assurance | Higher — requires vendor cooperation, evidence, possibly a site visit |
Report language | Names the vendor, lists CSOCs, notes exclusion of vendor controls from testing | Vendor controls appear in the tested control set alongside your own |
Common pitfall | Assuming a vendor's controls without verifying their attestation is current and scoped correctly | Underestimating how much vendor cooperation and lead time inclusive testing requires |
Best for | Hyperscale cloud providers, established SaaS vendors with public attestations | Small, single-purpose vendors integral to the service, without independent assurance |
"Carve-out isn't a way to make a vendor's risk disappear — it's a way to formally document that you've checked their homework instead of grading it yourself. If you carve out a vendor and never actually pull their SOC 2 report to confirm the CSOCs you're relying on are real, you've created a paper boundary, not a security boundary." — Marcus Feld, CPA, Partner, Hollis & Feld Assurance Partners
Common subservice organization categories and how they're usually treated
Subservice category | Example | Typical treatment | Why |
|---|---|---|---|
Cloud infrastructure (IaaS) | AWS, Azure, Google Cloud | Carve-out | Hyperscalers maintain their own SOC 2/ISO 27001 reports and are too large to test directly |
Identity provider | Okta, Auth0, Azure AD | Carve-out | Typically has independent attestations; you retain responsibility for configuration |
Payment processor | Stripe, Adyen | Carve-out | PCI DSS/SOC 2 attestations already exist; you're relying on, not replicating, their controls |
Email/communications infrastructure | SendGrid, Twilio | Carve-out | Established vendors with their own assurance reports |
Monitoring/logging SaaS | Datadog, New Relic | Carve-out | Same rationale — established, independently attested |
Background-check vendor (HR use) | Checkr and similar | Often out of scope entirely | Rarely touches the in-scope system directly unless tied to access provisioning |
Small, single-purpose data vendor | A boutique fraud-scoring or enrichment API with no public attestation | Inclusive, or requires additional due diligence | No independent assurance exists to lean on, but function is critical to the service |
Managed service provider (outsourced IT/SOC) | A contracted MSSP running detection/response | Inclusive or heavily documented CSOC reliance | Directly operates security controls on your behalf |
The rule of thumb I give clients: if the vendor is large enough to have its own current, relevant attestation report, carve them out and build your CSOC list around it. If they're small, bespoke, or operate controls on your behalf without their own assurance program, budget time for an inclusive approach or find a different vendor before your audit window opens.
Evaluating a subservice organization's own attestation before you carve them out
Carving out a vendor is not a paperwork exercise you complete once and forget. Before you finalize the carve-out method for any subservice organization, pull their actual report and check it against your own scope — a surprising number of "we're carved out, they have a SOC 2" assumptions don't survive that check.
What to verify in the vendor's report | Why it matters |
|---|---|
Report is current (typically issued within the last 12 months) | An expired or stale report doesn't support a current-period CSOC assumption |
Report type matches your need (Type II, not just Type I) | A Type I only confirms design, not operating effectiveness — weaker assurance to lean on |
Trust Services Criteria in their report cover what you're relying on (e.g., Availability if you need their uptime commitments backed) | Their report might only cover Security, leaving your Availability assumption unverified |
Their system boundary actually includes the service you use | Large vendors sometimes scope only certain product lines — confirm the specific service you consume is in their boundary |
No qualified or adverse opinion, or exceptions relevant to your reliance | A qualified opinion on a control you're depending on undermines your own CSOC assumption |
Their own subservice organizations (your fourth parties) are appropriately handled | Carve-outs can nest — know what your vendor's vendor is doing too |
This is a five-minute review per vendor, and it's the single most commonly skipped step in subservice organization scoping. Auditors will ask for evidence that you performed this review — usually in the form of a vendor management or vendor risk management record — as part of testing your own CC9 risk-mitigation controls, so treat it as a standing part of onboarding any new subservice organization, not a one-time favor to the audit team.
CUECs and the scope handshake with your customers
Every SOC 2 scope decision has a mirror-image counterpart sitting with your customer: complementary user entity controls, the controls your customer has to operate for your controls to work as intended. If you've scoped access control at the application layer assuming customers manage their own user provisioning and de-provisioning, that assumption needs to show up explicitly as a CUEC in your report — otherwise a customer's security reviewer will read your scope as incomplete rather than as a shared-responsibility model. Scope and CUECs are two sides of the same boundary line: everything on your side gets tested, everything you're pushing to the customer's side gets documented as their responsibility. Skipping that documentation is one of the most common reasons a technically correct scope still reads as evasive to an outside reviewer.
Visualizing the scope decision
flowchart TD
A[Start: What are we attesting to?] --> B[Security in scope — always required]
B --> C{Do contracts/SLAs commit\nto uptime or DR terms?}
C -->|Yes| D[Add Availability]
C -->|No| E[Skip Availability]
D --> F{Does the system process\ntransactions/calculations\ncustomers rely on?}
E --> F
F -->|Yes| G[Add Processing Integrity]
F -->|No| H[Skip Processing Integrity]
G --> I{Do contracts include\nconfidentiality/NDA terms\nbeyond normal privacy?}
H --> I
I -->|Yes| J[Add Confidentiality]
I -->|No| K[Skip Confidentiality]
J --> L{Is processing personal\ninformation the core\nproduct function?}
K --> L
L -->|Yes| M[Add Privacy]
L -->|No| N[Skip Privacy]
M --> O[Draw system boundary:\ninfrastructure, software,\npeople, procedures, data]
N --> O
O --> P[Classify every subservice\norganization: carve-out\nor inclusive]
P --> Q[Draft scope memo +\nsystem description]
Q --> R[Sign-off: sales, engineering,\nsecurity, auditor]
R --> S[Scope locked — readiness begins]How scope decisions affect cost and timeline
Scope is the single biggest lever on your engagement's price tag and duration — bigger than the auditor you choose, bigger than how mature your controls already are. Every additional system, environment, or subservice organization added to scope multiplies the audit evidence that has to be produced, reviewed, and tested.
Scope decision | Effect on readiness timeline | Effect on audit fee | Effect on ongoing maintenance |
|---|---|---|---|
Narrow, single-product scope | Baseline (fastest) | Baseline (lowest) | Lower — fewer systems to keep evidenced year-round |
Adding a second product line | +4–8 weeks | +15–30% | Doubles evidence collection for shared controls |
Adding Availability criteria | +2–3 weeks | +10–15% | Ongoing capacity/DR testing evidence required |
Adding Processing Integrity | +3–5 weeks | +15–25% | Transaction-level evidence sampling each period |
Adding Privacy criteria | +4–6 weeks | +20–30% | Consent/retention/disposal evidence, ongoing |
Including staging/dev with real data | +2–4 weeks | +10–20% | Additional environment to monitor and evidence |
Inclusive subservice organization (no existing attestation) | +6–10 weeks | +20–40% | Vendor cooperation required every audit period |
Every extra supporting function pulled in "to be safe" | +2–4 weeks each | +5–15% each | Compounding — each one needs its own control owner and evidence |
This is the table I'd put directly in front of a sales leader who wants to scope broad "just in case." Every row is a real cost, not a hypothetical one — and none of it buys goodwill with a customer who never asked about the systems you added.
Over-scoping: the hidden costs
Over-scoping feels safe. It rarely is. The most common over-scoping mistake is treating scope as a hedge against uncertainty — "let's include it in case a customer asks" — instead of a decision grounded in actual commitments. The result is a program that spends real budget and real engineering hours producing evidence for systems that add no customer-facing value, while slowing down the parts of the audit that actually matter.
I've seen over-scoped companies end up with control owners for systems nobody remembers assigning, audit evidence collection processes running against a defunct internal tool, and readiness timelines that stretch because the extra scope surfaced genuine gaps in systems the company would rather have retired than remediated. Over-scoping doesn't just cost money up front — it becomes a recurring tax on every subsequent audit period, because whatever you scope in year one, you're on the hook to keep evidencing every year after.
Under-scoping: the hidden costs
Under-scoping feels efficient right up until a customer's security team notices the gap. The most damaging version of this mistake is excluding a system or subservice organization that a sophisticated customer's due diligence process specifically expects to see — a payment sub-processor, a data-hosting region, a support tool with standing access to customer data. When that gap surfaces during a customer's own review of your report (and it does surface — enterprise security teams read system descriptions line by line), the conversation shifts from "show me your report" to "why did you leave this out," which is a much harder conversation to win.
Under-scoping also creates a specific structural risk: if you narrow scope to make the numbers look good and a security incident later occurs in an excluded-but-related system, your SOC 2 report doesn't protect you from that conversation with customers — because the report never claimed to cover that system in the first place. A narrow scope has to be defensible, not just convenient.
Risk category | Over-scoping | Under-scoping |
|---|---|---|
Cost | Higher audit fees, more control owners, more evidence collection | Lower short-term cost, but rework cost if gaps are found later |
Timeline | Longer readiness period, more remediation surface area | Faster initial timeline, but re-scoping delays if challenged |
Customer trust | Rarely damages trust, but doesn't build extra trust either | Can severely damage trust if a customer finds the gap themselves |
Report credibility | High — broad and defensible | Risk of appearing evasive if key systems are missing |
Ongoing maintenance burden | High — every scoped system needs evidence every period | Lower, but growing systems eventually force a re-scope anyway |
Sales cycle impact | Rarely blocks deals, may slow initial timeline | Can stall or kill deals when gaps surface in due diligence |
Internal morale/ownership | Diffuse ownership, "why do we track this" fatigue | Clear ownership, but gaps create firefighting later |
Choosing a scoping philosophy: minimal-defensible vs. future-proofed
Once you've internalized the over- and under-scoping risks, most companies land on one of two workable philosophies. Neither is universally "correct" — the right one depends on your growth trajectory and how often you expect the boundary to need revisiting.
Philosophy | How it works | Best fit | Watch-out |
|---|---|---|---|
Minimal-defensible scope | Scope strictly to current customer commitments and current architecture; revisit annually | Early-stage companies, single-product businesses, tight budgets | Requires discipline to actually revisit scope as the business changes, not just at renewal |
Future-proofed scope | Scope slightly ahead of current commitments to cover a near-term roadmap item (e.g., a product launching in the current audit period) | Companies with a near-certain, dated roadmap item that will need coverage within the year | Easy to justify padding that isn't actually near-term — apply only to committed, dated plans |
I generally steer first-time SOC 2 companies toward minimal-defensible scope. It's cheaper, it's easier to explain to an auditor and a customer, and — counterintuitively — it's also easier to expand later than an over-broad scope is to contract. Shrinking scope on a renewal report requires explaining to existing report readers why something that used to be covered no longer is, which is a harder conversation than adding something new with a clear rationale.
When to revisit scope: the growth triggers worth planning for
Even a well-drawn minimal-defensible scope has a shelf life. The companies that avoid painful mid-cycle re-scoping are the ones that treat certain business events as automatic scope-review triggers, rather than waiting for a customer or an auditor to raise the question first. A new product launch that shares infrastructure with the in-scope system is one trigger — even if the product itself won't be sold to the same customers, shared infrastructure means a control failure in the new product can affect the old one. A material contract change is another: if a new enterprise customer negotiates an uptime SLA your existing contracts never included, that's the moment Availability moves from "consider it" to "add it," not the moment the next audit period happens to start. Acquiring a company, replacing a subservice organization, or moving a meaningful volume of customer data into a new region are the other three triggers I flag most often for clients.
The discipline here isn't complicated — it's a standing five-minute agenda item at the quarterly compliance or security review: "has anything happened this quarter that should change our scope memo?" Companies that skip this check tend to discover the answer was yes only when a customer's security team asks a question the current report doesn't answer, which is the most expensive way to find out.
Scope creep: what causes it, and how to prevent it
Scope creep in a SOC 2 program rarely arrives as one dramatic decision — it arrives as a dozen small "sure, let's just add that" moments during readiness work, usually driven by well-intentioned people trying to be thorough. A new engineering lead points out a service that "probably should be in there." A customer asks a one-off question about a system, and the instinct is to fold it into scope rather than answer the question directly. A merger or acquisition brings in a new codebase nobody has formally decided whether to scope.
Common scope creep trigger | Why it happens | Prevention |
|---|---|---|
"Just to be thorough" additions during readiness | Team wants to appear comprehensive to the auditor | Anchor every addition to a specific customer commitment or contractual term, not a feeling |
Ad hoc customer questions about excluded systems | Fear of looking evasive in a single email thread | Answer directly with CUEC/vendor-attestation context instead of re-scoping mid-engagement |
New products/features shipped mid-audit-period | Product moves faster than the compliance program | Set a scope review checkpoint tied to the product roadmap, not just the annual audit |
M&A bringing in new systems/teams | Nobody owns the "does this need to be in scope" decision post-acquisition | Add scope review as a standing step in the M&A integration checklist |
Auditor requests expanded testing after finding a gap | A control gap in an in-scope system traces back to an out-of-scope dependency | Fix the dependency relationship (carve-out/CUEC) rather than silently expanding scope |
Internal stakeholders conflating "important system" with "in-scope system" | Confusing business criticality with SOC 2 relevance | Reinforce that scope tracks customer commitments and the TSC, not internal importance |
"Scope creep is death by a thousand reasonable-sounding requests. The fix isn't saying no to all of them — it's having a one-page scope memo everyone agreed to at the start, so every new request has to argue against a written decision instead of against a vague memory of a meeting." — Yuki Tanaka, Director of Compliance, Ledgerlight, Inc.
Documenting and locking scope: who signs off
Scope isn't real until it's written down and agreed to by the people who can each independently break it — sales (who sets customer expectations), engineering (who knows what actually touches what), security/compliance (who owns the audit relationship), and the auditor (who has to be willing to stand behind the boundary). A short RACI at the start saves weeks of relitigating later.
Scope activity | Sales/GTM | Engineering | Security/Compliance lead | Auditor (CPA firm) |
|---|---|---|---|---|
Propose TSC based on customer commitments | Consulted | Informed | Responsible | Consulted |
Draft system boundary (products/environments/teams) | Informed | Responsible | Accountable | Consulted |
Classify subservice organizations | Informed | Consulted | Responsible | Accountable (must agree treatment is defensible) |
Approve final scope memo | Consulted | Consulted | Accountable | Consulted |
Confirm scope aligns with engagement letter | Informed | Informed | Responsible | Accountable |
Communicate scope to customers/prospects | Responsible | Informed | Consulted | Informed |
What belongs in the scope memo itself
The scope memo I ask every client to produce before their engagement letter is signed isn't a formal audit document — it's an internal reference that keeps sales, engineering, security, and the auditor aligned, and it becomes the source document for the actual system description once readiness work begins.
Scope memo section | Contents |
|---|---|
Trust Services Criteria selected | Which of the five apply, with a one-line rationale tied to a contract, SLA, or product function for each |
System boundary | Named products, environments, and infrastructure in scope; explicit list of what's excluded and why |
Data in scope | Data types/classifications flowing through the boundary, mapped to the criteria they justify |
Teams in scope | Which functions (engineering, SRE, support, security) operate or have access to in-scope systems |
Subservice organizations | Every vendor relied on, with carve-out or inclusive treatment and current attestation status |
CUECs anticipated | Draft list of what the report will expect customers to be responsible for |
Sign-off | Names and dates for sales, engineering, security/compliance, and auditor acknowledgment |
Review cadence | When the memo will next be revisited (tied to the annual readiness assessment or a defined roadmap trigger) |
A memo this short — typically two to three pages — is what turns scope from an implicit, half-remembered set of assumptions into something every stakeholder can point to when a question comes up mid-engagement or mid-sales-cycle.
What a scope statement actually reads like
Abstractions are easier to apply once you've seen the finished shape. A scope statement condensed from a memo like the one above, in the plain language it would actually appear in internally, reads something like this: "This engagement examines the Security, Availability, and Confidentiality criteria as applied to the Ledgerlight production platform, comprising the customer-facing web application, its supporting APIs, and the production AWS environment (us-east-1 and us-west-2 regions). In scope are the engineering, site reliability, customer support, and security functions that operate, maintain, or have administrative access to this environment. Excluded from scope are the corporate marketing website, the legacy reporting service (scheduled for deprecation in Q1), and all corporate/back-office systems that do not provision access to or process data within the production environment. AWS is treated as a subservice organization under the carve-out method; Ledgerlight relies on AWS's own SOC 2 Type II report for physical, environmental, and infrastructure-layer controls."
Notice what that paragraph does: it names the criteria, names the boundary in specific and falsifiable terms (specific regions, specific functions, specific exclusions with a reason), and states the subservice treatment plainly. Nothing in it is vague, and nothing in it requires a follow-up question to understand. That's the bar a scope statement should clear — not exhaustive detail, but zero ambiguity about what's covered and what isn't.
How scope shows up in the finished report
Every decision covered so far becomes visible, in plain language, inside Section III of your report — the system description — and in the auditor's opinion that follows it. The Trust Services Criteria you selected appear on the cover of the report itself. The system boundary appears as a narrative description of infrastructure, software, people, procedures, and data, typically alongside an architecture diagram. Subservice organizations appear by name, with an explicit statement of carve-out or inclusive treatment and the associated CSOCs. A customer's security reviewer will read all of it — which is exactly why scope has to be decided deliberately up front rather than reverse-engineered from whatever systems happened to be easiest to evidence.
Report section | What reflects your scope decisions |
|---|---|
Report cover/title | Which Trust Services Criteria were examined |
Management's assertion | The system boundary management is asserting controls over |
System description (Section III) | Infrastructure, software, people, procedures, data — the full boundary |
Subservice organization disclosures | Named vendors, carve-out or inclusive treatment, associated CSOCs |
CUEC disclosures | What the report assumes the customer is responsible for |
Tests of controls (Type II) | Only tests controls within the agreed scope — nothing more, nothing less |
Auditor's opinion | States whether controls were suitably designed/operating for the described scope — the opinion is only as strong as the scope it covers |
Case study one: Ledgerlight closes the deal on a defensible narrow scope
Back to Priya. After a week of pulling sales, engineering, and Marcus Feld's team into the same room, Ledgerlight's scope memo settled on three things: Security, Availability, and Confidentiality as the criteria (their SLA promised 99.9% uptime, and their contracts carried explicit confidentiality clauses around customer financial data — but they didn't collect consumer PII as a core function, so Privacy stayed out, and their product recorded expenses rather than processing payments directly, so Processing Integrity stayed out too). The system boundary covered the production Ledgerlight platform and its AWS environment, explicitly excluding the legacy reporting tool (five customers, scheduled for deprecation within two quarters) and the corporate marketing site. AWS itself was treated as a carve-out, backed by AWS's own published SOC 2 report as the CSOC evidence.
The engagement closed at $48,000 against a 4-month readiness runway, and the Type II report landed six weeks before the logistics customer's renewal deadline. When the customer's security team reviewed the report, they had exactly one follow-up question — about the excluded legacy tool — which Priya answered in a single email referencing the deprecation timeline already documented in the scope memo. The $1.2 million renewal closed on schedule. Ledgerlight's second-year audit, scoped identically, came in under budget because nothing about the boundary had to be re-litigated.
Case study two: Bramwell Health Analytics narrows a multi-product platform
Bramwell Health Analytics ran two products on shared infrastructure: a flagship analytics platform serving hospital systems, and an older internal reporting tool inherited from an acquisition three years earlier. CISO Renata Okafor's initial instinct, backed by a board eager for "a clean bill of health," was to scope the whole company. A scoping workshop with her audit firm changed that: the acquired reporting tool had no active enterprise customers, ran on separate infrastructure, and no current sales conversations referenced it.
Renata scoped Security, Availability, and Confidentiality around the flagship analytics platform only, formally excluding the legacy tool with a documented rationale (no customer data flow, scheduled for sunset). That decision alone saved an estimated $60,000 in audit fees and roughly four months of readiness work that would have gone into remediating a product Bramwell was actively trying to retire. The finished report gave hospital-system customers exactly the boundary they needed to evaluate, and Bramwell avoided spending remediation budget on a product with a shrinking user base.
Case study three: Coastline Data Systems pays for an under-scoped boundary
Coastline Data Systems, a data-processing platform for regional retailers, took the opposite path. Founder Devon Marsh scoped the SOC 2 narrowly around the core processing platform, excluding a smaller subsidiary service that handled loyalty-program data enrichment — reasoning that the subsidiary was "basically a side project" that hadn't come up in customer conversations. Six weeks after the Type II report was issued, a prospective enterprise customer's security team, running its own due diligence, discovered during a product demo that customer loyalty data flowed through the subsidiary's systems — systems the report never mentioned.
The $410,000 deal didn't die outright, but it stalled for five months while Coastline commissioned a scope amendment, brought the subsidiary in as an additional in-scope system, and produced a bridge letter covering the gap period. The re-scoping engagement cost an additional $35,000 — more than it would have cost to include the subsidiary from the start, once the original readiness work was already in motion. Devon's postmortem, shared candidly at a regional SaaS founders' meetup, became the story I now tell every client tempted to draw the boundary around what's convenient rather than what's actually connected to the data.
Case study | TSC selected | Boundary decision | Subservice treatment | Outcome |
|---|---|---|---|---|
Ledgerlight, Inc. | Security, Availability, Confidentiality | Core platform only; legacy tool and marketing site excluded | AWS carved out via published SOC 2 | $1.2M renewal closed on schedule; $48K audit fee |
Bramwell Health Analytics | Security, Availability, Confidentiality | Flagship analytics platform only; legacy acquired tool excluded | Cloud hosting carved out | ~$60K and 4 months saved vs. company-wide scope |
Coastline Data Systems | Security, Confidentiality | Core platform only; loyalty-data subsidiary initially excluded | Subsidiary later brought in-scope after gap found | $410K deal stalled 5 months; $35K re-scoping cost |
Every one of these companies made a reasoned decision. Two of them tied the boundary to an actual, documented connection between systems and data; the third tied it to a gut sense of what "counted." That's the entire difference between a scope that holds up under a customer's scrutiny and one that doesn't.
Sequencing scope against readiness
Scope isn't a standalone exercise — it's the input every other part of the program consumes. Lock scope before you run your readiness assessment, not during it. A readiness assessment tells you where your in-scope controls have gaps; if the boundary is still shifting while that work is underway, you're gap-testing a moving target, and every week spent assessing a system that later gets cut from scope is a week you won't get back.
Companies running both an ISMS and a SOC 2 program hit a version of this same decision twice, and it's worth aligning them where the two frameworks overlap. The discipline of drawing a defensible boundary — tying it to actual data flows and business commitments rather than convenience — is exactly the same discipline covered in defining the scope of an ISMS for organizations pursuing ISO 27001 certification. The two scope statements don't have to be identical (SOC 2 scope tracks customer commitments and Trust Services Criteria; ISO 27001 scope tracks the information security management system's boundary), but a company running both should compare them side by side and be able to explain any deliberate differences rather than discover them by accident.
For teams standing up scope for the first time, a SOC 2 Trust Services Criteria Mapping Template turns the TSC selection questions in this article into a working document, and a SOC 2 Control Matrix / RACI Template is the fastest way to formalize the sign-off table above with your own sales, engineering, and security stakeholders.
Where scope decisions land relative to the rest of the program's timeline matters as much as the decisions themselves — every downstream milestone assumes the boundary underneath it is stable.
Program milestone | Where scope fits |
|---|---|
Kickoff / auditor selection | Draft TSC and boundary hypothesis, get preliminary auditor input on feasibility |
Scope memo sign-off | Finalized before readiness work begins — the hard stop this article argues for |
Readiness assessment | Gap-tests only the systems and criteria the scope memo defines |
Remediation | Fixes gaps within the agreed boundary; new gaps outside it get logged, not silently added to scope |
Engagement letter with CPA firm | Formally documents the agreed scope as the basis for the examination |
Observation period (Type II) | Evidence collected strictly within the locked boundary |
Report issuance | System description reflects the scope memo, refined through readiness learnings |
Annual renewal | Scope memo revisited deliberately, not reconstructed from memory |
Scope as a business decision, not just an audit input
It's tempting to treat scope as a purely technical exercise — a boundary drawn by engineers and blessed by an auditor. The companies that get the most value out of SOC 2 treat it differently: as a product decision, made with the same rigor you'd apply to a pricing tier or a feature roadmap. A well-scoped report is a sales asset that answers exactly the questions your target customers are asking, at a cost structure that lets you renew the engagement every year without it becoming a line-item fight. A poorly-scoped report — whether bloated with irrelevant systems or missing something a sophisticated buyer expects — becomes a recurring source of friction in exactly the deals you're trying to accelerate.
"A year after our first audit, I stopped thinking of scope as something the auditor tells us. It's something we tell the auditor, backed by our own contracts and architecture. That shift — from being scoped to actively scoping — is what turned SOC 2 from a checkbox into something our sales team actually uses in calls." — Priya Nandakumar, VP of Compliance and Risk, Ledgerlight, Inc.
Treat your first scope memo as a living document, not a one-time exercise. Revisit it whenever you ship a product that changes your data flows, sign a customer whose contract adds a new commitment, or bring on a vendor that becomes load-bearing to your service. The companies that avoid both over-scoping and painful re-scoping mid-engagement are the ones that review their boundary on a cadence — typically alongside the annual readiness assessment — rather than waiting for a customer or an auditor to force the conversation.
Get scope right once, document it clearly, and revisit it deliberately, and SOC 2 stops being an annual scramble and starts being what it should be: a report that says exactly what you mean, to exactly the audience that needs to hear it.
If you're building your first scope memo or preparing to defend an existing one to a customer's security team, PentesterWorld's SOC 2 Readiness Checklist walks through the boundary and subservice-organization questions in this article in a working format, and our SOC 2 Gap Analysis Tool can help you stress-test whether your proposed scope actually lines up with the controls you already have in place before you sign an engagement letter.