ISO 27001 gap analysis: method, example gaps, and a remediation plan

TL;DR: An ISO 27001 gap analysis compares your information-security program with the requirements of ISO/IEC 27001:2022 and the controls your ISMS needs. It reviews the management-system requirements in Clauses 4 to 10, the risk assessment and treatment decisions, and the Statement of Applicability, using Annex A’s 93 controls as a reference for checking omissions. The output is a prioritized remediation plan with evidence behind each finding.

An ISO 27001 gap analysis runs in five steps: define the scope and ISMS boundary, review the Clause 4 to 10 management-system requirements, assess necessary controls and Annex A coverage, optionally score control reliability, and build the remediation roadmap. An early review can show what needs to be built before certification. It does not have to precede risk assessment: risk assessment and treatment help determine which controls are necessary, so revisit the gap findings as those decisions develop.

Why we publish this. Search ISO/IEC 27001:2022 for the phrase “gap analysis” and you will not find it. The exercise is not a requirement, it is a practice the industry built to answer a question a program cannot otherwise answer on demand: where do we actually stand, right now. What the standard asks for instead is ongoing. Monitoring and measurement under Clause 9.1, internal audit under 9.2, management review under 9.3, risk reassessment under 8.2 when significant changes occur.

So this is a real method, because most programs need one today. It is also a method whose purpose is to make itself smaller.

The five steps at a glance

Define the scope and ISMS boundary. Name what is inside and outside the ISMS, and write a scope statement you can defend.

Review the Clause 4 to 10 management-system requirements. Walk the mandatory clauses that certification turns on, and name the documented information each one expects.

Assess necessary controls and Annex A coverage. Review the controls selected through risk treatment, compare them with all 93 Annex A references to check for omissions, and record implementation evidence and justified exclusions in the Statement of Applicability.

Optionally score control reliability from 1 to 5. Add a consistent readiness rubric if it helps prioritize work; keep that score separate from conformity and risk.

Build the remediation roadmap. Turn the findings into a sequenced, owned, and dated plan, separating quick wins from structural work.

{{ banner-image }}

Step 1: Define the scope and ISMS boundary

Scope is the first decision because it governs every decision after it. Clause 4.3 asks you to determine the boundaries of the ISMS, and it expects a scope statement that is specific, defensible, and available as documented information. In practice you are naming which legal entities, locations, products, systems, and data types sit inside the ISMS and which sit outside. Clauses 4.1 and 4.2 feed that decision: the internal and external issues that bear on information security, and the interested parties whose requirements the program has to meet.

Getting scope wrong inflates the rest of the work in both directions. Draw it too wide and the gap analysis drags in systems you cannot yet produce evidence for, so the roadmap fills with gaps you were never going to close before the audit. Draw it too narrow and you exclude a system that holds in-scope data, which an auditor will catch, because the scope statement has to be defensible, not just convenient.

Scope also decides what your evidence reaches. When compliance data is collected from connected systems, the boundary you set determines which accounts and systems are pulled in at all, and therefore which records ever get tested against a rule. The same identity-provider export might live in ISO 27001 alone or be shared with two other frameworks — an assignment that is a scoping decision, not a clerical one. Start Step 1 by writing the boundary down and having someone who was not in the room try to poke holes in it.

Step 2: Review the Clause 4 to 10 management-system requirements

Clauses 4 to 10 are the management system itself, and an organization claiming conformity cannot exclude their requirements. Review each clause for what the ISMS must do, then identify the documented information it requires and the evidence that demonstrates operation. The standard sets the requirements; the table below gives practical examples of records to inspect, not a mandatory document title for every row.

The most common way this step goes wrong is to treat the clauses as paperwork and Annex A as “the real controls.” An auditor reads them the other way. A program can hold strong technical controls and still fail Stage 1 for having no risk treatment plan, no Statement of Applicability, or no record of a management review. Walk each clause and ask two questions: who owns it, and what document proves it operates.

ClauseWhat it asksRecords to inspect4 Context of the organizationDetermine the ISMS scope and the internal, external, and interested-party issues that shape itA documented, defensible scope statement5 LeadershipShow top management owns the ISMS, sets the information security policy, and assigns rolesThe approved information security policy; documented roles and responsibilities6 PlanningAssess information security risks, plan their treatment, and set measurable objectivesRisk assessment methodology and risk register; risk treatment plan; Statement of Applicability; documented objectives7 SupportProvide the resources, competence, awareness, and document control the ISMS needsEvidence of competence and training records; a communication plan; document control procedures8 OperationRun the planned processes and reassess risk when significant changes occurOperational process documentation; risk assessment and risk treatment results9 Performance evaluationMonitor and measure the ISMS, audit it internally, and review it at management levelMonitoring results; internal audit program and results; management review outputs10 ImprovementCorrect nonconformities, eliminate root causes, and improve continuallyNonconformity records, root-cause analysis, corrective actions, effectiveness verification

