ISO 27001 Clause 9.1: Monitoring, Measurement, Analysis and Evaluation

Clause 9.1 is where ISO 27001 asks a simple, uncomfortable question: how do you know your ISMS is working? Having controls in place is not the same as knowing they are effective. Clause 9.1 requires you to monitor and measure your information security performance, analyse the results, and evaluate whether the ISMS is achieving what it is supposed to. This is the “Check” in the PDCA cycle - the point where your management system either produces evidence of effectiveness or exposes the gap between intention and reality.

What the clause requires

ISO 27001:2022 Clause 9.1 requires the organization to determine:

What needs to be monitored and measured - including information security processes and controls
The methods for monitoring, measurement, analysis and evaluation, as applicable, to ensure valid results - the standard adds, in a note, that the methods selected should produce comparable and reproducible results to be considered valid
When the monitoring and measuring is performed
Who monitors and measures
When the results are analysed and evaluated
Who analyses and evaluates the results

The organization must retain documented information as evidence of the results, and must evaluate the information security performance and the effectiveness of the ISMS.

The clause deliberately separates two activities. Monitoring and measurement is collecting the data. Analysis and evaluation is making sense of it. A patch report is monitoring. Concluding that your patch process is failing because 40% of criticals miss their SLA is evaluation. Auditors want to see both.

How to implement monitoring and measurement

Start from your objectives and risks, not from a metrics catalogue

The most common failure is measuring what is easy rather than what matters. Your monitoring programme should trace back to your information security objectives from Clause 6.2 and the risks in your risk assessment. If an objective is “reduce phishing susceptibility,” then phishing simulation click rates are a valid measure. If a top risk is unauthorized access, then failed-login anomalies and access-review completion are worth tracking.

Ask for each candidate metric: if this number moves, does it tell us something we would act on? If not, it is noise.

Define each measure so results are reproducible

The standard requires methods that produce comparable and reproducible results. In practice, document each measure with enough precision that two different people would calculate it the same way:

What is measured - e.g. “percentage of critical vulnerabilities remediated within the SLA window”
Data source - the vulnerability scanner, the ticketing system, the access-review log
Formula - numerator, denominator, and any exclusions
Frequency - monthly, quarterly, continuous
Owner - who produces the number
Target or threshold - what “good” looks like, and the level that triggers action

A short measurement plan or metrics register holds these definitions. It is one of the first things an auditor asks for under 9.1.

Choose a small set of meaningful metrics

For a 20-to-50-person organization, eight to fifteen well-chosen measures are far more defensible than fifty vanity metrics nobody reviews. A practical starter set:

Critical and high vulnerability remediation within SLA
Patch coverage across in-scope assets
Percentage of staff completing security awareness training
Phishing simulation click and report rates
Access reviews completed on schedule
Security incidents by severity and mean time to respond
Backup success rate and last successful restore test
Open corrective actions past their due date (feeding Clause 10.2)

Separate leading from lagging indicators

Lagging indicators (number of incidents, breaches) tell you what already happened. Leading indicators (training completion, patch timeliness, overdue access reviews) tell you where you are heading. A mature 9.1 programme uses both, so management is not only reading a post-mortem but steering.

Turn data into evaluation

Monitoring produces numbers. Clause 9.1 wants a conclusion. Each reporting cycle, record not just the value but the interpretation: is the control effective, is the trend improving or degrading, and does anything need action? That written evaluation is what feeds the management review under Clause 9.3 and, where a control is failing, a corrective action under Clause 10.2.

Connecting 9.1 to the rest of your ISMS

Clause 6.2 connection. Information security objectives are measurable by requirement. Clause 9.1 is how you demonstrate progress against them. Objectives without measurement are aspirations; measurement without objectives is data without direction.

Clause 8.3 connection. Risk treatment implements controls to reduce risk. Clause 9.1 checks whether those controls are actually reducing it. If monitoring shows a control is not performing, the treatment plan needs revisiting.

Clause 9.2 connection. Internal audit tests conformity and effectiveness through examination and sampling. Clause 9.1 provides continuous, quantitative evidence between audits. The two are complementary checks, not substitutes.

Clause 9.3 connection. Management review consumes 9.1 output directly - monitoring and measurement results are a required input to the review.

Clause 10 connection. When evaluation shows a control or objective is off track, it triggers continual improvement and, where there is a genuine gap, corrective action.

What auditors check

A defined measurement programme. Auditors expect a documented set of measures with methods, frequencies, and owners - not a metric invented the week before the audit. They check that the method would produce reproducible results.

Evidence of results over time. They ask for the actual monitoring records: dashboards, reports, logs. A single snapshot is weak; a run of monthly or quarterly results shows the process is live.

Evaluation, not just data. Auditors look for the analytical step. Did someone conclude anything from the numbers? Reports that present data with no interpretation, and no action when thresholds are breached, get flagged.

Traceability to objectives and risks. They test whether what you measure connects to your objectives and top risks. Metrics disconnected from either raise the question of why you measure them at all.

Flow into management review and improvement. Auditors trace 9.1 output into the 9.3 management review inputs and into corrective actions, confirming the results are used rather than filed.

Common mistakes to avoid

Measuring activity instead of effectiveness. “We ran 12 scans” is activity. “We remediate 92% of criticals within SLA, up from 78%” is effectiveness. Clause 9.1 is about the second kind.

A wall of metrics nobody reads. Fifty automated charts feel thorough but usually mean no one is evaluating anything. A focused set that management actually reviews beats a dashboard that scrolls forever.

No defined method. Reporting a number without documenting how it is calculated fails the “reproducible results” requirement. Next quarter someone computes it differently and the trend is meaningless.

Collecting data but never evaluating. The most common finding. Organizations monitor diligently and stop there. Without the analysis-and-evaluation step, and without acting on breached thresholds, 9.1 is only half done.

Metrics with no target. A value with no threshold cannot be judged good or bad. Every measure needs a target or an action trigger, or it cannot drive a decision.

How 27kay can help

We help organizations build a monitoring programme that proves the ISMS works rather than just producing charts. As part of ISO 27001 implementation, we define a right-sized set of measures tied to your objectives and risks, document the methods so results hold up under audit, and wire the output into your management review and improvement cycle. For the full picture, see our ISO 27001 knowledge hub.

Not sure your security metrics would survive an auditor’s questions? Get in touch - we will review what you measure and help you close the gap between data and evidence of effectiveness.