ISO/IEC 27001 Clauses Explained Template (Clauses 4 to 10)

ISO/IEC 27001 Clauses Explained: [Organization name]

A plain-language guide to clauses 4 to 10 of ISO/IEC 27001:2022 + Amd 1:2024, the requirement clauses an organisation is certified against. For each clause it explains the intent, what you must produce, what auditors look for, the nonconformities auditors raise most often and which templates in this library to use. It supports learning and the planning of an information security management system (ISMS), and can be kept as an internal reference under clause 7.5. All explanations are original wording: the standard's text is not reproduced, and you need the official standard to implement it. Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

1. How to read this guide
2. The structure of ISO/IEC 27001:2022
3. What changed in 2022 and in Amendment 1:2024
4. Clause 4: context of the organization
5. Clause 5: leadership
6. Clause 6: planning
7. Clause 7: support
8. Clause 8: operation
9. Clause 9: performance evaluation
10. Clause 10: improvement
11. Annex A and its link to the clauses
12. Required documented information at a glance
13. Size tiers: how the clauses play out
14. Our position per clause
15. Records and evidence
16. References

1. How to read this guide

Each clause section uses the same five headings:

• Intent: what the clause is trying to achieve, in plain words.
• What you must produce: the decisions, activities and records the clause leads to. Items marked (documented) are documented information the standard explicitly requires; the rest may be kept in any form, but you will need some evidence that they happen.
• What auditors look for: the questions and samples an auditor typically uses. These come from audit practice, not from the standard.
• Common nonconformities: the gaps auditors raise most often.
• Templates: the library templates that help, with Document IDs from the library register.

"Shall" statements in the standard are requirements. Notes in the standard are guidance and are not audited as requirements. This guide does not use the standard's wording; when in doubt, the official text prevails.

2. The structure of ISO/IEC 27001:2022

ISO/IEC 27001:2022 follows the harmonized structure that ISO uses for all management system standards, so its clause headings match ISO 9001, ISO 22301, ISO/IEC 42001 and others. That is why an integrated management system can share one context analysis, one document control process and one management review.

The clauses form a cycle. Context and leadership frame the system; planning decides what to do about risk; support and operation do it; performance evaluation checks it; improvement fixes what the checks find, and the cycle starts again.

3. What changed in 2022 and in Amendment 1:2024

Main changes from the 2013 edition, in summary:

Amendment 1:2024, published 2024-02-23, adds climate change: in clause 4.1 the organisation determines whether climate change is a relevant issue, and a note in clause 4.2 says interested parties can have climate-related requirements. Annex A did not change. Certification bodies audit the amended text; most organisations answer it with a documented decision in their context analysis, which may be "not relevant" with a real reason.

4. Clause 4: context of the organization

4.1 Understanding the organization and its context

Intent. An ISMS built without looking at the real business protects the wrong things. Look outward and inward first: the market you sell into, the laws you face, your technology and threat picture, how the company is run and, since 2024, whether climate change matters to you at all.

What you must produce. A list of relevant issues, kept current, with a decision on climate change. The standard does not require this list to be documented, but auditors will expect to see it.

What auditors look for. Issues that are specific to the organisation rather than generic; evidence that issues feed risk assessment (6.1) and management review (9.3); a recorded climate change decision.

Common nonconformities. No climate change decision; issues copied from a template that do not match the business; issues never reviewed.

4.2 Understanding the needs and expectations of interested parties

Intent. Security is done for someone. Identify the people and bodies whose expectations you must meet (customers, regulators, staff, suppliers, owners), find out what they actually expect, and decide openly which of those expectations the ISMS takes on.

What you must produce. A list of interested parties, their relevant requirements, and the decision on which requirements the ISMS addresses. Legal, regulatory and contractual requirements usually sit in a separate register.

What auditors look for. Contract clauses and laws that appear in the register and then in controls; the "addressed through the ISMS" decision.

Common nonconformities. Requirements listed but never traced to controls; contractual security clauses missing from the register.

4.3 Determining the scope of the ISMS

Intent. Everyone, including the auditor, needs to know what is in and what is out. The line is drawn around business units, sites, services, data and systems, and it has to make sense given your context, your obligations and what you depend on outside the line.