The 2022 edition was amended by Amendment 1:2024 (climate action changes), published February 23, 2024, which adds climate considerations to the context clauses. It is a small addition, but it lives in Clause 4, so a gap analysis run against an older copy of the standard will miss it. Work from the current text.

Step 3: Assess the Annex A controls

This is the part most people picture when they say “ISO 27001 gap analysis checklist.” Annex A of ISO/IEC 27001:2022 is normative, titled Information security controls reference, and lists 93 controls in four themes: Organizational (37), People (8), Physical (14), and Technological (34). Start from the controls your risk-treatment process determines are necessary, then compare that set with Annex A to check for omissions. Assess implementation and supporting evidence, including any necessary controls beyond Annex A.

The Statement of Applicability connects those decisions. It records necessary controls, why they were included, their implementation status, and reasons for excluding Annex A controls. The standard’s own structure makes the relationship plain: Clause 6.1.3 builds the Statement around the necessary controls, with Annex A entering as the list you must justify excluding from, and a note to the same clause records that Annex A’s controls are not exhaustive. So a control is not optional merely because it is difficult to implement, and Annex A is not a universal list of 93 controls every organization must implement. Keep the risk-treatment rationale and the implementation finding connected so an exclusion cannot hide a genuine gap.

The trap in this step is marking a control “met” because a policy for it exists. A written access-control policy is not the same as access rights that match it, which is why a binary met or not-met is often too crude. Our own control assessments distinguish three levels: effective, partially effective because of weaknesses in design, implementation or scope, and ineffective. A control can be present, documented, and still sit in the middle band. Mark it “partially met” when it does.

Step 4: Optionally score control reliability from 1 to 5

A gap analysis that only records met or missing can hide useful differences. Two controls may both be partially implemented, while one has an agreed owner and a repeatable process and the other depends on one person remembering to act. An optional 1 to 5 readiness score can help explain the work left to do. Record the conformity finding, implementation evidence, and risk separately: a higher score does not cancel a requirement or prove that a control is effective.

The rubric below is an editorial readiness rubric for this review, not a CMMI assessment, an ISO requirement, or Anecdotes’ product maturity model. It describes how consistently a control operates and how its owner checks and improves it. A well-run manual control can score highly; automation is one way to support operation, not the scoring criterion.

Score only what the evidence supports, and record what would move the control to the next level. A useful score survives the question “says who?” If a number adds little to your decisions, use the finding and remediation priority without it.

Step 5: Build the remediation roadmap

A list of gaps is not a plan. Clause 10.2 sets the frame for turning one into the other: for each nonconformity, you react to it, address its consequences, eliminate the root cause, and verify the fix worked. A roadmap that records the cause, the corrective action, and the evidence that the action held is the artifact an auditor asks for and the one you can defend to a board.

Sequencing is where judgment enters, and the method here is ours rather than the standard’s. Order gaps by a combination of risk and effort: high-risk quick wins first, high-risk structural work scheduled rather than rushed, low-risk items logged rather than chased. The full roadmap section below works through that sequencing, and what it means for an incoming CISO’s first 90 days.

Gap analysis vs risk assessment vs internal audit

Three exercises get confused constantly, and the confusion costs time, because a team runs the wrong one first and has nothing to feed the next. A gap analysis measures the program against the standard’s requirements to find what is missing. A risk assessment weighs the likelihood and impact of threats to decide what to treat and how. An internal audit tests whether an ISMS you have already built is operating the way it is documented.

Gap analysisRisk assessmentInternal auditQuestion it answersWhere does the current program fall short of ISO/IEC 27001:2022, across Clauses 4 to 10 and the Annex A controls?Which information security risks exist, how do they rate, and how will they be treated?Does the already-built ISMS conform to the standard and to the organization’s own requirements, and is it effectively implemented?When you run itBefore the ISMS is fully built, ahead of Stage 1, and again before recertificationUnder Clause 6.1.2, then repeated under Clause 8.2 at planned intervals and when significant changes occurOn the internal audit program, at planned intervals under Clause 9.2OutputA met, partial, or missing status for each requirement, and a prioritized remediation planRisk assessment criteria and results, which inform the treatment process, treatment plan, and Statement of ApplicabilityAn internal audit program, audit plans, and audit reports; nonconformities flow into Clause 10.2Who runs itAn internal team, or an external readiness firmRisk owners and the ISMS owner, who approve the treatment plan and residual riskAuditors with independence from the work they review

