· Guide · 11 min read

ISO 27001 Gap Analysis: The Complete Step-by-Step Guide

Learn how to run an ISO 27001 gap analysis, score findings, build a remediation plan and use a practical gap analysis template.


An ISO 27001 gap analysis compares your current information security management system (ISMS) with the requirements of ISO/IEC 27001:2022. Done properly, it tells you what already works, what is missing, what evidence you need and which actions should happen first.

It is not a certification audit and it should not be treated as a box-ticking exercise. Its purpose is to turn a broad standard into a practical, risk-based implementation plan.

If you need a quick starting point before the full analysis, complete the free ISO 27001 Readiness Checker. It asks 25 questions, scores six readiness areas and produces a downloadable report with your five highest-priority gaps.

What is an ISO 27001 gap analysis?

An ISO 27001 gap analysis is a structured review of your existing policies, processes, controls and evidence against the requirements of the standard. For each requirement, you determine:

  • whether it applies to your ISMS;
  • whether it has been implemented;
  • whether the implementation is effective;
  • whether objective evidence exists; and
  • what must be done to close any gap.

The output is normally a gap register and remediation roadmap. Each finding should name the requirement, describe the current state, identify missing evidence, assign an owner and set a target date.

ISO describes ISO/IEC 27001:2022 as the requirements standard for establishing, implementing, maintaining and continually improving an ISMS. That matters because a gap analysis must assess the management system—not only a list of technical security controls.

Gap analysis, risk assessment and internal audit: what is the difference?

These activities support each other, but they answer different questions.

ActivityMain questionTypical output
Gap analysisWhere are we now compared with ISO 27001?Gap register and implementation roadmap
Risk assessmentWhich information security risks matter, and how will we treat them?Risk register and risk treatment plan
Internal auditIs the implemented ISMS conforming and operating effectively?Audit findings and corrective actions

A gap analysis is most useful near the beginning of an implementation or when preparing to transition, expand scope or recover a stalled programme. An internal audit comes later, once the ISMS has been implemented and there is operating evidence to test.

Do not replace the risk assessment with the gap analysis. ISO 27001 expects an organisation-specific risk process. Your control decisions should follow that process, not a generic checklist.

What should the gap analysis cover?

A complete review covers clauses 4 through 10 and the organisation’s treatment of Annex A controls. The clauses examine how the ISMS is governed and operated:

  1. Context of the organisation: interested parties, internal and external issues, and ISMS scope.
  2. Leadership: policy, roles, accountability and management commitment.
  3. Planning: information security risk assessment, risk treatment and objectives.
  4. Support: resources, competence, awareness, communication and controlled documentation.
  5. Operation: execution of planned processes and risk treatment.
  6. Performance evaluation: monitoring, measurement, internal audit and management review.
  7. Improvement: nonconformity, corrective action and continual improvement.

Annex A is a reference set used during risk treatment. ISO/IEC 27001:2022 groups its 93 controls into organisational, people, physical and technological themes. ISO/IEC 27002:2022 provides implementation guidance for information security controls, but it does not replace the certifiable requirements in ISO 27001.

Your review should also account for ISO/IEC 27001:2022 Amendment 1:2024, which added climate-change considerations to the management-system context requirements.

Before you start: define the rules of the analysis

Weak gap analyses begin with a spreadsheet. Strong ones begin with scope and evidence rules.

Confirm the ISMS scope

Write down the products, services, teams, locations, systems and legal entities that are inside the proposed scope. Identify interfaces and dependencies with anything outside it. A finding is difficult to evaluate if the reviewer does not know which part of the organisation it covers.

Choose a consistent rating scale

Use a small scale that distinguishes design from operation. For example:

RatingMeaningEvidence expectation
0 — Not startedNo defined approachNo reliable evidence
1 — Partially designedSome activity or draft documentation existsIncomplete or informal evidence
2 — ImplementedRequirement is designed and operatingCurrent evidence exists, but effectiveness may not be proven
3 — EffectiveRequirement operates consistently and is reviewedRepeatable records demonstrate effectiveness
N/ARequirement or control is not applicableDocumented, risk-based justification

Avoid percentages that imply more precision than the evidence supports. The objective is prioritisation and accountability, not manufacturing an impressive readiness number.

Establish evidence standards

