Why Scope Definition Is Critical
Scope definition is the most consequential decision in an ISO 20000 program. The scope determines the audit surface area, implementation complexity, certification cost, and what the resulting certificate can demonstrate to clients and regulators. An overly broad scope will exhaust implementation resources and delay certification. An overly narrow scope will limit the commercial and regulatory value of certification. Organizations frequently revisit scope definition multiple times during implementation, discovering that their initial scope definition was either unrealistic or left important services uncovered.
What the Scope Must Define
ISO 20000-1:2018 Clause 4.3 requires the organization to determine the scope of the SMS. The scope must explicitly define:
The IT services provided that are managed within the SMS scope. Services are distinguishable from service components by the presence of a customer and an SLA. If it is not visible to a customer and does not have an agreed service level, it is likely a service component, not a service.
The service components (supporting infrastructure, processes, tools) that the SMS manages in order to deliver the in-scope services. Examples: data center operations, network infrastructure, security infrastructure, support service delivery channels.
The customers whose service requirements must be met within the scope. Customers may be internal (other departments), external (paying clients), or mixed. The scope statement must identify which customer populations are covered.
The organizational units and geographic locations involved in delivering or managing the in-scope services. For example: "All service delivery centers in Jakarta, Surabaya, and Bandung" or "The infrastructure team in the central IT organization."
Any services, geographic locations, or organizational units explicitly excluded from scope, with the justification for each exclusion. Auditors will test that excluded services are genuinely excluded and not being managed within the SMS in practice.
| KEY CONCEPT | The scope boundary is absolute. Everything inside must be fully SMS-managed; everything outside is excluded. There is no partial compliance within scope. If a service is in scope, all its service components, all its customers, and all its suppliers must be managed per ISO 20000 practices. |
The Scope Statement as a Required Document
The scope statement is a formal documented output of the SMS. It is typically 1-2 pages and is referenced in the service management plan and the certification certificate. The scope statement must be approved by top management and must be reviewed during the management review process. The scope statement will appear on the ISO 20000 certificate and become part of the organization's public compliance record, so it must be accurate and defensible.
Strategic Scope Considerations
Organizations typically face a scope size trade-off: larger scope means more implementation effort and higher certification cost, but greater commercial value; narrower scope means faster certification and lower cost, but limited applicability to the organization's full service offering.
Narrow scope (single service line or single customer/contract): certification can often be achieved within 6-9 months with lower implementation effort. However, the certificate covers only a subset of the organization's services, limiting its commercial value. Narrow scope is common in organizations that have not previously pursued ISO 20000, or that serve a specific client with an ISO 20000 compliance mandate.
Broad scope (all services, all customers, all locations): certification typically requires 12-18 months and higher overall cost, but the resulting certificate demonstrates SMS maturity across the full organization. Broad scope is valuable in organizations seeking to demonstrate enterprise-wide service management maturity to multiple clients or regulators.
Phased scope approach: some organizations certify a defined scope first, then expand the scope in subsequent certification cycles. This approach balances speed to market with eventual comprehensive coverage. For example: "Certify core infrastructure services in Year 1, add cloud services in Year 2, add service desk in Year 3."
Services versus Service Components
A critical scoping distinction is between a service (has a customer, has an SLA, is visible at the service portfolio level) and a service component (supporting infrastructure or capability, no direct customer, no independent SLA). Incorrectly classifying infrastructure components as services is a common scoping error that inflates scope and increases implementation complexity.
Example: "Managed hosting services" is a service--there is a customer (internal or external), there is an SLA, there is a service portfolio entry. The data center, physical infrastructure, operating system patches, and backup systems that support managed hosting are service components, not services.
The distinction matters because services must have full Clause 8 practice coverage (incident management, problem management, SLA monitoring, etc.), while service components are supported by those practices but do not require independent practice infrastructure.
In-Scope Customers and Suppliers
The scope must identify which customers the SMS is responsible to. "Internal customers only," "specific named external clients only," and "all customers across the organization" are each valid scope definitions, but they must be explicit.
Customer requirement flows are part of scope: if a customer's requirements cannot be accommodated within the SMS design, that is a scoping decision to address either by modifying the SMS or by excluding the customer from scope.
Suppliers whose services contribute to in-scope services must be managed through supplier relationship management practices. If a supplier provides a critical service component (e.g., a managed security services provider managing security infrastructure), that supplier relationship is in scope for supplier management practices.
Geographic and Organizational Boundaries
Multi-location organizations must decide: Is the SMS scope global? Regional? A single location? Clause 4.3 requires explicit definition. "All locations" is a valid scope; "Jakarta and Surabaya only, Bandung excluded" is a valid scope; "all locations except outsourced operations" is a valid scope. What is not acceptable is vague scope ("most locations" or "where applicable").
When part of the organization is excluded, the justification must be documented. Common justifications: "Outsourced services are managed by the supplier under separate contractual SMS requirements" or "Secondary data center is not yet integrated into primary service management architecture."
Scope Definition Process
The scope definition process typically involves: interviews with the customer account management function to identify key service offerings; interviews with service delivery and operations leadership to understand what services are actually being managed vs what is still largely unmanaged; examination of existing contracts and SLAs to understand customer commitments; and workshops with top management to make the strategic choice about scope breadth.
Who is involved: executive sponsor, SMS coordinator, key customer-facing stakeholders, operations leadership, and top management to approve. The process typically takes 4-6 weeks and produces a draft scope statement, management review and approval, and then a final scope statement that becomes the baseline for implementation.
| IMPORTANT | Auditors will test that actual service delivery aligns with the documented scope at Stage 2. Discovering that in-scope services are being delivered outside the SMS (for example, incident management by the customer instead of by the SMS) is a major nonconformity. The scope statement must be accurate to what is actually being managed. |
Scope and the Certification Certificate
The ISO 20000 certificate issued at the end of Stage 2 will include a "scope of certification" statement that describes exactly what services and organizational boundaries are certified. This becomes the organization's public record of what is covered by its ISO 20000 certification. Organizations use this certificate statement in marketing communications, tender responses, and client discussions. The scope must therefore be both accurate and strategically aligned with how the organization wants to represent its SMS maturity.
Indonesian Context: Common Scoping Patterns
Organizations serving Indonesian financial institutions frequently define scope around the specific service lines contracted to those institutions, since POJK (financial services regulator) compliance requirements often mandate SMS certification for particular service categories. MSP organizations in Indonesia often define scope around service lines (managed infrastructure, cloud services, managed security) rather than customer segments, since MSPs typically serve multiple customer segments with the same service offerings. Organizations in the early stages of SMS adoption often start with a narrow scope covering core infrastructure or service desk operations, planning scope expansion in subsequent certification cycles.
Common Scoping Errors
Including everything: organizations sometimes define scope to include all services and all customers, only to discover during implementation that available resources cannot support implementation of all required practices across that broad scope. This frequently results in implementation delays or in scope being reduced mid-program.
Excluding services that customers expect to see covered: if a customer expects a service to be part of the SMS but it is excluded from scope, this creates tension during customer communications and may cause client satisfaction issues.
Defining scope in terms of organizational units rather than services: "The Infrastructure Department" is not a service scope; "Infrastructure management services" is. Services are defined from the customer perspective, not the organizational structure perspective.
Not aligning scope with the service portfolio: the scope must correspond to actual entries in the service portfolio. If a service exists in the portfolio but is excluded from scope, this must be justified.
| BITLION INSIGHT | Bitlion GRC provides scope definition workshop templates, scope statement libraries with examples from Indonesian IT organizations, and decision frameworks for evaluating scope breadth trade-offs. These tools reduce scope definition time from 8-12 weeks to 4-6 weeks while improving quality. |
Scope Decision Matrix
| Dimension | Narrow Scope Option | Broad Scope Option | Recommended for... |
|---|---|---|---|
| Timeline to certification | 6-9 months | 12-18 months | Time-critical initiatives narrow; long-term strategy broad |
| Implementation effort | 200-400 days internal | 500-900 days internal | Resource-constrained narrow; well-resourced broad |
| Certification cost | Lower (smaller audit scope) | Higher (larger audit scope) | Cost-sensitive narrow; value-seeking broad |
| Commercial value of certificate | Limited to one service/client | Demonstrates enterprise-wide SMS maturity | Single-client contracts narrow; multi-client enterprise broad |
| Certificate reuse in tenders | Limited applicability | Broad applicability across client propositions | Varied client base broad; specialized offering narrow |
Scope Statement Template Elements
| Element | Description | Example | Required? |
|---|---|---|---|
| Service definitions | List of all in-scope services with brief description | Managed hosting for internal and external clients | Yes |
| Service components | Key supporting infrastructure and processes | Data centers, storage, backup, patches | Yes |
| Customer scope | Which customers are included | All enterprise customers and IT-dependent departments | Yes |
| Geographic scope | Which locations are covered | Jakarta and Surabaya operations centers | Yes |
| Exclusions | What is explicitly not in scope with justification | Outsourced development operations (managed separately by vendor) | Yes |
| Organizational units | Which parts of the organization are in scope | Core Infrastructure Team, Operations Center, Account Management | Yes |