What you must produce. The scope (documented).

What auditors look for. A scope that matches what the certificate will say; interfaces with cloud providers, group functions and outsourced services; exclusions that do not remove things customers rely on.

Common nonconformities. Scope silent on dependencies; scope that excludes the people or systems that actually handle in-scope information.

4.4 Information security management system

Intent. This is the clause that holds the rest together: the ISMS is not a binder but a set of working processes, each with an owner, that hand results to one another and get better over time.

What you must produce. A view of ISMS processes and their interactions, often a process map.

What auditors look for. That processes are defined with owners and inputs and outputs, and that they actually connect (risk results feed the SoA, audit findings feed corrective action).

Common nonconformities. Processes that exist on paper but have no owner.

Templates for clause 4. isms/isms-context-interested-parties (DOC-ISMS-003), compliance/legal-register (DOC-ISMS-014), compliance/ms-scope (DOC-ISMS-002), isms/isms-process-map (DOC-ISMS-004), isms/scope-extension-multisite-plan (DOC-ISMS-095).

5. Clause 5: leadership

5.1 Leadership and commitment

Intent. Security fails when leaders treat it as an IT side project. Leadership has to be visibly in charge: aligning security with business strategy, weaving it into how work is done, funding it, explaining why it matters, and checking that it delivers. They also back the managers who carry security in their own areas and push for things to keep improving.

What you must produce. Evidence of active involvement: decisions, resource approvals, review minutes, communications.

What auditors look for. An interview with top management; decisions in management review minutes; budget approvals; a sponsor who knows the main risks.

Common nonconformities. Top management absent from management review; security delegated entirely to one person with no authority.

5.2 Policy

Intent. The policy is leadership's statement of direction. It has to suit this business, point to where objectives come from, and put on record that the organisation will meet its obligations and keep improving the ISMS.

What you must produce. The information security policy (documented), communicated inside the organisation and available to interested parties as appropriate.

What auditors look for. The two commitments in the policy; approval by top management; staff who know where it is and what it means for them.

Common nonconformities. Policy missing one of the commitments; policy not communicated to contractors.

5.3 Organizational roles, responsibilities and authorities

Intent. Security work falls through the cracks when nobody owns it. People need to know who does what, and one named role must have the mandate to keep the ISMS in line with the standard and tell leadership how it is performing.

What you must produce. Role assignments, communicated within the organisation. A RACI is a common format.

What auditors look for. Named owners for the ISMS, risks, controls and assets; people who know their role when asked.

Common nonconformities. Roles in a document that staff have never seen; the ISMS manager role has no reporting line to top management.

Templates for clause 5. compliance/information-security-policy (DOC-ISMS-001), isms/isms-policy-framework (DOC-ISMS-005), isms/isms-roles-raci (DOC-ISMS-006), isms/isms-steering-committee-charter (DOC-ISMS-007), isms/information-security-governance-27014 (DOC-ISMS-104).

6. Clause 6: planning

6.1.1 General

Intent. Before diving into specific security risks, step back: given what you learned in 4.1 and 4.2, what could knock the ISMS off course and what could help it? Plan responses, make them part of normal ISMS work and later check they made a difference.

What you must produce. Planned actions for ISMS-level risks and opportunities (for example lack of resources, a new regulation). These are broader than information security risks to assets.

What auditors look for. That ISMS-level risks and opportunities are considered, not only asset risks.

Common nonconformities. Opportunities never considered; actions not evaluated.

6.1.2 Information security risk assessment

Intent. Risk assessment drives the whole ISMS, so it must not depend on who happens to do it. Agree the rules and scales up front, including what level of risk is tolerable, then look for anything that could harm the confidentiality, integrity or availability of in-scope information, give each risk an owner, rate it, and rank it against your own rules.

What you must produce. The risk assessment process (documented). This library uses likelihood 1 to 5 times impact 1 to 5, score 1 to 25, bands Low 1-4, Medium 5-9, High 10-16 and Critical 17 to 25 (in practice 20 and 25, since no score between 17 and 19 is possible).

What auditors look for. Criteria defined before assessment; a risk owner for every risk; the same scale used across the organisation; results that a second assessor could reproduce.

