Information security gap analysis: finding what is actually missing

An information security gap analysis puts the way an organisation currently works next to the requirements of a standard. The standard sets the yardstick, the analysis produces the list of differences. That standard can be ISO 27001, SOC 2, the duty of care under the Dutch Cybersecurity Act or DORA. The method stays the same, the yardstick changes.

The misunderstanding beforehand is that this is a tick list. Walking through the 93 controls in Annex A and writing yes or no after each one leaves you with a document that says very little. The question is not whether a policy exists, but whether that policy does what the standard expects of it and whether you can show it.

Start with the scope

Without a defined scope the outcome cannot be interpreted. In ISO 27001, clause 4.3 fixes the scope of the management system: which parts of the organisation, which locations, which services and which information fall inside it. For SOC 2 the question is which system you intend to report on later, and which Trust Services Criteria you include alongside the common criteria. For NIS2 and DORA the reach follows from the legislation itself, so the first question is whether your organisation falls under it and in what capacity.

In practice organisations regularly pick a scope that keeps the hardest part outside, for instance by leaving out the development team while the service being delivered is built there. That is allowed, but it has to be a deliberate choice. Otherwise it returns during the certification audit as a discussion about what the certificate actually covers, and by then changing the scope is no longer free.

The main clauses weigh more than Annex A

With ISO 27001 the attention almost always goes to the controls in Annex A, while the requirements themselves sit in clauses 4 to 10: context and interested parties, leadership and policy, risk assessment and risk treatment, competence and awareness, monitoring and measurement, internal audit, management review and corrective action. That is where most findings land in practice.

An organisation can be technically well arranged and still fail because the risk assessment was never repeated after the first time, the management review is missing, or the internal audit programme exists only on paper. An analysis that looks at Annex A alone sees none of this. The same applies to the Statement of Applicability: it has to justify the inclusion or exclusion of every control, and that justification is often the real gap. Anyone still coming from the 2013 version should treat the changes in ISO 27001:2022 as a separate item, including the climate amendment in clause 4.1.

Conformity and maturity are two different scales

Many reports mix two things. Conformity is binary: a requirement is met or it is not, and in a certification audit the second leads to a nonconformity. Maturity is a sliding scale describing how firmly something is embedded, from one-off and person-dependent to measured and adjusted. A control can be conformant and low in maturity at the same time, and that is a defensible position as long as you leave it that way knowingly.

Keep the two apart in the report. The conformity column decides whether you can start the audit. The maturity column decides where work remains after certification and what an auditor is likely to raise in year two.

What a usable report contains

For each requirement: the finding, the evidence it rests on and the difference with what the standard asks. Not just a verdict, but where that verdict came from, so a colleague can retrace it later. Alongside that, a prioritisation based on risk rather than on the order of the standard, because Annex A is not a work sequence. And for each gap an estimate of the kind of work involved: writing a document is something else than introducing a process that has to run for a period before there is evidence.

That last distinction drives the planning more than the number of gaps does. An organisation with thirty small documentary gaps is closer to certification than one with five gaps of which three need an observation period.

Who performs the analysis and who may not certify afterwards

A gap analysis is advice, not an audit. It produces no assurance report and no certificate. That distinction has a practical side: the accreditation requirements for certification bodies prohibit the same body from first consulting on the management system and then certifying it, with a cooling-off period of two years. So do not have a certification body run a gap analysis that you want to cash in with that same body later.

For SOC 2 and ISAE reporting the arrangement differs, but the independence reasoning is comparable. Anyone who helped design the control framework cannot report on it independently.

Four patterns that derail a gap analysis

Interviews without evidence. A conversation gives you what people believe happens. Ask for the underlying document, log or ticket behind every confirmation.

Speaking only to IT. Supplier management, HR processes and physical security sit with procurement, human resources and facilities, and that is exactly where the loose ends are.

Treating the analysis as a single moment. After six months of building, the baseline no longer holds. Recalibrate before you fix the audit date.

Leaving the report with the compliance officer. Without an owner, a date and a budget per gap it is an inventory, not a plan.

What you do with the outcome

The list feeds the risk treatment plan and the planning of the project. For ISO 27001 that planning continues in the certification roadmap; shortly before the audit, an audit readiness assessment checks whether the gaps are genuinely closed and whether the evidence can be found. If you would like the analysis carried out, or want to discuss the scope first, see our compliance services.