ISO 27001 Gap Analysis: A 0-5 Maturity Scoring Method to Know Where You Stand Before You Budget

Before you scope an ISMS project, before you run a formal risk assessment, before you commit a budget line to certification, there is one exercise that should come first: a gap analysis. It is a structured comparison of what your organization already does against what ISO/IEC 27001:2022 actually requires across Clauses 4-10 and the 93 controls in Annex A [2][5], and it produces exactly one thing — a prioritized list of what to fix, in what order. It does not produce a compliance judgment, a pass/fail grade, or anything a certification body will accept as evidence of anything. That distinction matters more than it sounds, because a lot of the confusion around ISO 27001 gap analyses comes from people treating them as a mini-audit rather than what they actually are: a planning tool [1].

Skip this step and the usual failure mode is predictable — teams jump straight to writing policies, buying a GRC tool, or asking a consultant for a certification-cost quote, only to discover three months in that half the “new” documentation they built already existed in some form, just undocumented or inconsistently applied. A gap analysis is what tells you, before you spend anything, exactly how far you actually are from the 6-18 month, several-thousand-euro project our ISO 27001 compliance guide describes — and which parts of it you can skip because you are already most of the way there.

What a Gap Analysis Actually Measures

A gap analysis walks the full structure of the standard — the management-system clauses (4 Context, 5 Leadership, 6 Planning, 7 Support, 8 Operation, 9 Performance Evaluation, 10 Improvement) and the 93 Annex A controls, grouped into four themes: Organizational (37 controls), People (8), Physical (14), and Technological (34) [2] — and rates your current state against each one. The output is not “compliant” or “non-compliant.” It is a scored inventory: which requirements are fully met, which are partially met, which do not exist at all, and — critically — which of those gaps actually matter given your risk profile.

Drata, one of the more widely cited compliance platforms writing on this topic, frames it plainly: a gap analysis “evaluates your organization’s information security practices against the ISO 27001:2022 standard” and exists specifically to identify shortfalls and build “a prioritized roadmap” before you invest further resources [1]. That prioritized-roadmap output is the entire point. A gap analysis that just tells you “you’re 40% compliant” and stops there hasn’t done its job — the value is in the ranked list of what to build or fix first, and roughly how much effort each item will take.

Why It Comes Before Scoping and Risk Assessment

The standard sequence most organizations actually follow is: gap analysis, then define the ISMS scope, then run the formal ISO 27005-aligned risk assessment, then build the Statement of Applicability, then implement, then internal audit, then the certification body’s Stage 1 and Stage 2 audits. Gap analysis sits first because every later step depends on knowing your starting point. You cannot honestly scope an ISMS boundary, size a risk assessment effort, or estimate a realistic budget and timeline if you don’t yet know whether your access control practices are mature and your documentation is the weak point, or the reverse.

It’s also a cheap, low-commitment exercise relative to everything that follows — no defined ISMS scope, risk methodology, or outside auditor required, just an honest internal walk through the requirements. Skip it and organizations tend to either over-scope the first risk assessment (assessing risk in areas already well-controlled) or under-scope the budget (discovering mid-project that documentation, not technical controls, is the real gap) — both expensive to unwind once a plan is already committed.

Gap Analysis vs. Internal Audit: “What’s Missing” vs. “Is It Working”

These two get confused constantly, and the confusion is understandable — both involve comparing your organization against ISO 27001’s requirements. The difference is timing and question. A gap analysis asks “what’s missing?” and runs once, at the start, before you’ve built an ISMS to test. An internal audit asks “is what we built actually working?” and runs repeatedly, on a planned cycle, after implementation — and it’s a mandatory, recurring requirement of the standard itself, not a one-off planning exercise [1].

Put another way: a gap analysis is a snapshot against a target state you haven’t reached yet. An internal audit is a formal, evidence-based check of a live system — verifying that the access control policy you wrote is actually being followed, that the incident log shows real entries, that the training records exist for the people the competence matrix says were trained. You’ll run one gap analysis (maybe a follow-up mid-project to check progress), but you’ll run internal audits on a recurring cadence for as long as you hold certification. For the full mechanics of building and running that recurring audit programme, see our ISO 27001 internal audit checklist.

Gap Analysis vs. Statement of Applicability: Maturity vs. Declaration

The other frequent mix-up is between a gap analysis and the Statement of Applicability (SoA). They cover the same 93 Annex A controls, which is where the confusion starts, but they answer different questions for different audiences. A gap analysis assesses maturity and existence — for each control, how well-developed is our current practice, on a scale, informally, for internal planning purposes. The SoA is a formal declaration — for each of the 93 controls, is it applicable to us, why or why not, and what is its implementation status — and it is a document a certification body auditor will read line by line during Stage 1 [4].

The relationship is sequential: your gap analysis findings feed directly into how you write the SoA. A control that scores poorly on maturity in the gap analysis doesn’t get excluded from the SoA — if it’s applicable to your risk profile, it goes in as “applicable, not yet implemented,” with a remediation commitment attached. Scrut’s glossary entry on the SoA describes it as the document that benchmarks your ISMS “against the full Annex A control set” with a justification for including or excluding every control [4] — which is a much more formal, audit-facing artifact than the internal maturity scoring a gap analysis produces. Once you’ve scored your gaps, our Statement of Applicability template covers how to turn those findings into that formal declaration.

