ISO 27001 Incident Communication: The Annex A Controls That Touch Your Status Page
Jul 26, 2026 | by openstatus | [compliance]
ISO 27001 is a management system standard. That distinction shapes everything about how it treats incident communication, and it is why advice written for SOC 2 transfers only partially.
A SOC 2 auditor asks: did this control operate effectively across the period? An ISO auditor asks: do you have a documented procedure, is it owned, is it followed, and can you show it improving? A status page is a small implementation detail inside that. Worth being precise about where it fits.
The scope boundary, stated first
ISO/IEC 27001:2022 has 93 Annex A controls plus clauses 4 through 10, which are the actual management system — context, leadership, planning, support, operation, performance evaluation, improvement. The clauses are mandatory. Annex A is a reference set you select from via risk assessment.
What a status page has nothing to do with
The ISMS scope statement, risk assessment methodology, Statement of Applicability, internal audit programme, management review, corrective actions, competence and awareness, and the great majority of Annex A — access control, cryptography, physical security, supplier relationships, secure development. A status page does not touch any of it.
The controls it does touch
A.5.24 — Incident management planning and preparation
Requires you to plan and prepare for incident management: define roles, responsibilities, and procedures before anything happens. Your status page is part of the preparation — having the channel already provisioned, branded, and subscribed-to is the difference between communicating in fifteen minutes and standing up a channel mid-incident. The control is about the plan, not the tool.
A.5.25 — Assessment and decision on information security events
You must assess events and decide whether they are incidents. This is triage, and it is entirely yours. A monitoring alert is an event; deciding it is an incident worth publishing is a judgement your procedure must define. Auditors like to see a documented severity threshold that determines what gets communicated externally.
A.5.26 — Response to information security incidents
The central one. Incidents must be responded to in accordance with documented procedures, which typically include notifying relevant interested parties. If your procedure says "we publish to the status page for severity 1 and 2," the auditor will check that you did, for the incidents you had.
A.5.27 — Learning from information security incidents
Knowledge from incidents must be used to reduce future likelihood or impact. Public postmortems are a natural artifact here, though internal ones satisfy the control equally. What matters is that learning is captured and acted on, not that it is published.
A.5.28 — Collection of evidence
Requires procedures for identifying, collecting, and preserving evidence. Timestamped, immutable-by-default incident records are directly relevant — as is being able to show who changed what. This is where an audit log earns its place.
A.5.29 and A.5.30 — Disruption and ICT readiness
A.5.29 covers maintaining information security during disruption. A.5.30 requires ICT readiness for business continuity — planned, implemented, maintained, and tested against defined recovery objectives (RTO/RPO). Your uptime record and incident timelines are supporting evidence that you measure real recovery against those objectives, rather than only asserting them on paper.
A.8.15 and A.8.16 — Logging and monitoring
A.8.15 covers logging; A.8.16 requires networks, systems, and applications to be monitored for anomalous behaviour with appropriate action taken. External synthetic monitoring is one legitimate input. It is not sufficient on its own — A.8.16 expects security-relevant monitoring, not just availability checks.
What an ISO auditor asks for
Certification audits are lighter on sampling than SOC 2 Type II fieldwork and heavier on procedure. Expect:
- Show me your incident management procedure. A document, versioned, owned, approved.
- Show me it being followed. Two or three real incidents traced end to end against the procedure.
- Show me the decision. For an incident you did not communicate externally, why not? Which criterion in your own procedure justified that? This is A.5.25 being tested, and it catches teams who only prepared the "we told everyone" story.
- Show me the learning. What changed as a result.
- Show me evidence handling. How records are captured and preserved, per A.5.28.
The most common gap
Teams document a procedure that says communication happens "promptly" or "as appropriate." Both are unauditable. Give the threshold a number — a severity level, a time target — so there is something to test against.
Retention and the certification cycle
ISO certification runs on a three-year cycle with annual surveillance audits. The standard sets no retention period for incident records; your documented retention policy does, and the auditor checks conformance with your own policy. In practice, evidence covering at least the last twelve months is the working floor for a surveillance audit.
Openstatus retention runs 14 days on Hobby, 3 months on Starter, 12 months on Pro, and 24 months on Scale. If your policy says you keep operational records for a year, the plan needs to back that up — a policy you cannot honour is itself a nonconformity.
What openstatus contributes
- A.5.24 — a channel provisioned in advance, with subscribers already attached, so communication is a preparation item rather than an incident-time scramble.
- A.5.26 — timestamped status reports through the full lifecycle: investigating, identified, monitoring, resolved.
- A.5.28 — durable records, plus a full audit log of every workspace mutation, recorded in-transaction with the actor attached. Pro and Scale.
- A.5.30 — a real availability record to test recovery objectives against, from 28 regions.
- A.8.16 — synthetic monitoring as one monitoring input, with alerting into Slack, Discord, PagerDuty, or email.
What it does not contribute
Everything else. The ISMS itself — scope, risk assessment, Statement of Applicability, internal audits, management review — is the substance of certification, and no monitoring tool produces it. Compliance automation platforms such as Vanta and Drata manage that layer; openstatus produces evidence you reference from inside it.
If you are choosing where to spend effort before a certification audit, the procedure document and the Statement of Applicability matter more than the tooling. Get those right, then make sure the tool can retain what your policy promises.
Primary sources
ISO standards are not free, which is worth knowing before you go looking. The catalogue pages describe scope and contents without paywalling that summary.
- ISO/IEC 27001:2022 — the certifiable standard. Clauses 4–10 are the requirements; Annex A is the reference control set.
- ISO/IEC 27002:2022 — implementation guidance for the Annex A controls. This is the document that actually explains what A.5.26 or A.5.30 expect of you; 27001 only names them.
- ISO/IEC 27035-1:2023 — information security incident management, part 1: principles and process. Defines the five-phase model (plan and prepare, detect and report, assess and decide, respond, learn lessons) that the A.5.24–A.5.28 controls compress into five lines.
If you are writing the incident procedure that A.5.26 tests, 27035-1 is the more useful purchase of the three.
Related reading
- SOC 2 and your status page — the other framework most teams carry alongside
- What is incident management — the process behind A.5.24 to A.5.27
- Incident severity matrix — gives A.5.25 a testable threshold
- What is MTTR — recovery measurement for A.5.30
- What is synthetic monitoring — one input to A.8.16
Start your status page