ISO 27001:2022 Gap Analysis: The Ultimate Field Guide

Standard Reference

ISO/IEC 27003 (the implementation guidance standard for ISO/IEC 27001) treats gap analysis as the output of the "analysis of the existing system" activity — conducted after scope definition and before risk assessment. It is an explicit prerequisite to ISMS design.

Core Purpose: Establish, Spot, and Roadmap

A well-executed gap analysis does three things. It establishes a documented baseline of existing controls, policies, and processes. It spots what is missing, incomplete, or not properly evidenced. And it produces a remediation roadmap — ranked actions that bridge the gap between current state and certification readiness.

Without this baseline, ISMS projects drift. Teams spend money on tools they don't need, overlook weaknesses that matter, and fail audits because fundamental requirements were quietly missed during implementation.

Gap Analysis vs. Risk Assessment: Not the Same Thing

Many organisations confuse these two activities. Both are essential — but they answer different questions.

Example: a gap analysis reveals no documented incident response plan (Clause 6.1.3). The risk assessment then quantifies the consequence — if an incident occurs without a response plan, recovery time could cost the organisation significantly in downtime. The gap tells you what's missing; the risk assessment tells you how much it matters.

Why Gap Analysis Is More Than a Checklist

A mature gap analysis goes three levels deep: documentation versus practice (do policies actually guide daily behaviour?), evidence versus assumptions (can you prove compliance with logs and records?), and alignment with business risk (are gaps prioritised by real impact?). A checklist only answers the first question.

1. Build a Clear Picture of Your Security Posture

Executives often assume "we're already secure" because technical measures are in place. But ISO/IEC 27001:2022 demands more than technology — it requires documented policies, demonstrable leadership commitment, a functioning risk management process, and evidence of continual improvement. Gap analysis surfaces the difference between what leaders believe is in place and what auditors will actually find.

A SaaS provider in Dubai had hardened AWS configurations and DevSecOps pipelines. Their gap analysis revealed they had no Statement of Applicability — a mandatory ISMS deliverable. Without it, audit readiness would have collapsed despite excellent technical security.

2. Avoid Audit Surprises

ISO audits are unforgiving when evidence gaps appear unexpectedly. A gap analysis gives you the chance to spot them months before Stage 1 or Stage 2 — when fixing them is manageable rather than urgent.

A regional bank believed it was ready for certification. The gap analysis revealed no documented supplier evaluation process (Annex A.5.19 in ISO/IEC 27001:2022). That would have been a major non-conformity. Identifying and remediating it early saved significant reputational and financial exposure.

3. Prioritise Based on Risk and Business Impact

Not all gaps carry equal weight. A missing clean desk policy is a low-risk observation. A missing and untested incident response plan is a high-risk major non-conformity candidate. Gap analysis lets you rank findings by likelihood × impact × asset value, allocate resources to what matters most, and build a management-approved remediation plan with defensible prioritisation.

4. Strengthen Compliance and Stakeholder Trust

Regulators, customers, and partners want to see evidence that your ISMS is structured and evidence-driven — not assembled at the last minute. A well-documented gap analysis is itself proof of systematic risk management, and auditors notice when organisations present it with confidence.

A hospital operating under local DoH regulations and international healthcare standards used the gap analysis to align ISO/IEC 27001:2022 with its existing compliance framework. The result was a single harmonised compliance programme — reducing audit fatigue and demonstrating patient data stewardship to regulators.

5. Save Time and Budget

A rushed implementation without a gap analysis leads to over-engineering — buying tools you don't need, writing policies that duplicate existing ones, and scoping controls that don't align with actual risk. A thorough gap analysis eliminates this waste by clarifying exactly what's missing and what can be directly leveraged from existing practices.

Step 1 — Define the Scope of the ISMS

The most common failure in ISO/IEC 27001 projects begins here. A scope that is too broad overwhelms teams and budgets. Too narrow, and critical assets are left unprotected — which auditors will notice and question.

Identify which business units, processes, and systems are relevant to information security. Decide whether to certify the entire organisation or a defined division. Map cloud providers, outsourced IT, and key suppliers. Document both inclusions and exclusions with written justification — auditors will ask whether scope boundaries exist to avoid compliance effort.