Common nonconformities. No acceptance criteria; risk owners missing or named as teams; criteria changed between assessments without a record.

6.1.3 Information security risk treatment

Intent. Turn the ranked risks into decisions. For each risk pick a response and the controls that deliver it, wherever they come from, then use Annex A as a cross-check for gaps. The outcome is a Statement of Applicability, a plan of work, and a sign-off from the people who own the risks, including on what is left over after treatment.

What you must produce. The risk treatment process (documented). The Statement of Applicability (documented), listing the necessary controls, why each is included, whether each is implemented, and why any Annex A control is excluded. A risk treatment plan with risk owner approval and residual risk acceptance.

What auditors look for. An SoA that matches the risk treatment plan and reality; justified exclusions; residual risk accepted by the right level (in this library: Low by the risk owner, Medium by the risk owner plus the department head, High by top management with a treatment decision, Critical only with treatment or a documented top management decision).

Common nonconformities. SoA exclusions without a reason; controls marked "implemented" with no evidence; no record of residual risk acceptance.

6.2 Information security objectives and planning to achieve them

Intent. Objectives turn the policy into targets people can work towards. They should line up with the policy, be measurable where that is sensible, reflect your obligations and risk picture, be tracked, shared and refreshed, and each needs a plan: the work, the resources, the owner, the deadline and how success will be judged.

What you must produce. The objectives (documented) with their plans.

What auditors look for. Objectives with a measure and target; progress reported to management review; links to risk and requirements.

Common nonconformities. Objectives that cannot be measured ("improve security"); no monitoring of progress.

6.3 Planning of changes

Intent. Changes to the ISMS itself (new scope, reorganisation, new site, new technology) should be thought through before they happen, not discovered afterwards. New in 2022.

What you must produce. Evidence that changes were planned. The clause has no explicit documented information requirement.

What auditors look for. A recent change (a merger, a new cloud platform, a new site) and how it was planned.

Common nonconformities. Major change made with no ISMS planning.

Templates for clause 6. compliance/risk-methodology (DOC-ISMS-010), isms/isms-risk-appetite-criteria (DOC-ISMS-015), compliance/asset-inventory (DOC-ISMS-012), isms/isms-threat-vulnerability-catalogue (DOC-ISMS-018), compliance/risk-register (DOC-ISMS-016), compliance/risk-treatment-plan (DOC-ISMS-013), isms/isms-risk-acceptance-record (DOC-ISMS-019), compliance/statement-of-applicability (DOC-ISMS-011), compliance/objectives-register (DOC-ISMS-024), isms/isms-change-plan (DOC-ISMS-025).

7. Clause 7: support

7.1 Resources

Intent. An ISMS without people, time, budget and tools behind it exists only on paper.

What you must produce. Evidence that resources were determined and provided, such as a budget and staffing plan.

What auditors look for. Whether the ISMS manager has the time stated; overdue actions that point to too few resources.

Common nonconformities. Persistent overdue treatment actions with no resource decision.

7.2 Competence

Intent. Anyone whose work affects security needs to be capable of doing it well. Work out what each such role needs to know, close any gaps (training, coaching, hiring), check that closing them worked, and be able to prove it.

What you must produce. Evidence of competence (documented).

What auditors look for. The competence of the ISMS manager, internal auditors and key control owners; evaluation of training effectiveness.

Common nonconformities. Training records with no defined competence requirement; no evidence for internal auditors' competence.

7.3 Awareness

Intent. Security depends on ordinary staff, not only specialists. Each person working for you should know the policy exists, see how their own work helps, understand what the ISMS gives the organisation, and know the consequences of ignoring it.

What you must produce. An awareness programme and evidence it reaches everyone, including contractors.

What auditors look for. Interviews with staff at random; completion rates; contractors included.

Common nonconformities. Staff unaware of how to report an incident.

7.4 Communication

Intent. Communication about the ISMS should be planned, not left to chance: the message, its timing, the audience and the channel, both inside the organisation and outside it.

What you must produce. Communication arrangements, often a plan.

What auditors look for. That planned communications happened.

Common nonconformities. External communication (customers, authorities) not planned.

7.5 Documented information

