4.3 — Determining the scope of the ISMS

The single decision that every other clause in the standard operates inside. Get the scope wrong, and nothing downstream can be entirely right.

In plain language

4.3 requires you to draw a clear, defensible boundary around what your ISMS actually covers — which entities, sites, systems, and services are in scope — based on the context you identified in 4.1 and the interested-party requirements you addressed in 4.2.

Why this requirement exists

Scope is the single biggest lever in the entire certification project — it directly determines cost, timeline, and how much value the certificate carries with your clients. A scope drawn too narrowly protects little and impresses nobody; a scope drawn too broadly multiplies your workload without necessarily reducing your real risk. This requirement forces the boundary to be a considered, documented decision rather than whatever happened to get included by default.

Scenario: a SaaS company scopes its ISMS around its production cloud environment, but a customer later asks whether the certificate also covers the internal HR system where employee data lives. If that system was never explicitly excluded with a documented rationale, the gap looks like an oversight rather than a decision — and the customer conversation gets much harder.

What the standard expects

The standard expects the organization to determine the boundaries and applicability of the ISMS to establish its scope, taking into account the external and internal issues from 4.1, the requirements from 4.2, and the interfaces and dependencies between activities performed by the organization and those performed by other organizations. The scope must be available as documented information.

In practice

• Define scope in terms auditors recognize: legal entities, physical sites, systems and applications, and the services delivered from them — not vague statements like “the company’s IT.”
• Explicitly document interfaces with anything outside the scope boundary — a cloud provider, an outsourced payroll system, a partner integration — since those handoffs are exactly where auditors probe.
• Justify exclusions explicitly rather than leaving them implicit — “the HR system is out of scope because it processes no customer data and sits on a fully segregated network” is defensible; silence is not.

Evidence the auditor will ask for

• A documented scope statement naming entities, sites, systems, and services covered.
• Documented justification for any notable exclusions.
• Consistency between the stated scope and what the risk assessment, SoA, and internal audits actually cover.

Common pitfalls

• A scope statement vague enough that reasonable people would disagree on what it actually covers.
• An exclusion with no documented rationale, discovered by the auditor rather than disclosed upfront.
• Scope drift: the business grows or changes and the documented scope quietly stops matching reality (see clause 6.3 on planning changes).

Related requirements

• 4.2 Interested parties — the requirements this scope decision has to account for.
• 6.1.1 General — requires your risk assessment scope to match this ISMS scope exactly.
• 6.3 Planning of changes — where scope-affecting changes get controlled instead of drifting silently.
• Parent clause: Clause 4 · Context of the organization