Scoping a SOC2 Audit in 2026

For technology companies, cloud providers, software-as-a-service platforms, managed service providers, data processors, and other service organizations, customers increasingly want evidence that sensitive systems and information are protected by effective controls.

A SOC 2 examination can help provide that assurance. However, a successful SOC 2 engagement begins long before an independent CPA issues a report. One of the most important early decisions is defining the correct scope: which services, systems, data, locations, people, vendors, and Trust Services Criteria should be included.

If the scope is too narrow, the final report may not answer the questions customers actually ask during security reviews or procurement. If the scope is too broad, the organization may spend unnecessary time and money documenting, testing, and remediating controls that are not relevant to the services being evaluated.

What Is a SOC 2 Examination?

SOC 2 is part of the American Institute of Certified Public Accountants (AICPA) System and Organization Controls reporting framework. A SOC 2 examination addresses controls at a service organization relevant to one or more of the following Trust Services Criteria categories:

• Security
• Availability
• Processing integrity
• Confidentiality
• Privacy

A SOC 2 report is often requested by customers, enterprise procurement teams, business partners, risk managers, and security reviewers that need information about how a service organization protects systems and information used to provide its products or services.

SOC 2 is not a cybersecurity certification and does not guarantee that an organization will never experience a security incident. Instead, it is an independent attestation report addressing whether defined controls have been suitably designed and, for a Type 2 report, operated effectively throughout the specified review period.

SOC 2 Type 1 vs. Type 2: What Is the Difference?

Organizations frequently begin their SOC 2 planning by deciding whether they need a Type 1 or Type 2 report.

SOC 2 Type 1

A SOC 2 Type 1 report addresses the description of the service organization’s system and whether the controls were suitably designed as of a specified date. It may be useful for organizations that have recently implemented controls and need an initial report before they have a longer operating history.

SOC 2 Type 2

A SOC 2 Type 2 report addresses the description of the system, whether the controls were suitably designed, and whether the controls operated effectively over a specified period. Customers often prefer a Type 2 report because it provides evidence about control operation over time rather than only at one point in time.

Whether an organization begins with Type 1 or proceeds directly toward Type 2 depends on customer expectations, contractual obligations, readiness, timeline, budget, and the maturity of its control environment.

SOC 1 vs. SOC 2: Why the Difference Matters

SOC 1 and SOC 2 reports are designed for different purposes. They should not be treated as sequential levels in which an organization completes SOC 1 before advancing to SOC 2.

A SOC 1 examination addresses controls at a service organization that are likely to be relevant to user entities’ internal control over financial reporting. It is commonly relevant where a service provider performs activities that could affect a customer’s financial statements, such as payroll processing, claims processing, transaction processing, or certain financial administration services.

A SOC 2 examination addresses controls relevant to security, availability, processing integrity, confidentiality, or privacy. It is commonly relevant for organizations that provide software, cloud infrastructure, hosting, managed services, data processing, analytics, or technology-enabled business services.

Some service organizations may need both reports because they provide services affecting financial reporting while also handling sensitive systems or information. The appropriate report type should be selected based on customer needs, contractual requirements, risk, and the nature of the service provided.

Why SOC 2 Scope Matters So Much

The scope of a SOC 2 examination defines what the report covers. That scope influences the controls that must be documented, implemented, tested, monitored, and described to customers.

A properly defined scope can help an organization:

• Address the security and compliance questions customers actually ask
• Avoid including unrelated systems or business operations unnecessarily
• Reduce surprises during audit fieldwork
• Align control testing with contractual and regulatory commitments
• Support more efficient customer due diligence and security reviews
• Create a repeatable foundation for future reporting periods

Scope decisions should not be driven only by the desire to reduce the initial audit effort. A report that excludes a customer-facing service, important hosting environment, material subprocessors, or relevant data handling process may deliver limited practical value.

The Five Trust Services Criteria Categories Explained