Intent. Paperwork should serve the ISMS, not bury it. Keep what the standard names plus whatever you decide you need (7.5.1). Make each item identifiable, in a usable form and approved before use (7.5.2). Then keep it under control so the right people can find the current version, nobody can tamper with it, old versions are retired and kept or destroyed on purpose, and outside documents you rely on are tracked too (7.5.3).

What you must produce. The documents and records listed in section 12, plus those you decide are necessary (documented), under control.

What auditors look for. Version and approval on documents; obsolete versions withdrawn; records protected from change; external documents (standards, contracts) controlled.

Common nonconformities. Uncontrolled copies; no owner or review date; records editable by anyone.

Templates for clause 7. isms/isms-budget-resource-plan (DOC-ISMS-031), isms/isms-competence-training-matrix (DOC-ISMS-026), security/security-awareness-program, isms/employee-security-handbook (DOC-ISMS-073), isms/isms-communication-plan (DOC-ISMS-027), isms/isms-documented-information-register (DOC-ISMS-028), compliance/controlled-document.

8. Clause 8: operation

8.1 Operational planning and control

Intent. Clause 8 is where plans become routine work. Decide how each ISMS process and each clause 6 action should run, run it that way, keep enough records to show it did, manage changes you intend and clean up after ones you did not, and keep a grip on anything outsourced that matters to the ISMS.

What you must produce. Operational records to the extent necessary (documented): for example change records, supplier reviews, control operation logs.

What auditors look for. Records of controls operating over time; how a cloud provider or outsourced service is controlled; a change sample.

Common nonconformities. No control over a key outsourced service; unplanned changes with no review.

8.2 Information security risk assessment

Intent. Risk is not assessed once and forgotten. Repeat the assessment on a schedule and whenever something big changes or is about to, always with the same rules from 6.1.2.

What you must produce. Risk assessment results (documented).

What auditors look for. A dated assessment within the planned interval; reassessment after a significant change.

Common nonconformities. Risk register not updated after a major change.

8.3 Information security risk treatment

Intent. Do the work the risk treatment plan promised.

What you must produce. Risk treatment results (documented).

What auditors look for. Treatment actions completed or tracked with dates; residual risk re-evaluated after treatment.

Common nonconformities. Plan written but not executed; overdue actions with no escalation.

Templates for clause 8. isms/control-evidence-matrix (DOC-ISMS-033), isms/isms-annual-calendar (DOC-ISMS-032), isms/isms-risk-assessment-report (DOC-ISMS-017), isms/supplier-register (DOC-ISMS-066), compliance/supplier-security-assessment (DOC-ISMS-067), isms/security-operating-procedure (DOC-ISMS-049), ops/change-request.

9. Clause 9: performance evaluation

9.1 Monitoring, measurement, analysis and evaluation

Intent. You cannot manage what you do not measure. Choose the processes and controls worth tracking, define how and how often, name who collects the data and who interprets it, then judge both how well security performs and whether the ISMS is worth what it costs. A number is only useful if someone else could repeat it and compare it over time.

What you must produce. Monitoring and measurement results (documented).

What auditors look for. Defined measures with owners; results that are analysed, not just collected; evaluation reported to management.

Common nonconformities. Dashboards with no analysis; measures with no defined method.

9.2 Internal audit

Intent. Internal audit is the organisation checking its own homework before anyone else does: is the ISMS doing what the standard and your own rules say, and is it really working (9.2.1)? Plan audits over a cycle, giving more attention to what matters most and what went wrong before, set the boundaries of each audit, use auditors with no stake in the area, and make sure the right managers hear the results (9.2.2).

What you must produce. The audit programme and audit results (documented).

What auditors look for. All clauses and applicable controls covered over the programme; auditors not auditing their own work; findings followed up.

Common nonconformities. Audit programme missing parts of the scope; ISMS manager auditing the processes they run.

9.3 Management review

Intent. Leadership steps back on a regular cycle and asks whether the ISMS still fits the business, is big enough and works (9.3.1). They look at what happened to last time's actions, what has changed around and inside the organisation, how security has performed (findings, metrics, audits, objectives), what interested parties are saying, where risk stands, and where things could be better (9.3.2). The review ends in decisions (9.3.3).

What you must produce. Management review results (documented).

What auditors look for. Every input addressed; decisions and actions recorded with owners; top management present.

