How to run an ISO 27001 gap analysis (and what to do with it)

The enterprise prospect wants to know when you will be ISO 27001 certified. Your team says you are "mostly there", but nobody can say how far "mostly" is, or what closing the gap will cost. An ISO 27001 gap analysis answers that question with evidence.

This guide is for founders, security leads and the people who inherited compliance at 25–250-person firms. It sets out a six-step method, a maturity scale for scoring what you find, and what the finished output should contain so it turns straight into a plan and a budget.

What is an ISO 27001 gap analysis?

An ISO 27001 gap analysis is a structured comparison between how your organisation manages information security today and what ISO/IEC 27001:2022 requires. It covers the mandatory clauses 4–10 and the Annex A controls, judges each against evidence, and produces a prioritised list of gaps you must close before a certification audit.

The standard itself does not require a gap analysis. Clauses 4–10 set the management system requirements, and the ISO committee overview of ISO/IEC 27001 describes certification as a choice each organisation makes. A gap analysis is the planning step that tells you whether that choice is weeks or months away.

It is easy to confuse with two activities the standard does require:

The difference matters because each produces a different artefact. The risk assessment decides which controls you need. The internal audit tests a system that already runs. The gap analysis comes first and tells you how much system you still have to build.

When should you run an ISO 27001 gap analysis?

Run an ISO 27001 gap analysis before you commit budget or a certification date, because its findings set both. It also earns its place after a failed or difficult audit, when your scope changes through a new service, entity or acquisition, and when the standard itself changes and your ISMS must catch up.

Four moments make the case most clearly:

• Before the project starts. The board wants a timeline and a number. A gap analysis gives you both, grounded in findings rather than a consultant's day rate.
• After a hard audit. A stack of nonconformities tells you what failed. A gap analysis tells you why, and what else is likely to fail next.
• When the scope moves. A new product line, a second legal entity or an acquisition brings systems, suppliers and data flows the ISMS has never governed.
• When the standard changes. The ISO/IEC 27001:2022 Amendment 1 (2024) added climate action changes to the context clauses. A targeted gap analysis checks whether your context and stakeholder work reflects them.

Timing also matters inside the year. A gap analysis run six weeks before a planned Stage 1 audit leaves no room to act on what it finds.

How do you run an ISO 27001 gap analysis?

Run an ISO 27001 gap analysis in six steps: fix the scope, walk the mandatory clauses 4–10, walk the Annex A controls, sample evidence to test what you were told, score maturity consistently, and convert the findings into a sequenced remediation roadmap. Each step feeds the next, so doing them out of order weakens the result.

Step 1: Set the scope

Start by deciding what the gap analysis covers, because the answer should match the scope you intend to certify. Name the legal entities, services, locations and technology estate in play, and note the joins with cloud providers and key suppliers.

If you have not yet drafted an ISMS scope, this step produces its first version. Our Clause 4.3 scope guide covers how to draw that boundary along your data flows.

Then list who you need to speak to. A gap analysis that only interviews IT will miss most of clauses 4–7. Book time with the owners of:

• leadership and budget;
• HR, for screening, onboarding and leavers;
• engineering and operations, for change, backups and access;
• suppliers and procurement;
• legal, for contractual and regulatory obligations.

Step 2: Walk clauses 4–10

The mandatory clauses are where most early-stage gaps sit, because they describe the management system rather than the technology. For each clause, ask what exists, who owns it, and what evidence proves it runs.

Planning and performance evaluation usually carry the biggest gaps in first-time assessments, because they depend on the ISMS having run for a while. Our Clause 6.1 guide explains how risk assessment, treatment and the SoA connect.

Step 3: Walk Annex A

Annex A of ISO/IEC 27001:2022 lists 93 controls in four themes: 37 organisational, 8 people, 14 physical and 34 technological. Assess each against your current practice, and record a provisional view of whether it applies to your scope.

Treat those applicability views as provisional. The Annex A controls guide explains why the final decision belongs to your risk assessment and the Statement of Applicability, not to the gap analysis.

Walk Annex A by theme owner rather than in numerical order. Engineering can answer most of the technological theme in one sitting. HR covers most of the people theme. Facilities, or whoever manages your office and cloud providers, covers the physical theme. The organisational theme is the cross-functional one, so it usually needs several short conversations rather than one long one.

Step 4: Sample evidence

Interviews tell you what people believe happens. Evidence tells you what actually happens. For every control or clause marked as in place, ask for a sample: the last three access reviews, a recent change ticket, last quarter's backup restore test, the most recent leaver's access removal.