A readiness review can begin early, but there is no universal gap-analysis-first sequence. Risk assessment identifies and evaluates risks; risk treatment selects controls and produces the treatment plan and Statement of Applicability. The gap review tests what is missing from that developing system, and the internal audit evaluates conformity and effective implementation with the required objectivity. Before certification, the management system needs operating evidence as well as documents.

Notice what the middle and right columns have in common. Both recur, by requirement, forever. Only the left one is a project — which is the first hint about where it is heading.

ISO 27001 gap analysis examples: Annex A gaps and fixes

The table below illustrates several Annex A control areas, the gaps a review of supporting evidence can reveal, and possible remediation. Read it as an example of what a checklist surfaces once you look past whether a policy exists to whether the control holds. The control numbers are the 2022 Annex A references; the gaps and fixes are representative of each area rather than a ruling on any single control.

Annex A control (area)Typical gap foundTypical remediationA.5.15, A.8.3 (access control)Access is granted broadly at onboarding and never narrowed, and storage that is public by mistake looks the same as storage meant to be publicReview access against role, remove standing access nobody uses, and separate deliberately public storage from the rest so the real exceptions are the only exceptionsA.8.5 (authentication)MFA is switched on, but “MFA active” hides which accounts still use a method that is not phishing-resistantRequire a phishing-resistant method such as a passkey or hardware key for privileged accounts, and evidence which accounts use which methodA.8.24 (cryptography)Encryption is enabled, but nothing shows the keys are rotated on the interval the policy namesSet the rotation interval in policy, then require evidence that each key gets rotated within it, so an overdue key is visible instead of assumedA.8.32, A.8.31 (secure development)A change record shows an author but not a second approver, and development, test, and production share a pathRequire a second approver on production changes and separate the environments so a change cannot reach production unreviewedA.8.8 (vulnerability management)A finding marked closed shows the work is done, not whether it met the remediation deadlineTrack closure against the SLA rather than closed-or-open, so a fix that missed its window is visible as a missed windowA.8.7, A.8.1 (endpoint protection)A protection policy is active, but an active policy is not the same as an endpoint with every required setting turned onCheck the settings on the endpoints themselves against the policy, and list the endpoints where a required setting is off

These rows are a worked sample, not full Annex A coverage. For the complete review, account for every Annex A reference in the comparison, document justified exclusions, and assess all controls your risk treatment identifies as necessary.

Read the middle column again and notice what every gap has in common: the artifact says the control is on, and the underlying records say something more complicated. That is the pattern the rest of this page is about.

An optional 1 to 5 readiness rubric

Use this rubric consistently across the controls you assess. It describes process reliability so the roadmap can distinguish an undocumented activity from a repeatable, measured one. Keep the supporting evidence next to the score, and keep both separate from the control’s conformity finding and the risk it treats.

LevelWhat it meansEvidence a reviewer expects1: Not establishedThe control is applicable, but no formal process or policy exists for itLittle to show: the control is acknowledged but not yet operating2: InconsistentAn informal or inconsistent process runs against a loosely defined policyThe control happens, but the evidence is ad hoc and depends on who runs it3: DefinedA formalized, approved policy and a consistent processAn approved policy with an approval date, and records that the process ran as written4: MeasuredOperation is measured against defined criteria, and exceptions have an ownerChecks or monitoring records over time, criteria, and evidence of exception handling5: ImprovingMeasured results lead to reviewed improvements in the processMetrics tracked across periods, and a plan that acts on what they show

The evidence column describes what could support a score whether a control runs manually or with software. The point is to explain what reliable operation would take, not to give a maturity label the authority of a certification decision.

The remediation roadmap: sequencing gaps for your first 90 days

The remediation roadmap is where a gap analysis stops describing the program and starts changing it. Of the four things Clause 10.2 asks of each entry, the one teams skip and auditors check is the last: verification that the corrective action worked. A finding marked closed tells you the work is done; it does not tell you the control now holds, or that the fix landed before its deadline. Close findings against evidence that the control operates, not against the ticket being marked done.

