Blog > SOC 2 Compliance Journey > Identifying the Scope of SOC 2 (Part 3)

Identifying the Scope of SOC 2 (Part 3)

Author

Rohith Sanam

Chief of Staff

Reading time

10 minutes

Introduction

Building on our previous discussions from Part 1: Business case for SOC 2 and Part 2: Choosing the right Trust Service Criteria, this guide focuses on the next crucial step. Defining the scope of SOC 2 to ensure your compliance efforts are both focused and effective.

The scope of your SOC 2 compliance journey determines what areas of your organization will be assessed and reported on. Getting this step right ensures your efforts are targeted, meaningful, and aligned with both your organizational goals and customers expectations.

Let’s break down the key components and expand on their significanc

Scoping Considerations

Rule of Thumb: When defining your SOC 2 scope, include all systems, vendors, and applications that store, process, or impact customer data security. The goal is to align your compliance efforts with real business risks while maintaining efficiency.

Customer-facing
systems

Internal systems &
Enterprise applications

Third-party services

Development &
testing environments

Process & resources

Customer-Facing Systems

These are the systems directly accessed by customers or involved in handling their data. Their security posture directly impacts customer trust and compliance obligations.
Include:

Primary SaaS platform / customer portal → The main application where customers interact and store data.
Public APIs and web interfaces → Any exposed endpoints that process customer requests.
Data storage systems (databases, object storage) → SQL/NoSQL databases, cloud object storage (e.g., AWS S3, Google Cloud Storage).
Production hosting infrastructure → Cloud platforms (AWS, Azure, GCP) or on-premises servers that host customer data.

Example Risk: A misconfigured API endpoint can expose sensitive customer data to unauthorized access.

Internal Systems and Enterprise Applications

These systems support internal operations but may impact SOC 2 compliance if they interact with customer data or production systems.

Include:

Employee access management tools (Okta, Active Directory) → Control access to production systems.

Example Risk: An overprivileged internal user in the CRM system could access customer PII without proper authorization.

Third-Party Services

Your vendors can introduce security risks, so their compliance posture affects yours. Any third party that processes, stores, or transmits customer data should be evaluated.

Include:

Cloud service providers (AWS, Azure, GCP) → Hosting and storage providers that hold customer data.
Email & communication platforms (Twilio, Slack) → If they process customer PII or security alerts.

Example Risk: A third-party email provider suffers a data breach, exposing customer invoices containing sensitive financial details.

Development and Testing Environments

Even non-production environments can impact compliance if they interact with sensitive data or have access paths to production.

Include:

Staging & pre-production environments → If they mirror production and contain real customer data.
CI/CD pipelines (GitHub Actions, Jenkins, GitLab CI/CD) → Automate code deployments and need strict access controls.
Infrastructure as Code (Terraform, CloudFormation) → Defines cloud resources and security settings.

Example Risk: A misconfigured CI/CD pipeline accidentally deploys sensitive customer data to a publicly accessible test environment.

Processes and Resources

Security isn’t just about systems, it’s also about how your people and workflows interact with those systems.

Include:

Change management processes → How software updates and security patches are deployed (e.g., ITIL, Agile).
Incident response & monitoring (SOC, SIEM tools like Splunk, Datadog) → How security incidents are detected and managed.
Internal teams and contractors → Employees, third-party developers, and security teams who access in-scope systems.

Example Risk: A contractor without proper security training gains temporary access to production but doesn’t follow access revocation policies.