A financial institution initially planned to certify its entire enterprise — hundreds of branches and thousands of staff. The gap analysis showed this would be a multi-year undertaking with disproportionate cost. Instead, they scoped digital payments, ATMs, and mobile banking systems. Certification was achieved faster, and the ISMS expanded in subsequent cycles.

Step 2 — Understand the Standard's Requirements

Gap analysis compares your current state against two equally mandatory parts of ISO/IEC 27001:2022. Clauses 4–10 cover ISMS governance — context, leadership, planning, support, operation, performance evaluation, and continual improvement. Annex A contains 93 controls grouped into four themes: Organisational, People, Physical, and Technological.

For each requirement, record whether it is fully implemented, partially implemented, or absent. This becomes the input to your gap analysis tracker.

A fast-growing SaaS provider had strong technical measures — cloud firewalls, MFA, IAM, SIEM, XDR. Their gap analysis highlighted management commitment (Clause 5.1) as completely absent. There was no evidence of security objectives in board minutes. Leadership involvement is mandatory for certification, and this would have failed Stage 1.

Step 3 — Collect Documentation and Evidence

ISO auditors operate by one principle: if it isn't documented, it doesn't exist. What to collect: ISMS policy and supporting security policies (access, cryptography, acceptable use), risk assessment and treatment methodology, asset inventory and classification, Statement of Applicability, and records of incident handling, internal audits, and management reviews.

Centralise evidence in a secure repository, tag each document against its relevant clause or Annex A control, and link them directly in your tracker. During audits, this saves hours of searching.

Step 4 — Assess Current Implementation Maturity

Two assessment models work in practice. The Yes/Partial/No model is a simple traffic-light system suitable for initial triage. The 1–5 maturity scale provides more granularity: 1 = non-existent, 2 = initial/ad hoc, 3 = defined and documented, 4 = managed and monitored, 5 = optimised. Assign scores for each control, record them in your tracker, and use conditional formatting to create visual heatmaps for management reporting.

A government IT ministry used the maturity scale across its full Annex A control set. 70% of controls reached Level 3 (defined/documented), but only 20% reached Level 4 (managed/monitored). The ISMS existed largely on paper. The gap analysis report reframed the conversation for leadership — from "are we compliant?" to "are we actually operating what we wrote?"

Step 5 — Identify Gaps and Associated Risks

For each missing or partial control, document: the control reference (e.g., Annex A.5.19), the gap description (e.g., "no supplier evaluation process exists"), the associated risk (likelihood and impact), and the recommended corrective action. This is where gap analysis connects to risk management — each gap maps to a business consequence.

An IT system integrator had no supplier risk assessments (Annex A.5.19). The risk: dependence on subcontractors handling classified data with no contractual security obligations. Corrective action: supplier due diligence questionnaires, annual security audits, and updated contract clauses requiring compliance with ISO/IEC 27001 controls.

Step 6 — Prioritise Gaps Using a Scoring Model

Three prioritisation approaches, from simple to rigorous. Qualitative ranking (High/Medium/Low) is fast and suitable for initial communication with leadership. Quantitative scoring (Likelihood 1–5 × Impact 1–5) adds defensibility. Weighted risk scoring (Likelihood × Impact × Asset Value) gives the most precise picture for resource allocation decisions.

Step 7 — Build the Remediation Action Plan

A gap analysis without a remediation plan is a report that sits in a folder. The action plan converts findings into accountable, time-bound tasks. Each row should include: gap description, corrective action, named owner (not a department — a person), target date, budget estimate, and measurable success criteria.

A retail group had no business continuity testing (Annex A.17). Action: run a tabletop exercise and full BCP drill. Owner: Head of Operations. Deadline: 90 days. Success criterion: recovery time objective below four hours demonstrated under test conditions. That specificity is what moves remediation from intention to execution.

Step 8 — Validate and Review Progress Before Audit

Before inviting external auditors, test whether gaps are actually closed — not just documented as closed. Conduct internal audits against ISO/IEC 27001:2022 clauses. Run a management review. Update the Statement of Applicability to reflect new control status. Re-run gap analysis sections if major changes occurred since the original assessment.

A financial institution's pre-audit internal audit revealed that log monitoring — fully remediated on paper — was not being consistently performed in practice. The gap was corrected before Stage 2. That's the difference between a closed gap and a verified gap.

Template Structure — Seven Columns

