Most ISO 27001 projects do not fail because the standard is too complex. They fail because the team started writing policies before they understood what was actually missing. The gap assessment is two weeks of work that saves three months of rework. It is also the step that gets skipped most often, because "we know what we need." You do not. This is how to find out.
Why a Gap Assessment Matters
The gap assessment answers one question - what is the distance between the organisation as it operates today and the requirements of ISO 27001:2022? It is not an audit. It is not a maturity assessment. It is a baseline measurement that tells you what to build, in what order, and how long it will take. Every other decision in the implementation depends on this baseline.
The teams that run a proper gap assessment finish their ISO 27001 implementation in 9 to 12 months. The teams that skip it routinely end up at 14, 16, or 18. The reason is not that the standard is harder for one team than another - it is that the team without an assessment discovers gaps at internal audit (Stage 5 of the implementation roadmap) instead of at week two. By that point, the cost of fixing each gap has multiplied.
A gap surfaced at week 2 costs roughly 1× to fix - you adjust the project plan and budget for it. The same gap surfaced at week 14 costs roughly 5× - work has been built on top of an assumption that turned out to be false, and unwinding it requires reworking documentation, evidence, and sometimes infrastructure. By month 9, the multiplier is closer to 10×.
What a Gap Assessment Is Not
Three things that get conflated with gap assessments and shouldn't be:
- It is not a risk assessment. Risk assessment evaluates threats, vulnerabilities, and impact. Gap assessment evaluates whether controls exist. Both are required for ISO 27001 - but they answer different questions and run at different times. The mechanics of the risk side are covered in how risk assessment works step by step.
- It is not an internal audit. Internal audit (Clause 9.2) tests whether the implemented ISMS actually works. It runs at the end of the implementation, not the start. A gap assessment evaluates the starting position. An internal audit evaluates effectiveness.
- It is not a maturity assessment. Maturity models (CMMI, NIST CSF tiers) evaluate how well a control is run. A gap assessment evaluates whether the control exists at all. Maturity is a Year 2 conversation. Gap assessment is a Week 1 one.
The assessment produces one core artefact - a gap register listing every requirement, the current state, the target state, and the work required to close the distance. Everything that follows in the project plan flows from that register.
The Six Steps, In Order
Define the Scope
Before any evidence gets collected, agree the scope of the assessment. This is not the final ISMS scope - that comes later - but it has to be specific enough to know what to evaluate. Which products? Which locations? Which technology platforms? Which organisational units? Without this, the assessment slides between scopes mid-stream, which produces a register where some controls were evaluated for the SaaS platform and others for the entire group.
The most useful framing is a one-page scope statement at the start of the assessment, signed off by the security lead and at least one business stakeholder. It can be revised once the assessment is complete and the team has a clearer picture - but at least the assessment itself is consistent.
Build the Assessment Matrix
The matrix is the spine of the entire assessment. One row per requirement, with columns for the requirement reference, the current state, the target state, the rating, the evidence, and the gap (if any). Use the structure of ISO 27001:2022 itself - Clauses 4 to 10 plus the 93 Annex A controls - so the matrix is already organised the way the auditor will think about it.
Skip the temptation to invent your own grouping or to combine controls into themes. The auditor will assess against the standard's structure; your matrix should match. The full breakdown of what each Annex A control means in plain language is in ISO 27001 Annex A controls explained simply.
Collect the Evidence
For each requirement, gather what proves the current state - policies, procedures, screenshots, logs, training records, contracts, exception registers. The evidence is what separates a serious gap assessment from a self-rated checklist. If you cannot show evidence for a control, the rating is not "Compliant," regardless of what the team says they do.
Most evidence collection is interviews plus document review. Sit with the IT lead, the engineering manager, the HR lead, the procurement lead. Walk through their day-to-day. Ask to see specific documents and screen-walks. The interviewer's job is not to take the team's word for what is in place - it is to verify each claim against an artefact.
Score Each Requirement
Apply the rating scale to every row in the matrix. Be conservative - this is the single most common place where assessments go wrong. Internal teams default to "Partial" when "Missing" would be more accurate, and to "Compliant" when "Partial" is the honest answer. Generous scoring at the gap assessment stage produces a project plan that is too short, a budget that is too low, and a Stage 1 audit that fails.
The honest test for "Compliant" is - could you show this control to an auditor today, with current evidence, and have them sign off? If the answer involves "we'd need to gather a few things first," it is not Compliant. It is Partial. The four-level scale, with the actual rules of thumb that hold up, is in the rating scale section below.
Build the Gap Register
For every Partial or Missing rating, capture a row in the gap register - the requirement reference, a description of the gap, the current state, the target state, the estimated effort, the owner, the target date, and the dependencies. The register is what survives after the assessment is filed; it becomes the source document for the risk treatment plan and the project Gantt.
The most useful form is a single living document - spreadsheet or GRC tool - that gets updated through the implementation rather than re-written. When a gap is closed, mark it closed; do not delete the row. The history of how the gap moved from Missing to Partial to Compliant is what the auditor wants to see at Stage 1.
Convert the Register Into a Treatment Plan
The gap register tells you what has to be done. The treatment plan tells you when, in what order, and by whom. Group the gaps into workstreams - access management, asset management, vendor management, incident response, and so on. Sequence the workstreams by dependency - foundational controls (logging, access, asset inventory) before dependent controls (vendor management, incident response, business continuity).
The output is a Gantt-shaped plan that feeds directly into Stage 4 of the implementation roadmap. If the treatment plan looks fine on paper but the team is uneasy about a specific workstream, trust the unease - that is usually where the under-scoped work is hiding.
The Rating Scale That Works
Many teams over-engineer the rating scale - five-level, seven-level, CMMI-style maturity, percentage scores. None of this surfaces extra information. The four-level scale below is what auditors expect, what consultants use, and what produces the cleanest gap register.
Internal teams systematically rate their own work too generously. The fix is not personality - it is process. Have a second person validate every "Compliant" rating with the evidence, and force a downgrade if the evidence does not stand on its own. External assessors are useful here because they have no relationship with the controls and rate them on what is shown, not what is described.
The Gaps Teams Always Find
Across the dozens of gap assessments I have run or supervised, the same eight gaps surface repeatedly. If your assessment does not flag at least four of these, the assessment was probably scored too generously.
| Common Gap | Why It Surfaces | Typical Effort |
|---|---|---|
| Vendor risk management | DPA in place but no risk assessment, no annual review, no termination triggers | 4–8 weeks |
| Access review evidence | Access is provisioned correctly, but no record of periodic review | 2–4 weeks |
| Backup testing | Backups run, but restore has never been tested or documented | 2–6 weeks |
| Incident response evidence | Plan exists but no tabletop exercise, no record of past incidents | 3–6 weeks |
| Asset inventory | Spreadsheet exists but is months out of date and missing categories | 4–10 weeks |
| Cryptographic policy | TLS and disk encryption in place, but no documented standard | 1–3 weeks |
| Secure development lifecycle | Code review happens but threat modelling, security testing, and approval gates are informal | 6–12 weeks |
| Information classification | No formal classification scheme, sensitive data treated by convention | 3–6 weeks |
The 24% Gap That Was Actually 61%
A SaaS company we worked with ran their own gap assessment before bringing us in. They scored themselves at 76% Compliant, with another 18% Partial and only 6% Missing - a picture that suggested the project would close in three to four months. Their finance team had budgeted accordingly.
When we re-ran the assessment with conservative scoring and evidence verification, the picture changed. Compliant dropped to 39%, Partial rose to 47%, Missing rose to 14%. The work was the same - but the timeline expanded from four months to nine, and the budget roughly tripled. The team's instinct on what controls were "in place" was correct in spirit; what was missing in every case was the evidence trail and the operational discipline that an auditor needs to see. Honest scoring up front is the cheapest course correction the project will ever experience.
What to Do With The Results
The gap register is not the end of the gap assessment - it is the start of everything else. Three things should happen within two weeks of the register being signed off:
- Brief leadership on the realistic timeline. If the gap assessment surfaced more gaps than expected (it almost always does), the project plan needs to be re-cut. Better to have that conversation now than at month four.
- Sequence the gaps into workstreams. Group by control family - access, asset management, vendor management, incident response. Run foundational workstreams first; dependent ones follow. This becomes the backbone of Stage 4 of the implementation.
- Set up the living register. The same gap register should be updated weekly through the project. When gaps close, mark them closed (don't delete). The history is what Stage 1 wants to see.
From here, the rest of the implementation is sequence and discipline. The gap assessment has done its job - it has converted "we need ISO 27001" from an aspiration into a project plan. The remaining work is execution, which is harder but no longer a mystery.
Final Thought
The gap assessment is the cheapest insurance policy in any ISO 27001 programme. Two weeks of focused work, conservatively scored, with verified evidence - and the project's worst surprises move from month nine to week two, where they cost a tenth of what they would have cost at internal audit. The teams that skip this step almost always come back to do it later, in worse conditions, under more pressure, with less goodwill from leadership.
If you are still deciding whether your business actually needs ISO 27001 in the first place, the six-trigger self-assessment answers that question first. If the answer is yes, this gap assessment is the next thing to do. Everything else flows from it.
Frequently Asked Questions
A focused gap assessment typically takes 2-3 weeks for a small to mid-sized organisation. Larger or multi-site organisations may need 4-6 weeks. The assessment itself is roughly 1 week of evidence collection and stakeholder interviews, 1 week of scoring and writing, and a few days of validation and stakeholder review.
Both work, with trade-offs. Internal teams know the systems but tend to score generously and miss controls outside their day-to-day visibility. External consultants bring an outside view but need more time to understand context. The most reliable pattern is consultant-led for the first ISO 27001 cycle and internal-led for subsequent recertifications.
A four-level scale works well in practice - Compliant (control fully implemented and evidenced), Partial (control partially implemented or evidence incomplete), Missing (control not implemented), Not Applicable (control out of scope, with documented justification). More granular scales (e.g. CMMI 0-5) tend to invite over-engineering without surfacing extra information.
A gap assessment runs at the start of an ISO 27001 project to identify what needs to be built. An internal audit runs near the end (Stage 5 of the implementation) to verify what has been built actually works. The gap assessment is forward-looking - it estimates effort. The internal audit is backward-looking - it tests effectiveness.
For every Partial or Missing finding: the requirement reference (Clause or Annex A control), a description of the gap, the current state, the target state, the estimated effort, the owner, the target completion date, and the dependencies on other gaps. The register becomes the source document for the risk treatment plan and the implementation Gantt.
No - they are different documents. A gap assessment evaluates whether controls exist and where. A Statement of Applicability declares which controls are applicable to the organisation, with justification. The SoA is produced after the risk assessment in Stage 3 of the implementation. The gap assessment informs the SoA but does not replace it.
Re-run it with conservative scoring and an external pair of eyes. In my experience, "mostly compliant" assessments are almost always over-rated - usually because the team conflated "we have a process" with "we have evidence the auditor can verify." If the second pass still shows a small gap delta, congratulations - you are an unusual case. If it shows the picture was rosier than reality, you have just saved yourself the most expensive surprise of the project.