4.3 Determining the Scope of the Information Security Management System
Clause 4.3 is where the organisation defines the boundaries and applicability of the ISMS. To do that properly, it must consider the internal and external issues identified in 4.1, the requirements gathered in 4.2, and the interfaces and dependencies between its own activities and those carried out by other organisations. Unlike 4.1 and 4.2, this subclause carries a clear and explicit documentation requirement: the scope shall be available as documented information. There is no flexibility on that point.
This is one of the most consequential decisions an organisation must make when setting up their ISMS. The scope determines where the management system applies, and therefore where risk assessment, control selection, internal audit, management review, and improvement activities must all operate. Get the scope wrong and everything built on top of it is compromised. ISO 27003 is direct about this: if scope is unclear, risk assessment and treatment will not produce valid results. It also makes the point that interfaces and dependencies with other organisations are critical considerations, and that changes to scope after the ISMS has been established can create significant extra effort and cost. It is much better to get this right at the beginning.
The purpose of Clause 4.3 is precision. A scope that is too broad can become unmanageable, spreading resources and attention too thin to be effective. A scope that is too narrow can become artificial, failing to cover the information flows, systems, or dependencies that actually matter to the business. Neither serves the organisation well, and neither will hold up well under scrutiny. The scope needs to reflect reality: what the organisation actually does, where it does it, and how its information assets and processes connect to the wider world.
Because the scope is the one piece of documented information explicitly required by Clause 4, it deserves careful attention. It should clearly describe the organisational, physical, and technological boundaries of the ISMS, along with the relevant interfaces and dependencies. ISO 27003 is specific about what that description should cover: organisational scope with its boundaries and interfaces, ICT scope with its boundaries and interfaces, and physical scope with its boundaries and interfaces. A scope statement that vaguely refers to "all information assets" without specifying what that means in practice is unlikely to satisfy an auditor or serve the organisation particularly well.
Implementation evidence for 4.3 can include an approved scope statement, network and system boundary diagrams, process maps, site lists, service descriptions, outsourcing maps, and where relevant, descriptions of areas that have been excluded from scope along with the justification for excluding them. That last point is worth emphasising. Exclusions are not inherently a problem, but they need to be thought through and documented. An auditor will want to understand why something sits outside the scope and whether that decision is defensible given the context and the requirements identified earlier.
Audit evidence will typically focus on a few key questions. Does the scope genuinely reflect the context identified in 4.1 and the requirements from 4.2? Were interfaces and dependencies with other organisations properly considered? And perhaps most importantly, is the ISMS actually implemented throughout the stated scope in practice, rather than just on paper? A scope that claims to cover three sites but where two of those sites show no evidence of ISMS activity will be a significant finding.