ISO 27001 is the information security management standard companies pursue the moment a customer or regulator asks for proof that they manage security and availability systematically. Where SOC 2 is the audit framework common in North American SaaS, ISO 27001 is the certification common in Europe, fintech, and any deal that crosses borders. Both ask the same underlying question: do you monitor what you committed to monitor, and can you prove it?
The part that catches teams out is that ISO 27001 treats monitoring as a formal evaluation process, not a dashboard you glance at. Clause 9.1 (monitoring, measurement, analysis, evaluation) requires you to define uptime targets, measure them against those targets, and retain the records for the entire certification period. Annex A 8.16 (monitoring activities) requires you to monitor systems for anomalous behaviour and take action. Auditors do not want a blank dashboard — they want historical data. If your policy says you track uptime, they will ask for the availability reports covering the whole period. This guide covers what ISO 27001 monitoring requires for availability and uptime, which records auditors expect, and how to keep them without building a compliance pipeline from scratch.
This is not legal or certification advice — your auditor and consultant own that. It is a practical map of the monitoring evidence that supports the availability and monitoring clauses, so you walk into the audit with records already in place.
What ISO 27001 Actually Requires for Monitoring
ISO 27001:2022 treats monitoring across two layers: the management system (Clause 9.1) and the technical controls (Annex A). Both have to operate during the certification period, and both require evidence.
Clause 9.1 — Monitoring, measurement, analysis, evaluation
You must determine what to monitor, how often, and what "bad" looks like, then evaluate the results against targets. The distinction auditors draw is between monitoring (collecting data) and measuring (comparing it to a target). You can monitor a server for 24 hours, but if you do not measure its uptime against a target, you have not satisfied Clause 9.1.
What auditors expect: a Measurement Matrix, defined thresholds (for example, uptime below 99.9% triggers action), a monitoring schedule with frequency appropriate to risk, and Evaluation Reports where someone has actually signed off on the analysis. A dashboard full of green lights with no evaluation report is a likely non-conformity.
Annex A 8.16 — Monitoring activities
Networks, systems, and applications shall be monitored for anomalous behaviour and appropriate actions taken. The 2022 revision expanded the scope to include user behaviour, network activity, and information processing, with documented response procedures for anomalies. A tool with a generic ruleset and no documented analyst workflow does not satisfy this control.
What auditors expect: what is monitored, why, what constitutes an anomaly, and what happens when one is detected — ideally with traceable examples from the audit period.
Annex A 8.6 — Capacity management
System resources must be monitored and tuned to meet current and future demand. Effective capacity management prevents the performance-related outages caused by CPU, memory, or storage exhaustion.
What auditors expect: resource utilisation trends and a capacity plan that shows you can absorb growth.
Annex A 8.14 — Redundancy
Information processing facilities must be implemented with sufficient redundancy to meet availability requirements — load balancing, failover, and redundant infrastructure to eliminate single points of failure.
What auditors expect: redundancy configurations (multi-region or multi-AZ) and evidence the redundancy is real, not theoretical.
Annex A 5.30 — ICT readiness for business continuity
You must plan for disruption and prove the business can continue. This connects availability to disaster recovery and business continuity.
What auditors expect: a disaster recovery plan and evidence of recovery testing.
The thread through all of these is evidence of operation. A control on paper that produced no records during the certification period is not a control that operated.
The Monitoring Evidence Auditors Expect
1. Continuous uptime records covering the full period
The baseline evidence is a continuous record of whether your system was reachable, retained for the entire certification period. Auditors ask for the availability reports for the whole period, not selected days. Gaps in the record are themselves a finding.
What this looks like: multi-region uptime checks logged continuously, with a retention window that covers the certification period, and a report you can hand the auditor showing uptime percentage per service.
2. Defined thresholds and an evaluation report
Clause 9.1 requires you to define what "bad" looks like. If your uptime drops below 99.9%, what happens? The threshold must be agreed with asset owners, and the auditor will verify it against your SLA. On top of the data, they want an Evaluation Report where someone signed off on the analysis.
3. Alerting with someone accountable
Monitoring that fires alerts into a void does not count. Auditors look for alerting that someone is accountable for reviewing, and an on-call or escalation path that shows incidents were acknowledged and acted on. The evidence is the alert log plus acknowledgement and response timestamps.
4. Incident records with timelines
For every incident during the period, the auditor expects a record: when it was detected, who was notified, what was done, when it resolved, and the root cause. Teams that resolve incidents in chat without preserving a formal record are the most common source of findings. The fix is an incident management workflow that captures the timeline automatically.
5. A public or private status page
A status page is clear evidence that availability commitments were operationalised and communicated. It shows you logged incidents with updates and maintained a historical record, which auditors treat as strong evidence.
6. Post-incident reviews and recovery testing
Annex A 5.30 is about recovery, and the proof that recovery procedures work is a post-incident review for each significant outage plus documented DR test results. A pile of incidents with no reviews is a gap.
7. SSL, DNS, and domain health
Outages often come from upstream causes — an expired SSL certificate, DNS drift, or a lapsed domain. Monitoring these alongside uptime shows you are preventing incidents, which strengthens the A 8.16 and A 8.14 story.
Mapping ISO 27001 Clauses to Monitoring Evidence
| ISO 27001 clause | What the auditor wants | Monitoring evidence |
|---|---|---|
| 9.1 Monitoring | Metrics measured against targets | Uptime % vs. SLA, evaluation reports |
| A 8.16 Monitoring activities | Anomalies detected and acted on | Alert logs, incident records, response actions |
| A 8.6 Capacity | Resources monitored and forecast | Utilisation trends, capacity plan |
| A 8.14 Redundancy | Redundancy implemented and real | Multi-region checks, failover evidence |
| A 5.30 ICT readiness | Recovery planned and tested | DR plan, recovery test results, post-incident reviews |
| Availability SLA | Uptime commitment measured | Continuous uptime record for the full period |
The pattern is consistent: every clause maps to a record the monitoring tool produces automatically. The audit becomes a retrieval exercise instead of a reconstruction scramble.
How Webalert Supports ISO 27001 Monitoring
Webalert produces the records an ISO 27001 availability audit asks for, continuously and without manual logging.
- Continuous uptime records — multi-region checks logged across the certification period, so you can produce an uptime-percentage report per service on demand instead of reconstructing it from memory.
- Smart alerting with accountability — downtime confirmed from multiple regions before paging, and on-call scheduling with escalation, so every alert has an owner and an acknowledgement timestamp on the record, supporting A 8.16.
- Incident management with timelines — incidents captured with detection, notification, response, and resolution timestamps, plus post-incident review, which is exactly the evidence auditors request for A 5.30 and A 8.16.
- Status pages — a public or private status page with incident history, clear evidence that availability commitments were operationalised and communicated.
- SSL, DNS, and domain monitoring — the upstream causes of outages monitored alongside uptime, strengthening the A 8.14 and A 8.16 evidence.
- Response time monitoring — performance trends that support the A 8.6 capacity story, showing the system stayed within acceptable bounds as demand changed.
- Heartbeat monitoring — for background jobs and scheduled tasks, covering the availability of components that active checks cannot reach.
The honest framing: ISO 27001 is broader than monitoring — it also covers access control, risk assessment, supplier management, cryptography, and physical security, which Webalert does not address. For the availability and monitoring clauses specifically, the records the auditor retrieves are exactly what a monitoring tool produces continuously, and having them in place is the difference between a clean audit and a reconstruction exercise.
How to Prepare for an ISO 27001 Availability Audit
1. Define your uptime target and the services in scope
Write down the uptime target (for example, 99.9%) and which services it applies to. The auditor measures evidence against this specific commitment, so it has to be explicit and agreed with asset owners.
2. Stand up continuous monitoring across those services
Configure multi-region uptime checks for every in-scope service, with alerting routed to an on-call rotation. Make sure the retention window covers the certification period before the audit begins — evidence collected after the fact does not help.
3. Define thresholds and the evaluation cadence
Agree what "bad" looks like (uptime below 99.9%, response time above a threshold) and how often you will evaluate (daily automated, monthly manual review). Document the threshold and the cadence in your Measurement Matrix.
4. Operationalise incident records
Make sure every incident produces a record: detection time, notification, response, resolution, and a post-incident review. If your team resolves issues in chat, configure an incident workflow that captures the timeline automatically so you are not reconstructing it later.
5. Publish a status page
A status page with incident history is strong availability evidence and doubles as stakeholder communication. Configure it before the certification period so the historical record exists when the auditor asks.
6. Test recovery procedures
Schedule at least one DR test or tabletop exercise during the period and document the results. This is the A 5.30 evidence — without a test on record, the control did not operate.
7. Produce the evaluation report
At the planned intervals, produce an Evaluation Report showing uptime against target, incidents and their resolution, and any capacity or redundancy actions taken. Someone signs off. This is the Clause 9.1 evidence that turns raw data into a satisfied control.
Frequently Asked Questions
Does ISO 27001 require uptime monitoring?
ISO 27001 requires monitoring under Clause 9.1 and Annex A 8.16, and availability commitments under A 8.14 and A 5.30. If your SLA or customer commitments include an uptime target, you must measure it and retain the records for the certification period.
What monitoring evidence does ISO 27001 require?
Auditors expect continuous uptime records, defined thresholds, an evaluation report, alert logs with accountable owners, incident records with timelines, status page history, and recovery test results. The evidence has to cover the full certification period, not selected days.
Is a status page required for ISO 27001?
Not explicitly, but a status page is strong evidence that availability commitments were operationalised and communicated. It shows you logged incidents with updates and maintained a historical record, which auditors treat favourably.
What is the difference between monitoring and measuring under Clause 9.1?
Monitoring is collecting data; measuring is comparing it to a target. You can monitor a server for 24 hours, but if you do not measure its uptime against a target, you have not satisfied Clause 9.1. Auditors look for both the data and the evaluation against thresholds.
Can monitoring tools help with ISO 27001?
For the availability and monitoring clauses, yes — the uptime, alerting, incident, and status page records are exactly what the auditor retrieves. ISO 27001 is broader than monitoring (it also covers access control, risk, and physical security), so monitoring supports the availability portion rather than the whole certification.
Walk Into the Audit With Evidence Already Collected
The availability and monitoring clauses are not a document you write the week before the audit. They are controls that have to operate during the certification period, and the proof is the records your monitoring produced continuously.
Start monitoring with audit-ready records — free. Continuous multi-region uptime logs, incident timelines, on-call escalation, and a status page with history — so when the auditor asks for availability evidence, you retrieve it instead of reconstructing it.