You can run security for a year and still not know whether it is working. The policies are written, the tools are bought, people have been trained. Then a customer asks how you know your access controls are effective, and the honest answer is that nobody has checked.
Clause 9 of ISO 27001 is where you check. It looks at your ISMS, the information security management system the standard asks you to run, and covers three things: tracking a small set of metrics that show whether your controls work, auditing yourself at planned intervals, and sitting management down to decide what changes. It is the clause that turns a pile of documents into something you can stand behind, and it is also the one most teams put off until the certification auditor asks for it.
What clause 9 covers
Three parts, and they run in sequence.
- 9.1 Monitoring, measurement, analysis and evaluation. You choose a small set of security metrics, such as the share of leavers whose access was removed on time, collect the numbers, and interpret what they say about how well your controls and the ISMS as a whole are working.
- 9.2 Internal audit. At planned intervals, in practice usually once a year, someone checks your system against the standard and against your own rules.
- 9.3 Management review. Top management looks at everything above and decides what to change.
The output of each one becomes the input to the next. Your metrics and your internal audit findings are what management reviews, and the decisions from that review set the direction for the following year.
Monitoring and measurement
Two words that sound the same and mean different things. Monitoring tells you whether something is happening. Measurement tells you how well.
Take access reviews. Monitoring is checking that the quarterly review took place. Measurement is finding that of 40 accounts reviewed, 6 belonged to people who had left the company. The first tells you the process ran. The second tells you something is wrong upstream in your offboarding.
For each metric, the standard asks you to decide and write down:
- what you are monitoring or measuring, including which processes and controls
- how you will do it, in a way that gives you a result you can trust
- when it gets done
- who does it
- when the results get analysed
- who analyses them
That last pair matters more than it looks. The standard asks you to name who collects each number and, separately, who reads and interprets it. The same person can hold both roles, but both have to be assigned, because the usual failure is numbers collected by someone whose job ends at collecting them.
There is one more condition on the method: it has to produce results that are comparable over time and that someone else could reproduce. If you measure phishing click rates with a different tool, a different sample and a different scenario each quarter, the numbers move for reasons that have nothing to do with your security, and you cannot tell improvement from noise.
Which metrics are worth having
The common mistake is measuring activity instead of outcome. "We ran 12 awareness sessions" and "we closed 94 tickets" are both true and neither tells you whether you are safer. A useful metric is one where a bad result would make you do something differently.
A few that tend to earn their place:
- The share of leavers whose access was removed inside your own deadline. If your rule says two working days and the real figure is nine days, you have found a live gap.
- Time to patch critical vulnerabilities, measured against the target in your own policy.
- Open risk treatment actions past their due date.
- Whether your last backup restore test restored.
Four metrics you would act on beat twenty you would not. Clause 9 sets no minimum number, and an auditor would rather see a small set with real analysis behind it than a dashboard nobody has opened since it was built.
Internal audit
Clause 9.2 asks you to audit your own system at planned intervals, and to check two things: that it matches what the standard requires, and that it matches your own rules. Those are different questions, and the second one catches more.
Each audit needs a defined scope and criteria, meaning what you are checking and what you are checking it against. The person doing it has to be objective and impartial, which in practice means nobody audits their own work. You also need an audit programme covering how often, how, who is responsible and how results get reported. The results have to be written up and kept, and the findings have to reach the managers who can act on them.
This is the part of clause 9 with the most moving pieces, so how an internal audit actually works covers it in full. If you have nobody in-house who can audit a process they did not build, bringing in an internal auditor is the usual answer.
Management review
Clause 9.3 puts top management back in the room. This means the people who control budget and priorities, reviewing the system and making calls about it, rather than the security lead reporting upwards.
How often is up to you. Most companies do it once a year and add a session after anything significant, like an acquisition, a major incident or a new product line.
What has to go into the review:
- what happened to the actions agreed last time
- what has changed inside and outside the company that affects security
- what your customers, regulators and other interested parties now expect
- how security performed: your metrics, your audit results, nonconformities (places where you missed a requirement or broke your own rule) and the corrective actions that followed, and whether you hit the objectives you set
- feedback you have had from interested parties
- where your risk assessment and risk treatment plan stand
- anything you have spotted that could be improved
What has to come out of it is shorter: decisions about improvements, and decisions about changes to the system. Written down.
That last point is where most management reviews fail. The inputs get presented, everyone nods, and the minutes record that the report was noted. An auditor reading those minutes sees a meeting that happened and a review that did not. If pulling these inputs together and chairing the conversation is nobody's job today, that is the gap an outside security lead is usually brought in to close.
What an auditor checks
Clause 9 findings follow a pattern:
- A list of metrics in the ISMS documentation, with no actual results behind any of them.
- Results recorded, with no sign anyone analysed them or acted on them.
- An internal audit run by the person who owns the process being audited.
- A management review held, with minutes that contain no decisions.
- Objectives set at the start of the year and never measured against.
- A metric that changed method halfway through, so the trend means nothing.
All of these are fixable before a certification body ever sees them, which is the main reason getting the evidence in order early shortens the audit itself.
Where to start
- Pick three or four metrics, choosing ones where a bad number would change what you do next week.
- For each, write one line: what it measures, how, how often, who measures it, who reads it.
- Record the next round of results, including the bad ones. A metric that never shows a bad month is usually measuring the wrong thing.
- Book the internal audit, and pick someone who did not build the process they will be auditing.
- Put the management review in the calendar with a real agenda, and write the minutes as a list of decisions with owners and dates.
What's next?
The management review only works if top management is already involved in the system, and what the standard requires from management covers the duties clause 5 puts on them before clause 9 asks them to sit down and decide. Once your metrics and your audit have turned up problems, nonconformity and corrective action covers what clause 10.2 expects you to do with them, which is where clause 9 turns into actual change.
- Global
- Governance & Compliance
- ISO 27001