Three rules keep sampling honest:

1. Choose the samples yourself. Records picked by the process owner tend to be the good ones.
2. Cover a period, not a moment. An auditor at Stage 2 looks for evidence that a control ran over months, so sample across at least the last quarter.
3. Follow one thread end to end. Trace a single risk from the register to its treatment, the control, and the record the control produced. One complete thread shows more than twenty isolated documents.

A control you cannot evidence is a gap, whatever the policy says.

Step 5: Score maturity

Give every clause and control a maturity score on a consistent scale, so findings can be compared and prioritised. The next section sets out the scale we use.

Step 6: Build the remediation roadmap

Turn the scored findings into a sequenced plan. Group related gaps into workstreams, assign an owner to each, estimate effort, and order the work so foundations come first: scope, risk method and policy before detailed control evidence.

A typical sequence looks like this:

1. Foundations: scope, context, interested parties, the security policy and named roles.
2. Risk: the risk method, the first full risk assessment, treatment decisions and the Statement of Applicability.
3. Controls: the Annex A gaps the risk treatment selected, ordered by risk rather than by control number.
4. Operating evidence: time for controls to run and produce records.
5. Assurance: the first internal audit and management review, which must happen before a Stage 1 audit.

Operating evidence and assurance cannot be compressed much. Controls need time to generate evidence, so plan the operating period into the roadmap from the start.

The roadmap is the bridge to delivery. Our ISO 27001 implementation roadmap shows how those workstreams fit into a phased project.

How should you score maturity in an ISO 27001 gap analysis?

Score maturity on a simple, defined scale so every finding is judged the same way. We use a five-point scale from 0 (absent) to 4 (measured and improving). The scale is our planning method, not an ISO requirement. Its value is separating controls that exist on paper from controls that operate and leave evidence.

For certification, aim for level 3 across everything in scope. Level 4 matters most in the performance evaluation and improvement clauses, where the auditor expects to see measurement and review in action.

Score honestly. A scale that rates a written-but-unused procedure at 3 hides exactly the gaps a Stage 2 auditor will find.

Two rules keep scoring consistent across assessors. First, score the evidence, not the interview: if nobody can produce a record, the score cannot exceed 2. Second, record the reason for every score in one line, so the result can be challenged and repeated next year.

What should the gap analysis output include?

A useful ISO 27001 gap analysis output contains four things: a findings register with the evidence behind each score, a maturity heatmap by clause and Annex A theme, a sequenced remediation roadmap with owners and effort, and a short executive summary stating readiness and what certification will realistically take.

Each part serves a different reader:

• Findings register. Every requirement, its score, the evidence sampled and the gap in one sentence. This is the working document for the people closing gaps.
• Maturity heatmap. Clauses 4–10 and the four Annex A themes on one page, coloured by score. This is what leadership reads.
• Remediation roadmap. Workstreams, owners, dependencies, effort estimates and target dates. This becomes the implementation plan.
• Executive summary. Overall readiness, the three to five gaps that drive the timeline, and the decisions leadership must make.

The roadmap's effort estimates also feed the budget conversation. Our ISO 27001 certification cost guide breaks down the cost lines those estimates sit within.

Keep the findings register live once the project starts. Updated as gaps close, it becomes the progress tracker, and its scoring logic carries straight into your first internal audit.

What are the most common ISO 27001 gap analysis mistakes?

The most common ISO 27001 gap analysis mistakes are treating it as a document checklist, accepting interview answers without sampling evidence, assessing Annex A before clauses 4–10, scoping it differently from the certification you want, and producing a findings list with no owners or sequence. Each one makes the result look better than reality, then fails at audit.

Watch for these in particular:

1. Checking documents, not operation. Confirming a policy exists says nothing about whether anyone follows it.
2. Skipping the clauses. Teams with strong technical controls often rush to Annex A and miss gaps in risk assessment, objectives, internal audit and management review.
3. Marking controls not applicable too early. Applicability is a risk decision. Deciding it during the gap analysis bypasses the risk assessment.
4. Scoring generously. Optimistic scores shorten the plan on paper and lengthen it in practice.
5. Stopping at the findings list. A list of 60 gaps with no owners, order or effort estimates gives leadership nothing to decide.

A gap analysis that only asks "do you have a policy?" measures paperwork, not security.

The fix for most of these is the same: anchor every score in evidence, and finish with a roadmap someone owns. Done that way, the gap analysis stops being a report and becomes the first piece of the ISMS itself.

Frequently asked questions