A Practical Scoring Approach: 0-5 Maturity, Weighted by Risk

The most common practical method — used across compliance consultancies and GRC platforms, not something specific to this site — is a simple maturity scale scored per clause and per control, rather than a binary yes/no. A widely used version of that scale runs:

• 0 — Non-existent: No control or process in place at all.
• 1 — Ad hoc: Something happens, but informally and inconsistently, with no documentation.
• 2 — Repeatable: Applied consistently in practice, but still undocumented.
• 3 — Defined: Documented and communicated, but not yet monitored for effectiveness.
• 4 — Managed: Implemented, monitored, and reviewed on a regular basis.
• 5 — Optimized: Continuously improved, with metrics feeding back into the process itself [3].

Score every clause and control against that scale for current state, then again for the target state you actually need (most controls don’t need to hit 5 — 3 or 4 is a realistic target for a first certification). The gap is simply target minus current. From there, the practical step most guides recommend — and the one that turns a long list of gaps into something usable — is weighting each gap by risk and effort before ranking it: a gap of 3 in a control tied to a high-likelihood, high-impact risk (say, access control on your primary data store) should outrank a gap of 4 in a control with minimal exposure, even though the raw gap number is smaller [3]. That weighted list becomes your remediation plan and, not coincidentally, the rough shape of your project budget.

Example Gap Analysis Table

A compact version of what this looks like in practice, scored on the 0-5 scale above:

Clause / Control Area	Current Maturity (0-5)	Target	Gap	Priority
Clause 5 — Leadership & ISMS governance	1	4	3	High
Clause 6 — Risk assessment & treatment methodology	2	4	2	High
Clause 9 — Internal audit programme & management review	0	4	4	Critical
Annex A — Access control / identity management	4	4	0	Low
Annex A — Incident management & response	3	4	1	Medium
Annex A — Supplier / third-party security	2	4	2	High

Notice the pattern in this (illustrative) example: the technical control — access control — already scores at target, while the governance clauses (leadership, risk methodology, internal audit programme) show the widest gaps. That pattern isn’t random, and it’s exactly what shows up for a specific type of organization, discussed next.

What Changes If You’re Already NIS2-Compliant

An organization running a mature NIS2 compliance programme and an organization starting from zero will produce very different-looking gap analyses, even if their final maturity targets are identical. A from-scratch organization typically shows gaps spread everywhere — technical controls, governance, documentation, all scoring low, because none of it has been built yet.

A NIS2-compliant organization’s gaps concentrate almost entirely in the ISO-specific governance and documentation layer: the formal ISMS scope statement, the Statement of Applicability, the management review cycle, the internal audit programme, and the specific documented-procedure format ISO 27001 auditors expect — not in the underlying security controls. NIS2’s Article 21 risk-management measures and ISO 27001’s Annex A controls overlap on roughly 70-80% of the underlying technical and organizational substance, as our ISO 27001 for NIS2-compliant organizations guide breaks down in full, so access control, incident handling, business continuity, and supplier security in the example table above tend to score in the 3-4 range for these organizations before the project even starts. What’s missing is the ISO-specific formalization: the SoA declaring applicability control-by-control, the internal audit programme run on ISO’s cadence and evidence standard, and the management-review documentation ISO 27001 requires as a standing agenda item rather than an ad hoc practice.

That difference matters for planning. If your gap analysis comes back with strong technical scores and weak governance scores, your remediation effort — and your budget — should be weighted toward documentation and process formalization, not toward buying new security tooling. Getting that weighting wrong is the single most common way a from-scratch project plan gets misapplied to an organization that didn’t need one.

FAQ

Who should run the gap analysis — internal staff or an external consultant?
Either works. An internal team member familiar with the standard can run it with a structured workbook; an external consultant adds objectivity and cross-assessor consistency, which matters more on larger, multi-department assessments.

How long does an ISO 27001 gap analysis take?
For a small or mid-sized organization with a defined scope, a few days to two weeks is typical, covering interviews, document review, and scoring against all clauses and the 93 Annex A controls.

Does a good gap analysis result mean we’re close to certification?
Not by itself. A gap analysis tells you where you stand today; it isn’t evidence a certification body accepts, and it doesn’t replace the risk assessment, the SoA, or the internal audit that still have to happen before a Stage 1/Stage 2 audit. Think of it as the planning input, not a milestone toward certification.

Do we need to redo the gap analysis if we already did one for NIS2 or another framework?
You don’t need to start from zero, but you do need to re-map findings against ISO 27001’s specific clause and Annex A structure — a NIS2 risk assessment or gap review won’t have scored ISO-specific governance items like the management review cycle or the SoA, because NIS2 doesn’t require those in that form.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

• [1] ISO 27001 Gap Analysis: What is It and How to Perform One?, Drata
• [2] ISO 27001 Controls Explained: A Guide to Annex A, Secureframe
• [3] Preparing an ISO 27001 Cybersecurity Maturity Comparison, ISOsecu
• [4] Statement of Applicability, Scrut Automation
• [5] ISO/IEC 27001:2022 — Information security management systems, International Organization for Standardization (ISO.org)