Clause 4 decides your certificate before you pick a single control¶
Most ISO 27001 projects start at Annex A. Ninety-three controls, a spreadsheet, and a comfortable feeling of progress.
Clause 4 comes first for a reason, and it is not ceremonial. It is four questions, and the answers determine what the certificate says.
Four subclauses, four questions¶
- 4.1 Context. What world are we operating in?
- 4.2 Interested parties. Who else has a say, and what binds us?
- 4.3 Scope. Where does the system start and stop?
- 4.4 The ISMS. What is the system made of?
The dependency runs in one direction, and it is worth being precise about it because people assume a sequence that is not there. 4.1 and 4.2 do not come before each other. They are two independent inputs, usually produced in the same workshop. Both feed 4.3. And 4.3 bounds 4.4.
That shape is the whole clause. Everything downstream, every risk assessment and every control decision, inherits the boundary drawn in 4.3.
Each subclause has its own page: 4.1 Context, 4.2 Interested parties, 4.3 Scope and 4.4 The ISMS.
4.3 is the expensive one¶
The scope is the one decision you cannot walk back cheaply, because it is what the certificate says.
Draw it too wide and you have committed to running a management system over parts of the business that were never going to cooperate, and every surveillance audit will find that out. Draw it too narrow and the certificate arrives and a customer reads it properly and asks why the service they buy is not inside the boundary. Both are discovered late and both cost more than the original conversation would have.
Which is why 4.3 needs top management to sign it, not just approve it in passing. The clause says so.
4.1 and 4.2 are not paperwork¶
The two inputs get treated as a formality, filled in with generic external issues copied from a template. That is exactly why so many scopes are indefensible.
4.1 asks for a short written picture of the external and internal issues that affect your information security. Short. It is not an environmental scan, and a good one fits on a page.
4.2 produces one table, from three questions: who has a stake, what do they need, and which of those needs actually bind us. The last column is the one that does work. A customer's expectation and a regulator's requirement look similar on a slide and are entirely different things when you have to decide what "good enough" means. You do not get to decide that on your own, which is the point of the clause.
4.4 is one sentence and four verbs¶
The shortest clause in the standard. Establish, implement, maintain, continually improve. Plus a phrase almost everyone reads past: including the processes needed and their interactions.
Interactions. Not a list of processes, a description of how they hand off to each other. That word is why an ISMS is a system rather than a folder, and it is the thing an auditor probes when they want to know whether you built one or documented one.
What is on the page¶
A clause-by-clause reading of all four, each with what it has to produce and where it goes wrong, plus a dependency diagram showing why 4.3 is highlighted. There is also a ninety-second version of Clauses 1, 2 and 3, which exist and which nobody reads.
If you want the paper set to go with it, the implementation kit has the scope document, the context record and the interested-parties table as working files rather than examples.
Clause 4 of ISO/IEC 27001:2022, Context of the organisation →
ISO/IEC 27001:2022 Clause 4, with ISO/IEC 27003 as the guidance on scoping. Practitioner material, not legal advice, and not affiliated with or endorsed by ISO.