ISO 27001 A.5.24: Information Security Incident Management Planning and Preparation

ISO 27001 A.5.24 requires an organization to plan and prepare for security incidents before they happen: define the roles, the response process, the severity model, and the reporting channels while the environment is calm rather than during a live event. The action teams most often get flagged on is exercising the plan. A documented incident response plan that has never been run in a tabletop is the single most common A.5.24 gap.

What is ISO 27001 A.5.24?

ISO 27001 A.5.24, titled Information security incident management planning and preparation, is the control that asks an organization to establish how it will manage security incidents before one occurs. Paraphrasing the intent attributed to ISO/IEC 27001:2022, Annex A: the organization defines the incident management process, assigns the roles and responsibilities that run it, and puts the procedures, channels, and capabilities in place so that a real incident is handled through a prepared process rather than improvised. A.5.24 is an organizational governance control rather than a technical one. It covers the plan and the readiness; no single detection tool satisfies it.

ISO 27001 A.5.24 is the planning and preparation control that comes before the three operational incident controls in the same theme. A.5.25 covers assessment and decision on security events (deciding what is an incident), A.5.26 covers response to confirmed incidents (running the response), and A.5.27 covers learning from incidents (feeding lessons back into the program). A.5.24 is where the plan those three controls execute against gets built. Get A.5.24 right and the other three have something to operate. Skip it and the operational controls have no documented process to point an auditor to.

How do you implement A.5.24?

Implementing ISO 27001 A.5.24 is a sequence of preparation actions a team carries out while there is no active incident. Each one produces an artifact an auditor can later sample.

1. Define incident management roles and responsibilities. Name the incident commander who owns containment and communication decisions, the technical lead who executes the response steps, the communications lead who handles internal, customer, and regulator messaging, and an evidence custodian who maintains the record. Each role needs a named owner and a documented backup. Separating the evidence custodian from the technical lead is a meaningful segregation-of-duties control even on a small team.
2. Establish an incident response plan and runbooks. Document the end-to-end process (detection, triage, containment, eradication, recovery, and post-incident review) as a plan, then build per-scenario runbooks for the events the team is most likely to face: credential compromise, ransomware, web application exploitation, data exfiltration, and insider misuse. The plan is the shape of the process; the runbooks are the step-by-step actions.
3. Define severity classification and escalation. Set a severity model (for example, critical, high, medium, low) with concrete criteria for each level and an escalation path that states who is notified and how fast at each severity, with paging and on-call rotation handled through tooling such as PagerDuty or Opsgenie. Severity drives the response time commitment, so the classification has to be unambiguous enough that an on-call engineer can apply it at 2am without a meeting.
4. Set reporting channels. Establish how a security event reaches the response team from every source: monitoring alerts, staff reports, customer reports, and inbound notifications from vendors or providers. A source that drops events into a mailbox nobody watches is not a reporting channel. Every path needs to reach one triage queue. Staff event reporting specifically is governed by A.6.8 information security event reporting, which feeds this control.
5. Prepare communication and evidence-handling procedures. Write the notification templates and contact lists before they are needed: internal escalation, customer notification (for example, through a public status page), and regulator notification where breach rules apply. Document how forensic evidence and chain of custody are handled so the record holds up if an incident becomes a legal matter. Communication prepared in advance is communication that goes out on time.
6. Arrange training and a tabletop exercise. Train the people named in the roles, then exercise the plan with at least one tabletop that walks a realistic scenario end to end. The tabletop is what converts a written plan into a tested one, and it produces the evidence that the program was prepared rather than merely documented.

Detection inputs: cloud vs on-prem

The A.5.24 plan, roles, severity model, and process are the same regardless of where the environment runs. What differs is where the detection signal that feeds the reporting channels comes from. In cloud environments, the inputs are provider-native: cloud provider logs, managed threat detection such as AWS GuardDuty or Microsoft Defender for Cloud, and managed monitoring services. In on-prem or self-hosted environments, the inputs come from a self-run SIEM, syslog collection, IDS, and endpoint tooling the team operates itself. Wire whichever inputs apply into the single triage queue the plan defines. The SOC 2 incident response for on-prem environments guide covers the self-hosted detection stack and forensic pre-staging in depth. Do not let the environment difference fragment the governance: one plan, one severity model, one set of roles, fed by whichever detection inputs the infrastructure provides.

