It is a scene that repeats itself in the first meeting. Someone from the IT team opens a spreadsheet with the Annex A controls of ISO/IEC 27001 and a yes/no column. The result comes out high: seventy-something per cent, sometimes more. The conclusion drawn is that not much is missing.
Quite a lot is usually missing. Not because the spreadsheet is badly built, but because the question it asks is no use for deciding anything.
The problem with asking “does it exist?”
The 2022 version of the standard reorganised Annex A into 93 controls grouped under four themes: organisational, people, physical and technological. A binary self-assessment asks, for each one, whether the control exists.
The problem is that “exists” covers wildly different realities:
- Someone wrote a document nobody read.
- The control is applied, but it depends on one person remembering.
- The control is in the procedure and gets executed, but leaves no record.
- The control is executed, leaves a record, and nobody reviews those records.
- The control is executed, recorded, reviewed, and deviations are corrected.
All five situations answer “yes”. Only the last survives a certification audit, and the difference in effort between the first and the last is enormous.
That is where the systematic optimism of self-assessments comes from: they are not measuring badly, they are measuring something else.
Measure maturity, not presence
Our methodology assesses each of the 93 controls independently on a six-level maturity scale, drawing on personal interviews, review of documented information and verification during the gap assessment audit.
The logic of the scale, broadly, runs from the non-existent control to the managed and optimised one, passing through intermediate stages: the control that is executed informally and depends on individuals, the one that is defined and documented, and the one that is also measured and reviewed.
The change this produces is concrete. A control at an early stage and one a single step from the target stop looking the same, and with that something appears that the binary spreadsheet cannot give you: the real distance and the effort required to close it.
What you see when you look by domain
Aggregating the results by theme reveals a profile that tends to be fairly consistent across organisations.
Technological controls score better than expected. Backups, antivirus, segmentation and patch management are already there. Often the problem is not that the control does not exist, but that it is neither documented nor reviewed systematically. This is the cheapest gap to close.
Physical controls score high in organisations with their own premises and low in those operating from shared offices or with distributed working arrangements, where the perimeter is blurred.
People controls are consistently the weakest. Background checks, current confidentiality agreements, offboarding processes that actually revoke access, awareness with evidence behind it. It is the domain that depends most on a function —HR— that rarely took part in the security conversation.
Organisational controls are the ones that carry the most weight and are most often missing: they are the management system itself. Policy, roles, risk management, information classification, supplier relationships, incident management.
From which comes a conclusion that surprises many technical teams: the heavy lifting in an implementation is not technological. Technology is usually further along than management.
The three controls that uncover the most work
Three controls, in our experience, open up the largest amount of downstream work.
Asset inventory and information classification. It looks administrative and it is structural: without knowing what information you hold, where it is and how critical it is, you cannot assess risk, define access control or size continuity. When this control sits at a low level, it drags another twenty down with it.
Supplier relationships. Almost no organisation has identified its critical information suppliers, nor security clauses in the contracts, nor a follow-up mechanism. And it is a control that depends on third parties, so the organisation does not control its closing timeline: contracts have to be renegotiated and answers waited for.
Incident management. It usually exists reactively —whatever comes up gets resolved— but without classification, escalation criteria, root cause analysis or lessons learned. And without an incident record there is no input for improving the system.
What the number is good for, then
A global maturity percentage has exactly one legitimate use: comparing against itself over time. It works for showing progress to the Board and for defending the second year’s budget.
It is no use for comparing organisations, because scope and context change what it means. And it is no use as an objective in itself: chasing the number leads to improving the easy controls and postponing the ones that matter.
What does work —and is the real deliverable of the assessment— is the roadmap: which controls to close first, in what order, with what effort, with what dependencies between them, and who owns each one. A sequence, not a score.
How to improve your own self-assessment
If you are going to run the exercise internally before bringing anyone in, three adjustments make it far more useful:
- Replace yes/no with five or six levels. Even if you define them yourself, the mere obligation to choose between “exists informally” and “is defined and reviewed” organises the discussion.
- Demand evidence for any high rating. If nobody can produce the record in under five minutes, the control is not where you think it is.
- Do not let one person fill it in. The IT function overestimates organisational controls and underestimates people controls. Bring in HR, Legal and Operations.
With that alone, the result will drop. And it will start being useful.
Our security gap assessment evaluates the 93 controls on a six-level scale and delivers a roadmap prioritised by criticality and effort.