Sequence by risk and effort, and keep the two axes separate. High-risk, low-effort gaps come first: they lower real exposure this month and show leadership early progress. High-risk, high-effort gaps — a missing risk treatment process, a control area with no owner — are scheduled as structural work with budget, headcount, and a date, not squeezed in before Stage 1. Low-risk gaps are logged and revisited, not allowed to crowd out the work that matters. The output is an ordered list where every item has an owner, a severity, and a due date.

This is also where the plan becomes trackable rather than aspirational. When a gap is detected in connected evidence, it can open a finding automatically through a playbook you configure: the finding carries a title, a severity, an assignee, and a due date, and a separate trigger fires when a finding passes its due date without being resolved. The automation is something you set up, not something that runs by default, and a person still owns the finding and decides how to close it. What that buys the roadmap is that an overdue structural gap surfaces before anyone asks, instead of resurfacing at the next audit.

For the incoming CISO, this is the artifact that answers the board: what you are fixing first, what you are scheduling and why, and when you can realistically certify. Every line traces back to a requirement in the standard and the evidence behind its status.

Why a checklist alone goes stale

A checklist is a photograph of the program on the day you filled it in. It is the right way to start, and the wrong thing to trust six months later, because the systems it described keep moving after the shutter closes. This is not a failing of the checklist or the team that built it. It is what a static artifact is: a record of one moment, in a program that changes every day. The useful question is what keeps the gap list current between the day you build it and the day the auditor arrives.

For technical controls, scheduled evidence collection keeps system records available between reviews. Analysis rules can compare that evidence with defined conditions and bring exceptions to the owner. A user list, for example, can support access reviews when the reviewer checks it against the correct employee population and scope. This reduces repeated collection work while leaving the ISMS owner responsible for the wider assessment.

The limits matter as much as the mechanism. A clean result means the configured check found no exception in the evidence and scope it examined. It cannot establish that every necessary control was tested, that the risk treatment is appropriate, or that leadership review and competence requirements are met. Conformity remains a conclusion about the whole ISMS.

Two more things go stale, and both bite enterprises running several frameworks. The first is the assumption that a control mapped across frameworks is satisfied everywhere it is mapped. A mapping shows a relationship, not satisfaction, and it operates at the level of expected evidence rather than a broad control name — so a control adopted for ISO 27001 from two other frameworks can look covered while missing the intent of one. The gap hides behind the mapping until the worst possible moment. The second is the standard itself: ISO 27001 moved from its 2013 edition to 2022, with the transition ending October 31, 2025, and 2022 was amended in 2024. A frozen checklist measures against a version that no longer applies.

Three questions help you judge whether a mark on your gap list can be trusted, whatever tool produced it: when the evidence under it was collected, whether it covers the whole population or a clearly flagged sample, and whether it reconciles with the source system it came from. A gap list whose every line can answer those is one an auditor can work from. A spreadsheet filled in by hand months ago usually cannot, which is the case for reading the list off live systems in the first place.

The version of this you are working toward

Run the program that way long enough and something changes about what a gap analysis is.

The exercise exists because the state of the program is unknown between reviews. Every part of the method above — the clause walk, the Annex A comparison, the scoring, the roadmap — is work you do to reconstruct a picture nobody currently holds. Remove the not-knowing and most of that work has nothing left to do.

That is what continuous compliance means in practice, and it is less exotic than it sounds. Technical control status reads from live evidence rather than a spreadsheet filled in last quarter. The Statement of Applicability is a maintained record rather than a document reprinted before audits. Clause 9.1 monitoring is a query rather than a project. When a control drifts, the finding opens and reaches its owner that week, so the roadmap never accumulates six months of surprises for a reviewer to discover.

In that program a gap analysis stops being an event and becomes a view. You do not run it, you look at it. The question changes from “where were we when someone last checked” to “what is failing right now, and who owns it.”

None of that removes the judgment, and it is not meant to. Scope, risk treatment, exclusions, competence, leadership review, and the decision that a control is effective stay with people, and the standard means them to. What continuous evidence removes is the reconstruction — the weeks of chasing between asking a question and getting an answer.

So treat this method as scaffolding. It is the right way to move a program from unknown to known, and you should need less of it every cycle. The measure of a mature ISO 27001 program is not how well it runs a gap analysis. It is how little of one it needs.

How the review connects to other frameworks

