Menu
SOC 2 scope determination is the process of defining exactly what your audit covers: the service being examined, the systems and data that support it, the people and procedures that operate it, the third parties it depends on, the Trust Services Criteria included, and whether the report is Type 1 or Type 2. For any first-time SOC 2, Security is mandatory, and that mandatory criterion includes 56 control objectives that every audit must evaluate, forming the core of the engagement and driving approximately 80-90% of the audit effort in typical engagements, according to Linford & Co’s overview of SOC 2 audit scope.
If you’re a startup CTO reading this, you’re probably here because a customer, prospect, or procurement team asked for a SOC 2 report and now you need to decide what “getting SOC 2” means for your company. Teams often make expensive mistakes at this juncture. They either scope too broadly and burn months of engineering time on controls nobody asked for, or scope too narrowly and end up with a report that doesn’t satisfy enterprise buyers.
My advice is simple. Treat soc 2 scope determination as a business decision with audit consequences, not a compliance formality. Your scope determines cost, timeline, evidence burden, vendor review effort, and whether your report helps close deals.
Defining Your SOC 2 Scope The First Critical Step
The first decision in SOC 2 is not which software to buy or which auditor to hire. It’s defining the audited service and drawing a boundary around it. That boundary tells the auditor what to test and tells your buyers what they can rely on.
Most first-time teams start in the wrong place. They start by asking which controls they need. That’s backward. First define the service. If your company sells one core SaaS platform, scope that. If you sell a platform plus managed services plus internal analytics consulting, don’t throw everything into the first audit just because it exists.
Start with the service customers actually buy
For SOC 2, scope should follow the offering that matters in deals. Usually that means:
- Your production application used by customers
- The infrastructure that runs it, such as AWS, Azure, or GCP
- The support processes that affect security and reliability
- The people who administer, deploy, or support the service
- The data flows tied to the service
That sounds obvious. It isn’t. I routinely see teams include staging environments nobody outside the company touches, old internal tools that don’t support the core platform, or side products with no current enterprise demand. Every extra component adds evidence requests, walkthroughs, policy mapping, and testing.
Practical rule: If removing a system from the environment would not materially change the service commitment you make to customers, challenge whether it belongs in scope.
What matters for someone pursuing SOC 2
Scope forms the basis for everything else. Your auditor will build the examination around it. Your control matrix will map to it. Your evidence collection process will reflect it. If the scope is sloppy, the audit will be sloppy.
A clean first scope should be narrow enough to finish, but broad enough to be credible. The best first SOC 2 reports are rarely the biggest. They’re the most defensible.
Aligning Stakeholders and Inventorying Key Assets
SOC 2 scoping usually breaks before the auditor ever shows up. Sales promises one thing, engineering supports another, legal uses broader contract language, and compliance tries to write controls around all of it. If those groups aren’t aligned, your scope will drift in the middle of the project.
Get the right people in one room early. For a first SOC 2, that usually means the CTO, head of engineering, security lead, someone from customer-facing operations or support, legal or finance if they own contracting, and a sales leader who knows what buyers are asking for.
What that alignment meeting should settle
Don’t leave the meeting with vague agreement. Leave with written decisions:
-
The named service in scope
Use the exact product or service wording you want in the report description. -
The customer commitments attached to it
Review MSAs, security addenda, SLAs, privacy language, and security questionnaires. -
The environments that support that service
Production almost always matters. Staging and development depend on how tightly they connect to production risk. -
The teams with operational responsibility
Include people who deploy code, manage access, respond to incidents, approve changes, and support users.
Build an asset inventory that auditors can actually use
A useful SOC 2 inventory isn’t just a spreadsheet of servers. It should show how the service works end to end. At minimum, document:
- Infrastructure assets such as cloud accounts, storage, compute, CI/CD tools, endpoint management, and identity systems
- Software assets including customer-facing apps, internal admin panels, background jobs, and logging platforms
- Data assets like customer data, credentials, logs, backups, and regulated information if applicable
- Key procedures including onboarding, offboarding, access review, vulnerability handling, incident response, backup management, and change control
- Critical vendors such as AWS, GitHub, Okta, Stripe, Snowflake, HubSpot, Zendesk, or Datadog if they materially support the service
A short walkthrough can help your team sanity-check that inventory before you lock scope.
Sales language often expands scope more than architecture does. Read your customer commitments before you finalize anything.
Why this matters for SOC 2
A bad inventory creates mid-audit surprises. Those surprises force rescoping, extra evidence collection, and awkward conversations with auditors about whether omitted systems are material. A good inventory does the opposite. It gives you a source of truth for control ownership, evidence requests, and vendor review.
Defining Your System and Organizational Boundaries
Once you know the service and have an inventory, you need to define the system boundary in a way an auditor can test and a customer can understand. Here, the AICPA framing is useful. Your system consists of infrastructure, software, data, procedures, and personnel. If your scope ignores one of those components, it’s probably incomplete.
Infrastructure and software
Start with production. For most startups, that means your cloud environment, networking configuration, application stack, storage, logging, and deployment pipeline. If engineers can push code that affects customers, the deployment process belongs in scope. If support staff use an internal admin console to modify customer accounts or data, that tool probably belongs in scope too.
Exclude systems only when you can clearly explain why they don’t support the in-scope service. For example, your marketing website, recruiting ATS, or finance ERP may be outside the system boundary if they don’t affect the service commitments under examination.
Data and procedures
Data is where many first-time audits go sideways. Don’t just list databases. Identify what data types move through the service, where they are stored, how access is restricted, what gets logged, and how backups and retention work.
Procedures matter just as much as infrastructure. Your SOC 2 report won’t just test whether the service exists. It will evaluate whether your organization operates controls around that service. That includes user access provisioning, change approvals, security incident handling, risk assessment, and vendor oversight.
Personnel and real ownership
Personnel means actual humans with responsibilities over the system. Name roles, not just departments. Auditors want to know who approves production access, who reviews logs, who triages incidents, and who owns policy maintenance.
A practical way to define boundary ownership is to map each in-scope component to one accountable role:
| In-scope component | Typical owner |
|---|---|
| Production cloud environment | Platform or DevOps lead |
| Customer application | Engineering manager or CTO |
| Identity and access platform | Security lead or IT admin |
| Incident response process | Security lead or engineering on-call owner |
| Customer support admin tooling | Support operations or engineering |
If nobody clearly owns part of the scoped system, your audit will expose that weakness fast.
Why this matters for someone pursuing SOC 2
This boundary is what shows up in your report narrative and drives auditor testing. If it’s too vague, your auditor will keep probing. If it’s too broad, your team will drown in evidence. A defensible boundary lets you answer buyer questions clearly: this is the service audited, these are the supporting systems, and these are the controls we operate around it.
Choosing and Mapping the Right Trust Services Criteria
Founders often treat the Trust Services Criteria like a menu where more is better. It isn’t. Adding criteria that don’t match your service is one of the easiest ways to waste budget and slow the audit down.
The correct approach is to select criteria based on what your service does, what customers rely on, where your risk sits, and what your team can support. That aligns with the four-factor analysis described by Safetica’s guidance on SOC 2 scope and purpose: client needs, business model alignment, risk assessment, and resource feasibility. That same guidance warns that including irrelevant TSCs can increase audit duration and cost by 20-40% without corresponding value.
The criteria you should actually consider
Security is mandatory. The others are optional, and they should earn their place.
| Business Model | Common TSCs to Add | Rationale |
|---|---|---|
| SaaS application | Availability | Add it when uptime, resilience, or service continuity is part of the customer expectation |
| FinTech processor | Processing Integrity, Confidentiality | Add them when your service processes transactions, calculations, or sensitive financial information |
| HealthTech platform | Confidentiality, Privacy | Add them when the service stores or handles personal information and customers expect controls around protected data handling |
| Data storage provider | Availability, Confidentiality | Add them when customers depend on access to stored data and restricted disclosure |
| Internal workflow software with limited external commitments | Security only, sometimes Availability | Keep scope tight if customers mainly want baseline assurance and your contractual promises are limited |
If you need a deeper breakdown of the categories themselves, this summary of SOC 2 Trust Services Criteria is a useful reference.
My recommendation for most first audits
For many startup SaaS companies, Security plus Availability is the most practical first target. It speaks to what enterprise buyers usually care about: can you protect the system, and can they rely on it being available? If you don’t make specific commitments around transactional correctness, don’t add Processing Integrity just because it sounds impressive.
Be especially careful with Privacy. If your service handles personal information, you may eventually want it in scope. But that doesn’t mean it belongs in your very first audit if your customers aren’t demanding it yet and your privacy program isn’t ready to withstand formal testing.
Why this matters for SOC 2
The TSCs define what promises your report makes. The wrong set creates one of two bad outcomes. Either the report is too thin to satisfy buyers, or it becomes bloated and expensive without helping sales. Good soc 2 scope determination means matching the report to customer requirements, not to your ambition.
Managing Third-Party Vendors in Your SOC 2 Scope
Your product depends on vendors. Cloud hosting, identity, monitoring, payment processing, support systems, source control, data platforms. The audit won’t ignore them just because you don’t directly manage their staff.
The hard decision is how you address those subservice organizations in scope. The default is usually to carve out the vendor’s controls and rely on their own assurance reports, while documenting your oversight of that dependency. That’s normal. But default doesn’t mean automatically correct.
According to Sensiba’s discussion of SOC 2 scope definition, auditor exceptions appear in 15-25% of reports due to insufficient management of third-party subservice organizations. The same source notes that while carve-out is the default, some benchmarks show carved-in reports can achieve 15% higher customer satisfaction scores because they provide fuller coverage.
When carve-out is fine
Use carve-out when the vendor is mature, their controls are standard, and your buyers are comfortable reviewing that vendor’s own report if needed. That often works for major cloud providers and established infrastructure vendors.
But carve-out still requires work from you. You need vendor due diligence, contract review, monitoring, and evidence that you understand how the dependency affects your controls.
When you should consider stronger coverage
If a vendor handles highly sensitive workflows or sits directly in your service promise, a bare carve-out can make your report less useful. Think of a payment processor in a FinTech stack, a data enrichment vendor with broad customer-data access, or a third-party service integral to your product’s core function.
In those cases, you may need one of these approaches:
- Rely on the vendor’s own assurance and map your oversight controls clearly
- Implement compensating controls around the dependency
- Reconsider whether the service architecture creates too much audit risk
- Work with an auditor who understands vendor-heavy environments
For teams comparing firms on this issue, this guide to SOC 2 vendor management requirements is useful because it frames vendor oversight as a scoping and evidence problem, not just a procurement checklist.
A vendor outside your org chart can still sit squarely inside your audit risk.
Why this matters for someone pursuing SOC 2
Third-party scoping is one of the clearest signals of maturity. Buyers want to know whether you understand your supply chain risk. Auditors want to see whether you can explain dependencies, review vendor assurance, and operate controls around gaps. If you mishandle this, the report may technically exist but still leave procurement unconvinced.
How Scoping Decisions Directly Impact Audit Cost and Timeline
SOC 2 scope determines two things founders care about immediately: how long this will take and how much it will cost. Every extra environment, every extra criterion, and every unresolved vendor dependency pushes those numbers in the wrong direction.
The biggest fork in the road is Type 1 versus Type 2. A Type 1 looks at design effectiveness at a point in time. A Type 2 evaluates operational effectiveness over a period of at least 6 months. According to Schellman’s guidance on scoping a SOC 2 audit, Type 2 reports have made up over 85% of issued reports since 2014, and they can lead to 2-3x higher auditor fees than a Type 1, while delivering significantly greater customer trust.
The trade-off most startups should accept
If you need something quickly to start procurement conversations, a focused Type 1 can make sense. If your target buyers are larger enterprises, many will push for Type 2 because they want evidence that controls operate consistently, not just that they existed on one date.
That’s why I tell CTOs to decide based on sales timing, not compliance ego. If a Type 1 gets you into the conversation now and you’re building toward Type 2 next, that can be rational. If you already know your pipeline depends on sustained assurance, skip the half step.
Where scope blows up budget
The fastest way to overspend is to pile on unnecessary complexity:
- Extra TSCs that don’t map to customer commitments
- Internal systems that don’t materially support the audited service
- Weak vendor oversight that forces compensating control work
- Ambiguous ownership that slows evidence collection
If you’re budgeting the broader program, not just auditor fees, this breakdown of the cost of a SOC 2 audit is worth reviewing because it helps frame the hidden costs around remediation, tooling, and internal time.
Why this matters for SOC 2
Your report only has value if you can get it on a timeline that supports deals and at a cost your team can absorb. Scoping is your primary lever. Get it right, and the audit becomes manageable. Get it wrong, and compliance starts dictating your engineering roadmap.
From Scoping to Success Your Audit Readiness Blueprint
A first SOC 2 goes well when the scope is deliberate. Define the service clearly. Inventory the assets and owners behind it. Draw a boundary around the actual system, not the whole company. Add only the Trust Services Criteria that match customer expectations. Treat vendors as part of your control story, not someone else’s problem.
If you’re building the broader readiness plan, it helps to borrow discipline from adjacent audit work too. This guide on how to prepare for your first financial audit is useful because the underlying lesson is the same: clear ownership, clean documentation, and early evidence preparation prevent chaos later. That’s exactly why soc 2 scope determination is the foundation of SOC 2 audit readiness. It sets the audit boundary, shapes the evidence plan, and determines whether the final report helps your company close business instead of just checking a box.