How to run an ISO 27001 gap analysis (free template)

ISO 27001:2022 gives you two distinct yardsticks, and a proper gap analysis covers both. The first is Annex A: 93 controls organized into four themes (organizational, people, physical, technological). This is the part everyone remembers, because it is where the concrete security measures live: access control, encryption, logging, supplier security, incident management.

The second yardstick is the one that gets skipped: clauses 4 to 10, the management system requirements themselves. Context of the organization, leadership, planning, support, operation, performance evaluation and improvement. These clauses are not optional and cannot be excluded. They are what makes an ISMS a system rather than a pile of controls. A surprisingly common failure mode is the organization that walks all 93 controls and feels good about the score, then discovers at the certification audit that it never documented its scope or stood up an internal audit programme, and that management reviews never happened.

The mechanics matter less than the discipline. A workable approach:

• Fix the scope first. Decide which parts of the organization, which locations and which systems the ISMS covers before you assess a single control. Otherwise every answer is "it depends".
• For each control, ask two questions, not one: does something exist (a policy, a routine, a technical measure), and does it actually operate in practice? A policy nobody follows is a gap with paperwork.
• Use a consistent status scale (for example compliant, partially compliant, non-compliant, not applicable) and apply it the same way across all controls.
• Write a short justification for every answer, including the not-applicable ones. Six months from now, the justification is the only thing that explains the status.
• Note the evidence, or its absence, as you go. If you can't point to where proof would come from, the honest status is weaker than you think.
• Involve the people who operate the control, not only the ones who wrote the document. The distance between those two views is often the real finding.

The raw output of a gap analysis is a long list, and a long list is not a plan. Prioritize on three axes. Risk first: which gaps expose the assets and scenarios your risk assessment worries about most? A missing control that guards your customer data outranks a missing control on a system nobody depends on.

Dependencies second: governance and policy gaps unblock everything downstream, because procedures and technical measures need something to trace back to. And momentum third: a few quick wins (a configuration change, an owner assigned, a routine written down) keep the programme moving while the structural work, like a supplier security process or a business continuity capability, is built over months.

Most bad gap analyses fail the same few ways:

• Assessing only Annex A and ignoring clauses 4–10. Controls without a management system will not certify.
• Grading on paper: marking a control compliant because a document exists, when the question is whether the practice exists.
• Skipping justifications, so the analysis can't be defended, or even understood, later.
• Confusing the gap analysis with the risk assessment. They complement each other: the gap analysis measures distance to the standard, the risk assessment decides what your organization actually needs.
• Treating it as a one-off. A gap analysis dated last spring describes an organization that no longer exists; the value is in re-measuring against the same yardstick as the work progresses.

If you want to start today, we've packaged the approach above as a spreadsheet: download the ISO 27001 gap analysis template (.xlsx). No email gate, no sign-up. There is a Swedish version too.

It contains all 115 rows you actually need to assess: the 93 Annex A controls and the 22 management-system requirements from clauses 4 to 10, which most free templates leave out. Each row takes a status on the four-step scale above (as a dropdown), a justification, evidence, an owner and a target date. A summary tab counts progress per area so you can see the trend between re-assessments.

One note on rights: the copyright to ISO/IEC 27001:2022 sits with ISO and IEC, so the template gives you the control numbering and short titles only. For the actual requirement text you need the standard itself, in Sweden sold by SIS.

Fair warning, repeating the mistake list on purpose: a spreadsheet describes your organization on the day you filled it in, and it won't remind you to look again. That's the ceiling. When you hit it, your gap analysis should be a living thing explains what we think comes next.

A gap analysis earns its cost only when it turns into commitments: every prioritized gap gets an owner, a target date and a definition of done that includes evidence. "Policy written" only counts once the policy is approved and demonstrably in use. Then you re-assess on a cadence, and the interesting number becomes the trend, not the snapshot.

This is exactly the working model behind Aquil's Compliance Assistant. It tracks all 93 Annex A controls, each with a status and a written justification, and lets you link the documents and runnable processes that implement a control as its evidence. An approval step sits on top, so every answer is attributed to a person and a point in time rather than to a spreadsheet cell. Cross-framework mappings then show how the same work carries over into other frameworks you answer to, such as NIS2 or GDPR. The mappings inform rather than decide: nothing is ever marked automatically, because the coverage judgment stays yours. The gap analysis stops being a yearly project and becomes the standing state of your ISMS.