Evidence should be current, attributable and relevant to the scoped organisation. A policy proves that an approach was defined; it does not prove that the approach operates. Look for records such as approvals, tickets, logs, meeting minutes, training results, risk decisions, review outputs and completed corrective actions.

How to conduct an ISO 27001 gap analysis step by step

Step 1: appoint an owner and secure leadership access

Assign one person to coordinate the analysis. That person needs access to process owners and senior leadership, because many ISO 27001 requirements sit outside IT. Human resources, procurement, facilities, legal, product and executive management may all hold relevant evidence.

Agree how findings will be escalated and who can accept remediation priorities. Without this, the analysis becomes a document-collection project with no route to decisions.

Step 2: collect existing ISMS material

Request evidence before interviews so you can test practice rather than spend meetings searching for files. Start with:

  • ISMS scope and information security policy;
  • organisation chart and security responsibilities;
  • asset inventory and information classification rules;
  • risk assessment method, risk register and treatment plan;
  • Statement of Applicability (SoA);
  • supplier, access-control, incident and continuity processes;
  • security objectives and performance measures;
  • internal audit and management review records; and
  • corrective-action records.

Do not mark a requirement complete because a file has the right title. Check its approval, ownership, review history, scope and use in daily work.

Step 3: review clauses 4–10 requirement by requirement

Work through the mandatory clauses first. For each requirement, record the current state in plain language, cite the evidence examined and rate the gap.

Ask three questions repeatedly:

  1. Is it defined? There is an approved, appropriate approach.
  2. Is it operating? People follow the approach in the scoped environment.
  3. Is it effective? Results are monitored and weaknesses lead to improvement.

This prevents the common mistake of giving full credit for documentation alone.

Step 4: test the risk assessment and treatment process

The risk process is the engine of an ISO 27001 ISMS. Confirm that the organisation has repeatable criteria for identifying, analysing, evaluating and treating information security risks.

Sample several risks from beginning to end. Can you trace each risk to an owner, treatment decision, selected controls, implementation evidence and residual-risk approval? If not, describe the broken link precisely. “Risk management incomplete” is too vague to guide remediation.

If the risk register itself is weak, use the practical guide on how to build an information security risk register before finalising the treatment plan.

Step 5: assess the Statement of Applicability

The SoA should connect risk treatment decisions to the Annex A control set. Check that it:

  • identifies necessary controls;
  • explains why controls are included;
  • justifies exclusions;
  • records implementation status; and
  • remains consistent with the risk treatment plan.

Do not assume every Annex A control must be implemented in exactly the same way. Applicability and implementation should follow the organisation’s risks, obligations, scope and operating context. Additional controls may also be necessary.

Step 6: test control operation with samples

Move beyond interviews. Select samples that demonstrate whether controls operate consistently—for example, recent joiners and leavers, privileged-access reviews, supplier assessments, incidents, backups, vulnerabilities or change records.

For each sample, note the population, selection method, period and result. A single screenshot may show configuration at one moment; it rarely proves sustained operation.

Step 7: document gaps so another person can act on them

Every finding should contain five elements:

  1. Requirement: clause or control reference.
  2. Current state: what is actually happening.
  3. Gap: what is absent, incomplete or ineffective.
  4. Evidence: what was reviewed and what could not be produced.
  5. Recommended outcome: the capability or evidence needed—not a generic instruction to “create a policy.”

A useful finding reads: “Quarterly privileged-access reviews are defined, but no completed review records were available for the two most recent quarters.” That is clearer than “Access reviews missing.”

Step 8: prioritise by risk and dependency

Not all gaps should be closed in spreadsheet order. Prioritise findings using:

  • information security risk;
  • certification impact;
  • legal, regulatory and contractual obligations;
  • dependency on other work;
  • implementation effort; and
  • time needed to generate operating evidence.

Start early on activities that need a history, such as awareness measurement, access reviews, performance monitoring, internal audit and management review. A newly written procedure cannot create six months of records retrospectively.

Step 9: build the remediation roadmap

Convert the gap register into managed work. Each action needs a named owner, target date, required resources, dependency and acceptance criterion.

Group related actions into workstreams such as governance, risk management, people, suppliers, technology, physical security and assurance. Review progress regularly and retain evidence as actions close.

Step 10: validate closure and prepare for internal audit

Closing an action is not the same as closing a gap. Re-test the requirement and confirm that the evidence demonstrates design, operation and effectiveness at the expected maturity level.

