9.1 — Monitoring, measurement, analysis and evaluation
The requirement that turns "we have controls" into "we know whether our controls are working," with numbers to back it up.
In plain language
In plain language: sub-clause 9.1 requires you to decide, in advance, exactly what security-relevant things you will measure, how you will measure them, when, and who is responsible — then actually evaluate the results, rather than collecting data nobody looks at.
Position in the standard
Why this requirement exists
Controls degrade silently. A backup job that worked at implementation can start failing months later with nobody noticing until a restore is needed. This requirement exists so that failure gets caught by a metric, not by an incident.
Scenario: a company rolled out MFA at 100% coverage a year ago and considers the control "done." No one has re-checked coverage since. In the meantime, a dozen new accounts were created without MFA enforced by default. Without a monitoring metric tracking MFA coverage monthly, that gap goes unnoticed until an auditor — or an attacker — finds it.
What the standard expects
The standard expects you to determine what needs monitoring and measuring — including information security processes and controls; the methods for monitoring, measurement, analysis, and evaluation needed to ensure valid results; when monitoring and measuring shall be performed; who shall do it; when the results shall be analyzed and evaluated; and who shall analyze and evaluate them. You must keep documented evidence of the results, and — beyond just collecting numbers — actually evaluate the information security performance and the effectiveness of the ISMS as a whole.
In practice
- Build a short list of metrics tied to your riskiest controls — MFA coverage, patch compliance rate, backup success rate, phishing test click rate, access review completion — rather than measuring everything.
- For each metric, define a target, a measurement frequency, and a named owner who reviews it.
- Set a threshold that triggers action — a metric that just gets logged without a reaction defeats the purpose.
- Feed monitoring results into management review (9.3) so leadership sees trends, not just a single snapshot.
Evidence the auditor will ask for
- A documented list of metrics with methods, frequency, and owners.
- Actual measurement records or dashboards over time, not a one-off snapshot taken just before the audit.
- Evidence the results were analyzed and evaluated — meeting notes, reports, or a documented review, not just raw numbers.
Common pitfalls
- Measuring dozens of metrics nobody reviews, instead of a handful that are actually acted on.
- Producing a single metrics snapshot right before the audit instead of showing a real, ongoing measurement history.
- Collecting data with no defined evaluation step — numbers with no analysis attached.
Related requirements
9.2 Internal audit
Checks whether the monitoring described here is actually happening as designed.
9.3 Management review
Monitoring results feed directly into what leadership reviews.
Parent link: Clause 9 · Performance evaluation
Frequently asked questions
How many metrics do we need?
Can monitoring be automated?
Turn control monitoring into a metric, not an incident report.
Sentrix tracks your key security metrics continuously and surfaces drift before it becomes a finding.