Many SaaS teams start SOC 2 by collecting policy documents, access screenshots, vendor reports, and control evidence before they have defined what the audit is actually covering. That creates scope creep: evidence for systems that may not belong in the report, missing evidence for systems that do, and late changes when the auditor asks how the service boundary was chosen.
A faster approach is scope first, controls second. Define the product, environments, data flows, vendors, Trust Services Criteria, exclusions, and owners before building the evidence plan. Get the boundary right early and you avoid a lot of annoying evidence work, as long as it still reflects how the service actually operates and the auditor has reviewed it.
What SOC 2 scope means for a SaaS company
SOC 2 scope is the boundary of the system and services covered by the report. The AICPA describes a SOC 2 examination as addressing management’s description of the service organization’s system and the controls relevant to the selected Trust Services Criteria (AICPA & CIMA).
For a SaaS company, that system is usually not “the whole company,” it is the customer-facing service and the systems, people, processes, and third parties that store, process, transmit, protect, deploy, monitor, or grant access to that service.
A narrow first scope is defensible only when it matches the real operating model. Excluding a legacy product, demo environment, or internal tool may be reasonable; excluding a production database, identity provider, or deployment system that controls the scoped service usually needs a much stronger explanation.
Start with customer commitments and Trust Services Criteria
SOC 2 uses Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security’s Common Criteria are basically the baseline; additional categories should be added only where they are relevant to the service’s commitments and system requirements (AICPA & CIMA).
Use customer commitments and service behavior to choose criteria:
- Security: baseline for the report.
- Availability: consider when the service makes material commitments about uptime, resilience, or availability for operation and use.
- Confidentiality: consider when the service handles information designated as confidential by contract, policy, or service design.
- Processing Integrity: consider when customers rely on the service to process transactions, calculations, workflows, or outputs completely, validly, accurately, timely, and with authorization.
- Privacy: consider when the service collects, uses, retains, discloses, or disposes of personal information under privacy commitments. Do not treat this as legal advice; confirm with counsel and the auditor where needed.
Do not add criteria because they sound more mature. Each category expands the control and evidence questions the auditor may need to evaluate.
Map the SaaS system boundary
Once criteria are selected, map the architecture. The practical test is simple: if a component stores, processes, transmits, protects, deploys, monitors, or grants privileged access to the scoped SaaS service, treat it as a scoping candidate. Not just the app itself.
Inventory these areas:
- Customer-facing service: web application, mobile backend, tenant admin portal, customer console.
- APIs and integrations: public APIs, webhooks, customer integrations, internal APIs that process customer data.
- Production infrastructure: cloud accounts, clusters, serverless functions, load balancers, network controls, secrets management.
- Application services: core app services, workers, queues, schedulers, data pipelines.
- Data stores: relational databases, object storage, caches, search indexes, warehouses receiving scoped customer data.
- Identity and access: SSO, identity provider, privileged access management, admin consoles.
- CI/CD and deployment: source control, build systems, deployment pipelines, release approvals.
- Monitoring and response: logging, alerting, observability, incident tracking.
- Support and customer operations: ticketing, support consoles, customer-success tools that access customer data or privileged functions.
- People and processes: engineering, security, support, operations, incident response, change management, access reviews, vendor reviews.
The boundary should describe both technology and responsibility. An auditor will not only ask where the app runs; they will ask who can change it, who can access data, how incidents are handled, and which vendors the service depends on.
Decide what is in scope, out of scope, or dependent on data use
Avoid treating every connected system as automatically in scope. Also avoid excluding systems merely because they are inconvenient. Document the rationale and validate material exclusions with the auditor.
| Area | Starting position | What the decision depends on |
|---|---|---|
| Production environment | In scope | It delivers the scoped SaaS service and usually contains customer data, runtime infrastructure, and operational controls. |
| Production databases and object storage | In scope | Stores scoped customer data or service configuration. |
| Public APIs and webhooks | In scope | Processes or transmits customer data, or forms part of the contracted service. |
| Identity provider | Scoping candidate | Grants user or administrator access to the scoped service. |
| CI/CD and source control | Scoping candidate | Can change production code, infrastructure, or configuration. |
| Monitoring, logging, alerting | Scoping candidate | Supports security monitoring, incident response, availability commitments, or operational detection. |
| Support and admin tools | Depends | Include when they access customer data, perform privileged actions, or affect service delivery. |
| Staging, QA, demo | Depends | Include or control carefully if they contain real customer data, production-like credentials, privileged access paths, or can affect production. |
| Development environments | Depends | Consider code promotion, secrets exposure, access to customer data, and administrative paths into production. |
| Analytics and BI | Depends | Include when they receive customer data from the scoped service or support commitments in the report. |
| Legacy systems | Candidate for exclusion | May be excluded if they do not support the scoped service and do not process scoped customer data. |
| Internal corporate tools | Candidate for exclusion | May be excluded when unrelated to delivering or securing the scoped SaaS service. Retain rationale if they support approvals, access, incidents, or evidence. |
| Personal productivity tools | Usually peripheral | Consider only where used for customer data handling, security approvals, ticketing, or audit evidence. |
For each exclusion, write down four things: the system’s purpose, whether it touches scoped customer data, whether it can affect production, and who approved the exclusion for auditor review.
Classify vendors and subservice organizations
Most SaaS scopes depend on third parties: cloud providers, identity providers, CI/CD platforms, monitoring tools, payment processors, email providers, support tools, security tooling, and data warehouses.
Where a third party performs services relevant to the scoped system and criteria, the SOC 2 report needs to address that relationship. Under a carve-out approach, the provider’s controls are excluded from the examination; under an inclusive approach, relevant provider controls are included and tested, provider by provider where needed (Compass IT Compliance).
Classify vendors by what they do for the scoped service:
- hosts infrastructure or stores customer data
- controls user or administrator access
- deploys, builds, or changes production code
- monitors production systems or sends alerts
- supports customers or handles tickets
- processes payments, emails, files, logs, or personal data
- provides security controls relied on by the scoped service
Do not assume a vendor can always be carved out, and do not assume a vendor’s own SOC report resolves your responsibilities. Vendor treatment depends on reliance, control responsibility, available evidence, service commitments, and auditor judgment.
Account for Type 1 versus Type 2 before finalizing scope
A Type 1 SOC 2 examination evaluates controls as of a specified date. A Type 2 examination also evaluates operating effectiveness over a period (AICPA & CIMA).
That difference matters for scope. For Type 1, the immediate question is whether the system description and control design match the selected boundary at the examination date. For Type 2, the scope should be finalized and documented before collecting period evidence where practicable. More accurately, it should be finalized before the evidence period starts unless there is a good reason not to, because later additions can complicate access reviews, change records, incident evidence, vendor monitoring, and control operation.
Do not pick Type 1 or Type 2 solely as a scoping shortcut. The report type should reflect customer requirements, readiness, and auditor guidance.
Document the final SOC 2 scope
Your final scope package should be clear enough for a readiness call and specific enough to become an evidence plan. It should include:
- scoped product or service name
- short system description
- selected Trust Services Criteria
- customer commitments that influenced the criteria
- included environments
- included infrastructure, applications, APIs, databases, and storage
- included teams and control owners
- included vendors and proposed carve-out or inclusive treatment
- explicit exclusions and rationale
- evidence sources by system or process
- open questions for auditor review
SaaS SOC 2 scoping worksheet
Use this as editorial guidance, not as an AICPA template or auditor-approved form.
| Field | What to document |
|---|---|
| Product/service being audited | Name the SaaS product, module, API, or customer-facing service. |
| Customer commitments | Security, uptime, confidentiality, processing, privacy, support, or contractual commitments relevant to the report. |
| Trust Services Criteria selected | Security baseline plus any additional criteria and the reason each was selected. |
| Data types processed | Customer content, account data, logs, files, payment metadata, personal information, confidential data, or other scoped data. |
| Production environments | Cloud accounts, regions, clusters, networks, serverless services, production apps. |
| Non-production environments and rationale | Staging, QA, demo, development; note customer data use, production access paths, and exclusion rationale. |
| APIs and integrations | Public APIs, webhooks, internal APIs, customer integrations, third-party connectors. |
| Databases and storage | Primary databases, replicas, object storage, caches, search indexes, backups, warehouses receiving scoped data. |
| Cloud infrastructure | Hosting provider, network controls, infrastructure-as-code, secrets management, cloud admin roles. |
| Identity/access systems | SSO, identity provider, MFA, privileged access, service accounts, admin consoles. |
| CI/CD and deployment tools | Source control, build pipeline, artifact registry, deployment platform, release approval workflow. |
| Logging/monitoring/alerting | Observability platform, SIEM or alerting tools, incident channels, on-call process. |
| Support/ticketing/customer-success tools | Tools that access customer data, manage incidents, or perform privileged support actions. |
| Teams and control owners | Engineering, security, operations, support, customer success, executive owner, vendor owner. |
| Vendors/subservice organizations | Vendor name, function, data handled, dependency level, available assurance reports. |
| Carve-out or inclusive treatment | Proposed treatment and auditor question for each relevant vendor. |
| Exclusions and rationale | Systems excluded, reason, data-flow basis, risk rationale, owner approval. |
| Evidence sources | Access reviews, change tickets, deployment records, vendor reviews, incident records, monitoring alerts, security testing. |
| Auditor questions | Items needing confirmation before evidence collection begins. |
Example narrow first-audit scope package
The following example is illustrative. It must be adapted to the company’s actual data flows, service commitments, vendor dependencies, and auditor review.
Sample scope statement
The scope of the SOC 2 examination covers the Security criterion for the Acme Analytics SaaS platform, including the production web application, customer API, production cloud infrastructure, application services, primary customer database, object storage used by the platform, identity and administrative access systems, CI/CD pipeline used to deploy production changes, monitoring and incident response tooling, and support processes that access customer accounts. The scope excludes the legacy on-premises reporting product, internal finance systems, sandbox demo tenant, and development workstations, because these do not process production customer data for the Acme Analytics SaaS platform or deliver the scoped service. These exclusions are subject to confirmation based on actual data flows, access paths, and auditor review. Relevant cloud hosting, identity, monitoring, support, and payment-processing providers will be documented as vendor dependencies, with carve-out or inclusive treatment confirmed during audit planning.
| Component | Example | In scope / out of scope / depends | Rationale | Evidence source or auditor question |
|---|---|---|---|---|
| Customer-facing SaaS app | Production web app | In scope | Delivers the scoped service to customers. | System description, architecture diagram, deployment records. |
| Customer API | REST API and webhooks | In scope | Processes customer data and supports integrations. | API inventory, access controls, logging, change evidence. |
| Production cloud infrastructure | Production cloud account and network | In scope | Hosts the scoped service. | Cloud access review, configuration evidence, monitoring records. |
| Primary database | Customer tenant database | In scope | Stores scoped customer data. | Database access review, backup evidence, encryption/configuration evidence. |
| Object storage | Customer file storage | In scope | Stores customer-uploaded files. | Bucket permissions, logging, retention settings. |
| Identity provider | SSO and admin access | Depends / likely in scope | Controls access to the scoped service and admin consoles. | Access policy, MFA settings, user review; confirm vendor treatment. |
| CI/CD | Source control and deployment pipeline | Depends / likely in scope | Can change production code and infrastructure. | Change tickets, pull request approvals, deployment logs. |
| Monitoring and alerting | Observability and incident alerts | Depends | Supports detection and response for scoped systems. | Alert rules, incident records, on-call evidence. |
| Support tool | Ticketing with customer account lookup | Depends | Include if support can view customer data or perform privileged actions. | Role review, ticket samples, support access policy. |
| Payment processor | Subscription billing provider | Depends | Relevant if it processes payment or customer account data tied to the scoped service. | Vendor review, data-flow note, auditor treatment question. |
| Staging | Staging environment | Depends | Decision turns on real customer data, production credentials, and access path to production. | Data-use confirmation, access review, masking evidence. |
| Demo tenant | Sales sandbox | Out of scope if isolated | Candidate for exclusion if it has no production customer data or production access path. | Exclusion rationale, environment diagram. |
| Legacy product | Retired reporting app | Out of scope if separate | Candidate for exclusion if it does not support the scoped service or process scoped data. | Data-flow confirmation, customer/service mapping. |
| Internal finance | Accounting system | Out of scope if unrelated | Not part of delivering or securing the scoped SaaS service. | Exclusion rationale; confirm no scoped customer data dependency. |
After scoping, turn the boundary into evidence work
Once the boundary is documented, map evidence to the scoped systems, criteria, vendors, and owners. Access reviews should cover the relevant identity and admin paths. Change management evidence should cover the production deployment flow. Vendor reviews should focus on providers that support the scoped system. Incident response, monitoring, and security testing should align with the service components in scope; confirm with the auditor that security testing covers the relevant externally exposed and in-scope components.
Plan evidence around the documented boundary, while retaining enough information to justify exclusions or support controls that depend on excluded services.
Ciphrix helps teams turn the scoped boundary into operational evidence workflows by mapping SaaS systems, data flows, vendors, control owners, Trust Services Criteria, and evidence sources into a readiness plan. The goal is fewer repeated compliance tasks and clearer audit preparation, not a larger document project.
A good SOC 2 scope is narrow enough to manage and complete enough to defend. Start with the worksheet, turn it into a scope statement, and review unresolved boundary decisions with your auditor before collecting evidence at scale, where possible.