Category: SOC Reporting

Boundaries of the System

Also known as: System Boundaries, System Scope

Simply put

The boundaries of the system describe exactly which parts of an organization's services, infrastructure, people, and processes are covered by a SOC 2 examination. Defining these boundaries makes clear what the resulting report does and does not address. Anything outside the stated boundaries is not evaluated by the auditor.

Formal definition

In a SOC 2 examination performed under the AICPA's SSAE 18 standard, the boundaries of the system delineate the components in scope for evaluation against the applicable Trust Services Criteria, typically encompassing the infrastructure, software, people, procedures, and data used to provide the services covered by the engagement. The boundaries are established through scoping decisions and are described in the system description, framing the population of controls the service auditor assesses for suitability of design (Type I) and, where applicable, operating effectiveness over the review period (Type II). Because the report attests only to the controls and period within the defined boundaries, components, services, or subservice organizations excluded from those boundaries are outside the scope of the auditor's opinion; the specific treatment of subservice organizations (for example, inclusive versus carve-out methods) depends on scoping decisions for the particular engagement.

Why it matters

The boundaries of the system determine what a SOC 2 report actually covers, and by extension what it does not. A reader who assumes a report speaks to an organization's entire operating environment may draw unwarranted conclusions if only a single product line or a subset of infrastructure was in scope. Because the auditor's opinion extends only to the controls and the period within the defined boundaries, precisely scoped boundaries are what allow customers, prospects, and their own auditors to interpret the report correctly rather than reading assurance into areas that were never evaluated.

For the service organization, boundary decisions shape both the effort required and the usefulness of the resulting report. Boundaries that are drawn too narrowly may fail to cover the services customers most care about, prompting follow-up questions or bridge requests; boundaries drawn too broadly can expand the population of controls under examination and increase the burden of demonstrating suitability of design and, in a Type II, operating effectiveness over the review period. The treatment of subservice organizations is a common source of confusion here, since whether a dependency is presented under an inclusive or carve-out approach affects what falls inside the auditor's opinion, and that choice depends on scoping decisions for the particular engagement.

It is worth emphasizing what boundaries do not do: a SOC 2 report attests only to the controls and period within the stated scope and does not guarantee that no incidents occurred, nor does it evaluate anything outside those boundaries. Clear boundary definitions protect all parties by preventing the report from being read as broader assurance than it provides.

Who it's relevant to

Compliance and GRC Managers

They lead scoping decisions that define what falls inside the boundaries, balancing customer expectations against the effort of demonstrating control design and operating effectiveness. Clear boundaries help them produce a report that answers the questions stakeholders are actually asking without expanding the examination unnecessarily.

Service Auditors

The defined boundaries frame the population of controls a CPA firm evaluates against the applicable Trust Services Criteria and set the limits of the opinion. Auditors rely on the system description to ensure the report clearly conveys what was and was not assessed, including how subservice organizations are treated.

Customers and Their Auditors

Readers of a SOC 2 report use the stated boundaries to understand exactly which services and components received assurance and which did not. This prevents misreading a scoped report as covering an organization's entire environment and informs follow-up due diligence on anything excluded.

Security Engineers and Control Owners

They implement and maintain the controls within the in-scope infrastructure, software, and processes. Understanding where the boundaries fall helps them focus evidence-gathering and control operation on the components the auditor will actually examine over the review period.

Inside Boundaries of the System

System Description Scope

The delineation of the specific services, infrastructure, software, people, procedures, and data that make up the system under examination. In a SOC 2 engagement, the boundaries define exactly what the report covers and, by extension, what falls outside the CPA firm's attestation.

Infrastructure and Software Components

The in-scope hardware, networks, virtualization, cloud environments, and applications supporting the service being examined. Components not identified within the boundaries are typically excluded from the auditor's evaluation of control design and, in a Type II, operating effectiveness.

People and Procedures

The personnel, roles, and operational processes that interact with the system. Boundaries clarify which teams and workflows are within scope, which can vary considerably depending on how the service organization defines the service.

Data Flows and Handling

The categories of data processed, transmitted, and stored within the system, along with the points at which data enters and leaves the defined environment. Data crossing outside the stated boundary is generally treated as out of scope.

Subservice Organizations and Boundary Treatment

Third-party providers whose controls affect the system. Depending on scoping decisions, these are typically addressed using either the inclusive method (their controls are described and examined) or the carve-out method (their controls are excluded from the description), which materially affects where the boundary sits.

