ISO 27001 clauses are not just headings to memorize. For implementation, the useful question is: what does each clause require your organization to operate, document, assign, review, and evidence?
This guide focuses on ISO/IEC 27001:2022 clauses 4–10: the ISMS requirements an organization must deal with when claiming conformity. It translates each main clause and important subclause into practical actions, likely ownership, documents or records to consider, and example evidence that may support audit readiness.
ISO 27001 clauses at a glance: what is mandatory, supporting, and risk-based
ISO/IEC 27001:2022 is structured with an introduction; clauses 1–3 covering scope, normative references, and terms; clauses 4–10 covering ISMS requirements; and normative Annex A, “Information security controls reference” (ISO/IEC 27001:2022 preview).
Basically, the practical distinction matters:
| Part of ISO 27001 | Role in implementation |
|---|---|
| Introduction and clauses 1–3 | Provide framing, scope, references, and terminology. |
| Clauses 4–10 | Define the ISMS management system requirements. When an organization claims conformity to ISO/IEC 27001, these requirements apply and cannot be excluded. Certification is voluntary and performed by an independent certification body, not ISO (ISO/IEC JTC 1/SC 27). |
| Annex A | Provides a control reference set for risk treatment. Controls are selected based on risk and applicability; every Annex A control is not automatically required. |
Annex A in ISO/IEC 27001:2022 contains 93 controls grouped as organizational, people, physical, and technological controls (ISO/IEC JTC 1/SC 27). This article keeps Annex A directional because the main implementation work starts with clauses 4–10.
How to read clauses 4–10 as an implementation system
The clause order is a useful operating model, not just a table of contents. ISO 27001 moves from context and leadership through planning, support, operation, performance evaluation, and improvement (ISO/IEC 27001:2022 preview).
Read the clauses this way:
- Clause 4 defines the ISMS boundary. You identify the organization’s context, interested parties, and scope.
- Clause 5 establishes accountability. Leadership sets direction through policy, roles, responsibilities, and authorities.
- Clause 6 turns context into plans. You address risks and opportunities, define the risk assessment and treatment approach, and set information security objectives.
- Clause 7 supplies the system. You provide resources, competence, awareness, communication, and control of documented information.
- Clause 8 operates the ISMS. You run the planned processes, perform risk assessments, and execute risk treatment.
- Clause 9 checks whether it works. You monitor, measure, audit, and review the ISMS.
- Clause 10 fixes and improves it. You handle nonconformities, corrective action, and continual improvement.
That flow is also how evidence tends to become credible. In practice. Policies should match scope, risk treatment should match assessed risk, records should show operation, and reviews should drive improvement.
Clause-by-clause practical guide to ISO 27001 clauses 4–10
The tables below are practical implementation aids, not official ISO templates. Owners, documents, and evidence examples are illustrative and vary by organization. A certification assessment may consider documented information, observed processes, staff interviews, and other verification needed to gain confidence, where needed, that the ISMS is implemented and effective (ISO/IEC 27001 practical guide for SMEs).
Clause 4: Context of the organization
| Clause/subclause | What it means | Practical action | Typical owner | Document or record to consider | Example audit evidence may include | Annex A relationship |
|---|---|---|---|---|---|---|
| 4.1 Understanding the organization and its context | Identify internal and external issues that affect the ISMS. | Document business, technical, regulatory, supplier, and threat-context factors that shape security decisions. | Compliance lead, security lead, executive sponsor | Context analysis, risk inputs, business environment notes | Context register, workshop notes, leadership review records | Informs which risks and controls are relevant. |
| 4.2 Understanding the needs and expectations of interested parties | Identify relevant stakeholders and their information security requirements. | List customers, regulators, employees, suppliers, partners, and internal functions with relevant security expectations. | Compliance lead, legal, customer/security team | Interested-party register, requirements register | Customer security requirements, contractual security clauses, regulatory obligations inventory | Helps determine risk criteria and control obligations. |
| 4.3 Determining the scope of the information security management system | Define the boundaries of the ISMS. | Specify included entities, products, locations, systems, processes, teams, and interfaces. | Executive sponsor, security lead, compliance lead | ISMS scope statement | Approved scope, system boundary diagrams, included/excluded service rationale | Determines where Annex A control decisions apply. |
| 4.4 Information security management system | Establish, implement, maintain, and improve the ISMS. | Define the core ISMS processes and how they interact: risk, policies, operations, monitoring, audits, reviews, corrective action. | ISMS owner, compliance lead | ISMS process map, governance model | ISMS calendar, process descriptions, ownership records | Provides the management system that governs control selection and operation. |
ISO/IEC 27001:2022 has Amendment 1:2024, which addresses climate action changes (ISO). If your organization is updating clause 4 materials, verify the consolidated current wording before final approval.
Clause 5: Leadership
| Clause/subclause | What it means | Practical action | Typical owner | Document or record to consider | Example audit evidence may include | Annex A relationship |
|---|---|---|---|---|---|---|
| 5.1 Leadership and commitment | Top management must support and direct the ISMS. | Show leadership involvement in policy, objectives, resourcing, risk decisions, and management review. | CEO, CTO, CISO, executive sponsor | Governance charter, leadership review notes | Management review attendance, approved objectives, resourcing decisions | Leadership approves priorities that affect control investment. |
| 5.2 Policy | Establish an information security policy appropriate to the organization. | Create and approve a policy that sets direction, commitments, and expectations for the ISMS. | Executive sponsor, security lead | Information security policy | Approved policy, version history, publication or acknowledgement records | Policy direction guides control expectations. |
| 5.3 Organizational roles, responsibilities and authorities | Assign responsibility and authority for ISMS roles. | Define who owns the ISMS, risks, controls, policies, audits, and corrective actions. | Executive sponsor, compliance lead, HR where relevant | RACI, role descriptions, responsibility matrix | Assigned risk/control owners, job descriptions, governance records | Control ownership should align to selected Annex A controls. |
Clause 6: Planning
| Clause/subclause | What it means | Practical action | Typical owner | Document or record to consider | Example audit evidence may include | Annex A relationship |
|---|---|---|---|---|---|---|
| 6.1.1 Actions to address risks and opportunities — General | Plan how the ISMS will address risks and opportunities arising from context and stakeholder requirements. | Define how security risks, ISMS risks, and improvement opportunities are identified, evaluated, and acted on. | Security lead, compliance lead, risk owner | Risk management procedure, opportunity/gap log | Risk methodology approval, planning records, issue registers | Creates the planning basis for control selection. |
| 6.1.2 Information security risk assessment | Define and apply a repeatable method for assessing information security risk. | Establish risk criteria, assessment process, likelihood/impact approach, and risk acceptance rules. | Security lead, risk manager, system owners | Risk assessment methodology, risk register | Completed risk assessments, asset/process risk records, accepted risk decisions | Identifies risks that may require Annex A or other controls. |
| 6.1.3 Information security risk treatment | Decide how assessed risks will be treated. | Select treatment options, identify controls, compare them with Annex A, and prepare risk treatment plans. | Security lead, control owners, risk owners | Risk treatment plan, Statement of Applicability | Treatment decisions, control assignments, SoA entries, implementation status | Direct link to Annex A and the SoA. |
| 6.2 Information security objectives and planning to achieve them | Set measurable or evaluable information security objectives and plan how to achieve them. | Define objectives, owners, measures, target dates or review points, and required resources. | Executive sponsor, security lead, compliance lead | Information security objectives, objective plan | Objective tracking, KPI/KRI reports, leadership review outputs | Objectives may drive control improvements or treatment priorities. |
Clause 7: Support
| Clause/subclause | What it means | Practical action | Typical owner | Document or record to consider | Example audit evidence may include | Annex A relationship |
|---|---|---|---|---|---|---|
| 7.1 Resources | Provide the resources needed for the ISMS. | Identify people, tools, budget, external support, and time required to operate ISMS processes. | Executive sponsor, security lead | Resource plan, budget notes, staffing plan | Approved budgets, tool ownership, support contracts | Resources help selected controls operate. |
| 7.2 Competence | Ensure people doing ISMS work are competent. | Define required competencies for security, risk, audit, control, and process roles; close gaps through training or hiring. | HR, security lead, compliance lead | Competence matrix, training records | Training completion, qualifications, role-based onboarding records | Supports people-dependent controls and process reliability. |
| 7.3 Awareness | Ensure relevant people understand information security policy, contribution, and consequences. | Run awareness activities tied to roles, policy, reporting channels, and expected behavior. | Security awareness owner, HR, managers | Awareness plan, training materials | Attendance logs, acknowledgements, phishing education records where applicable | Supports people controls and policy adoption. |
| 7.4 Communication | Define what, when, with whom, and how the ISMS communicates. | Map internal and external security communications, including incidents, policy updates, customer requests, and governance reporting. | Security lead, communications owner, customer/security team | Communication plan | Security bulletins, stakeholder updates, reporting cadence, escalation records | Supports controls that rely on timely communication. |
| 7.5 Documented information | Create, update, and control ISMS documentation and records. | Define document ownership, approval, version control, access, retention, and change handling. | Compliance lead, document owners | Document control procedure, document register | Approved policies, version history, access permissions, retained records | Documents control design and evidence control operation. |
Clause 8: Operation
| Clause/subclause | What it means | Practical action | Typical owner | Document or record to consider | Example audit evidence may include | Annex A relationship |
|---|---|---|---|---|---|---|
| 8.1 Operational planning and control | Run the ISMS processes as planned and control changes or outsourced processes where relevant. | Operate recurring ISMS activities: risk reviews, control reviews, supplier/security processes, policy workflows, and exception handling. | ISMS owner, process owners, security operations | ISMS operating calendar, process procedures, change records | Completed tasks, control operation records, supplier review records, exception approvals | Shows selected controls are embedded in operations. |
| 8.2 Information security risk assessment | Perform risk assessments at planned intervals or when significant changes occur. | Reassess risks based on schedule, major system changes, new suppliers, incidents, or business changes. | Security lead, risk owners, system owners | Updated risk register, reassessment records | Risk review minutes, updated likelihood/impact ratings, new or changed risk entries | May trigger new or changed control decisions. |
| 8.3 Information security risk treatment | Implement the risk treatment plan. | Track treatment actions, control implementation, accountable owners, status, and residual risk decisions. | Control owners, security lead, risk owners | Risk treatment tracker, control implementation records | Closed treatment tasks, control test results, residual risk approvals, SoA status updates | Confirms Annex A or other selected controls are being implemented. |
Clause 9: Performance evaluation
| Clause/subclause | What it means | Practical action | Typical owner | Document or record to consider | Example audit evidence may include | Annex A relationship |
|---|---|---|---|---|---|---|
| 9.1 Monitoring, measurement, analysis and evaluation | Decide what to monitor and evaluate to understand ISMS performance. | Define metrics, review cadence, methods, and responsibilities for evaluating policy, objectives, risks, controls, and incidents. | Security lead, compliance lead, control owners | Metrics plan, monitoring procedure, performance dashboard | KPI/KRI reports, control review results, incident trend analysis, objective status | Evaluates whether selected controls and ISMS processes are effective. |
| 9.2 Internal audit | Conduct internal audits to assess conformity and implementation. | Plan an audit programme, define criteria and scope, assign impartial auditors where possible, record findings and follow-up. | Internal audit owner, compliance lead | Internal audit programme, audit plan, audit reports | Audit schedule, interview notes, findings, evidence samples, follow-up actions | Tests both clause requirements and applicable control operation. |
| 9.3 Management review | Top management reviews the ISMS at planned intervals. | Prepare inputs on performance, audit results, risks, objectives, changes, feedback, and improvement needs; record decisions and actions. | Executive sponsor, ISMS owner, security lead | Management review agenda, minutes, action log | Review deck, attendance, decisions, assigned actions, resourcing outcomes | Leadership reviews whether control and risk decisions remain suitable. |
Clause 10: Improvement
| Clause/subclause | What it means | Practical action | Typical owner | Document or record to consider | Example audit evidence may include | Annex A relationship |
|---|---|---|---|---|---|---|
| 10.1 Continual improvement | Improve the suitability, adequacy, and effectiveness of the ISMS. | Use monitoring, audits, incidents, reviews, and risk changes to identify improvement actions. | ISMS owner, executive sponsor, process owners | Improvement register, roadmap | Improvement backlog, completed enhancements, review outputs | Improvements may add, change, or retire controls. |
| 10.2 Nonconformity and corrective action | Respond to nonconformities, address causes, and keep records of action taken. | Log nonconformities, investigate cause, define corrective action, assign owners, verify effectiveness, and retain records. | Compliance lead, process owner, control owner | Corrective action log, root-cause analysis | Nonconformity records, action evidence, effectiveness review, closure approval | Corrective actions may affect control design, operation, or SoA status. |
How clauses 4–10 connect to Annex A, risk treatment, and the Statement of Applicability
Clauses 4–10 define the ISMS requirements. Annex A supports risk treatment by providing a reference set of information security controls, it does not replace the management system requirements.
The practical flow is:
- Context and scope define what the ISMS covers.
- Risk assessment identifies information security risks within that scope.
- Risk treatment determines which controls are needed to reduce risk.
- Annex A comparison helps check selected controls against the ISO control reference set.
- Statement of Applicability records the control decisions.
During risk treatment, organizations determine the controls needed to reduce information security risk, compare those controls with Annex A, and record the applicable information in the SoA. A control’s presence in Annex A does not by itself make it necessary for every organization (ISO/IEC JTC 1/SC 27).
The SoA is documented information that identifies necessary controls, explains why they are included, states whether they are implemented, and records justification for excluded Annex A controls.
A simple example:
| Risk finding | Treatment decision | Annex A/SoA connection |
|---|---|---|
| Sensitive customer data is accessible by too many internal users. | Reduce risk by tightening access management, reviewing privileges, and assigning access-control ownership. | Compare the selected access controls with Annex A. In the SoA, record applicable controls, inclusion rationale, implementation status, and any justified exclusions. |
The important point is sequence: do not start by assuming all 93 Annex A controls are mandatory. Start with scope and risk, then justify control decisions.
Recommended implementation sequence for clauses 4–10
This is a practical implementation sequence, not a mandated project order or certification timeline. Organizations often iterate, especially when risk assessments, control implementation, audits, and management review expose changes.
| Step | Implementation focus | Clause connection |
|---|---|---|
| 1 | Define organizational context, interested parties, and ISMS scope. | Clause 4 |
| 2 | Establish leadership responsibilities and information security policy direction. | Clause 5 |
| 3 | Define the risk assessment and risk treatment approach. | Clause 6.1 |
| 4 | Set information security objectives and plans to achieve them. | Clause 6.2 |
| 5 | Identify resources, competence, awareness, communication, and documented information needs. | Clause 7 |
| 6 | Operate ISMS processes, perform risk assessments, and implement risk treatment. | Clause 8 |
| 7 | Monitor, measure, analyze, and evaluate ISMS performance. | Clause 9.1 |
| 8 | Run internal audits and track findings. | Clause 9.2 |
| 9 | Conduct management review and record decisions. | Clause 9.3 |
| 10 | Address nonconformities and support continual improvement. | Clause 10 |
A practical shortcut is to build the first version of the ISMS around traceability: scope links to risks, risks link to treatments, treatments link to controls, controls link to owners, and owners maintain evidence as the work continues.
How to use this guide for audit readiness
Use the matrix as a working checklist, but do not treat it as a substitute for the standard, professional advice, or certification-body assessment.
For each clause and subclause:
- assign an accountable owner;
- confirm the relevant document or record exists;
- check that documents match how the process actually works;
- collect evidence during normal ISMS operation rather than rebuilding it before an audit;
- identify weak evidence, unclear ownership, stale risk decisions, and policy/process mismatches before internal audit and management review.
Audit readiness is strongest when evidence reflects real operating behavior: decisions made, risks reviewed, controls operated, findings corrected, and leadership informed. This is mostly about collecting proof. More accurately, it is about running the ISMS in a way that leaves proof behind.
Ciphrix can support this operational approach by helping teams turn clause requirements into workflows for owners, tasks, policies, risks, controls, and evidence. The objective is not to automate responsibility or guarantee certification; it is to make the ISMS easier to run consistently and easier to evidence when reviewed.