SGRII Insights  ·  ISO 27001:2022  ·  2026

Your ISMS Scope Was Set on Day One. Your Organisation Has Not Stood Still Since.

Most certified ISMS implementations treat Clause 4 as a project-launch activity. ISO 27001:2022 treats it as a permanent system obligation. That gap is where scope becomes liability — and where Stage 2 auditors find their first finding.

Pull any ISMS document pack produced between 2016 and 2022 and find Clause 4. What you will almost certainly find is a two-to-four-page document titled ‘Context of the Organisation’ or ‘Organisational Context Statement.’ It lists internal issues — usually a SWOT. It lists external issues — usually a PESTLE. It names interested parties and, in the better implementations, captures what those parties require. And then it was filed. Approved at project kickoff, referenced at Stage 1 audit, and not substantively updated since.

This is the most structurally consequential error in ISO 27001 implementation. Not because the document is wrong — it was probably accurate on the day it was written. But ISO/IEC 27001:2022 does not ask the organisation to describe its context once. It asks the organisation to determine external and internal issues relevant to its purpose that affect its ability to achieve the intended outcomes of the ISMS. The word ‘determine’ is not past tense. The clause does not expire.

What Clause 4 Actually Requires

Clause 4.1 requires the organisation to determine external and internal issues relevant to its purpose and that affect its ability to achieve the intended outcome of the ISMS. Clause 4.2 requires the identification of interested parties and the determination of their requirements relevant to information security. Clause 4.3 uses both outputs to define the ISMS scope. And Clause 6.1 requires that the risk assessment process takes the context of the organisation as its starting point.

Four clauses. One living foundation. When the foundation is static, all four are compromised. The risk register reflects threats that existed when the context analysis was completed. The scope reflects boundaries that were commercially convenient at project inception. The interested party register lists requirements that were documented without a mechanism for monitoring change. And the ISMS is — silently, without any visible finding — increasingly detached from the organisation it is meant to protect.

The Three Traceability Failures Auditors Find Most Often

The first is the absence of a traceability link between the context analysis and the ISMS scope boundary. The scope document names what is included. It rarely explains why specific assets, sites, or processes are excluded — and whether that exclusion was a deliberate, risk-informed decision or a pragmatic choice made at kickoff to limit the certification scope. An auditor who asks ‘why is your cloud infrastructure outside scope?’ expects a context-grounded answer. ‘Because it was not in scope at certification’ is not one.

The second is the absence of a monitoring mechanism for interested party requirements. ISO 27001:2022 Clause 4.2 requires identification of the requirements of relevant interested parties and determination of which of those requirements will be addressed through the ISMS. The standard implies ongoing determination, not one-time listing. Customer contracts change. Regulatory obligations are amended. Supplier security requirements evolve. An interested party register that has not been reviewed since implementation is a Clause 4.2 finding waiting to be raised.

The third — and most consequential — is the failure to connect context changes to risk register updates. Clause 6.1 risk identification must reflect the organisation’s actual information security environment. If the context analysis identifies a new external issue — an emerging regulatory requirement, a significant change in the threat landscape, a new major customer with contractual security obligations — the risk register must respond. If it does not, the ISMS has not processed the change. The system has a gap between its stated context and its operative risk model.

What the Standard Specifically Requires as Evidence

ISO/IEC 27001:2022 Clause 4.1 requires documented information to the extent necessary to support confidence that the processes have been carried out as planned — which in audit practice means auditors expect to see evidence of context determination, not just a context statement. Evidence includes: meeting records, review logs, documented issue registers with dates of last review, and traceable links between context outputs and scope decisions.

Clause 4.2 evidence requirements are equally specific. The interested party register must capture not just who the parties are, but what their requirements are and how the ISMS addresses them. A register that lists ‘Customers: data protection’ without capturing specific contractual or regulatory obligations is not satisfying Clause 4.2 — it is describing it.

Why Most Implementations Treat Clause 4 as a Document, Not a Process

The implementation industry has a structural incentive to treat Clause 4 as a deliverable rather than an obligation. A document can be produced, reviewed, approved, and submitted. A process requires a governance mechanism, a review cycle, a trigger framework, and a traceability architecture. Documents have a completion point. Processes do not.

The result is a certification industry that has normalised static context analysis at the same time as the threat and regulatory environments that context analysis is meant to reflect have accelerated dramatically. GDPR came into force after many certifications were in maintenance. AI-driven threats were not in scope discussions five years ago. Supply chain attack vectors that the ISMS risk register should now address were not the dominant threat pattern at most organisations’ original certification. The context has changed. The Clause 4 document, in most certified systems, has not.

The SGRII Position

The SGRII view on Clause 4 is structural: context is the first pillar of the ISMS architecture. The Systems pillar requires that the information security management system is designed as a system — one in which every component is connected to a living, accurate picture of the organisational environment. A system built on a static context analysis is not a system. It is a document hierarchy that was current on the day it was approved and has been decaying since.

Every element of the SGRII ISO 27001:2022 ISMS Framework is designed with Clause 4 traceability built in. The ISMS Context & Scope Register is a structured, reviewable document with version control and review date tracking — not a narrative statement. The Interested Party Register captures specific, attributable requirements with review cycles. The ISMS Scope Boundary Definition includes risk-based exclusion justification. And the Management Review Record includes context review as a mandatory agenda item, ensuring that leadership receives and acts on changes to the organisational information security environment at every review cycle.

The Direct Challenge

When was your Clause 4 context last substantively reviewed? Not re-approved — reviewed. When were your interested party requirements last verified against current contracts and regulatory obligations? When was your scope boundary last examined against your actual operational footprint? If the honest answer to any of these questions is ‘at certification,’ your ISMS is built on a context that no longer exists.