Skip to main content
Control Institute
Category: Certification and Accreditation

Scope Statement

Also known as: Project Scope Statement, Scope Definition
Simply put

A scope statement is a document that clearly describes what a project or initiative includes and excludes, along with its objectives, deliverables, and boundaries. In a compliance context, it helps everyone involved understand exactly what work is covered and what falls outside the effort. It typically also captures assumptions, requirements, and constraints so that stakeholders share a common understanding.

Formal definition

A scope statement is a foundational document that defines the specific deliverables, objectives, and boundaries of a project or engagement, together with its assumptions, requirements, constraints, responsibilities, and acceptance criteria. It is generally developed with stakeholder input and updated as necessary over the life of the effort to reflect scoping decisions. In compliance work, such a document informs the boundaries of what is being assessed; note, however, that framework-specific boundary artifacts, such as the defined scope of an ISO/IEC 27001 ISMS or the system description and controls covered in a SOC 2 examination, are governed by their respective standards and are distinct from a general project scope statement.

Why it matters

In compliance programs, ambiguity about what is and is not covered is one of the most common sources of wasted effort, missed deadlines, and disputes between teams and their assessors. A scope statement addresses this by giving stakeholders a shared, documented understanding of the deliverables, objectives, and boundaries of the effort before substantive work begins. When everyone agrees on what falls inside the initiative, and, just as importantly, what falls outside it, teams can allocate resources accurately and avoid the scope creep that inflates timelines and budgets.

The distinction matters especially in audit and certification work, where the boundary of the effort drives the boundary of the outcome. It is important not to confuse a general project scope statement with the framework-specific boundary artifacts governed by their respective standards. A SOC 2 examination attests only to the system described and the controls and period covered, and an ISO/IEC 27001 certificate covers only the defined scope of the ISMS; neither speaks to anything outside those boundaries. A well-constructed project scope statement can help a program plan toward those framework-defined boundaries, but it does not itself substitute for the system description, Statement of Applicability, or other artifacts the standards require.

Because scope statements capture assumptions, requirements, and constraints alongside deliverables, they also create an accountable record of scoping decisions. As those decisions evolve over the life of an engagement, the document is updated to reflect them, which reduces the risk that stakeholders operate from divergent expectations about what the compliance effort will and will not deliver.

Who it's relevant to

Compliance and program managers
These practitioners rely on scope statements to define the deliverables, objectives, and boundaries of a compliance initiative and to secure shared stakeholder understanding before work begins. The document helps them plan resources, manage assumptions and constraints, and keep the effort aligned as scoping decisions change over time.
Auditors and assessors
For those conducting SOC 2 examinations or supporting ISO 27001 certification efforts, a clear project scope statement provides useful planning context, while recognizing that the assessment's actual boundaries are set by framework-specific artifacts such as the SOC 2 system description or the defined scope of the ISMS, which are governed by their respective standards rather than by a general scope document.
GRC teams and project stakeholders
Governance, risk, and compliance teams and their stakeholders use the scope statement as a common reference for what is included and excluded, helping avoid divergent expectations, scope creep, and disputes. It gives them a documented, accountable record of scoping decisions and the assumptions, requirements, and constraints behind them.

Inside Scope Statement

Boundary Definition
A description of the systems, services, products, locations, and organizational units covered by the assessment. For ISO 27001, this defines the boundaries and applicability of the ISMS; for SOC 2, it identifies the system being examined against the selected Trust Services Criteria.
In-Scope Systems and Services
An enumeration of the specific infrastructure, applications, data, and processes included in the engagement, which drives what the auditor examines and what the resulting report or certificate ultimately covers.
Out-of-Scope Exclusions
An explicit statement of what falls outside the assessment, clarifying the boundaries so that readers understand the limitations of the resulting report or certificate. A SOC 2 report attests only to the controls and period covered, and an ISO 27001 certificate covers only the defined ISMS scope.
Applicable Criteria or Requirements
For SOC 2, the Trust Services Criteria categories selected for the engagement, Security (the Common Criteria) is required, while Availability, Processing Integrity, Confidentiality, and Privacy are optional and chosen based on scope. For ISO 27001, the ISMS requirements in clauses 4 through 10 apply, with Annex A reference controls selected via the Statement of Applicability.
Locations and Organizational Units
Identification of the physical sites, business functions, and teams included, which is particularly relevant to defining the interfaces and dependencies of the ISMS in an ISO 27001 context.
Review Period or Point in Time
For SOC 2, whether the engagement is a Type I (suitability of design at a point in time) or Type II (design and operating effectiveness over a defined period, the length of which varies based on scoping decisions). This temporal element frames what the scope statement covers.

Common questions

Answers to the questions practitioners most commonly ask about Scope Statement.

