.png)
.avif)
.svg)
The short answer: An ISO 27001 gap analysis compares what your organisation does today against every requirement in ISO/IEC 27001:2022, clauses 4 to 10 plus the 93 Annex A controls, and records where you fall short. The output is a scored list of gaps, each with an owner and an effort estimate, which becomes your implementation plan. Run it before you build an ISO 27001 information security management system, and again before you book the certification audit. It is not an internal audit and does not replace one.
Most gap analyses get commissioned because a customer asked for the certificate and someone has to tell the board how far away it is. This is where the project takes its real shape: scope, budget, timeline, and the awkward conversation about who owns supplier due diligence. Get it wrong and you build the wrong ISMS at speed. Skip it and you find the gaps at stage 2, on the auditor's clock.
{{snapshot}}
ISO 27001 gap analysis at a glance
- What it measures: current practice against clauses 4 to 10 and the four Annex A themes (organisational, people, physical, technological).
- What it produces: a scored gap register with owners, effort and priority, which becomes the implementation plan.
- When to run it: before implementation starts, and again four to six weeks before stage 1 as a readiness check.
- How long it takes: one to three weeks for a single-site company of under 100 people.
- What it is not: an internal audit. Clause 9.2 still requires one, and no auditor accepts a gap report in its place.
{{/snapshot}}
Gap analysis, readiness assessment, internal audit: three different things
These terms get used interchangeably and should not be. A gap analysis is a one-off diagnostic run before you have an ISMS, or before you have finished one. It asks what the standard requires and what you have. Nobody checks whether a control operates effectively, because most do not exist yet.
A readiness assessment is the same exercise pointed at the audit rather than the standard. It assumes the ISMS is built and asks whether the evidence would survive a stage 1 document review and a stage 2 site visit. A short, self-scored version tells you whether you are three weeks or three months away.
An internal audit is a clause 9.2 requirement: planned, independent of the work being audited, sampled against real evidence, and reported into management review. Certification bodies expect at least one full cycle before stage 2. The clause 9.2 internal audit guide covers what independence means when you have 30 staff. Present a gap analysis as your internal audit and you collect a non-conformity for the audit itself, a special kind of embarrassing.
Who should run it, and how long it takes
Three options, in ascending order of cost. Your own project owner with a good checklist and a fortnight of protected time. An external consultant, typically two to five days of interviews plus a report. Or a platform that walks you through the requirements and stores the answers as the first draft of your evidence library, so the gap analysis becomes the project.
Self-run works when the assessor has read the standard rather than a summary, and has the seniority to get honest answers out of engineering, HR and finance. It fails when the assessor is also the person who will be blamed for the gaps. In small businesses those are usually the same person, which is the strongest argument for a guided assessment over a blank spreadsheet. Consultants earn their fee on a first certification with no in-house experience. They are poor value when the gaps are obvious and the real problem is capacity.
A single-site firm of 20 to 100 people should expect one to three weeks from kick-off to a report you can plan against. Multi-entity or regulated businesses take longer, mostly because agreeing scope takes longer. Feed the scored output into the certification timeline tool and the ISO 27001 cost calculator for a date and a budget the board can argue with.
How to structure an ISO 27001 gap analysis
Work through the standard in the order it is written. Clauses 4 to 10 are the management system; Annex A is the control set you will later justify in the Statement of Applicability. For every area, record what good looks like, what you have, and what evidence you would show an auditor. Blank cells are gaps. Work from the standard itself, not a summary.
| Area assessed | What good looks like | Typical gap | Evidence to collect |
|---|---|---|---|
| Clause 4: context and scope | Documented scope with boundaries, interfaces and interested parties | No scope statement, or "the whole company" with nothing excluded and nothing justified | Scope document, interested parties register, organisation chart |
| Clause 5: leadership | Approved security policy, defined roles, visible management commitment | Policy exists but nobody senior has signed or read it | Signed policy, role descriptions, leadership minutes |
| Clause 6: planning | Written risk method, risk treatment plan, measurable objectives, Statement of Applicability | No written method; risks copied from a template register | Risk methodology, risk register, treatment plan, SoA |
| Clause 7: support | Competence records, awareness training, controlled documents | Training ran once; documents have no owner or version | Training records, document register |
| Clause 8: operation | Risk assessment repeated at planned intervals and on significant change | Assessment done at implementation and never revisited | Dated risk assessment results, change records |
| Clause 9: performance evaluation | Internal audit programme, management review with recorded inputs and outputs | No internal audit; management review is a calendar invite with no minutes | Audit programme, audit reports, management review minutes |
| Clause 10: improvement | Non-conformities logged with root cause and corrective action | Issues fixed informally in Slack with nothing recorded | Non-conformity log, corrective action records |
| Annex A: organisational (37 controls) | Supplier, asset, access and incident processes defined and owned | Supplier contracts with no security clauses; no asset register | Supplier register, asset inventory, incident log |
| Annex A: people (8 controls) | Screening, contract terms, awareness, disciplinary process, remote working rules | Background checks skipped for contractors | HR onboarding records, signed agreements, training completion |
| Annex A: physical (14 controls) | Secure areas, clear desk, equipment disposal, off-site assets | Office access relies on a door code unchanged since 2019 | Visitor logs, disposal certificates, access lists |
| Annex A: technological (34 controls) | Logging, backup, malware protection, secure development, configuration management | Backups exist but restores are never tested; MFA is partial | Backup test records, MFA coverage reports, configuration baselines |
Two rules make this useful. Collect the evidence column as you go, even for areas that pass, because it becomes the skeleton of your evidence library. And nobody answers yes to a row without naming the document or system that proves it. "We do that" is not a finding.
Scoring gaps without fooling yourself
A gap analysis with three states (yes, no, partial) produces a report where most rows say partial and nobody learns anything. Use a maturity scale with at least four levels: nothing in place, informal practice, documented but not operating, operating with evidence. Score every clause and every applicable control, then weight by effort and audit risk. A missing management review is a fast fix with high audit risk. An untested backup restore is slower and, for a SaaS company, existential.
Keep the scoring honest by separating the assessor from the owner. Whoever runs your infrastructure will rate patching as operating with evidence because they know it happens. The real question is whether a stranger could confirm it in twenty minutes from records alone. If not, it scores documented but not operating. That is the test an auditor applies.
Annex A controls need a decision before they get a score. If you have not drafted your Statement of Applicability, do a first pass now: mark each control applicable or not, with a one-line justification. Scoring controls you will later exclude wastes a day and tempts people to keep them "just in case".
The gaps we see most often
The pattern repeats across sectors and company sizes.
- No scope, or a scope nobody can defend. Clause 4.3 asks for a documented scope with boundaries and interfaces. First-timers tend to have nothing, or "the whole company" covering three legal entities and a product in beta. Fix this first, because every other gap changes size with it. Our guide to ISO 27001 scope has three worked scope statements to borrow.
- No risk method. A register full of risks copied from a template, with no written methodology explaining how likelihood and impact were scored or what level of risk the business will accept. Auditors read the method before the register. The ISO 27001 risk assessment page walks through a scoring approach that holds up under clause 6.1.2.
- Policies nobody reads. Twenty documents from a policy pack, naming a CISO you do not employ and a change board that has never met. Rewrite them until they describe what your team does, then get them attested. The ISO 27001 documentation guide separates what must be written down from what is optional, which is less than the pack implies.
- No evidence trail. The controls run. The proof lives in an inbox, a Slack thread and a folder one person understands. This is the gap that turns a two-month project into a nine-month one, and the one a gap analysis most reliably catches, provided you insisted on the evidence column.
Turning the gap report into a project plan
The report is worth what happens on the Monday after it lands. Convert every scored gap into a task with an owner, effort estimate and target date, then sequence in dependency order rather than by severity: scope, then the risk method, then the risk assessment, then the SoA, then policies, then the technical controls the treatment plan calls for. Writing policies first because they look easy produces documents that contradict the risk assessment you write afterwards.
Track the gaps somewhere with live control status, not the spreadsheet you ran the analysis in. Controls Monitor holds each control's status and evidence and generates the SoA from the control set, so the gap register and the ISMS are the same object rather than two files drifting apart. Net-Defence, a UK cyber-resilience and IT MSP, moved off spreadsheets and reached ISO 27001 compliance roughly 50% faster; its managing director said the result "far exceeded what we originally thought we would get from it". Advantex, a UK IT and comms integrator already holding ISO 9001 and Cyber Essentials Plus, cut audit preparation time by 30 to 40% once gaps and evidence lived in one place.
Re-run the analysis four to six weeks before stage 1. Same structure, same scoring, different question: no longer "do we have it" but "could an auditor find it". Anything still below operating with evidence is what you fix in the final month. Nothing else gets added.
{{snapshot}}
Hicomply's take
We have read a lot of gap reports, and the worst ones were written to reassure. Fifty rows of "partial", no evidence column, no owners, and a summary saying the organisation is "well positioned". Six months later the same company is scrambling before stage 2. The reports that work are uncomfortable: they name the missing scope statement, say the risk register was copied, and attach an effort estimate to every line. Score harshly, insist on evidence for every yes, and run the analysis inside the tool you will run the ISMS in, so the answers become your evidence library rather than a PDF nobody opens again.
{{/snapshot}}
Find the gaps before the auditor does
A gap analysis done properly is the cheapest week of the whole certification. It sets the scope, sizes the budget, and tells you which four gaps out of forty matter.
Start with the free ISO 27001 readiness assessment for a first read on where you stand, then book a demo and we will run the structure above against your scope, with the answers landing in a platform that typically gets you audit-ready in two to three months rather than a spreadsheet you abandon by stage 1.
