ISO 27001 Clause 4: Define an ISMS Scope That Matches Your Information Risks

What clause 4 requires in practice

Clause 4 sets the foundation for everything that follows. It has four parts that build on each other. The organisation works out the internal and external issues that bear on what its ISMS is meant to achieve. It identifies the interested parties that matter and decides which of their requirements the ISMS will address. It then uses both of those inputs, together with the interfaces and dependencies between its own activities and those of other organisations, to set the boundaries and applicability of the system. Finally it establishes, runs, maintains and keeps improving the system, including the processes it needs and how they interact.

The scope must be available as documented information; the other parts do not name a specific record, though an assessor will want to see how the conclusions were reached. The outputs are a defined scope, a clear understanding of obligations and an ISMS that functions as a connected set of processes.

4.1: understand the conditions affecting your ISMS

The requirement concerns relevant internal and external issues and their effect on intended ISMS outcomes. Internal conditions might include a changing operating model or reliance on specialist knowledge. External conditions could include supplier dependence or customer expectations. The amendment explicitly adds determining whether climate change is relevant. Relevance should be considered in relation to the ISMS, rather than assuming an environmental topic is automatically irrelevant to information security.

A practical discussion can start with changes already affecting decisions. A planned move to a hosted platform alters dependencies; recurring power disruption could affect availability. A context list becomes useful when the team can explain how an issue influences scope, risk or resources. A lengthy catalogue of global trends with no connection to the organisation achieves little.

4.2: decide whose requirements the system must address

Identify relevant interested parties, their relevant requirements and which requirements will be addressed through the ISMS. Customers, regulators, employees, owners and service providers can have different interests. The amendment notes that relevant parties can have climate-related requirements. This is not permission to invent obligations; distinguish binding requirements from expectations and decisions the organisation makes voluntarily.

Suggested practice is to connect each significant requirement to its source and an accountable owner. If a client contract requires particular incident communication, someone should understand where that commitment enters the operating process. Avoid assuming the legal team has implemented an obligation merely because it reviewed the contract. Equally, do not represent every customer preference as a legal duty.

4.3: draw the boundary without hiding dependencies

The documented ISMS scope must consider the context and requirements above, plus interfaces and dependencies between your activities and those of other organisations. Scope can cover a defined business service without covering the entire group, but the wording must remain accurate about that boundary. A department name alone rarely explains the information flows that make the service possible.

In a hypothetical remote accounting business, staff deliver a client-reporting service using a cloud platform and outsourced support. Excluding the cloud company's corporate management from the organisation's scope does not remove the dependence on its service. The business still needs to understand how its own supplier decisions, access arrangements and responsibilities affect the information it manages.

In a second illustrative case, a manufacturer includes its customer-order platform within scope while factory maintenance remains a shared service. Maintenance still controls network connections used by the platform. The interface must be considered even if the wider factory is outside the proposed boundary. The dedicated scope guide explores these decisions.

4.4: establish the connected management system

The organisation must establish, implement, maintain and improve the ISMS, including necessary processes and their interactions. A scope statement therefore needs an operating system behind it. Risk assessment should connect with control decisions; staff changes should connect with access responsibilities; evaluation should connect with improvement. The connections matter even when existing business processes perform much of the work.

Why defining the ISMS scope matters to the business

Clause 4 decides what the rest of the ISMS will be about. A business that skips this thinking tends to protect what is easy to protect rather than what customers depend on, and it later struggles to explain what its certificate covers. Working through context, interested parties, boundary and system design gives leaders a defensible answer to the question customers ask first: which of your services, locations and suppliers does this assurance actually cover. It also prevents wasted effort, because controls and documents are built around a boundary that reflects real operations. When the scope is accurate, sales claims, audit findings and incident responses all point to the same facts.

How to implement clause 4 in sequence

The four parts work best when taken together with a single project owner. One approach used by Sterling teams is a short series of working sessions with senior managers.

1. Gather leaders to talk through what is changing in the business and its environment, and note the issues that could affect ISMS outcomes.
2. List customers, regulators, staff, providers and other parties, then record what each expects and which expectations the ISMS will take on.
3. Draft the boundary, naming locations, services, teams and the points where other organisations take part.
4. Test the draft against a real customer commitment to see whether it is credible and accurate.
5. Map the processes the system needs, who owns them and how outputs of one feed the next.
6. Approve the scope and process map through top management and agree when they will be reconsidered.
7. Check at the end that scope, context, requirements and processes tell one consistent story, because assessors often discover mismatches between the boundary statement and the way teams actually describe their work.

Evidence and proportionate implementation

Explore each numbered part

Common nonconformities with clause 4

Clause 4 findings often come from work that was done once and then left alone.

• A scope statement that is vague about locations or services, or that no longer matches how the business operates.
• Interested parties listed, but without any connection between their requirements and ISMS decisions.
• Supplier or shared-service dependencies missing from the boundary even though they handle in-scope information.
• Context issues that read as a generic threat list with no link to the organisation.
• Processes that exist on paper but whose interactions nobody can describe.

Illustrative example: scoping a Philippine BPO account

A hypothetical Philippine BPO wins a client that wants its customer records handled securely by a dedicated team. Management first notes that the client expects incident notification, that the provider depends on a landlord for building access and on a cloud supplier for case-handling software. They list the client, staff, the landlord and the supplier as interested parties and decide which expectations the ISMS will address. The scope names the dedicated floor, the support teams that touch the records and the interfaces with the cloud supplier, and explains why the rest of the company sits outside. Process owners then map how a client instruction becomes an access change, a monitored task and a reported result. When the client later asks what the certificate covers, the answer matches the scope statement exactly.