The AICPA Trust Services Criteria provide the framework used in SOC 2 examinations. The relevance of each category depends on the organization’s services, commitments, system requirements, customer expectations, and risks.

Security

Security addresses whether systems and information are protected against unauthorized access, unauthorized disclosure, and damage that could compromise the organization’s ability to meet its objectives.

Security is central to a SOC 2 examination and may involve controls relating to:

• Logical access management and authentication
• User provisioning and access reviews
• Security monitoring and incident response
• Risk assessment
• Change management
• Vendor and subservice organization oversight
• Physical and environmental protections, where relevant

Availability

Availability addresses whether the system is available for operation and use as committed or agreed. This category may be relevant when customers depend on an application, platform, infrastructure environment, or managed service being accessible and resilient.

Availability controls may relate to:

• Business continuity and disaster recovery planning
• Backup processes and restoration testing
• Capacity and performance monitoring
• Service availability monitoring
• Incident management and communications
• Recovery objectives and customer service commitments

Processing Integrity

Processing integrity addresses whether system processing is complete, valid, accurate, timely, and authorized in accordance with the organization’s objectives.

This category may be important for organizations that perform transactions, calculations, workflows, data transformations, reporting, billing, payment processing, or other functions where customers rely on accurate system output.

Confidentiality

Confidentiality addresses whether information designated as confidential is protected as committed or agreed. This may include proprietary business information, customer data, intellectual property, contracts, financial records, or other nonpublic information.

Controls supporting confidentiality may involve encryption, access restrictions, secure transmission, data retention practices, information classification, and secure disposal.

Privacy

Privacy addresses the collection, use, retention, disclosure, and disposal of personal information in accordance with the organization’s commitments and applicable criteria.

Privacy may be relevant when a service processes personal information about customers, users, employees, patients, students, consumers, or other individuals. Privacy scope decisions should be aligned with the service organization’s actual data practices, notices, contractual responsibilities, and applicable legal requirements.

How to Choose the Right Trust Services Criteria for Your SOC 2 Scope

Not every SOC 2 examination must include every Trust Services Criteria category. The correct scope should reflect what the organization provides, what customers depend on, and what commitments have been made.

When selecting relevant categories, ask:

• What services are customers buying from us?
• Which systems support those services?
• What data do we receive, store, process, transmit, or dispose of?
• What availability, security, confidentiality, processing, or privacy commitments have we made?
• What questions appear repeatedly in customer security questionnaires?
• Which risks could materially affect customers if controls failed?
• Which categories are required by contracts, procurement processes, or market expectations?

For example, a hosted software platform that stores customer confidential data and commits to service uptime may reasonably include Security, Availability, and Confidentiality. A service that processes personal information may need to evaluate whether Privacy is also relevant. A platform that performs important customer calculations or transactions may need to consider Processing Integrity.

What Should Be Included in SOC 2 Scope?

Selecting Trust Services Criteria is only one part of scoping. The organization must also identify the system boundaries that support the services described in the report.

A SOC 2 scope assessment may need to consider:

• Products and services: The specific customer-facing services covered by the report
• Applications: Production platforms, administrative applications, authentication tools, monitoring tools, and supporting software
• Infrastructure: Cloud environments, servers, databases, networks, endpoints, and hosting arrangements
• Data: Customer information, personal information, confidential data, logs, backups, and retained records
• People: Employees, contractors, administrators, developers, support staff, and management involved in delivering the service
• Processes: Access control, change management, incident response, vendor management, risk management, backup, recovery, and monitoring activities
• Locations: Offices, data centers, remote work environments, or physical facilities relevant to the service
• Subservice organizations: Cloud providers, hosting providers, payment vendors, support vendors, data processors, and other third parties supporting the system

A useful scope should reflect how the service is actually delivered, rather than describing only the parts of the environment that are easiest to document.

Common SOC 2 Scoping Mistakes

Incorrect scope decisions can create delays, unnecessary remediation work, customer dissatisfaction, or a report that does not provide sufficient assurance.

Choosing Scope Only Based on Audit Cost

