Auditing ISO 27001 Clause 4: Context and Scope

Clause 4 is audited by testing whether the ISMS scope is a reasoned boundary rather than a convenient one. You read the scope statement against what the organisation actually does, trace interested-party requirements into the risk assessment, and look for the interfaces and dependencies with other organisations that Clause 4.3 requires be considered.

The clause reference sets out what 4.1 to 4.4 require. This page is about how you audit them, which is a different problem — Clause 4 asks for almost no documented information, so most of the evidence has to be found somewhere else.

The worked findings on this page are invented, and so are the organisations in them. They are written to show how a finding is built and graded, not to catalogue the findings you should expect.

Why ISO 27001 Clause 4 is audited last and first

A useful paradox. Clause 4 is where an audit begins on paper and where the findings tend to arrive at the end.

You read the scope before the audit starts, because it tells you what is in and out. But you cannot tell whether a scope is honest until you have seen the business, and by then you are in Clause 6 or walking a site. The Clause 4 finding usually announces itself while you are auditing something else — a risk that turns out to sit outside the scope, a supplier nobody has assessed because the interface was never considered.

So audit Clause 4 twice. Once at the start, to know the boundary. Once at the end, to ask whether the boundary survived contact with what you found.

The audit trail for ISO 27001 Clause 4

Before anything else, get three documents: the scope statement, whatever records exist of the context analysis, and the interested-party analysis. Only the scope must be documented, so the other two may not exist as documents at all — and the absence is informative rather than automatically a finding.

4.1 — the issues. Ask what external and internal issues affect the ISMS’s ability to achieve its intended outcomes. Then ask when they were last reviewed, and by whom. An organisation whose issues list has not changed while its business has is describing a snapshot rather than running a process.

One 4.1 issue is now named in the standard itself. An amendment — the climate action changes, made to this and to many other management system standards — adds a requirement that the organisation shall determine whether climate change is a relevant issue, with a note at 4.2 that relevant interested parties can have climate-related requirements. It is short and easy to evidence: the organisation either considered the question or it did not. One caution for candidates: the amendment sits outside the main body of the 2022 edition, so a clean copy of the standard may not contain it and course material written earlier will not mention it. Check which text your copy carries.

4.2 — interested parties. Three questions in sequence. Who are the relevant interested parties? What are their relevant requirements? And which of those requirements will be addressed through the ISMS? That third question is the one that finds things, because it is the one most organisations answer with a list and no decision.

Then trace one. Pick a demanding customer or a regulator, find their requirement, and follow it into the risk assessment and the objectives. If it stops at the list, you have something — though be careful where you cite it, because 4.2 asks the organisation to determine which requirements the ISMS will address. A requirement determined and then not implemented is a failure further downstream, not at 4.2.

4.3 — the scope. Read the scope statement against the organisation’s website, its service catalogue, and what the people you meet actually do. Three considerations must have been taken into account: the 4.1 issues, the 4.2 requirements, and the interfaces and dependencies between the organisation’s activities and those performed by other organisations.

That third one is where cloud, outsourcing, group shared services and intra-group processing live, and it is the consideration most often absent from the reasoning.

4.4 — the ISMS itself. Ask to be shown the processes needed and their interactions. A surprising number of organisations cannot, which tells you something about how the system is held together.

Evidence and sampling on ISO 27001 Clause 4

There is little to sample, so the technique is corroboration rather than sampling. Take the scope statement as a claim and test it three ways: against documents, against what people say, and against what you see.

Against documents. Does the risk assessment contain risks that belong to activities outside the scope? Does the Statement of Applicability include controls for something the scope excludes?

Against people. Ask someone in a scoped team what they do all day. Ask whether any of it involves a system, a site or a supplier you have not heard mentioned.

Against the world. The organisation’s own marketing is a legitimate source. So is a certificate on a website whose scope wording differs from the one you were given.

A worked ISO 27001 finding on Clause 4.3: the boundary drawn by legal entity

Haverbrook Milling defines its ISMS scope by reference to a single legal entity. Its archived paper records are stored and retrieved by a facilities management contractor, whose staff also hold badge access to the communications room at the head office site. The scope reasoning does not mention either arrangement.

One discipline in writing any of these. Record what you were told as fact where it establishes how far the failure reaches; do not write your own diagnosis of why it happened. “The manager confirmed no records exist for contract staff” is evidence of extent. “This happened because onboarding is not joined up” is a cause, it is the organisation’s to establish under Clause 10.2, and supplying it hands the auditee something to argue about.

Note what the finding does not say: it does not say the boundary is wrong, and it does not tell Haverbrook to widen it. A scope may legitimately exclude a contractor’s activities; what it may not do is fail to consider the interface.

A second worked ISO 27001 finding on Clause 4.1, graded differently

Ashcroft Pensions maintains a record of the external and internal issues affecting its ISMS. Since it was last revised, the organisation has acquired a competitor with a second operating site, and has insourced a scheme administration function it previously contracted out.

Notice that the second finding cites nothing larger than the evidence supports, which is what makes it survivable at the closing meeting. Clause 9.3.2 b) was the obvious alternative — it requires changes in internal and external issues to be an input to management review, and no such item appears in two reviews. That is a second, separate finding on the same visit rather than a second citation on this one, because it describes a different failure by different people.

Major or minor on ISO 27001 Clause 4

Grade from the evidence and its reach, never from how serious it feels. A major is a significant or systemic failure — a requirement absent, a process that is not operating, a breakdown that raises doubt the ISMS can achieve its intended results. A minor is an isolated or occasional lapse that does not by itself break the system. Several related minors can together show a systemic problem and become a major.

On this clause specifically, the distinction usually comes down to how much of the organisation the problem removes from the ISMS.

Major territory: no context or interested-party consideration at all; a scope statement that does not describe what the organisation does; a whole category of consideration — interfaces and dependencies, most often — absent from the reasoning.

Minor territory: an issues analysis not revisited after a change; one interested-party requirement recorded and not carried into the ISMS; a scope statement whose wording is imprecise but whose boundary is right.

Observation or opportunity: a context analysis that is thin but present, where nothing downstream has gone wrong yet.

And keep the opportunity for improvement in its place. It is advice the organisation may take or leave, and it must never be used to avoid raising a genuine nonconformity.

Where ISO 27001 Clause 4 connects

Almost every Clause 4 finding is discovered somewhere else, which is why the connections matter more here than on any other clause.

Most Clause 4 findings travel in that direction: you meet them while auditing something else, and follow the trail back to the boundary.

Frequently asked questions about auditing ISO 27001 Clause 4

Where to go next: more ISO 27001 Lead Auditor exam preparation

Auditing Clause 5: leadership, policy and roles

Auditing Clause 6: risk assessment, treatment and objectives

Clause 6.3 planning of changes, the clause people miss

Auditing Clause 7: competence, awareness and documented information

3FOLD TRAINING is a CQI and IRCA Approved Training Partner, ATP number 6039853. Its ISO 27001 Lead Auditor training course is the CQI and IRCA Certified ISO/IEC 27001:2022 Lead Auditor (Information Security Management Systems) Training Course. The course identification number is 2889. Both the partner approval and the course certification are on 3FOLD TRAINING’s Approved Training Partner record, and any provider’s certified courses can be looked up in CQI and IRCA’s own directory of certified courses and approved training partners. The course page carries the schedule and what the course includes. If you would rather ask a person first, use the course enquiry form.