Control Definition
The organization must build its incident management capability before incidents occur — defining and establishing the processes it will use to handle information security incidents, assigning the roles and responsibilities that will run them, and communicating both to everyone who needs to know.
Control Objective
To enable a fast, consistent, and orderly response to information security incidents — including clear communication about security events — because the structures were agreed and rehearsed before they were needed.
What This Really Means
Nobody designs the fire escape while the building is burning. A.5.24 is the one part of incident management you get to do calmly: deciding, in advance, who takes charge when something breaks, how bad news gets classified, who calls the regulator, and how the team rehearses. Every other control in the incident cluster — A.5.25 through A.5.28, plus the A.6.8 reporting channel — assumes this groundwork already exists.
In practice the control asks for a small set of concrete things. A documented incident response plan that defines what counts as an event versus an incident, the lifecycle you follow, and who holds authority for drastic actions — disconnecting production, engaging law enforcement, invoking a forensics retainer. Named roles with deputies: an incident manager who runs the response and owns decisions, a technical lead who directs containment and investigation, and a communications lead who controls every message that leaves the response team, with legal, HR, and the DPO on call for the scenarios that need them. And a severity classification scheme — most teams use SEV1–SEV4 or P1–P4 — with concrete criteria and response expectations per tier, so the question of who gets woken at 2 a.m. is a lookup, not a debate.
Preparation also means capability, not just paperwork. The people named in the plan need training for their roles. Reporting channels (A.6.8) must feed a single intake. Tooling should be staged before the bad day: an incident ticketing workflow, a war-room channel, an out-of-band communication method for when email or chat is itself compromised, and — if you have no in-house forensics — a retainer with an external DFIR firm. A notification matrix lists every party you may owe notice to (regulators such as CERT-In or a data protection authority, customers with contractual breach clauses, your cyber insurer) with windows, formats, and owners per row.
What auditors treat as the heart of A.5.24 is rehearsal. A current plan with named, trained people is the baseline; the differentiator is evidence the capability has been exercised — tabletop minutes, gaps found, corrective actions closed. A plan nobody has tested is scored as a paper control, however well written.
Why It Matters
The first hours of an incident set most of its final cost. Teams that decided in advance who is in charge, what severity means, and which systems may be isolated start containing immediately; teams that did not spend those same hours on conference calls working out who owns the problem. Meanwhile regulatory clocks — some as short as six hours in India — run from the moment you notice, whether or not you are ready.
For certification, A.5.24 anchors the entire incident management chain: auditors read A.5.25, A.5.26, A.5.27, A.5.28, and A.6.8 against the structures this control creates, and the absence of past incidents is no defense, because preparation is judged on its own evidence. Where this control is weak, the failure modes are predictable:
- •Decision paralysis in the first hours – without a named incident manager and escalation path, containment waits while people debate ownership, and attackers do not wait
- •Missed regulatory windows – CERT-In’s 6-hour reporting window and DPDPA breach notification duties expire fastest exactly when an unprepared team is slowest
- •Evidence destroyed by instinct – well-meaning admins reimage compromised machines before anyone preserves them, forfeiting root-cause analysis and legal options
- •Uncoordinated communication – employees speculate to customers, executives contradict each other, and an attacker reading a compromised inbox learns your next move
- •Cascading audit findings – a hollow A.5.24 typically drags A.5.25, A.5.26, and A.6.8 into nonconformity with it, because they all depend on its structures
Regional Compliance Context
India. CERT-In directions require specified categories of cyber incidents to be reported within 6 hours of noticing them — a window you will only meet if the report format, contact points, and internal decision authority are staged in the plan beforehand. The same directions require 180-day log retention, which your investigators will rely on. Under the DPDP Act 2023 (Rules notified in 2025; full compliance obligations land 13 May 2027), a personal data breach must be notified to each affected data principal and to the Data Protection Board of India — there is no harm threshold, and the detailed report to the Board runs on a 72-hour clock extendable only with the Board's permission — so the notification matrix needs a dedicated privacy lane with the DPO as a named role. RBI-regulated entities and SEBI CSCRF market intermediaries carry additional sector reporting duties measured in hours, not days.
Gulf. Organizations within scope of the Saudi PDPL should plan for notifying the regulator (SDAIA) on a 72-hour clock from becoming aware of a breach, with affected individuals notified where the breach may cause them harm. The UAE federal PDPL requires prompt notification to the UAE Data Office, with operational detail sitting in executive regulations. If you operate across India and the Gulf, keep one notification matrix with a row per jurisdiction — mid-incident is the wrong time to research regulator portals.
Implementation Guidance
Write and Approve the Incident Response Plan
Draft a plan that defines security events versus incidents, the lifecycle you follow (detect, assess, contain, eradicate, recover, learn), and the authority levels that matter under pressure — who may take production systems offline, who may engage law enforcement, who may invoke a forensics retainer. Keep it short enough to be used during an incident, not just audited. Have management approve it formally and version-control it alongside your other ISMS documents.
Define and Staff the Core Incident Roles
Assign an incident manager (runs the response and owns decisions), a technical lead (directs containment and investigation), and a communications lead (owns every message that leaves the response team), with legal, HR, and the DPO on call for relevant scenarios. Define roles by function with named deputies, so attrition does not hollow out the plan. Publish an on-call rota and keep the contact tree somewhere an attacker cannot delete — printed, or in an out-of-band app.
Build a Severity Classification Scheme
Define three to five severity tiers (SEV1–SEV4 works for most organizations) with concrete criteria: data classification affected, system criticality, spread, customer impact, and regulatory reportability. Attach response expectations to each tier — who is engaged, how fast, who is informed — and include worked examples, because abstract criteria fail under stress. This scheme is what A.5.25 applies at triage, so build it once and share it.
Create the Regulator and Customer Notification Matrix
Build a table of every party you may owe notice to: regulators (CERT-In, the Data Protection Board of India, sector regulators, Gulf data protection authorities where you operate), customers whose contracts contain breach-notice clauses, your cyber insurer, and law enforcement. For each row record the trigger, the window, the format, and the owner. Harvest the contractual rows from your MSAs now — discovering a 24-hour customer commitment during an incident is a self-inflicted wound.
Prepare Playbooks, Tooling, and External Support
Write short runbooks for your most likely scenarios — ransomware, business email compromise, data exfiltration, lost or stolen device, supplier breach — and stage the tooling: an incident ticketing workflow, a war-room channel template, an evidence kit, and an out-of-band communication method for when email or chat is itself suspect. If you have no in-house forensic capability, put a DFIR retainer in place and record its engagement procedure in the plan.
Train the Team and Run Tabletop Exercises
Train every named role on the plan, then rehearse at least annually with tabletop exercises that rotate scenarios — include one that takes your identity provider or collaboration tools offline. Involve executives in at least the highest-severity scenario, so the people who must approve drastic actions have practiced doing so. Capture minutes, gaps, and corrective actions: exercise records are among the strongest evidence this control has.
Maintain the Capability as a Living System
Review the plan after every exercise and every real incident, on regulatory change, and at least annually. Refresh contact trees and on-call rotas quarterly — stale names are the most common audit finding under this control. Track simple readiness indicators (date of last exercise, open corrective actions, contact-list currency) and report them into management review.
Audit Evidence
During your ISO 27001 certification audit, auditors will expect to see the following evidence to demonstrate compliance with A.5.24:
Documentation
- Approved and version-controlled incident response plan with management sign-off
- Severity classification scheme and escalation matrix with response expectations per tier
- Notification matrix covering regulators, customers, insurers, and law enforcement, with windows and owners per row
- Tabletop exercise records: scenario, attendance, minutes, gaps identified, and corrective actions closed
- On-call rota and incident role assignments with named deputies and role training records
Interviews
- Incident manager or CISO on how the plan is invoked, severity assigned, and escalation triggered
- Communications lead, legal counsel, or DPO on notification obligations and pre-approved templates
- A service desk agent or engineer on what they would do on discovering something suspicious — testing whether the plan reaches the front line
Observations
- The incident ticketing workflow and war-room setup, including how a new incident is opened and assigned
- Contact trees and on-call schedules inspected for currency against the HR roster
- A walkthrough of the most recent tabletop exercise or real incident, traced against the documented plan
Practitioner Insights
The first question I ask against this control is simple: show me the last time you used or tested this plan. A pattern I see across audits is a well-written plan with no exercise record behind it, and that gap between the approval date and any evidence of rehearsal tells me more than the document does. Schedule a tabletop before your certification audit — the minutes, the gaps found, and the closed actions are stronger evidence than the plan itself. And make authority explicit: who may disconnect production, who may engage law enforcement. Mid-incident is the worst possible time to seek permission.
Smaller organizations often assume this control demands a 24x7 SOC and a dedicated response team, and then freeze. It does not. A focused plan of a few pages, three named roles with deputies, a one-page severity table, an out-of-band chat group, and a retainer with a forensics firm will outperform a 40-page template nobody has read. The evidence mistake I see most often is staleness — contact trees listing people who resigned a year ago, escalation paths pointing at org structures that no longer exist. Put a quarterly reminder on the contact list and treat it like a smoke-detector battery.
Common Challenges & Solutions
Challenge
The plan names specific people who have since left, and nobody noticed until the audit — or the incident.
Solution
Define roles by function with named deputies, not by individuals alone. Put a quarterly calendar task on refreshing the contact tree and rota, owned by the security lead, and verify it during internal audit. A response plan is infrastructure; treat staleness as an outage.
Challenge
Nobody can say what severity an incident is, so every issue becomes either a panic or an ignored ticket.
Solution
Write concrete criteria per tier with worked examples — "customer personal data confirmed exposed" is SEV1, "single endpoint malware quarantined by EDR" is SEV3. Give the service desk a one-page triage card, and calibrate during tabletop exercises until two people independently assign the same severity to the same scenario.
Challenge
Notification obligations are scattered across dozens of customer contracts and several regulators, and nobody holds the full picture.
Solution
Run a one-time harvest: legal extracts every breach-notice clause from active MSAs into the notification matrix, with trigger, window, format, and owner per row. Make legal the owner of the matrix, and add a review step to contract onboarding so new commitments land in the matrix the week they are signed.
Challenge
Tabletop exercises keep getting postponed because operations always has something more urgent.
Solution
Book the exercise into the ISMS annual calendar with the same standing as internal audit — a named owner, an executive sponsor, a fixed date. A 90-minute single-scenario tabletop is enough to generate real findings. Report completion or slippage into management review, where it becomes visible to the people doing the postponing.
Challenge
The plan quietly assumes corporate email, chat, and SSO will be available — the very systems an incident may take down.
Solution
Stage an out-of-band channel (a Signal or WhatsApp group, or a separate tenant) and keep offline copies of the plan and contact tree. Create break-glass accounts with sealed credentials for critical systems. Then test the assumption: run one tabletop where the identity provider is locked out, and watch what breaks.
