ISO 27001 for Auditors: What to Ask, Clause by Clause

Auditing ISO/IEC 27001 is not the same as understanding it. An implementer asks what the standard requires them to build. An auditor asks what evidence would demonstrate it, what a broken version looks like, and which clause a given failure belongs to. This page goes through the clauses in the second spirit.

Three things to hold on to before the ISO 27001 clauses

Every audit finding, on any clause, reduces to the same three things: the requirement (what the criteria demand), the objective evidence (what you actually saw, read or were told and verified), and the gap between them. A finding that cannot name all three is an opinion.

You audit against criteria, not against your own judgement. The criteria are the standard, the organisation’s own documented information, and any legal or contractual requirements. An auditor who would have designed the control differently has an opinion, not a finding.

Scope and criteria are different things, and there are two different scopes. The audit scope is the boundary of the audit — sites, units, activities, the period covered. The ISMS scope is the boundary of the management system, determined by the organisation under Clause 4.3, and is itself something you audit. Criteria are what you audit against: the standard, the organisation’s own documented information, and applicable legal and contractual requirements. Confusing any of the three produces findings that cannot be defended.

One note on sources. Clause references here are to ISO/IEC 27001, and definitions are given in short form rather than reproduced, because the standards are copyright documents you buy. Where a requirement is commonly summarised in words that are not in the clause, this page says which is which — that distinction is what makes a finding citable.

ISO 27001 Clause 4 — Context of the organization

Clause 4.3 names three things the organisation must consider when determining the scope, and the third is the one most often forgotten: the external and internal issues from 4.1, the interested-party requirements from 4.2, and the interfaces and dependencies between what the organisation does and what other organisations do for it. The scope must be available as documented information. That third consideration is what makes cloud, outsourced and shared-service scopes auditable.

What to ask. Is the scope available as documented information? Which internal and external issues, which interested-party requirements, and which interfaces and dependencies were considered? Does any of that feed the risk assessment and the objectives? Clause 4.4 also requires the ISMS itself, including the processes needed and their interactions — which is the hook for asking to see how the system actually fits together.

What broken looks like. A scope that has been narrowed artificially so that the risky part of the business falls outside it. That is the finding to look for, and it is rarely stated openly — you find it by reading the scope alongside what the organisation actually does.

ISO 27001 Clause 5 — Leadership

What to ask. Clause 5.2 asks more of a policy than most summaries suggest: that it is appropriate to the purpose of the organisation, that it includes objectives or a framework for setting them, that it commits to satisfying applicable requirements and to continual improvement, that it is available as documented information, communicated within the organisation, and available to interested parties as appropriate. That last one is a common finding. Clause 5.3 asks whether roles, responsibilities and authorities are assigned and communicated.

How to audit the bit that resists direct evidence. Top management commitment is real but not documentable on its own, so probe it through other clauses. Were the resources Clause 7.1 requires actually provided? Did the management review Clause 9.3 requires actually take place, with management present and decisions recorded? Commitment that produced neither resources nor decisions is a claim rather than a fact.

ISO 27001 Clause 6 — Planning

The risk engine, and the most heavily audited clause in the standard. It deserves more space than the others because most substantive findings live here or downstream of here.

Start before the risk assessment. Clause 6.1.1 requires the organisation to determine the risks and opportunities that need addressing for the ISMS to achieve its intended outcomes, and to plan actions and how their effectiveness will be evaluated. Separate from 6.1.2, auditable in its own right, and routinely skipped by auditors who go straight to the risk register.

The trail to follow. Do not ask to see the risk register and read it. Take one or two real risks and walk them all the way through:

Is there a defined, documented risk assessment method that produces consistent, valid and comparable results?

For your chosen risk: is it identified, is its owner named, and were likelihood and impact analysed and the level evaluated against defined criteria?

Which treatment option was chosen, which controls were determined, and were those compared against Annex A so that nothing necessary was omitted?

Does it reconcile to the Statement of Applicability — applicable, justified, with an implementation status that matches what you traced?

Does a risk treatment plan exist, and is it being progressed?

Did the risk owners approve the plan and accept the residual risks, with records?

Is the process live — repeated at planned intervals or when significant changes are proposed or occur, with results retained?

The useful part is what a break tells you. A missing owner points to the risk assessment requirements. A control excluded without justification, or a Statement of Applicability that does not reconcile, points to the risk treatment requirements. Residual risks never accepted point to the acceptance requirement specifically. A risk assessment never repeated points to Clause 8. Knowing which break belongs to which clause is most of what the exam tests in this area.

The Statement of Applicability is where an organisation’s risk decisions and its controls meet, and it is required by Clause 6.1.3 d). Learn the letter, not just the clause: the sub-clause letters are how a finding gets cited. It must contain the necessary controls — those determined for risk treatment, which need not all come from Annex A — the justification for including each of them whether implemented or not, their implementation status, and the justification for excluding any Annex A control.

It is not the risk treatment plan, and the two get muddled constantly. The risk treatment plan says how identified risks will be treated. The Statement of Applicability says which controls are applicable, why, and whether they are in place.

Reading an ISO 27001 Statement of Applicability like an auditor

Four questions per line, and three patterns that reliably produce findings.

Per line: applicable or excluded? What is the justification, and does it make sense given this organisation’s risks? Marked implemented — and can that be demonstrated? Does the picture reconcile with the risk assessment and the risk treatment plan?