Common nonconformities. Missing inputs (often interested party changes or risk treatment status); no decisions recorded.

Templates for clause 9. isms/isms-measurement-programme (DOC-ISMS-080), isms/isms-performance-report (DOC-ISMS-081), compliance/internal-audit-program (DOC-ISMS-082), isms/isms-internal-audit-checklist (DOC-ISMS-083), isms/isms-internal-audit-report (DOC-ISMS-084), compliance/management-review (DOC-ISMS-085).

10. Clause 10: improvement

10.1 Continual improvement

Intent. The ISMS should get better each year, not just stay compliant.

What you must produce. Evidence of improvements over time, often an improvement register.

What auditors look for. Improvements that come from audits, incidents, measurement and reviews, not only from nonconformities.

Common nonconformities. No evidence of improvement between audits.

10.2 Nonconformity and corrective action

Intent. When something goes wrong, first contain and fix it and deal with the fallout. Then dig into why it happened and whether it could happen elsewhere, decide whether a deeper fix is warranted, do it, check it worked, and adjust the ISMS if needed. The size of the response should match the size of the problem.

What you must produce. Records of the nature of nonconformities, actions taken and results of corrective action (documented).

What auditors look for. Root cause analysis; effectiveness reviews; a search for similar cases.

Common nonconformities. Corrections closed as corrective actions with no root cause; no effectiveness check.

Templates for clause 10. isms/audit-findings-register (DOC-ISMS-086), compliance/capa-nonconformity (DOC-ISMS-087), isms/continual-improvement-register (DOC-ISMS-088), isms/post-incident-review (DOC-ISMS-022).

11. Annex A and its link to the clauses

Annex A lists 93 reference controls in four themes: A.5 organizational (37), A.6 people (8), A.7 physical (14) and A.8 technological (34). Eleven are new in 2022: A.5.7, A.5.23, A.5.30, A.7.4, A.8.9, A.8.10, A.8.11, A.8.12, A.8.16, A.8.23 and A.8.28.

Annex A works through clause 6.1.3. You decide the controls needed to treat your risks, from any source, then compare them with Annex A to check that nothing necessary is missing. The Statement of Applicability records the result for all 93 controls. ISO/IEC 27002:2022 gives guidance on each control and adds attributes (control type, information security properties, cybersecurity concepts, operational capabilities, security domains) that help group and filter them. The cybersecurity concepts attribute uses the five functions Identify, Protect, Detect, Respond and Recover (as in the NIST Cybersecurity Framework 1.1; NIST CSF 2.0 later added Govern, which is not a 27002 attribute value). Attributes are optional aids, not requirements.

For plain-language explanations of each theme, see isms/annex-a-organizational-controls-guide, isms/annex-a-people-physical-controls-guide and isms/annex-a-technological-controls-guide.

12. Required documented information at a glance

Clause 6.3 (planning of changes) has no explicit documented information requirement. Many organisations still keep a change plan (isms/isms-change-plan, DOC-ISMS-025) because it is the easiest evidence.

13. Size tiers: how the clauses play out

Tiers are the library's working tiers (small under 50 people, medium 50 to 500, large or multi-site over 500 or several sites).

14. Our position per clause

15. Records and evidence

Records that show this guide is used and that the clauses are met:

See isms/control-evidence-matrix for the full mapping of records to clauses and controls.

16. References

Related templates: isms/isms-learning-path, isms/isms-glossary, isms/isms-self-test, isms/annex-a-organizational-controls-guide, isms/annex-a-people-physical-controls-guide, isms/annex-a-technological-controls-guide, isms/certification-audit-explained, compliance/iso-27001-gap-assessment, isms/isms-documented-information-register, isms/control-evidence-matrix.

Standard and licence note

Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 clauses 4 to 10 and Annex A. All explanations, audit tips, nonconformity examples and tables are original text written as plain-language paraphrase. No ISO or IEC text, requirement wording, control titles in full, notes or definitions are reproduced; you need the official standard to implement or audit against it, and the official text prevails over this guide. Editions change: check the current edition on iso.org before you rely on this guide. This is a learning aid, not certification or legal advice; certification decisions belong to the accredited certification body. Template licence: MIT.