Define an ISO 27001 Scope That Matches Your Service

What clause 4.3 requires in practice

Clause 4.3 asks the organisation to decide the boundaries and applicability of its ISMS, which together make up its scope. In deciding, it must take into account the issues from 4.1, the requirements from 4.2, and the interfaces and dependencies between what it does itself and what other organisations do.

The interfaces point matters most in practice. A boundary drawn around a team that relies on an outside provider for hosting, support or processing cannot ignore that provider. The scope does not need to pretend the other organisation is inside the system, but the handover points, shared responsibilities and reliance should be understood and addressed.

The clause is explicit about one output: the scope must be kept as documented information. How the statement is worded is the organisation's choice. Whatever words are used, they should tell a customer, an employee and an assessor what is covered and what is not.

Separate a business boundary from a convenient audit boundary

A scope can focus on part of an organisation. That does not make every narrow scope credible. If delivery depends on a shared support function, external hosting or employees outside the named office, the organisation must consider those relationships. Excluding a function from the organisational boundary does not make its effect on the in-scope service disappear.

List the service, activities, locations and significant interfaces before trying to compress the result into a short statement. Test the proposed wording against an ordinary transaction and a difficult exception. This practical exercise often identifies dependencies that an organisation chart misses: emergency administrator access, central recruitment, customer-owned equipment or a subcontractor performing overnight work.

Why a precise scope matters to the business

The scope is the promise on which everything else is built, and it is also the statement customers quote back. A boundary that is too narrow can leave critical services unprotected while still being advertised as certified. One that is too broad stretches resources and invites findings in areas that were never ready. A well-judged scope focuses investment on the services that matter, makes risk assessment manageable and lets marketing and sales describe the result accurately. It also avoids the awkward situation where a customer discovers that the activity they depend on sat outside the boundary all along.

How to implement clause 4.3

Start from the service the business wants to protect and work outwards. One approach Sterling teams use is a boundary workshop that combines business and technical staff.

1. Name the services, products or activities that the customers and leaders most want covered.
2. List the information, people, locations, systems and legal entities involved in delivering them.
3. Identify every point where another organisation supplies, hosts, supports or receives something in-scope.
4. Draft the scope statement in plain language, including what is deliberately excluded and why.
5. Check the draft against context and interested-party requirements, and revise where they conflict.
6. Have top management approve the statement, keep it under document control and use it as the single reference for marketing claims.
7. Keep a brief note of the reasoning behind the boundary, including options that were considered and rejected, so that a later review can see why the scope was drawn as it was and revise it with confidence.

Example: a software service with shared group functions

Example: construction design information across projects

A construction group wants to protect design coordination for major customer projects. Drawings pass through a central design office, temporary site teams and specialist designers. Some subcontractors use their own collaboration tools. The group should examine where sensitive information is created, changed, approved, shared and retained before declaring which project activities the ISMS covers.

A project that sits outside the certification scope may still exchange information with in-scope teams. Documenting that interface prevents a misleading assumption that the boundary is also a technical wall. It also helps procurement and project managers explain which requirements apply to the exchange.

Make exclusions and dependencies understandable

The management-system requirements in clauses 4–10 are not optional exclusions when claiming conformity. That is different from deciding organisational boundaries and different again from selecting controls through risk treatment. The Statement of Applicability explains control decisions; it is not a substitute for the scope required by clause 4.3.

Consider customer expectations early. A customer buying an operated service may find a certificate covering only product development insufficient for its procurement needs. The issue is not merely whether wording can pass review; it is whether the scope represents what the customer needs assurance about.

Evidence that supports a scope discussion

Common nonconformities with clause 4.3

Scope findings are often about mismatch between the written statement and the facts.

Auditors usually test the scope by comparing the written statement with what they see and hear on site.

• A scope statement that omits a location, team or service where in-scope information is actually handled.
• Outsourced activities that touch in-scope information, with no consideration of the interface.
• Wording so general that nobody can say what is inside or outside.
• Scope not updated after a reorganisation, new site or new service.
• Public claims of coverage that go beyond the documented scope.