Does a SOC 2 report and an ISO 27001 certificate use the same kind of scope statement?
No. While both frameworks define what is covered, they do so differently and are not interchangeable. A SOC 2 scope is expressed in the description of the system covered by the attestation examination, defining the services, controls, Trust Services Criteria categories selected, and the review period (for a Type II) or point in time (for a Type I). An ISO 27001 scope defines the boundaries of the Information Security Management System (ISMS) under clauses 4 through 10, including the organizational and technological boundaries and interfaces. Satisfying the scope requirements of one framework does not automatically satisfy the other, and the two scope statements should not be treated as equivalent.
If my scope statement is broad, does that mean the report or certificate guarantees my whole organization is secure?
No. The scope statement defines a boundary, not a guarantee. A SOC 2 report attests only to the controls and the period covered within the defined scope and does not guarantee freedom from breaches or cover systems outside that boundary. Similarly, an ISO 27001 certificate covers only the defined scope of the ISMS; activities, locations, or systems excluded from the scope are not addressed by the certification. A broader scope covers more, but it still attests only to what is stated within its boundaries and against the applicable criteria or requirements.
How do I decide what to include in a SOC 2 scope statement?
Scoping decisions are typically driven by the services relevant to your customers and the commitments you make to them. Security (the Common Criteria) is the only required Trust Services Criteria category; Availability, Processing Integrity, Confidentiality, and Privacy are optional and selected based on the nature of the service and stakeholder expectations. In most engagements, the scope also identifies the systems, infrastructure, and supporting processes relevant to those criteria, along with whether the examination is a Type I or Type II. Because these are scoping choices rather than fixed rules, the auditor and your stakeholders will influence the final boundaries.
How is the ISO 27001 scope statement documented and where does it fit in the ISMS?
The scope of the ISMS is a required output under the clause 4 requirements and is documented as part of establishing the management system. It defines the boundaries and applicability of the ISMS, considering internal and external issues, interested parties, and interfaces with other organizations or systems. The scope informs the risk assessment and the selection of Annex A reference controls, which are recorded in the Statement of Applicability. The certification issued by an accredited certification body references this defined scope, so precision here directly shapes what the certificate covers.
Can a scope statement be changed after the initial engagement or certification?
Yes, scope can typically evolve. For SOC 2, a subsequent examination can expand or narrow the scope, add Trust Services Criteria categories, or shift from a Type I to a Type II, depending on scoping decisions made for that engagement. For ISO 27001, the ISMS scope can be revised as the organization changes, though scope changes generally need to be reflected in the ISMS documentation and are reviewed by the certification body, often during surveillance or recertification activities. In both cases, the extent and process depend on the auditor or certification body and the applicable standard.
What are common mistakes to avoid when writing a scope statement?
A frequent issue is defining a scope that is too narrow or ambiguous to meet stakeholder expectations, which can leave important systems or services uncovered. Another is conflating the two frameworks by assuming a SOC 2 description and an ISO 27001 ISMS scope are the same document or that one can be reused for the other. It is also important not to overstate what the scope conveys, since a report or certificate attests only to what is within the stated boundaries and applicable criteria or requirements. Aligning the scope with your actual services, commitments, and risk assessment, and confirming it with your auditor or certification body, helps avoid these problems.

Common misconceptions

A broad scope statement means the report or certificate covers the entire organization and all its systems.
A scope statement typically defines specific boundaries, and both a SOC 2 report and an ISO 27001 certificate cover only the systems, services, and controls explicitly included. Anything outside the defined scope is not attested to or certified.
The scope statement for a SOC 2 engagement and an ISO 27001 certification can be treated interchangeably.
The two frameworks structure scope differently. SOC 2 scope centers on a defined system and the selected Trust Services Criteria under an attestation examination, while ISO 27001 scope defines the boundaries of a management system certified against clauses 4 through 10. Mapping between them is possible but partial, and one scope statement does not automatically satisfy the other.
A well-defined scope statement guarantees the organization is free from breaches within the covered systems.
A scope statement only frames what is examined. A SOC 2 report attests to the design and, for Type II, operating effectiveness of controls over the covered period and does not guarantee freedom from breaches; an ISO 27001 certificate similarly attests only to the defined ISMS and its conformance to requirements.

Best practices

Define scope boundaries explicitly, stating which systems, services, locations, and organizational units are included and which are excluded, so readers understand the limitations of the resulting report or certificate.
For SOC 2 engagements, document which Trust Services Criteria categories are selected, noting that Security (the Common Criteria) is required while Availability, Processing Integrity, Confidentiality, and Privacy are included based on scope.
For ISO 27001, align the scope statement with the ISMS requirements in clauses 4 through 10 and ensure the Statement of Applicability reflects the Annex A reference controls selected through risk assessment.
Clarify the temporal dimension of the scope, whether a SOC 2 examination is a point-in-time Type I or a Type II covering a defined review period whose length is set by scoping decisions.
Revisit and update the scope statement as systems, services, or organizational boundaries change, and confirm consistency between the scope and the controls actually examined.
Avoid overstating equivalence when maintaining both frameworks; document scope separately for each, recognizing that satisfying one framework's scope does not automatically satisfy the other.