Complementary User Entity Controls

Controls that the service organization assumes its customers will implement for the overall control objectives to be met. These sit at the edge of the system boundary and clarify responsibilities that fall to the user entity rather than the service organization.

Common questions

Answers to the questions practitioners most commonly ask about Boundaries of the System.

Does defining the boundaries of the system mean my entire company is covered by the SOC 2 report?

No. The boundaries of the system describe only the specific service, infrastructure, software, people, data, and processes included in the examination. A SOC 2 report attests only to the controls within the defined system boundary and over the period covered; portions of your organization outside that boundary are not addressed, and the report does not guarantee freedom from breaches even within scope.

Are the boundaries of the system in SOC 2 the same as the ISMS scope in ISO 27001?

They serve a similar purpose but are not equivalent. In SOC 2, the boundaries of the system frame what the CPA firm examines against the applicable Trust Services Criteria in the attestation. In ISO 27001, the scope of the ISMS defines what the accredited certification body certifies against the clause 4-10 requirements. Because the two frameworks differ in structure and outcome, defining one boundary does not automatically define or satisfy the other; mapping between them is possible but partial.

What elements are typically included when describing the boundaries of the system?

In most engagements, the system description addresses the infrastructure, software, people, procedures, and data that support the service being examined. The exact composition depends on the service offered and the scoping decisions made with the service auditor, so the boundary should reflect what is relevant to the applicable Trust Services Criteria for that engagement.

How do subservice organizations affect the boundaries of the system?

Services provided by subservice organizations are often addressed through either the inclusive method, which brings the subservice organization's relevant controls inside the boundary and description, or the carve-out method, which excludes them from the description while noting the complementary controls expected of them. The choice affects what falls inside the boundary and is typically determined during scoping based on the reliance placed on those providers.

How should we decide which Trust Services Criteria categories to include within the boundaries?

Security, the Common Criteria, is required in every SOC 2 examination. Availability, Processing Integrity, Confidentiality, and Privacy are optional and selected based on the nature of the service and commitments made to users. The boundary should be defined so that the included system components align with the criteria categories chosen for the engagement.

Can the boundaries of the system change between a Type I and a Type II examination?

The boundary is a scoping decision and can be adjusted between engagements. A Type I assesses the suitability of design of controls at a point in time, while a Type II assesses design and operating effectiveness over a defined review period whose length is set by scoping decisions. If the service or its supporting components change, the system description and its boundaries should be updated to reflect what is actually examined in each report.

Common misconceptions

The boundaries of the system automatically cover an organization's entire IT environment.

The boundaries cover only the specific service, components, people, and data defined in the system description. A SOC 2 report attests only to the controls and system within those stated boundaries and over the period covered; anything outside the defined scope is not evaluated.

Defining system boundaries for SOC 2 is the same exercise as defining the ISMS scope for ISO 27001.

They are related but distinct. A SOC 2 system description delineates the boundaries of the system examined under the AICPA SSAE 18 attestation against the applicable Trust Services Criteria, while ISO 27001 defines the scope of the information security management system per clauses 4 through 10. Satisfying one scoping exercise does not automatically satisfy the other, and mapping between them is at best partial.

Once subservice organizations are involved, their controls are always part of the system boundary.

Whether a subservice organization sits inside or outside the boundary depends on scoping decisions. Under the carve-out method the provider's controls are typically excluded from the description, whereas the inclusive method brings them inside the examined boundary. The chosen approach determines where the boundary is drawn.

Best practices

Document the boundaries explicitly in the system description, identifying the in-scope infrastructure, software, people, procedures, and data so that readers understand precisely what the report does and does not cover.

Decide and state clearly whether subservice organizations are handled using the inclusive or carve-out method, since this choice directly shapes where the system boundary lies.

Identify complementary user entity controls at the boundary so that responsibilities assumed to fall on customers are transparent rather than implied.

Align the boundaries with the applicable Trust Services Criteria in scope, recognizing that Security (the Common Criteria) is required while Availability, Processing Integrity, Confidentiality, and Privacy are included only if selected.

Revisit boundary definitions when the service, its components, or its data flows change, and reconfirm scope with the CPA firm before each examination period.

Communicate the limitations of the boundary to stakeholders, noting that the report attests only to the controls and period covered within those boundaries and does not guarantee freedom from breaches outside them.