The template covers Clauses 4–10 and all 93 Annex A controls in ISO/IEC 27001:2022. Seven columns per row:

1. Reference — Clause or Annex A control number
2. Current Status — Fully implemented / Partial / Missing
3. Gap Description — What is missing or weak
4. Risk Level — High / Medium / Low or quantitative score
5. Corrective Action — Specific steps to close the gap
6. Owner & Deadline — Named individual, not a department
7. Evidence / Notes — Links to policies, logs, or supporting documentation

Sample Rows (Filled Example)

Note: Control references updated to ISO/IEC 27001:2022 numbering. A.8.24 = Cryptography. A.5.29 = Information security during disruption. A.8.5 = Secure authentication.

Five Practical Tips from the Field

1. Keep it simple. Overly complex trackers discourage updates. Stick to the seven essential columns — add more only if a specific workflow demands it.
2. Use conditional formatting. High-risk gaps in red, partial in amber, compliant in green. Leadership grasps this instantly without reading a single row.
3. Assign named owners. "IT" is not an owner. A named individual with a deadline is. Accountability accelerates remediation — vague ownership stalls it.
4. Link evidence directly. Hyperlink policies and logs where possible. During audits, this reduces evidence retrieval from hours to minutes.
5. Treat it as a living document. Review it in management meetings and internal audits. A static snapshot becomes outdated within weeks of the first remediation action.

Mini Case Study — Healthcare Provider

During an ISO/IEC 27001:2022 implementation, a healthcare provider used the structured tracker and identified 34 gaps across 93 Annex A controls. Rather than attempting to close all 34 simultaneously, the team prioritised the ten High-risk findings — incident response, supplier evaluation, and backup testing among them.

Within two months, 80% of High-risk gaps were closed. The tracker was presented directly to external auditors as part of the evidence trail. The lead auditor's observation: this was one of the most structured gap analysis presentations they had reviewed.

Over-Focusing on Technology

Organisations often treat ISO/IEC 27001:2022 as an IT project. They assume purchasing a SIEM, deploying firewalls, or enabling MFA constitutes an ISMS. Auditors disagree. The management system clauses — leadership commitment (Clause 5), risk management (Clause 6), and performance evaluation (Clause 9) — carry equal weight to technical controls. Technical remediation without management system evidence will not pass audit.

Fix: Allocate gap analysis effort equally between Clauses 4–10 and Annex A. Never treat the clauses as administrative background.

Conducting It As a One-Time Exercise

A gap analysis conducted once, filed, and forgotten is not a gap analysis — it is a point-in-time snapshot with a limited shelf life. Cloud migrations, mergers, new regulations, and changes in the threat landscape can invalidate findings within months. The ISMS must evolve, and so must the gap assessment that feeds it.

Fix: Schedule annual reassessments and trigger additional reviews whenever a significant change occurs — new systems in scope, material outsourcing arrangements, or regulatory changes affecting information security obligations.

Lack of Cross-Functional Input

Gap analyses run exclusively by the IT or security team miss the business context that auditors probe. HR's handling of joiners/movers/leavers (Annex A.6), procurement's supplier management practices (Annex A.5.19), and legal's regulatory obligations all fall within scope. A gap analysis conducted in a silo produces a silo result.

Fix: Involve HR, legal, procurement, and operations from the outset. Document their inputs and evidence — it demonstrates cross-functional ISMS ownership that auditors look for.

Confusing "Documented" with "Implemented"

A policy document is not evidence of an implemented control. Auditors distinguish between the existence of a written procedure and observable evidence that the procedure is followed. A change management policy filed on SharePoint but never referenced in actual change requests is not an implemented control.

Fix: For each control marked as implemented, collect operational evidence — audit logs, ticket records, meeting minutes, training completion records. If evidence cannot be produced, mark the control as partial regardless of what documentation exists.

Underestimating the Effort Required

A full ISO/IEC 27001:2022 gap analysis covering all Clauses and 93 Annex A controls typically takes a dedicated team two to four weeks to complete properly — longer for complex or multi-site organisations. Compressing this into a few days produces a superficial assessment that misses the nuances auditors probe.

Fix: Budget adequate time at the start of the ISMS project. A thorough gap analysis is the most high-leverage investment in the certification timeline — it prevents expensive corrections later.