Once the major gaps are closed and processes have produced records, run an internal audit across the defined scope. Findings from that audit should feed corrective action and management review before the certification audit.

ISO 27001 gap analysis template: essential columns

A practical ISO 27001 gap analysis template should include these fields:

FieldPurpose
Requirement referenceClause, subclause or Annex A control
Requirement summaryPlain-language review point
ApplicabilityApplicable or justified N/A
Current stateWhat is implemented today
Evidence reviewedFile, record, system or interview source
RatingAgreed maturity or implementation score
Gap statementSpecific missing or ineffective element
Risk/priorityBusiness and certification significance
Remediation actionDefined outcome required to close the gap
OwnerOne accountable person
Target dateRealistic completion date
Closure evidenceProof required before validation
StatusOpen, in progress, blocked or validated

Keep the requirement text short and use your licensed copy of the standard during the review. ISO standards are copyrighted; copying the full standard into a public spreadsheet is not appropriate.

Common gap-analysis mistakes

Treating Annex A as the whole standard

An organisation can operate many good security controls and still lack a conforming ISMS. Clauses covering scope, leadership, objectives, measurement, internal audit, management review and improvement are mandatory parts of the system.

Scoring documents instead of outcomes

A policy is evidence of design. It is not evidence that access was reviewed, incidents were handled or suppliers were monitored. Ask for operating records and sample them.

Writing findings that cannot be closed

“Improve security awareness” has no defined finish line. Specify the missing capability, the expected evidence and the person responsible.

Ignoring dependencies

The SoA depends on risk treatment. Security objectives depend on context and leadership direction. Internal audit needs implemented processes to test. Sequence the roadmap accordingly.

Overstating readiness

A gap-analysis score is an internal planning indicator, not a certification prediction. Certification bodies make conformity decisions through independent audit evidence.

How long does an ISO 27001 gap analysis take?

The duration depends on scope, organisational complexity, evidence quality and interview availability. A focused small organisation may complete an initial analysis in several working days. A multi-entity or highly regulated scope may require several weeks.

The more useful planning question is: how much evidence must be reviewed to make the findings reliable? A rapid workshop can identify obvious gaps, but it cannot provide the same assurance as document review, process-owner interviews and control sampling.

What should you do after the gap analysis?

Use the output as a living implementation backlog:

  1. approve priorities and resources;
  2. resolve scope and risk-method issues first;
  3. implement controls and supporting processes;
  4. collect operating evidence as work progresses;
  5. validate completed actions;
  6. perform the internal audit;
  7. conduct management review; and
  8. resolve corrective actions before certification assessment.

Revisit the analysis when the organisation, threat environment, technology or scope changes. ISO 27001 is a continual-improvement system, so readiness is maintained rather than achieved once.

Start with a five-minute readiness check

If you are not yet ready for a clause-by-clause workshop, use the free ISO 27001 Readiness Checker to establish a baseline. You will receive:

  • an indicative readiness score;
  • a breakdown across six implementation areas;
  • your five highest-priority gaps; and
  • a downloadable PDF action summary.

Check your ISO 27001 readiness now →

The checker is an initial self-assessment. Use the full gap-analysis method above—and competent, independent audit support where appropriate—before making certification decisions.

Frequently asked questions

Is an ISO 27001 gap analysis mandatory?

The standard does not require a document specifically named “gap analysis.” Organisations use one because it is an efficient way to compare the current state with the target requirements and plan implementation. Mandatory assurance activities such as internal audit still need to be performed when applicable to the implemented ISMS.

Can we perform the gap analysis ourselves?

Yes. Internal teams often perform the first analysis because they understand the business and systems. An experienced independent reviewer can add challenge, reduce interpretation bias and identify evidence weaknesses before certification.

Is a gap analysis the same as a readiness assessment?

The terms are sometimes used interchangeably. In practice, a gap analysis is usually a detailed requirement-by-requirement review, while a readiness assessment may be a shorter evaluation of whether the organisation is prepared for the next stage.

Should every Annex A control be marked applicable?

Not automatically. Control selection should follow information security risk treatment and relevant obligations. Include necessary controls, justify exclusions and ensure the SoA matches the risk treatment plan.

What is the most important gap to fix first?

Fix high-risk issues and foundational dependencies first. Scope, leadership, risk methodology and treatment decisions often unlock several downstream activities. Also begin early where operating history is needed to demonstrate effectiveness.