Keeping scope manageable is important, but excluding systems or criteria that customers genuinely require may result in a report that cannot support sales, renewals, or vendor-security reviews.

Including Every System in the Company

A broad scope is not automatically a better scope. Systems unrelated to the covered service may create additional testing requirements without improving the report’s relevance to customers.

Forgetting Subservice Organizations

Many service organizations rely on cloud infrastructure, data hosting, customer support platforms, monitoring providers, identity tools, payment processors, or other vendors. The role of relevant third parties should be evaluated during scoping.

Failing to Match Customer Commitments

If contracts or sales materials include commitments about security, uptime, data handling, encryption, backup, recovery, or privacy, those commitments should be considered carefully when defining the report scope.

Confusing SOC 1 With an Easier First Step Toward SOC 2

SOC 1 and SOC 2 address different user needs. Selecting one report before the other simply because it appears easier can waste resources if it does not address what customers or stakeholders actually require.

Treating SOC 2 as a One-Time Exercise

A Type 2 report addresses controls over a specified review period. Organizations need ongoing control operation, evidence collection, monitoring, training, vendor oversight, risk review, and remediation processes rather than a short-term effort focused only on completing an examination.

The Role of Compliance and Audit Leaders in SOC 2 Scoping

Compliance, security, risk, and internal audit professionals play an important role in preparing for a SOC 2 examination. However, they cannot define an effective scope in isolation. Scoping requires input from senior leadership, product owners, technology teams, legal teams, sales leaders, customer-success teams, and operations personnel.

Compliance and audit leaders commonly help by:

• Gathering customer, contractual, and regulatory requirements
• Identifying the services and system components that may belong in scope
• Mapping risks to appropriate control activities
• Evaluating which Trust Services Criteria categories are relevant
• Coordinating readiness assessments and remediation plans
• Preparing documentation and evidence collection processes
• Working with independent CPA firms on engagement planning
• Helping management understand scope, cost, timelines, and customer impact

Why Executive Involvement Is Essential

SOC 2 scope decisions can affect sales, customer trust, engineering priorities, vendor relationships, operational processes, and future compliance costs. As a result, executive leadership should be involved early rather than treating the engagement as a project owned only by compliance or information technology.

Executives should help answer questions such as:

• Which products and customer segments are strategically most important?
• What security and reliability commitments are being made in sales and contracts?
• Which enterprise customers require a SOC 2 report or specific criteria?
• Are new products, acquisitions, hosting environments, or data practices likely to affect future scope?
• What budget and internal resources are available for readiness work and ongoing control operation?

A scope that matches both current services and near-term business strategy can reduce the need for avoidable rework as the organization grows.

How a SOC 2 Readiness Assessment Helps

Before beginning a formal SOC 2 examination, many organizations conduct a readiness assessment. A readiness assessment is not the same as a SOC 2 report. Instead, it is a preparation process designed to identify gaps before formal testing begins.

A readiness assessment may help an organization:

• Confirm which services and criteria should be included in scope
• Identify missing or incomplete policies and procedures
• Review whether controls are operating consistently
• Improve evidence collection practices
• Identify vendor-management or access-control weaknesses
• Resolve gaps before the Type 2 review period begins
• Develop a more realistic audit timeline and budget

For a Type 2 report, controls generally need to operate effectively throughout the specified review period. Identifying and addressing control gaps before that period can reduce the risk of exceptions appearing in the final report.

A Practical SOC 2 Scoping Process

Organizations preparing for a SOC 2 examination can use the following process to define a practical and customer-relevant scope:

1. Identify business objectives. Clarify why the organization needs a SOC 2 report, which customers require it, and what business opportunities depend on it.
2. Define the covered service. Specify the products, platforms, or services the report is intended to address.
3. Map the service architecture. Identify applications, infrastructure, data stores, integrations, vendors, locations, and operational teams supporting that service.
4. Review customer commitments. Examine contracts, service-level commitments, privacy notices, security questionnaires, and sales representations.
5. Select relevant criteria. Determine which Trust Services Criteria categories are relevant to the service and customer expectations.
6. Identify controls and evidence. Map applicable risks and criteria to policies, processes, technical safeguards, monitoring, approvals, and documentation.
7. Perform a readiness assessment. Identify control gaps, missing evidence, and operational improvements needed before formal examination.
8. Confirm scope with the CPA firm. Work with the independent service auditor to align expectations, boundaries, timing, and reporting approach.
9. Prepare for ongoing operation. Establish processes that allow controls to operate consistently and evidence to be maintained throughout the reporting period.

SOC 2 Scope Checklist for Service Organizations

Before beginning a SOC 2 engagement, consider whether you can clearly answer the following questions:

• Which service or services will be covered by the report?
• Which customers or contractual requirements are driving the need for SOC 2?
• Which Trust Services Criteria categories are relevant and why?
• Which applications, infrastructure, databases, networks, and cloud platforms support the service?
• What categories of customer or personal data are handled?
• Which employees, contractors, and departments support in-scope operations?
• Which third-party vendors or subservice organizations are relevant?
• What security, availability, confidentiality, processing, or privacy commitments have been made?
• Are controls documented and operating consistently?
• Is evidence available to demonstrate control operation?
• Should a readiness assessment be completed before the formal reporting period?
• Does leadership agree that the proposed scope supports business and customer needs?

Key Insights

• SOC 2 is an independent attestation report addressing controls relevant to security, availability, processing integrity, confidentiality, or privacy.
• A SOC 2 Type 1 report addresses control design as of a specified date, while a Type 2 report also addresses operating effectiveness over a specified period.
• SOC 1 is not a preliminary or simpler version of SOC 2; it addresses controls relevant to user entities’ internal control over financial reporting.
• The appropriate SOC 2 scope should be based on services, systems, data, customer commitments, risk, and business objectives.
• Not every SOC 2 report needs to include every Trust Services Criteria category.
• An overly narrow scope may fail to meet customer needs, while an overly broad scope may increase cost and complexity unnecessarily.
• Compliance and audit leaders should work with executives, product teams, technology teams, legal teams, and customers when shaping scope.
• A readiness assessment can help identify control gaps before formal Type 2 testing begins.

Frequently Asked Questions

What is a SOC 2 report?

A SOC 2 report is an independent CPA attestation report addressing controls at a service organization relevant to security, availability, processing integrity, confidentiality, or privacy. Customers and business partners may request it when evaluating risks connected with using a service provider.

What is the difference between SOC 2 Type 1 and Type 2?

A SOC 2 Type 1 report addresses the description of a service organization’s system and control design as of a specified date. A SOC 2 Type 2 report additionally addresses whether controls operated effectively over a defined period.

Is SOC 1 required before SOC 2?

No. SOC 1 and SOC 2 reports address different objectives. SOC 1 focuses on controls relevant to user entities’ internal control over financial reporting, while SOC 2 focuses on controls relevant to security, availability, processing integrity, confidentiality, or privacy.

Does a SOC 2 report need to cover all five Trust Services Criteria categories?

No. The appropriate categories depend on the service organization’s system, services, customer commitments, risks, and reporting needs. The selected scope should provide relevant assurance without including unnecessary areas.

Why is SOC 2 scope important?

Scope determines the services, systems, data, personnel, vendors, processes, and criteria covered by the examination. A report with poorly defined scope may be more expensive than necessary or may not provide the information customers need.

What is a SOC 2 readiness assessment?

A readiness assessment is a preparation process used to identify possible gaps in scope, controls, documentation, and evidence before the formal SOC 2 examination begins. It can help an organization prepare more effectively for a Type 1 or Type 2 engagement.

Who should be involved in defining SOC 2 scope?

SOC 2 scoping commonly requires involvement from compliance, security, risk, information technology, engineering, product, legal, operations, sales, customer-success, and executive leadership teams, along with an independent CPA firm performing the examination.