ISO/IEC 27001:2022 Clauses 4–10 (how to implement)

ISO/IEC 27001 follows the standard ISO management-system structure: clauses 4–10 describe how to run an ISMS. This page is not a restatement of the standard — it’s a practical guide to what teams implement and what evidence tends to exist.

How to use this page

Treat each clause as a set of mechanisms to put in place (scope, governance, risk method, control execution, audits, improvement) — then link the resulting artifacts to an auditable trail.

A quick map: clause → typical outputs

Clause	What you’re putting in place	Typical outputs (examples)
4 Context	ISMS boundaries and expectations	scope statement, interested parties, ISMS description
5 Leadership	Accountability and direction	information security policy, roles, approvals
6 Planning	Risk method and objectives	risk assessment method, SoA decisions, treatment plan, objectives
7 Support	People and documented information	training/awareness records, document control
8 Operation	Repeatable security operations	risk assessments, treatment execution, operational controls evidence
9 Performance evaluation	Assurance cadence	monitoring, internal audit, management review
10 Improvement	Fix and learn	corrective actions, continual improvement backlog

Frameworks

EU AI ActRegulatory

ISO 42001Standard

Requirements

Art. 9.1Risk management

Art. 10.2Data governance

6.1.1Risk assessment

Controls

Risk assessment processReusable

Data validation checksReusable

Components

Risk identification

Impact analysis

Evidence

Risk registerDocument

Test resultsArtifact

Requirements preserve the source structure

Controls are reusable across frameworks

Evidence attaches to components (sub-claims)

Clause 4 — Context of the organization

Goal

Define a scope you can defend and a management system that matches how your organization actually operates.

What to implement

• A clear ISMS scope statement (boundaries, locations, systems, and interfaces).
• Interested parties and relevant obligations (customers, regulators, contracts).
• A description of the ISMS: how it fits into existing governance.

What evidence tends to look like

• Scope statement + exclusions rationale.
• Asset/information boundary documentation (what matters, where it lives).
• “How security decisions get made” operating model.

Common pitfalls

• Scope that is “everything” (too broad to operate) or “almost nothing” (not credible).
• Scope not updated when systems, vendors, or architecture change.

In Modulos

• Use the organization project to keep ISMS governance artifacts stable and reviewable.
• Link scope docs and decisions into relevant controls as evidence.

Clause 5 — Leadership

Goal

Make security governance real: leadership commitment, policy direction, and explicit responsibilities.

What to implement

• A policy that is usable and auditable (not aspirational).
• Roles and authorities (who approves, who owns risks, who reviews).
• Governance cadence and escalation paths (incidents, exceptions, nonconformities).

What evidence tends to look like

• Policy approval and periodic review records.
• Role descriptions / responsibility matrix.
• Decision records for exceptions and risk acceptance.

Common pitfalls

• “Policy as a poster”: no link between policy and decisions.
• Unclear authority over risk acceptance and exceptions.

Clause 6 — Planning

Goal

Turn security intent into a plan: risk assessment, risk treatment, and objectives.

What to implement

• A consistent information security risk assessment method (criteria, frequency, approvals).
• A risk treatment approach (avoid/mitigate/transfer/accept) and a way to track progress.
• Objectives that are measurable and reviewed (not just “improve security”).
• A statement of applicability approach (how you decide which controls apply).

What evidence tends to look like

• Risk assessment records and risk register decisions.
• Risk treatment plan and implementation status.
• Objectives and measures with owners and review cadence.

Common pitfalls

• Treating risk assessment as a one-time compliance activity.
• Conflating “implemented controls” with “operated controls” (auditors test operation).

Clause 7 — Support

Goal

Ensure you can operate the ISMS consistently: resources, competence, awareness, communication, and documented information control.

What to implement

• Competence and training requirements (including reviewers and approvers).
• Awareness mechanisms (security training, targeted comms).
• Documented information controls (versioning, approvals, access).

What evidence tends to look like

• Training completion records.
• Document register and document control procedure.
• Communications plan for incidents and changes.

Common pitfalls

• “Documentation debt”: uncontrolled working docs and lost decision history.

Clause 8 — Operation

Goal

Operate security as a system: do the risk work, run the controls, keep evidence current.

What to implement

• Operational planning and control (how security work runs day to day).
• Periodic risk reassessment triggers (system change, vendor change, incidents).
• Supplier/third-party governance where it materially affects security.

What evidence tends to look like

• Operational records: access reviews, incident records, change approvals, backups tests, etc.
• Supplier assessment records and review cadence.

Common pitfalls

• Controls exist but have no execution cadence, owner, or evidence.
• Monitoring exists but is disconnected from decisions and corrective actions.

Clause 9 — Performance evaluation

Goal

Prove the ISMS works: monitoring, internal audit, and management review.

What to implement

• Monitoring and measurement signals that indicate control effectiveness.
• Internal audit program (cadence, sampling, independence, competence).
• Management review as a decision point (not just a status meeting).

What evidence tends to look like

• Internal audit plan and audit reports with follow-ups.
• Management review inputs and outputs.

Common pitfalls

• Internal audit treated as document review only.
• Management review with no decisions or resulting actions.

Clause 10 — Improvement

Goal

Close the loop: corrective actions and continual improvement.

What to implement

• Nonconformity and corrective action process with effectiveness checks.
• Improvement backlog linked to audits, incidents, and measurement results.

What evidence tends to look like

• Corrective action records (root cause, actions, verification).
• Improvement roadmap and completed items.

Integrated Management System (IMS) note

ISO/IEC 27001 is commonly operated as an IMS alongside ISO/IEC 42001 (AI governance) and ISO/IEC 27701 (privacy governance). Shared processes (document control, audits, management review, corrective action) can be reused while keeping AI- and privacy-specific governance explicit.

Disclaimer

This page is for general informational purposes and does not constitute legal advice.