When an enterprise operates several frameworks, the useful question is which evidence can be reused without losing each requirement’s meaning. Control mapping records those relationships; a review still needs to check applicability, scope, and evidence separately.

Certificate scope matters too. An organization can hold ISO 27001 alongside other management-system certifications, with different boundaries and evidence needs for each. Our account of earning ISO 27001, ISO 27701 and ISO 42001 describes how they fit together. Here, the roadmap stays specific to the ISMS and the information-security risks it must address.

Frequently asked questions

What is an ISO 27001 gap analysis?

An ISO 27001 gap analysis compares the ISMS with the standard’s requirements and its necessary controls, identifies missing or incomplete implementation, and produces a remediation plan. It covers Clauses 4 to 10 and reviews the Statement of Applicability and Annex A comparison. It can begin early and be updated alongside risk assessment and treatment; it is not a substitute for either process or for the internal audit.

Does ISO 27001 require a gap analysis?

No. The phrase does not appear in ISO/IEC 27001:2022. What the standard requires on an ongoing basis is monitoring and measurement (Clause 9.1), internal audit (9.2), management review (9.3), risk reassessment when significant changes occur (8.2), and corrective action (10.2). A gap analysis is a practice the industry developed to answer a question a program cannot otherwise answer on demand. It is useful, and the better your ongoing evidence, the less of it you need.

What are the steps of an ISO 27001 gap analysis?

Define the ISMS scope, review Clauses 4 to 10, assess necessary controls and the Annex A comparison, optionally score control reliability, and build a remediation plan with named owners. Record evidence for each finding and a justification for Annex A exclusions in the Statement of Applicability. Risk assessment and treatment inform the control decisions throughout.

What is the difference between a gap analysis, a risk assessment, and an internal audit?

A gap analysis identifies shortfalls against the standard and the ISMS’s necessary controls. Risk assessment evaluates information-security risks so risk treatment can select an appropriate response. An internal audit evaluates conformity and effective implementation of the ISMS. The exercises inform one another; ISO 27001 does not require a separate gap analysis to precede risk assessment.

Is an ISO 27001 gap analysis checklist enough on its own?

A checklist needs current supporting evidence and periodic review of scope, risks and the management system. Scheduled evidence collection can refresh technical records, and configured analysis can flag exceptions for an owner to examine. Policies, risk-treatment decisions and management reviews still require people. An absent flag does not prove that the relevant check ran or that the requirement is met. Keep the checklist, source evidence and reviewer decisions together.

How long does an ISO 27001 gap analysis take?

It depends on three things more than on any fixed timeline: the number of systems and sites inside the scope you set in Step 1, the number of evidence owners you have to coordinate across teams, and how much of the evidence you can pull automatically versus gather by hand. A tightly scoped program with connected evidence moves through it faster; a broad multi-entity scope with manual collection takes longer, because the bottleneck is almost always evidence-gathering, not the analysis.

Who should perform an ISO 27001 gap analysis, an internal team or an external consultant?

Either can, and the deciding factor is candor and capacity rather than a rule. An internal team that knows the systems can run a strong gap analysis, provided it assesses its own program candidly; the independence requirement applies to the internal audit under Clause 9.2, not to the gap analysis. External readiness firms bring pattern-matching across many programs and extra hands. Many enterprises combine the two.

Key takeaways

What a gap analysis is worth is decided later, by what the program changes because of it. Five points hold up whichever step you are on:

• Pin down a defensible scope, and update the gap review as risk assessment and treatment establish which controls the ISMS needs.
• Review all Clause 4 to 10 requirements and all necessary controls; use the Annex A comparison and justified exclusions to check coverage.
• Use an optional readiness score when it clarifies the work, keeping process reliability, control effectiveness, conformity, and risk distinct.
• Treat the roadmap as the artifact leadership will read: ordered by risk and effort, with each finding closed against proof the control operates rather than a ticket marked done.
• Expect a hand-filled checklist to age from the day it is finished, and keep the gap list reading from live systems so a control’s status shifts as the systems do, remembering that a missing flag is not proof a relevant check ever ran.

Do the work this way and the question you can answer changes. You can ask not just whether you were compliant at the last review, but which controls are drifting today and where the evidence for that answer sits. That is the difference between a date on a certificate and a program you can account for to a board on the day it asks.

And the exercise itself gets smaller. ISO 27001 never asked for a gap analysis; it asked for a management system that knows its own state. Every cycle your program can answer more of that on its own is a cycle where this page has less work to do.

‍