
An ISO 27001 gap analysis answers a question you did not actually ask.
It tells you what is missing from your documentation, measured against a list of requirements. It does not tell you whether you can operate what is missing afterwards. Those are two different things, and the difference costs more time in ISO projects than the audit itself.
The reflex makes sense. At some point a tender says «ISO 27001 preferred», or the board of directors asks for evidence, and then the first step is almost always: let us do a gap analysis first. That is a good step, provided you know what you are ordering.
What the standard says and what it does not
The term «gap analysis» does not appear in ISO/IEC 27001. The standard covers risk treatment in clause 6.1.3, the Statement of Applicability, the internal audit in clause 9.2 and the management review in clause 9.3. A gap assessment is a consulting service that borrows this structure. That is not a criticism, only a clarification: there is no normative requirement for what such an analysis has to look like. The scope is a matter of negotiation. That is exactly why two offers with the same title often differ considerably in price, without the text saying why.
In practice you get a table. The requirement on the left, the current state in the middle, the gap and a recommendation on the right. The provider compares this against clauses 4 to 10 of the standard and against Annex A, which in the 2022 edition lists 93 controls across four themes: organizational, people, physical, technological.
This document is useful to you. It makes something visible that was previously a gut feeling, and it stops you from starting a certification project with a number in your head that nobody ever checked. But it remains a description of a state, not a plan.
A gap analysis is not an internal audit
We see this mix-up regularly, and it is expensive because it only surfaces late.
Clause 9.2 requires the organization to audit its own ISMS at planned intervals. That is a separate, recurring obligation, and it examines something other than a gap analysis does: not whether the requirements are described, but whether what you described actually runs that way and works. An internal audit needs a running system. A gap analysis comes before that and therefore cannot logically deliver the same thing.
Bringing in someone external for the internal audit later is fine, and with small teams it is often the only way to establish objectivity. It is simply a second, later engagement with a different subject. Anyone who ticks off the gap analysis in the project plan as «internal audit done» arrives at the certification audit without one of the first evidence trails they will be asked for.
The same applies in the other direction: a gap analysis is not a penetration test and does not replace one. It examines paperwork and processes, not technology. We separated out which test is worth what and when in Security Assessment vs Penetration Test.
The order matters more than the list
Clause 6.1.3 of the standard sets an order: the organization determines the controls necessary to treat the risks it has identified, and then compares them with Annex A to verify that no necessary control has been overlooked. The Statement of Applicability then records which controls were determined to be necessary, with what justification, whether they are implemented, and with what justification individual Annex A controls are excluded.
So Annex A is the cross-check, not the starting point.
A gap analysis reverses this. It starts from the list and asks what is missing from it. As a stocktake that is fine. It becomes a problem when the result then carries on as the action plan, because you end up collecting controls for which nobody has a risk justification. This shows up at the latest with the Statement of Applicability, because there you need a reason for every excluded control that traces back to your risk treatment. «It was not in the gap analysis» is not such a reason.
On top of that comes an effect that is hard to capture in a table. Two companies with an identical gap list have different amounts of work ahead of them, because their scope differs. Which sites, which processes, which service providers are included determines the effort behind every single line. That is why the scope statement belongs at the beginning of the analysis and not in an appendix.
The gap analysis you are paying for anyway
The certification audit runs in two stages, and by its purpose stage 1 is a gap analysis.
The accreditation requirement for certification bodies, ISO/IEC 17021-1, requires the body to communicate to the client documented conclusions regarding the fulfilment of the stage 1 objectives and the readiness for stage 2, including the identification of any areas of concern that could be classified as a nonconformity during stage 2 (European Accreditation, question 32.5 on the two-stage audit). In plain terms: you get a gap list from precisely the body that decides on the certificate in the end. And you pay for it regardless, because stage 1 is part of the audit price.
This does not mean «so skip the gap analysis». It means that the timing determines the entire value.
Early, it is a basis for a decision. Do we want this at all, at what scope, with what budget, and is an operating ISMS enough for us in the end or do we need the certificate on paper. Late, two or three months before stage 1, it is mostly reassurance. Then you buy the same information twice, and the second time is the more expensive one, because it sits in the project budget instead of the preliminary phase. For anyone watching the costs, this is one of the clearer levers in the whole ISO 27001 budget.
Every line needs someone to operate it
A gap list treats every line like a task with a beginning and an end. Policy missing, so write the policy, tick the box. But in several places the standard does not require a state, it requires operation. Internal audits and management reviews take place at planned intervals. Risks are assessed and reassessed. Effectiveness is monitored and measured. The evidence an auditor wants to see comes from something having run for a while, not from it having been introduced. You cannot speed up that operating time and you cannot buy it. Why it sets the pace of an ISO project is covered in the article on the duration of an ISO 27001 project.
The real gap is therefore almost never a missing policy. It is the missing person who operates what was missing afterwards.
For businesses covered by the Swiss Information Security Act, this point also gets a date attached. There the gap list comes with a deadline, and a deadline changes the arithmetic: whatever you cannot operate yourself, you have to either buy in or take out of scope, and you want to make both decisions early rather than in the final quarter. Whether you are covered at all is the first question, and it is less clear than the discussion suggests. We took it apart in ISG ISMS mandatory by 2026.
The pattern here is easy to spot once you watch for it. The gap list gets shorter from quarter to quarter, and the project still does not get closer to an audit. Documents appear, evidence does not. Someone described the controls, nobody took them on. A table with the column «Responsible: IT» produces exactly this result in our experience, because «IT» is not a person who sits on a chair in an audit and explains how often they did something.
How to recognise a usable gap analysis
If you order one, check the offer against five points. A provider who knows the craft has no problem with them.
- The scope comes first, not last. One sentence on what is in and what is not, before anything is checked against Annex A.
- One owner per line, with a name or a role. Not «IT», not «management». A person who can answer in an audit.
- Two effort figures instead of one. The one-off effort in days and the recurring effort per year. The second one is what decides feasibility.
- A deletion list. What you do not need based on today's risk picture, and which tools you are paying for twice. A look at your existing licences belongs here, because some of the supposed gaps are often already covered by features included in a subscription you are already running.
- A recommended decision at the end. Certify, operate an ISMS without a certificate, or for now just answer the customer's question. A report without a recommendation pushes the work back to you.
If these points are missing, you get a conformity table. That is not wrong, it is simply considerably less than what the invoice says. We describe the same pattern in the article on what a security assessment actually delivers: the report is not the product, the decisions it makes possible afterwards are.
That is exactly how we set up a baseline review in our Security Assessment. With owners, with two effort figures, with a deletion list. If the order is more what occupies you, measure first or build straight away, we sorted that out in Security Assessment before ISO 27001. And if you are facing the question of whether an ISO project is the right path for you at all, an initial conversation is free of obligation and often already half the answer.
The line that appears in no gap analysis
Take the list you have or are about to get, and cross out in your head every line for which you cannot name a person who will still be operating it in twelve months.
What is left is your actual project scope. The rest is a declaration of intent, and declarations of intent get noticed in stage 2.
One question about this genuinely interests us: how many lines are left standing for you when the owner has to be a human being and not a department?
Frequently asked questions
What is an ISO 27001 gap analysis?
A target-versus-actual comparison: the provider checks your current state against clauses 4 to 10 of the standard and against Annex A, recording status, gap and recommendation for each requirement. The term itself does not appear in ISO/IEC 27001. It is a consulting service with no normatively defined scope, which is why offers with the same title differ so widely.
Does a gap analysis replace the ISO 27001 internal audit?
No. Clause 9.2 requires the organization to audit its own ISMS at planned intervals, checking whether what is described actually runs and works. An internal audit presupposes a running system, whereas a gap analysis comes before it. Ticking it off as the internal audit leaves you without that evidence at the certification audit.
When is an ISO 27001 gap analysis worth it?
Early, as a basis for a decision: scope, budget and whether you need the certificate or an operating ISMS is enough. Shortly before the audit it adds little, because stage 1 of the certification audit is itself a gap list by purpose and is included in the audit price. At that point you pay for the same information twice.