An exclusion with a weak or missing justification. Cryptography excluded as “not relevant” by an organisation that plainly transmits sensitive data.

A control marked implemented that operational evidence contradicts. The Statement of Applicability says backups are tested; operations cannot show a single restore test.

A mismatch with the risk assessment. A high risk whose only treatment control is marked excluded.

ISO 27001 Clause 7 — Support

What to ask. Competence records for the people in security roles. Awareness activity that reached actual staff rather than a training plan that describes reaching them. Defined communication. Document control that works.

The classic finding. An obsolete, uncontrolled version of a policy in use while a newer approved version exists. It is a control-of-documented-information failure, it is extremely common, and it is found by asking the person doing the work to show you the version they use rather than asking the quality manager for the current one.

ISO 27001 Clause 8 — Operation

Clause 8 is where you test whether the design in Clause 6 is real. The controls in the Statement of Applicability — are they operating? Are risk assessments repeated at planned intervals or when significant changes are proposed or occur? Note the clause’s or: the two triggers stand independently, so keeping to a stated interval does not answer a significant change that went unassessed. Clause 8.1 also requires that externally provided processes, products or services relevant to the ISMS are controlled — note the breadth of that wording, which reaches a bought service as readily as an outsourced process, and is wider than the “outsourced processes” formulation it replaced.

A useful habit: pick the control the organisation is proudest of and ask to see it working on a real record, rather than in the procedure that describes it.

ISO 27001 Clause 9 — Performance evaluation

What to ask. Monitoring with metrics that mean something. An internal audit programme that considers the importance of the processes concerned and the results of previous audits, defines criteria and scope for each audit, and selects auditors and conducts audits in a way that ensures objectivity and the impartiality of the audit process. Management reviews that considered the required inputs and produced decisions, with records.

And note what an audit examines, because “conformity” alone is an incomplete answer. An internal audit must determine whether the ISMS conforms to the organisation’s own requirements and to the standard and whether it is effectively implemented and maintained. In third-party certification, evaluating implementation including effectiveness is the stated purpose of the second-stage audit.

Two phrases in common use are not clause text, and knowing what stands behind each matters when you write the requirement out. “Auditors must not audit their own work” is the practical consequence of 9.2.2, which requires auditors to be selected and audits conducted so as to ensure objectivity and the impartiality of the audit process — cite the clause, not the phrase. “The whole ISMS and all applicable controls” stands for 9.2.1, which states what internal audits are conducted to provide information about: whether the ISMS a) conforms to the organisation’s own requirements for it and to the requirements of the standard, and b) is effectively implemented and maintained. Both limbs are requirements, so audits that do not deliver that information are citeable at 9.2.1 in their own right; how the programme is planned to deliver it, including the importance of the processes concerned, is 9.2.2.

What broken looks like. A programme that audits the same three comfortable areas every cycle. Objectivity that fails because the person who runs a process audited it. A management review whose minutes record attendance and no decisions.

ISO 27001 Clause 10 — Improvement

Nonconformity and corrective action, and the distinction the exam returns to more than any other.

Correction eliminates the detected nonconformity — the immediate fix. Corrective action eliminates the cause so that the nonconformity does not recur or occur elsewhere.

Clause 10.2 sets out five steps: react to the nonconformity, controlling and correcting it and dealing with the consequences; evaluate the need for action to eliminate the causes by reviewing the nonconformity, determining its causes and determining whether similar ones exist or could occur; implement any action needed; review the effectiveness of any corrective action taken; and change the ISMS if necessary. Documented information is required on the nature of the nonconformity, the actions taken and the results of any corrective action.

Read that carefully, because the common summary overstates it. The standard mandates the evaluation of cause, not corrective action in every case. An organisation that evaluated a genuine one-off and justifiably concluded no further action was needed has conformed. The defensible finding against a correction-only response is not “you did not take corrective action” but “there is no evidence you evaluated the need for it”. That distinction is worth marks.

So an organisation that responds to every finding by fixing the instance is worth a hard look, because it usually explains why the same issues keep appearing. Establish first whether cause was ever evaluated, and write the finding on that.

ISO 27001 Annex A, and what it is not

Annex A is normative, and the distinction that matters to an auditor is between implementing and considering. Nothing requires an organisation to implement all 93. Clause 6.1.3 c) requires the controls determined by the risk treatment to be compared against Annex A so that no necessary control is missed, and 6.1.3 d) requires any Annex A control excluded to be justified. So the auditable questions are whether every control was considered, whether the exclusions hold up, and whether what was selected operates.

An auditor’s interest is not whether all 93 are implemented — that would be the wrong question — but whether every one was considered, whether the selection is justified by the risk assessment, whether the exclusions hold up, and whether the selected controls operate.

The other standards an ISO 27001 auditor uses, and what each is for

The mnemonic worth carrying: ISO/IEC 27001 is what the organisation must achieve; ISO 19011 is how any audit is conducted; the certification-body standards are how an accredited body must operate when it audits and certifies. And one precedence rule that catches people: for third-party certification audits, the certification-body requirements take precedence over the general guidance in ISO 19011 where the two differ.

Frequently asked questions about auditing ISO 27001

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

What an information security management system actually is

Confidentiality, integrity and availability in an audit

Threat, vulnerability, asset and control

Six myths that cost Lead Auditor candidates marks

The ISO 27001 Lead Auditor training course teaches this against a full case study, and is the CQI and IRCA certified route.

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.