ISO 27001 ISMS Scope — Boundaries, Interfaces, and Context

The scope statement is the shortest document in your ISMS and the one with the most leverage. It decides what your ISO 27001 certificate covers and what it does not. Certification auditors read it first. Enterprise customers read it when evaluating your certificate. And the scope you set determines how much effort, cost, and risk your ISMS programme carries for years.

Clause 4.3 of ISO 27001 requires that the organization determine the boundaries and applicability of the ISMS to establish its scope. That sounds simple. In practice, scope decisions are where many ISO 27001 programmes quietly set themselves up for trouble.

What ISO 27001 requires

Clause 4.3 has three inputs that must be considered when setting scope:

• The external and internal issues identified under Clause 4.1. Market conditions, regulatory landscape, internal culture, technology dependencies.
• The requirements of interested parties identified under Clause 4.2. Customers, regulators, investors, employees, partners, and their relevant information security expectations.
• The interfaces and dependencies between activities performed by the organization and those performed by other organizations. Cloud providers, managed services, contractors, subsidiaries, and shared services.

The scope must be available as documented information. Most organizations produce a formal scope statement as part of the ISMS manual, with enough detail to stand on its own if extracted.

What a scope statement should include

A credible ISO 27001 scope statement covers six dimensions:

1. Organizational boundaries

Which legal entities, business units, divisions, or subsidiaries are covered. If your parent company operates multiple regulated subsidiaries, the scope should be explicit about which are included.

2. Locations

Physical and logical locations within scope. Offices, data centers, colocation facilities, remote work arrangements, and cloud regions. For distributed organizations, scope often covers specific regions or excludes locations without in-scope activities.

3. Products and services

Which products or services the ISMS protects. A SaaS company might scope its ISMS to the production platform and supporting functions, explicitly excluding unrelated consulting arms.

4. Processes

Which business processes are within scope. Customer data processing, product development, incident response, HR onboarding, finance, and so on. Processes that handle in-scope information must be included even if they sit in a business function that is otherwise out of scope.

5. Technology

Which systems, platforms, and infrastructure are within scope. This often overlaps with products and services but should also call out supporting tooling like identity providers, monitoring platforms, collaboration tools, and ticketing systems.

6. Information types

Which information assets the ISMS protects. Customer data, intellectual property, employee records, financial data, or specific regulated data types.

Example scope statements

The scope is the boundary itself. The scope statement is the short written description of that boundary -- usually a single paragraph, and usually the wording your certification body carries onto the certificate. It is the only part of your scoping work that customers and prospects ever see, which is why it is worth writing deliberately rather than pasting from a template.

Most statements that survive review follow the same skeleton: legal entity operates an ISMS covering products and services, including supporting processes and functions, delivered from locations and cloud regions, in accordance with Statement of Applicability version and date. Exclusions, each with the reason for it.

Three worked examples, written against the six dimensions above.

SaaS platform with offices in two countries

"Northwind Analytics Ltd operates an information security management system covering the design, development, hosting, and support of the Northwind Analytics platform, including the supporting engineering, customer support, information security, and people operations processes. These activities are delivered from company offices in Manchester, United Kingdom and Lisbon, Portugal, and from AWS regions eu-west-2 and eu-west-3. In accordance with Statement of Applicability version 2.1, 12 March 2026."

Fully remote organization

"Harbourline Software Inc. operates an information security management system covering the development, operation, and support of the Harbourline payments API and its customer administration console, including the engineering, support, and security operations processes. The organization works entirely remotely, with no office or data centre of its own; production runs in Google Cloud regions us-east4 and europe-west1. The registered address in Wilmington, Delaware is used for correspondence only and hosts no in-scope activity. In accordance with Statement of Applicability version 1.4, 2 February 2026."

Scope with a deliberate exclusion

"Calder Group Ltd operates an information security management system covering the delivery of the Calder Claims platform to insurance clients, including product development, hosting, client onboarding, and support, from its Leeds, United Kingdom office and Azure UK South region. The Calder Advisory consulting practice is excluded: it operates on a separate tenant and network, holds no Calder Claims client data, and is staffed and managed independently. Interfaces with shared group finance and payroll services are documented and controlled under the ISMS. In accordance with Statement of Applicability version 3.0, 8 January 2026."

What makes these defensible is not the wording but the specificity. Each one names a legal entity rather than a brand, names the services a customer could actually buy, states where the work happens, gives a reason for every exclusion, and ties itself to a dated Statement of Applicability. A statement that reads "all information systems of the company" tells an auditor nothing about where to point the audit, and tells a prospect nothing about whether the thing they are buying is covered.

Adapt the shape, not the content. The exclusions in particular have to reflect real separation in your organization -- see the pitfalls below.

Defining boundaries

Boundaries are the edges of your ISMS. Inside the boundary, ISO 27001 controls apply. Outside, they do not. Clear boundaries prevent audit disputes about whether a control failure falls within scope.

Boundaries should be drawn by:

• Logical separation. Networks, accounts, environments, and data flows that can be cleanly isolated from out-of-scope systems.
• Organizational separation. Distinct teams, reporting lines, and access controls between in-scope and out-of-scope operations.
• Physical separation. Different buildings, floors, or secured areas.
• Contractual separation. Documented agreements with parent entities, subsidiaries, or shared service providers that clarify responsibility.

Where separation is weaker, the case for including those adjacent activities in scope strengthens. Trying to carve a tight scope through tightly integrated operations creates more risk than it saves.

Defining interfaces

Interfaces are where in-scope activities meet out-of-scope activities, either inside your organization or with third parties. Clause 4.3 specifically requires that interfaces be considered when scoping. Auditors will ask how you handle each interface.

Typical interfaces include:

• Cloud providers. You consume their services. They provide infrastructure, platform, or software controls. Your ISMS covers how you use their services, configure them, and manage your responsibilities under the shared responsibility model.
• Managed service providers. Third parties operating in-scope activities on your behalf. Scope should address contractual controls, monitoring, and right to audit.
• Parent or sister companies. Shared HR, finance, IT, or security functions that cross the ISMS boundary. Scope should clarify how those shared functions are controlled.
• Contractors and consultants. Time-limited access to in-scope systems or data. Scope should describe how access is governed.
• Customer-facing interfaces. How customer data flows in and out, and where responsibility transitions.

A common auditor test is to trace a piece of customer data through every interface and confirm that controls and responsibilities are clear at each boundary crossing.

Organizational context (Clause 4.1)

Clause 4.1 requires the organization to determine external and internal issues relevant to its purpose that affect its ability to achieve the intended outcomes of the ISMS. The scope flows from this context.

External issues commonly include:

• Regulatory environment. GDPR, HIPAA, state privacy laws, sector regulation.
• Customer expectations. Enterprise procurement requirements, vertical-specific standards.
• Threat landscape. Ransomware trends, supply chain attacks, relevant threat actors.
• Technology trends. Cloud adoption, AI integration, remote work norms.
• Economic and geopolitical conditions. Sanctions, export controls, market pressures.

Internal issues commonly include:

• Organizational structure. Growth stage, distributed or centralized operations.
• Culture. Security maturity, engineering velocity, risk tolerance.
• Technology estate. Legacy systems, cloud-native architecture, SaaS sprawl.
• Resourcing. Team size, budget constraints, leadership engagement.
• Change pace. Product release frequency, M&A activity, reorganizations.

The context analysis is usually captured in a short document that feeds into the scope statement and into risk assessment.

Interested parties (Clause 4.2)

Clause 4.2 requires identifying interested parties relevant to the ISMS and their relevant requirements. Interested parties typically include:

• Customers, particularly enterprise and regulated customers with security requirements in contracts.
• Regulators whose rules touch the in-scope information or services.
• Employees, whose data is typically in scope and who depend on the ISMS for their own protection.
• Shareholders and investors.
• Partners and suppliers.
• Certification bodies and accreditation bodies.

For each, record the requirements relevant to the ISMS. Customer security addenda, regulatory obligations, and investor due diligence expectations all inform scope and control decisions. These requirements also frequently drive the Statement of Applicability.

How this fits into your ISMS

Scope sits at the foundation of the entire ISMS. Everything downstream depends on it. ISMS implementation builds inside the scope boundary. The Statement of Applicability selects controls for the scope. The risk assessment assesses risks to assets within scope. The certification body audits against scope during the certification process.

When scope changes, everything downstream must be reviewed. Adding a new product line, a new office, or a major new service usually triggers a scope update that cascades through the rest of the ISMS.

Common pitfalls

• Scope too narrow. Excluding activities that customers expect to be covered. A SaaS scope that excludes the shared identity provider used by the platform will raise procurement objections.
• Scope too broad. Including every activity in the organization inflates audit cost and effort. Consulting practices, sales operations, and unrelated business lines often do not belong.
• Vague scope statement. "All operations" is not a scope. Auditors need specificity.
• Exclusions with no justification. Carving something out is allowed, but the statement has to say why it is out -- separate tenant, no in-scope data, independently managed -- and the separation has to be real.
• Ignoring interfaces. Cloud providers, shared services, and contractors are almost always in scope in some capacity and must be addressed.
• Copying scope from a competitor's certificate. What works for one organization may not match yours.
• Failing to revisit scope. Business changes quickly. A scope written in year one may not match the organization by year three.
• Disconnection between scope and SoA. Controls listed as applicable in the SoA must cover the scope described in the scope statement.

How episki helps

episki captures your ISMS scope, interfaces, interested parties, and organizational context as structured data rather than a static document — and then enforces it. A program reports against individual scope boundaries with rules on cloud account, region, resource, and tag, so "the ISMS covers our production estate in eu-west-1" is a rule the evidence is filtered by, not a sentence in a Word file. Every record collected from a connected system is stamped with the account, region, and provider it came from, so out-of-scope infrastructure cannot contribute evidence to an in-scope control. When scope changes, downstream controls, risks, and SoA entries are flagged for review, and the next sync reports against the new boundary automatically.

Return to the ISO 27001 framework overview for how scope connects to the full certification journey.