What evidence demonstrates A.5.24?

ISO 27001 A.5.24 evidence is the set of artifacts that prove the incident management capability was planned and prepared in advance rather than assembled after an event. Auditors sample across configuration artifacts (the plan exists) and execution artifacts (the plan is exercised). Teams that wire triage records and exercise artifacts into automated evidence collection are practicing GRC engineering, which keeps this evidence current without a quarterly scramble.

How does A.5.24 map to SOC 2?

ISO 27001 A.5.24 maps to the SOC 2 System Operations criteria that cover evaluating and responding to security events. The overlap is Full: the incident management planning artifacts produced for SOC 2 satisfy A.5.24 without adaptation.

CC7.3 is the event-evaluation criterion and CC7.4 is the response-execution criterion; A.5.24 falls under the planning side of both. A team that has built its incident response program for SOC 2 has already produced the A.5.24 evidence. The SOC 2 to ISO 27001 control mapping covers the full crosswalk across every criterion.

Related controls

ISO 27001 A.5.24 is the planning control; the operational incident controls in the Organizational theme execute against the plan it builds. A.5.25 assessment and decision on information security events covers deciding which events are incidents, A.5.26 response to information security incidents covers running the response, and A.5.27 learning from information security incidents covers feeding lessons back into the program. A.6.8 information security event reporting is the people-side control that gets events reported into the process A.5.24 defines, and A.8.16 monitoring activities is the technological control that generates much of the detection signal those reporting channels carry. All belong to the ISO 27001 certification guide.

Frequently Asked Questions

What is ISO 27001 A.5.24?

ISO 27001 A.5.24, information security incident management planning and preparation, is the organizational control that requires an organization to plan and prepare for security incidents before they occur. It covers defining the incident management process, assigning roles and responsibilities, setting a severity and escalation model, establishing reporting channels, and preparing communication and evidence-handling procedures. It is attributed to ISO/IEC 27001:2022, Annex A.

What evidence satisfies A.5.24?

Typical A.5.24 evidence includes a documented incident response plan or policy, a roles and responsibilities matrix with named owners and backups, a severity and escalation matrix, tabletop exercise records with tracked follow-up actions, alert triage records showing events were evaluated, and an on-call schedule. Auditors look for both the plan itself and evidence that it has been exercised; documentation alone typically falls short.

How is A.5.24 different from A.5.25, A.5.26, and A.5.27?

A.5.24 is the planning and preparation control: it builds the plan, roles, and process before an incident. A.5.25 covers assessing security events and deciding which are incidents. A.5.26 covers responding to confirmed incidents. A.5.27 covers learning from incidents and improving the program. A.5.24 is what the other three execute against.

Does A.5.24 require a tabletop exercise?

A.5.24 requires the organization to prepare for incidents, and exercising the plan is how preparation is demonstrated. A documented incident response plan that has never been run in a tabletop is the most common gap under this control. At least one annual tabletop that walks a realistic scenario end to end, with follow-up actions tracked to completion, is the practical way to show the plan is tested rather than only written.

Do cloud and on-prem environments implement A.5.24 differently?

The plan, roles, severity model, and process are environment-agnostic and stay the same. Only the detection inputs feeding the reporting channels differ: cloud environments draw on provider logs and managed threat detection such as GuardDuty or Defender for Cloud, while on-prem environments draw on a self-run SIEM, syslog, and IDS. Both feed the same triage queue the plan defines.

How does A.5.24 map to SOC 2?

A.5.24 maps to SOC 2 CC7.3 and CC7.4 with Full overlap. CC7.3 covers evaluating security events and CC7.4 covers responding to incidents; A.5.24 falls under the planning side of both. The incident response plan, roles matrix, escalation procedures, and tabletop records produced for SOC 2 satisfy A.5.24 without adaptation.

Part of Truvo's ISO 27001:2022 Annex A implementation series. Browse the full set from the ISO 27001 certification guide. If you want a second set of eyes on your incident management plan as part of an effective security program, Truvo runs scoping calls.