Appearance
ISO/IEC 27001:2022 — Clauses 4–10 implementation guide
ISO/IEC 27001 follows the Annex SL harmonized structure. Clauses 4–10 describe how to run an ISMS; the ISMS-specific content (information-security policy in 5.2, information-security risk assessment in 6.1.2, risk treatment and the mandatory Statement of Applicability in 6.1.3) sits inside the shared backbone. This page is the implementation playbook — not a restatement of the standard text.
Quick decision
- You already operate a security program (SOC 2, NIST CSF) → Clauses 4–10 will require formalising the management-system spine; gap focus on Clause 6.1.3 d SoA and Clause 9 audit + review.
- You are starting from scratch → stand up the Annex SL backbone (4 Context, 5 Leadership, 6 Planning, 7 Support, 8 Operation, 9 Performance evaluation, 10 Improvement) and produce the SoA in parallel.
- You need to write the risk assessment method (6.1.2) → define criteria, thresholds, cadence, approval authority. Lifecycle, not one-shot.
- You need to build the SoA (6.1.3 d) → every one of the 93 Annex A controls gets a position — included with justification, or excluded with justification.
TL;DR
- Annex SL backbone shared with ISO 42001 / 27701 / 9001 — Clauses 4 (Context), 5 (Leadership), 6 (Planning), 7 (Support), 8 (Operation), 9 (Performance evaluation), 10 (Improvement).
- Information-security content inside the shared clauses: 5.2 information-security policy; 6.1.2 information-security risk assessment; 6.1.3 information-security risk treatment + mandatory Statement of Applicability (6.1.3 d); 6.2 information-security objectives.
- Annex A is normative — 93 controls in 4 themes. The SoA covers all of them.
- Internal audit (9.2) + management review (9.3) + corrective action (10.2) = the operating loop auditors use to evaluate conformity and effectiveness.
- Modulos models Clauses 4–10 via OFF-9 (28 ORF requirements) and MFF-9 (2 MRF requirements).
Primary source
ISO/IEC 27001:2022 — Information security, cybersecurity and privacy protection — Information security management systems — Requirements, Clauses 4 through 10. Available via the ISO Online Browsing Platform. © ISO.
Annex SL backbone
| Clause | Headline | What you put in place | Typical evidence |
|---|---|---|---|
| 4 Context | ISMS boundaries and expectations | Scope statement, interested parties, ISMS description | Scope doc, interested-parties register, operating model |
| 5 Leadership | Accountability and direction | Information-security policy, roles, authorities | Approved policy, RACI, governance-meeting minutes |
| 6 Planning | Risk method, treatment, objectives, change planning | Risk method, risk register, treatment plan, SoA, objectives | Risk records, SoA, change log |
| 7 Support | People, resources, documented information | Competence plan, training, document control | Competence matrix, training records, document register |
| 8 Operation | Repeatable security operations | Annex A control execution, periodic risk reassessment | Control evidence, runbooks, supplier assessments |
| 9 Performance evaluation | Measurement + governance cadence | Monitoring, internal audit, management review | Metric reports, audit findings, review minutes |
| 10 Improvement | Fix and learn | Nonconformity + corrective action, continual improvement | Corrective-action records, improvement backlog |
Framework mapping
Four layers, one reusable spine.
Frameworks
EU AI Act
ISO 42001
Requirements
Art. 9.1Risk management
Art. 10.2Data governance
6.1.1Risk assessment
Components
Risk identification
Impact analysis
Evidence
Risk register
Test results
Controls
The reusable spine
One control satisfies many requirements across many frameworks, and groups the components and evidence beneath them.
Risk assessment process
Data validation checks
Edge from any layer card crosses into the Controls spine — the same control may serve a regulatory article, a standards clause, a downstream component, and the evidence that closes it.
Clause 4 — Context of the organization
Goal: define the ISMS boundaries and the reality it operates in.
What to implement:
- ISMS scope statement (Clause 4.3) — boundaries, locations, systems, interfaces with activities performed by other organisations.
- Interested parties (4.2) — customers, regulators, contracts, staff, suppliers.
- ISMS description (4.4) — how the management system fits into existing governance.
Common pitfalls:
- Scope that is "everything" (too broad to operate) or "almost nothing" (not credible).
- Scope not updated when systems, vendors or architecture change.
Clause 5 — Leadership
Goal: make security governance real — leadership commitment, policy direction, explicit responsibilities.
What to implement:
- An information-security policy (5.2) — usable and auditable, not aspirational.
- Roles and authorities (5.3) — who approves, who owns risks, who reviews.
- A governance cadence and escalation path — incidents, exceptions, nonconformities.
Common pitfalls:
- A policy that reads like marketing but doesn't bind decisions.
- Ambiguous authority — "everyone is responsible" usually means "no one is accountable".
Clause 6 — Planning
Goal: turn intent into a plan — risk method, treatment, objectives, change planning.
What to implement:
- A risk-assessment method (Clause 6.1.2) — criteria, thresholds, cadence, approval authority.
- A risk-treatment plan (6.1.3) — selecting controls from Annex A + any additional controls.
- The Statement of Applicability (6.1.3 d) — mandatory documented information covering all 93 Annex A controls with inclusion/exclusion justification.
- Measurable information-security objectives (6.2) — owners, measures, review cadence.
- Planning of changes (6.3) — what triggers reassessment of the ISMS itself (organisational change, system change, vendor change, regulatory change).
Common pitfalls:
- Treating the risk assessment as a one-time exercise rather than a lifecycle mechanism.
- An SoA that copies Annex A control text into a spreadsheet but doesn't link to the risk register.
- Objectives that aren't measurable or aren't linked to any governance decisions.
Go deeper: ISMS foundations — scope and SoA.
Clause 7 — Support
Goal: ensure people, resources, competence, awareness and controlled documentation to run the ISMS reliably.
What to implement:
- Resource planning — time and expertise for risk, control execution, documentation, review.
- Role-based competence and training, including reviewers and approvers.
- Communication — who needs to know what, when (internal and external).
- Documented-information discipline (7.5) — versioning, review cadence, access control.
Common pitfalls:
- Documentation debt — artefacts exist but no one owns them; they silently rot.
- Uncontrolled working docs — critical decisions live in chat threads and get lost.
Clause 8 — Operation
Goal: run security governance as an operational system — Annex A control execution, periodic reassessment, supplier management.
What to implement:
- Operational planning and control (8.1) — the processes that execute the selected Annex A controls.
- Periodic information-security risk assessment (8.2) — operational re-assessment as systems, suppliers and the threat environment change.
- Risk-treatment execution (8.3) — implementing controls and tracking residual risk acceptance.
- Supplier governance — Annex A theme 5 covers supplier relationships including critical AI/ML vendors and cloud providers.
Common pitfalls:
- Annex A controls treated as policy artefacts rather than operational practices.
- Monitoring exists but isn't connected to governance decisions or corrective actions.
- Supplier reviews stop at onboarding — no periodic reassessment.
Go deeper: Annex A (controls reference).
Clause 9 — Performance evaluation
Goal: prove the ISMS works — monitoring, internal audit, management review.
What to implement:
- Monitoring and measurement (9.1) — what signals indicate the ISMS controls are working (or failing).
- Internal audit programme (9.2) — scope, cadence, sampling, auditor competence.
- Management review (9.3) — what leadership reviews, how often, what outcomes are expected. Inputs include audit findings, monitoring results, supplier evaluations, nonconformities, resourcing.
Common pitfalls:
- "Internal audit" treated as document review only — weak signal that doesn't catch operational gaps.
- Management review becomes a status meeting, not a decision point.
Clause 10 — Improvement
Goal: make failures productive — fix nonconformities and continually improve the system.
What to implement:
- Nonconformity and corrective action (10.2) — ownership, deadlines, root cause analysis, effectiveness verification.
- Continual improvement (10.1) — driven by audits, incidents, monitoring, stakeholder feedback.
Common pitfalls:
- Corrective actions closed without verifying effectiveness.
- Improvements tracked informally without traceability back to the trigger.
How to operationalise Clauses 4–10 in Modulos
The OFF-9 framework template maps the 28 Clauses 4–10 requirements to ISMS-level governance work:
| Requirement | ISO 27001 clause | Topic |
|---|---|---|
ORF-196 | 4.1 | Understanding the organisation and its context |
ORF-197 | 4.2 | Understanding the needs and expectations of interested parties |
ORF-198 | 4.3 | Determining the scope of the ISMS |
ORF-199 | 4.4 | Information security management system |
ORF-200 | 5.1 | Leadership and commitment |
ORF-201 | 5.2 | Policy |
ORF-202 | 5.3 | Organisational roles, responsibilities and authorities |
ORF-203 | 6.1.1 | Actions to address risks and opportunities — general |
ORF-204 | 6.1.2 | Information-security risk assessment |
ORF-205 | 6.1.3 | Information-security risk treatment + Statement of Applicability (6.1.3 d) |
ORF-206 | 6.2 | Information-security objectives and planning |
ORF-207 | 6.3 | Planning of changes |
ORF-208 | 7.1 | Resources |
ORF-209 | 7.2 | Competence |
ORF-210 | 7.3 | Awareness |
ORF-211 | 7.4 | Communication |
ORF-212 / ORF-213 / ORF-214 | 7.5.1 / 7.5.2 / 7.5.3 | Documented information |
ORF-215 | 8.1 | Operational planning and control |
ORF-216 | 9.1 | Monitoring, measurement, analysis and evaluation |
ORF-217 / ORF-218 | 9.2.1 / 9.2.2 | Internal audit |
ORF-219 / ORF-220 / ORF-221 | 9.3.1 / 9.3.2 / 9.3.3 | Management review |
ORF-222 | 10.1 | Continual improvement |
ORF-223 | 10.2 | Nonconformity and corrective action |
MFF-9 (app-level) maps the per-AI-system overlap with the ISMS:
| Requirement | Clause | Topic |
|---|---|---|
MRF-221 | 8.2 | Information-security risk assessment (operational, per AI system) |
MRF-222 | 8.3 | Information-security risk treatment (operational, per AI system) |
Operating rules:
- Scope, policy, risk method, SoA, internal audit, management review live on OFF-9. One organisation project per organisation.
- AI-system-specific information-security risk + treatment live on MFF-9. Each AI-system MFF-9 project gets its own evidence trail.
- The Statement of Applicability is owner-authored documented information stored as control-level evidence on
ORF-205. Modulos does not provide a dedicated SoA workflow surface.
Integrated Management System (IMS) with ISO 42001 / 27701
Clauses 4–10 are shared with ISO 42001 (AIMS) and ISO 27701 (PIMS) — document control, internal audit, management review, corrective action work the same way across all three. What stays standard-specific:
- ISO 27001: information-security risk and Annex A (normative) information-security controls.
- ISO 42001: AI policy (5.2), AI risk + impact (6.1.2/3/4), Annex A (informative) AI lifecycle and data controls.
- ISO 27701: privacy risk, PII processor / controller distinctions, privacy controls.
Related: Integration with AI governance · ISO 42001 vs ISO 27001 comparison.
Cross-framework mapping (preview)
| ISO 27001 clause | Adjacent provision |
|---|---|
| Clause 4.3 ISMS scope | ISO 42001 Clause 4.3 AIMS scope; ISO 27701 Clause 4.3 PIMS scope |
| Clause 5.2 information-security policy | ISO 42001 Clause 5.2 AI policy; ISO 27701 Clause 5.2 privacy policy |
| Clause 6.1.2 risk assessment | ISO 42001 Clause 6.1.2 AI risk assessment; ISO 31000 |
| Clause 6.1.3 d Statement of Applicability (mandatory) | ISO 42001 SoA (informative but expected); EU AI Act Annex IV |
| Clause 6.3 planning of changes | ISO 42001 Clause 6.3; new in the 2022 edition |
| Clause 8 operational planning | EU AI Act Article 15(5) cybersecurity for high-risk AI; NIS2 Article 21(2) |
| Clause 9.1 monitoring | ISO 42001 Clause 9.1; EU AI Act Article 72 PMM |
| Clause 9.2 internal audit | ISO 42001 / 27701 / 9001 Clause 9.2 |
| Clause 10.2 corrective action | ISO 42001 / 27701 / 9001 Clause 10.2; EU AI Act Article 20 |
Related pages
ISO 27001 overview
Hub: ISMS structure, Annex SL backbone, Annex A themes
ISMS foundations (scope + SoA + certification)
Scope, Statement of Applicability, Stage 1 / Stage 2 / surveillance / recertification
Annex A (controls reference)
93 controls in four themes — organizational, people, physical, technological
Operationalizing in Modulos
OFF-9 + MFF-9 rollout, ISMS evidence patterns
Integration with AI governance
How ISO 27001 supports ISO 42001 AIMS and the EU AI Act
Source attribution
ISO/IEC 27001:2022 — Information security, cybersecurity and privacy protection — Information security management systems — Requirements, Clauses 4 through 10. © ISO/IEC. Available via the ISO Online Browsing Platform.
Disclaimer
This page is for general informational purposes and does not constitute legal or certification advice.