Control Definition
Information security incidents must be handled according to the organization's documented procedures, by the people designated and prepared for the role — covering containment, evidence collection, eradication, recovery, escalation, and controlled communication, with the response recorded and the incident formally closed.
Control Objective
To resolve information security incidents quickly and in a controlled way, limiting damage by executing procedures agreed in advance instead of improvising under pressure.
What This Really Means
Everything before this control was rehearsal. A.5.24 wrote the playbook, named the roles, and staged the tooling; A.5.25 assessed the event and declared the incident; A.5.26 is game day — executing the documented procedures while the clock runs and the pressure is real. The requirement reads almost trivially ("respond to incidents per the documented procedures"), but it is where the whole incident cluster gets tested, because the only proof this control operates is what your team actually did, recorded while they did it.
The technical spine of a response runs in a deliberate order. Containment comes first — isolating affected endpoints through EDR, disabling or re-credentialing compromised accounts, blocking attacker infrastructure, segmenting whatever can spread — using the authority the plan pre-delegated, so nobody is hunting for permission to pull a production system offline at 2 a.m. Evidence preservation runs in parallel, not afterward: before anyone reimages or "cleans up", forensic images, volatile data, and logs are captured and handed into the A.5.28 chain-of-custody process, because the instinct to restore is exactly what destroys root cause. Then eradication — removing persistence mechanisms, closing the exploited weakness, resetting credentials, rebuilding compromised hosts from known-good sources — and only then recovery, in controlled stages, restoring from clean backups with defined verification criteria and heightened monitoring before anything is declared healthy.
Around that spine sits the discipline layer. Escalation follows the severity scheme: a SEV1 engages executives and may invoke crisis management or the business continuity plan when impact outgrows the incident process. Communication runs through one channel — the communications lead owns every message that leaves the response team, internal updates are need-to-know, and external notifications to regulators, customers, and the insurer execute from the notification matrix rather than from anyone's memory, over out-of-band channels if corporate email or chat may itself be compromised. And everything is logged as it happens: a war-room decision log with timestamps — who decided what, when, on what information — is the artifact that later defends every judgment call to auditors, regulators, insurers, and sometimes courts.
What auditors treat as the heart of A.5.26 is the trace through real incidents. They will pick a closed incident and read it against your procedures: was severity assigned, did containment follow the playbook, was evidence preserved before the rebuild, who approved recovery, when did notifications go out, was the incident formally closed with a report. Plans demonstrate A.5.24; only incident records — or, for organizations lucky enough to have had no incidents, realistic exercise records — demonstrate A.5.26. The gap between what the procedure says and what the records show is precisely where findings live.
Why It Matters
Response quality is measured in blast radius. The same initial compromise becomes a contained nuisance or a company-defining breach depending almost entirely on what happens in the first hours: how fast spread is stopped, whether eradication actually removes the attacker or just their most visible foothold, and whether recovery restores clean systems or reinfects them. Improvised response reliably gets the order wrong — teams wipe machines before imaging them, restore service before eradicating persistence, and announce the all-clear while the attacker still holds valid credentials.
The response window is also when legal and commercial obligations bite. Regulatory clocks — six hours for CERT-In reportable incidents in India, 72-hour detailed-report windows in several data protection regimes — expire during the response, not after it, and contractual breach-notice clauses to customers run on the same compressed timeline. A team that cannot run notifications in parallel with containment converts a technical incident into a compliance incident.
Where incident response is improvised rather than executed, organizations face:
- •A wider blast radius – every hour of delayed containment is more lateral movement, more privilege escalation, and more data leaving the building
- •Reinfection after premature recovery – restoring service without verified eradication invites the same attacker back through the persistence they left behind
- •Evidence destroyed by the cleanup – reimaging before imaging forfeits root cause analysis, legal options, and the ability to prove what was and was not touched
- •Missed regulatory and contractual windows – notification clocks expire mid-chaos, stacking penalties and broken customer commitments on top of the breach itself
- •An attacker reading the response – uncoordinated communication over compromised channels tells the intruder exactly what you know and what you will do next
Regional Compliance Context
India. The CERT-In reporting window for specified incident categories is 6 hours from noticing — which lands squarely inside the response phase, so the report must be triggered in parallel with containment, by an owner the plan names, using the format and contact points staged under A.5.24. CERT-In's 180-day log retention direction is also what keeps the investigation viable. For personal data breaches, the DPDP Act 2023 requires notifying each affected data principal and the Data Protection Board of India, with the detailed report to the Board running on a 72-hour clock extendable only with the Board's permission — so the DPO lane of the response activates the moment a personal-data flag is raised, not at closure. RBI-regulated entities and SEBI CSCRF intermediaries carry parallel sector duties measured in hours.
Gulf. Organizations in scope of the Saudi PDPL should execute regulator notification (SDAIA) on a 72-hour footing, with affected individuals informed where the breach may cause them harm; the UAE federal PDPL expects prompt notice to the UAE Data Office. Run all of it from the notification matrix — one row per jurisdiction, with the owner and window on each row — rather than researching regulator portals mid-incident.
Implementation Guidance
Confirm the Declaration and Take Command
The incident manager assumes command the moment A.5.25 triage declares an incident: confirm the severity tier, mobilize the roles that tier requires, open the incident ticket and the war-room channel, and start the decision log. Appoint a scribe in the first minutes — the contemporaneous record of who decided what, and when, is the single most valuable artifact the response will produce.
Contain Fast, Using Pre-Delegated Authority
Stop the spread before perfecting the diagnosis: isolate affected endpoints through EDR, disable or re-credential compromised accounts, block attacker infrastructure at the boundary, and segment networks where movement is suspected. Use the authority matrix from the A.5.24 plan for drastic actions such as taking production offline — the incident manager acts provisionally and management ratifies, never the reverse. Record each containment action and its business impact in the log.
Preserve Evidence Before Changing Anything
Before eradication touches a system, capture what investigators and lawyers will later need: forensic images of affected hosts, volatile data where relevant, cloud snapshots, and log exports that outlive rotation windows. Hand the artifacts into the A.5.28 process with chain-of-custody records started at first capture. Prefer EDR isolation over power-off where volatile evidence matters, and make "image before reimage" a hard rule.
Eradicate the Root Cause, Not Just the Symptom
Remove the attacker's presence and the condition that admitted them: delete persistence mechanisms, patch or reconfigure the exploited weakness, reset every credential the attacker could have touched, and rebuild compromised hosts from known-good images rather than trusting spot cleaning. Verify eradication deliberately — IOC sweeps, scans, and a review of authentication activity — before anyone proposes recovery.
Recover in Verified Stages
Restore services in a planned sequence from clean sources (A.8.13 backups or rebuilt systems), with explicit verification criteria for each stage and heightened monitoring (A.8.16) over the restored estate for a defined window. Resist the pressure to declare victory early: a documented go/no-go decision per stage, owned by the incident manager, is what separates recovery from reinfection.
Run All Communication Through One Channel
The communications lead controls every message: internal updates on a fixed cadence to a need-to-know list, external notifications executed from the notification matrix — regulator reports, customer notices under contractual clauses, the cyber insurer — and pre-approved holding statements where facts are still forming. Move the response conversation to out-of-band channels whenever corporate email or chat may be within the attacker's reach.
Close Formally and Hand Off the Lessons
Close the incident against defined criteria: eradication verified, services recovered, notifications completed, evidence preserved and indexed. Complete the incident record — timeline, actions, decisions, estimated cost — and brief management with a closure report. Then schedule the A.5.27 post-incident review within days, while memory is fresh, so the response converts into improved controls rather than just a closed ticket.
Audit Evidence
During your ISO 27001 certification audit, auditors will expect to see the following evidence to demonstrate compliance with A.5.26:
Documentation
- Incident response procedures and scenario playbooks, version-controlled and aligned with the A.5.24 plan
- Completed incident records showing timeline, severity, containment and eradication actions, and recovery decisions
- War-room decision logs or ticket histories with contemporaneous timestamps for key judgment calls
- Communication records: internal updates, regulator notifications, and customer notices with send times against the required windows
- Closure reports with eradication verification, post-recovery monitoring results, and management sign-off
Interviews
- The incident manager on a recent incident: how command was taken, severity confirmed, and drastic actions authorized
- Technical responders on the containment and eradication steps actually performed, and how evidence was preserved before rebuilds
- The communications lead or DPO on how external notifications were triggered, approved, and tracked against regulatory clocks
Observations
- A closed incident traced end to end against the documented procedure — declaration to containment to recovery to closure
- Live demonstration of opening an incident: ticket creation, war-room setup, decision log, and role assignment
- Containment capability shown in the tooling — isolating a host or disabling an account through EDR or identity management
Practitioner Insights
When I audit this control, the document I want is not the procedure — it is the incident record for your last SEV1 or SEV2, read side by side with that procedure. A pattern I see across audits: a beautifully written response plan, and incident tickets that contain three lines — investigated, resolved, closed — with no timeline, no decisions, no notification timestamps. That gap is the finding, because an undocumented response is indistinguishable from an improvised one. Put a scribe in every war room and log decisions as they happen; contemporaneous records are also what defend your judgment calls to a regulator or insurer when they get second-guessed months later.
In smaller organizations the failure mode is the quiet fix: an engineer spots the compromise, cleans it up alone in an afternoon, and tells nobody — no ticket, no evidence, no notification assessment, and quite often persistence left behind. The fix is to make the lightweight path official: a fifteen-minute discipline of open the ticket, note the timeline, snapshot before rebuilding, plus a standing rule that nobody recovers a system without a second person confirming eradication. The evidence mistake I see most is records reconstructed weeks later for the audit — backdated narratives read exactly like what they are. A thin record written during the incident beats a polished one written after it.
Common Challenges & Solutions
Challenge
Engineers jump straight to wiping and rebuilding compromised systems, destroying the evidence and frequently missing the attacker's persistence.
Solution
Make "preserve, then eradicate" a hard rule in the playbook: forensic image or snapshot before any rebuild, EDR quarantine instead of power-off where volatile data matters, and rebuilds only from known-good images once capture is confirmed. Stage an evidence kit and train responders on the A.5.28 handoff so preservation costs minutes, not hours.
Challenge
Containment stalls because nobody on shift dares take a production system offline without permission.
Solution
Pre-delegate the authority in the response plan: the incident manager may take provisional containment action up to defined impact levels, with management ratifying at the first review point. Publish the authority matrix, rehearse the drastic-action decision in tabletop exercises, and log every such call. An hour of outage decided fast is usually cheaper than a day of spread decided slowly.
Challenge
Communication freelancing — engineers update customers directly, executives speculate, and versions of the story multiply.
Solution
Route every outbound message through the communications lead, with pre-approved holding statements for the period before facts settle and a fixed internal update cadence that removes the vacuum speculation fills. Brief staff that inquiries get forwarded, not answered. Where the attacker may read corporate channels, move response coordination out-of-band immediately.
Challenge
Recovery is declared too early and the environment is reinfected within days.
Solution
Define eradication verification before recovery begins: IOC sweeps across the estate, confirmation that every exposed credential was reset, scans of rebuilt systems, and a review of authentication activity for the attacker's return. Recover in stages with go/no-go gates and run heightened monitoring for a defined window after restoration — reinfection almost always shows up there first.
Challenge
The response itself goes undocumented, so nothing can be proven afterward to auditors, regulators, or the insurer.
Solution
Assign a scribe role in the first minutes of every significant incident and keep a decision log with timestamps as a living document in the war room. Make the incident ticket the single system of record — actions, approvals, notification times — and gate formal closure on its completeness. The discipline pays twice: cleaner audits and a defensible position in any later dispute.
