ISO 27001:2022 Implementation Guide: From Zero to Certified

ISO 27001:2022 is the world's leading information security management standard, trusted by over 70,000 certified organisations globally. The 2022 revision brought the most significant changes in a decade — 11 new controls, reorganised Annex A, and stronger focus on threat intelligence and cloud security. This guide walks you through implementation from first gap assessment to certification audit.

Phase 1: Initiation and Planning (Weeks 1–4)

Define the ISMS Scope

Scope definition is the most important decision in any ISO 27001 implementation. A poorly defined scope creates audit findings and wasted effort. Your scope should cover the information assets, business processes, locations, and technology that are relevant to the information security risks you face.

Consider: which systems handle sensitive customer data? Which processes are revenue-critical? Which locations will the certification cover? Document your scope statement clearly — auditors will test everything within it.

Conduct a Gap Assessment

Before building anything, understand where you stand. Map your existing controls against ISO 27001:2022 Annex A and identify gaps. This assessment should cover all 93 controls and produce a prioritised remediation backlog. Most organisations find they have 60–70% of required controls in some form — the challenge is documentation and consistency.

Get Board Buy-In

ISO 27001 clause 5.1 requires demonstrated leadership commitment. This isn't box-ticking — you need an executive sponsor, a defined information security policy approved at board level, and resources allocated to the implementation. Without genuine leadership support, ISMS programmes stall.

Phase 2: Risk Assessment and Treatment (Weeks 4–10)

The information security risk assessment is the heart of ISO 27001. Clause 6.1.2 requires you to define a risk assessment methodology, identify risks to information confidentiality, integrity, and availability, analyse and evaluate those risks, and select appropriate treatment options.

Phase 3: Controls Implementation (Weeks 8–20)

Based on your risk treatment decisions, implement the required Annex A controls. The four themes in ISO 27001:2022 organise controls as follows:

Phase 4: Statement of Applicability

The Statement of Applicability (SoA) is a mandatory document that lists all 93 Annex A controls, states whether each is applicable to your ISMS, justifies inclusions and exclusions, and references the implementation status. The SoA is one of the first documents an auditor reviews — it needs to be thorough, accurate, and linked to your risk treatment decisions.

A common mistake: excluding controls without documented justification. Every exclusion must reference why the control is not applicable — typically because the associated risk doesn't exist in your context (e.g. physical media controls excluded because you're fully cloud-based and handle no physical media).

Phase 5: Internal Audit and Management Review

Before your certification audit, you must complete at least one full internal audit cycle (clause 9.2) and a management review (clause 9.3). The internal audit must be conducted by someone independent of the areas being audited — this can be internal staff not responsible for those areas, or an external consultant.

The management review must cover: audit results, risk assessment outcomes, ISMS performance metrics, nonconformities and corrective actions, and opportunities for improvement. Minutes must be retained as evidence.

Phase 6: Certification Audit

Certification audits are conducted by accredited certification bodies (CBs) in two stages:

Getting the scope right — the decision that sets everything else

Scope is the single biggest lever on cost, duration and difficulty, and it gets decided in week one by people who do not yet know what they are choosing. Certification-body audit duration is driven primarily by the number of people inside your ISMS boundary, so a wide scope is not a marginally more expensive certificate — it is a materially larger project.

A defensible scope statement names what the ISMS covers: the product or service, the supporting infrastructure, the teams and the locations. Excluding a function is entirely legitimate provided the exclusion is justified and the interfaces are managed. What is not legitimate is excluding something your customers assume is included — a certificate scoped to a subsidiary that does not build the product they buy is exactly what enterprise procurement now checks.

• Scope to the product and the people who build, run and support it — that is what customers are asking about
• Name cloud environments explicitly: "our AWS production account" beats "our infrastructure"
• Decide about the office early. Remote-first companies can often scope out physical premises entirely
• State exclusions with a reason — "no customer data and no network path to production" is an argument, silence is not
• Read the scope statement back as a prospect would. It appears on the certificate, and it is public

The clauses everyone underestimates

Teams arrive focused on Annex A — the 93 controls — because controls feel like the substance. But you are certified against the management system clauses, 4 to 10, and that is where most non-conformities are raised. Annex A controls are selected as a result of your risk assessment; the clauses are the machinery that makes the whole thing a system rather than a checklist.

What changed in the 2022 revision

If you are working from older material — and much of what is online still is — the control structure will not match. The 2022 revision reorganised Annex A from 114 controls in 14 domains into 93 controls across 4 themes: organisational, people, physical and technological. Most of the reduction is consolidation rather than removal.

Eleven controls are genuinely new, and these are the ones worth confirming you have actually addressed rather than assumed:

• Threat intelligence — collecting and using information about threats relevant to you, not merely subscribing to a feed
• Information security for use of cloud services — acquisition, use and exit, pairing closely with supplier management
• ICT readiness for business continuity — continuity of the technology, tested
• Physical security monitoring — relevant only if premises are in scope
• Configuration management — baselines, and detection of drift from them
• Information deletion — including from backups and from sub-processors
• Data masking — non-production environments in particular
• Data leakage prevention
• Monitoring activities — anomaly detection across networks, systems and applications
• Web filtering
• Secure coding — for a software company, usually the one with the most work behind it

The 2022 version also introduced control attributes — tags for control type, security property, operational capability and security domain. They are optional. Useful for reporting if your tooling supports them, but not something to build a project around.

The five things that most often cause findings

Across first certifications the same handful of gaps recur, and none of them is exotic.

A risk assessment nobody believes. Thirty risks imported from a template, all scored medium, none traceable to a decision. Auditors test whether risk actually drove your control selection. Eight real risks you can argue about beat thirty you cannot.

Policies describing a company that does not exist. Written early, often bought, describing an access-request workflow nobody follows. Write policy after the control works, not before.

No evidence of operation. The control exists; nothing shows it ran. Stage 2 tests operation over time, not design. Start collecting in month one — reconstructing evidence retrospectively is the single largest source of pre-audit overtime.

Internal audit performed by the person who built it. Clause 9.2 requires independence. A self-audit is a finding regardless of its quality.

Supplier management as a list. A spreadsheet of vendors with no tiering, no assessment depth and no reassessment dates does not satisfy A.5.19–5.23.

Realistic Timeline and Cost