Skip to content

Clause 4.3 of ISO/IEC 27001:2022, Determining the scope of the ISMS

The scope is the one decision you cannot walk back cheaply. It is what the certificate says.

Clause 4.3 asks you to write down, in one place, what is in and what is out, and have top management sign it.

  • Three boundaries. Organisational, technical, physical.
  • Exclusions stated, with a reason for each.
  • Signed by top management, and dated.
  • Inputs: the context picture from 4.1 and the parties register from 4.2.
Determining the ISMS scope, in four steps Defining the ISMS scope in four steps. The organisation starts with a preliminary scope set by a small management group, refines it by reviewing functional units and their interfaces, finalises it through a management review of the refined scope, and ends with formal approval by top management. Scope sets the boundary inside which every other ISMS activity operates. Context, interested parties, support functions identified 1 Preliminary scope A small, representative group of management representatives sets the starting boundary. 2 Refined scope Functional units inside and outside the boundary are reviewed for interfaces. 3 Final scope All management in the refined scope reviews and adjusts, then describes it. 4 Management sign-off Documented scope is formally approved; it is the boundary for every later ISMS activity. Determining the ISMS scope, in four steps Defining the ISMS scope in four steps. The organisation starts with a preliminary scope set by a small management group, refines it by reviewing functional units and their interfaces, finalises it through a management review of the refined scope, and ends with formal approval by top management. Scope sets the boundary inside which every other ISMS activity operates. Context, interested parties, support functions identified 1 Preliminary scope A small, representative group of management representatives sets the starting boundary. 2 Refined scope Functional units inside and outside the boundary are reviewed for interfaces. 3 Final scope All management in the refined scope reviews and adjusts, then describes it. 4 Management sign-off Documented scope is formally approved; it is the boundary for every later ISMS activity.

What the decision has to consider

Factor Look at
Context (4.1) The external and internal issues affecting information security
Interested parties (4.2) Regulators, customers, suppliers, employees, and what they require
Business activities Whether the candidate scope is operationally ready
Support functions HR, IT, facilities, and anything in-scope activities depend on
Outsourced functions Anything a third party delivers that in-scope activities depend on

What the statement must contain

Boundary Name explicitly
Organisational Which legal entity, which business units, which geographies
Technical Which systems, platforms, networks, data flows
Physical Which sites, data centres, offices, secure rooms

Exclusions go in the same place, one line of reason each.

  • Defensible: "Outsourced payroll, under a separately certified provider."
  • Not defensible: silence.

How to do it

  1. Draw a first line. Small group who know the business. These units, these systems, these locations.
  2. Walk the interfaces. For each unit, list what it depends on. Pull in every support function that is not optional: identity, network, the data centre, the SaaS the team cannot work without. Adjust until the boundary is defensible.
  3. Take it to the management inside it. They know what you do not: a unit about to be divested, a system being replaced, a regulator with views on one process.
  4. Get it signed. Top management approves the documented scope. This is the artefact an auditor asks for first. Without the signature, every other ISMS document floats.

Common pitfalls

  • Scope by org chart. The org chart is rarely the shape of where information moves. Walk the data, not the boxes.
  • No exclusions at all. An auditor reads that as a scope nobody thought about. Explicit, justified exclusions build confidence.
  • Outsourcing treated as excluding. Handing a function to a third party does not hand over the risk. It stays yours.
  • Scope that drifts. New system, new contract, new jurisdiction: each gets a documented review. The clause does not say annually; it says when issues and requirements change.
  • Signed but not dated. Without a date you cannot show the scope was right at the time of a later incident.

Linked documents

Document Why it needs the scope
Information security policy (5.2) States the ISMS purpose within the scope
Risk methodology and register (6.1.2, 8.2) Risks are identified within the scope, no further and no less
Statement of Applicability (6.1.3 d) Annex A controls apply to the systems and people inside it
Risk treatment plan (6.1.3 e) Actions owned and budgeted within the scope
Audit programme (9.2) Audit coverage is sized to the scope
Management review (9.3) Scope is the first item checked for fitness

Key definitions

Term Meaning here
Scope The boundaries and applicability of the ISMS: organisational, technical and physical, with justified exclusions
Outsourced function Delivered by a third party but depended on by in-scope activities. Not excluded by being outsourced; the risk stays with you

Primary sources

Verify before you rely on it

A working interpretation of ISO/IEC 27001:2022 clause 4.3, written for practitioners. The standard is the only authoritative source. Check the current text before relying on any wording in an audit or filing.

Part of Clause 4, Context of the organisation, which shows how 4.3 depends on the other three. The working files are in the implementation kit.