A.5.24
Information security incident management planning and preparation
ISO 27001 · ISO/IEC 27001:2022 · Last verified July 2026
Objective
Plan and prepare for information security incidents so the organization can respond effectively when one occurs.
Points of focus
- Incident response plan defines severity levels, roles, and escalation paths
- Plan names actual people or teams that match the current on-call rotation
- Communication plan covers internal, customer, and regulatory notification paths
- Plan is tested via tabletop or live exercise on a defined cadence with recorded findings
Implementation notes
Write the plan around who is actually on-call today, not an idealized org chart, and cross-check named roles against the current PagerDuty or Opsgenie rotation every time either changes. Define severity levels with concrete triggers, such as a customer-facing outage, confirmed data exposure, or suspected compromise, so the right people get paged without debate mid-incident. Build the regulatory notification clock into the plan explicitly, naming who decides whether an event meets the GDPR 72-hour threshold or a state breach-notification law, and pre-draft customer communication templates so the first message isn't written from scratch during an active incident. Run at least one tabletop a year using a realistic scenario for your stack, such as a leaked API key or a compromised admin account, and keep the dated notes — that record is what separates this from a document nobody has read.
Audit tip: Ask for the date and notes from the most recent tabletop exercise. A plan that exists but has never been rehearsed, or was rehearsed with people no longer in those roles, is the most common finding here.
Evidence auditors typically request:
- Current incident response plan with version history and named roles, such as incident commander and comms lead
- On-call schedule (PagerDuty, Opsgenie) cross-referenced against the roles in the plan
- Tabletop exercise notes with date, scenario, participants, and follow-up actions
- Customer-facing communication template, such as a status page post or notification email, referenced by the plan
Common gaps
- The plan names roles by title, but those titles map to people who have since left or changed teams
- No tabletop or simulation has been run in the last 12 months, so the plan is untested
- The plan doesn't address regulatory notification timelines, such as GDPR's 72-hour clock, even though the business processes EU personal data
- Severity definitions in the plan don't match what the on-call escalation policy actually triggers on
Cross-Framework Mapping
| Framework | Requirement | Implementation note |
|---|---|---|
| ISO 27001 | A.5.24 | This control |
| SOC 2 | CC7.3 | CC7.3 expects a documented response process defined before an event — reuse the same plan rather than writing a second one for the audit. |
| GDPR | Article 33 | Article 33's 72-hour notification clock should be an explicit step in the plan with a named decision-maker, not an assumption that legal will handle it when the time comes. |
| HIPAA | 164.308(a)(6) | 164.308(a)(6) requires response and reporting procedures for incidents involving PHI; if you handle PHI, the plan needs a PHI-specific notification path, not just a generic one. |
Primary sources
- ISO/IEC 27001:2022 Annex A: ISO/IEC 27001:2022 Annex A (A.5.24)