ISO/IEC 27001:2022 Implementation Roadmap — From Scope to Certification Readiness

ISO/IEC 27001 implementation fails when it is treated as a document-production exercise. A working ISMS is a decision system for information-security risk: it defines what matters, who owns risk, how controls are selected, what evidence exists and how leadership knows whether the system is improving.

The roadmap below follows the logic of ISO/IEC 27001 and the PECB Lead Implementer programme. The sequence is practical, not a mandatory ISO project plan; organisations should adapt it to their context, maturity and scope.

---

Roadmap at a glance

---

Stage 1 — Understand organisational context

Start with the business, not Annex A.

Document:

• mission and strategic objectives;
• critical products/services;
• internal and external issues;
• legal, contractual and market requirements;
• relevant interested parties;
• major technology dependencies;
• risk expectations from customers and partners.

A weak context section produces a generic ISMS. A strong context creates the logic for the rest of the system.

---

Stage 2 — Define the ISMS scope

Scope should be explicit enough that a third party can understand what is covered.

Consider:

• organisational boundaries;
• locations;
• people and teams;
• business processes;
• systems and applications;
• cloud platforms;
• third parties;
• interfaces with out-of-scope areas.

Warning sign
If the scope is drawn only to make certification easier and ignores material dependencies, the resulting ISMS may be formally neat but operationally misleading.

---

Stage 3 — Secure leadership and project governance

Define:

• executive sponsor;
• implementation lead;
• project team;
• risk owners;
• decision forums;
• escalation process;
• resources and timeline.

This is where ISO/IEC 27001 stops being “the security team’s project”.

---

Stage 4 — Perform a gap analysis

A gap analysis compares the current state with the target state.

Useful outputs include:

• requirement-by-requirement status;
• evidence already available;
• missing processes;
• maturity target;
• remediation priorities;
• dependencies.

Do not confuse a gap with a risk. A missing document is not necessarily the organisation’s highest risk.

---

Stage 5 — Define the risk method

Before assessing risk, define the rules.

A workable method should explain:

• what constitutes an information-security risk;
• likelihood scale;
• impact scale;
• risk calculation / evaluation logic;
• risk-acceptance criteria;
• who can accept which level of risk;
• review frequency.

Consistency is more valuable than false mathematical precision.

---

Stage 6 — Assess information-security risks

Identify risk scenarios linked to assets, services, threats, vulnerabilities and consequences.

Good risk statements are specific enough to support a decision.

Weak:

“Ransomware risk.”

Better:

“A ransomware event affecting the identity platform and core file services could prevent staff access to critical systems for multiple business days, creating operational and contractual impact.”

The second statement is easier to treat, own and monitor.

---

Stage 7 — Build the risk-treatment plan and Statement of Applicability

For each relevant risk, decide whether to:

• modify/reduce;
• avoid;
• share/transfer;
• retain/accept.

Then build the Statement of Applicability (SoA) documenting applicable controls, their justification, exclusions and implementation status.

The SoA should connect risk reasoning to control decisions.

---

Stage 8 — Implement controls and documented information

Implementation can cover:

• access control;
• identity and privilege;
• supplier security;
• incident management;
• backup and resilience;
• secure development;
• logging and monitoring;
• physical security;
• asset management;
• HR security;
• cloud governance;
• cryptography;
• change management.

Controls need operating evidence, not only policy statements.

---

Stage 9 — Build competence, awareness and operational routines

An ISMS that exists only inside a GRC platform is not mature.

Teams should understand:

• their security responsibilities;
• escalation paths;
• incident procedures;
• evidence requirements;
• supplier obligations;
• change and exception processes.

PECB’s Lead Implementer programme explicitly includes competence, awareness, communication and security operations.

---

Stage 10 — Monitor and measure

Define metrics that help management make decisions.

Avoid dashboards full of activity counts with no risk context.

Better measures often connect to:

• control effectiveness;
• risk trend;
• critical vulnerabilities beyond SLA;
• recovery-test results;
• privileged-access exceptions;
• supplier-risk remediation;
• incident response performance;
• audit findings aging.

---

Stage 11 — Conduct an internal audit

The internal audit should test both conformity and operation.

Questions include:

• Is the defined process actually followed?
• Is evidence reliable?
• Are risk decisions traceable?
• Do controls operate as described?
• Are exceptions managed?

Audit independence and objectivity matter.

---

Stage 12 — Run management review

Management review is where security governance meets executive decision-making.

A useful review should cover:

• audit results;
• risk changes;
• incidents;
• performance metrics;
• objectives;
• resource needs;
• changes in context;
• opportunities for improvement.

The output should include decisions — not merely meeting minutes.

---

Stage 13 — Correct root causes

When an issue appears, distinguish symptom from cause.

Example:

Symptom: evidence missing for access reviews.
Possible root cause: no owner, no recurring workflow, no escalation and no system-generated evidence.

Corrective action should make recurrence less likely.

---

Stage 14 — Prepare for certification assessment

If certification is the objective, prepare for external assessment by ensuring:

• scope is stable;
• evidence is available;
• internal audit is complete;
• management review is complete;
• nonconformities are addressed;
• teams can explain their responsibilities;
• risk and SoA decisions are traceable.

Certification typically includes a Stage 1 and Stage 2 audit process, followed by surveillance/renewal activities according to the certification scheme.

---

How long does implementation take?

ISO does not prescribe a universal project duration.

An illustrative programme for a focused, reasonably mature scope may take several months. A complex enterprise with multiple countries, legacy systems, regulated data and many suppliers may need substantially longer.

The right question is not “How fast can we get the certificate?”

It is:

How quickly can we build a management system that will still work after the auditors leave?

---

The AI and cloud layer

Modern ISMS projects should include cloud and AI dependencies early.

Questions to add:

• Which AI services process sensitive information?
• Which agents can perform actions rather than simply generate text?
• Where are prompts, embeddings and model outputs stored?
• Which cloud services are single points of failure?
• What evidence exists for supplier controls?
• Which responsibilities remain with the organisation under shared-responsibility models?

PECB’s programme explicitly covers AI, machine learning, cloud computing and outsourcing as emerging-technology considerations.

---

ECW Executive Experience — Dakar

ECW runs a five-day PECB Certified ISO/IEC 27001 Lead Implementer Executive Experience in Dakar from 14–18 December 2026, with the certification exam on Day 5.

Explore the Executive Experience

Related: How to Become an ISO/IEC 27001 Lead Implementer

---

Sources

• ISO — ISO/IEC 27001:2022: https://www.iso.org/standard/27001
• PECB — ISO/IEC 27001 Lead Implementer: https://pecb.com/en/education-and-certification-for-individuals/iso-iec-27001/iso-iec-27001-lead-implementer