ISO 27001 incident management runs on five Annex A controls, 5.24 through 5.28, plus the personnel reporting requirement in 6.8. A compliant program needs a named Incident Management Team, a documented severity matrix, at least one tested playbook, and evidence records with a defensible chain of custody. Auditors don’t just want policies. They want proof the loop from detection to lessons-learned actually closes.
TL;DR:
- Implementing a documented incident management team with clear authority and role delegation is essential for effective ISO 27001 compliance.
- Organizations must establish a measurable severity classification process to ensure prompt decision-making and escalation within designated timeframes.
- Evidence collection, including logs and memory snapshots, should be pre-planned with a chain of custody to prevent data loss during incident response.
- Regular tabletop exercises and real incidents are critical to test the entire loop from detection to lessons learned, not just policy documentation.
- Using assessment tools can rapidly identify gaps in incident management preparation, ensuring readiness before an actual incident occurs.
Table of Contents
- What Does ISO 27001 Incident Management Cover?
- The Five Incident Management Controls, Explained Control by Control
- Who Runs the Incident Management Team?
- How Do You Classify Incident Severity?
- Containment, Eradication, Recovery, and Parallel Communication
- Collecting Evidence Without Slowing Down the Response
- Turning Incidents Into ISMS Improvements
- What Do Auditors Ask For During Testing?
- How ISMS Calculator Speeds Incident Management Readiness
- Author Perspective: Incident Management as an Iterative Program
- Start Your ISO 27001 Incident Management Readiness Check
- Sources
What Does ISO 27001 Incident Management Cover?
Information security frameworks draw a hard line between an “event” and an “incident.” An event is any observed occurrence in a system, network, or service. Most events are noise: a failed login, a blocked port scan, a flagged email attachment. An incident is an event (or series of events) that compromises confidentiality, integrity, or availability with real business consequence. That distinction matters because it determines when the incident-management machinery switches on.
ISO/IEC 27001:2022 places the incident-management requirements in Annex A, controls 5.24 through 5.28, with a supporting control at 6.8 for personnel reporting. These five controls sit apart from the preventive controls that dominate most of Annex A, access control, cryptography, network segmentation, because they assume something has already gone wrong. Preventive controls try to stop the fire. Incident-management controls tell you what to do once smoke is in the room.
That’s a deliberate structural choice. A firewall rule set and an incident playbook solve different problems: one reduces the odds of compromise, the other governs what happens the moment odds don’t hold. Organizations that treat incident management as an extension of their technical controls tend to write playbooks nobody follows, because the controls read like security architecture instead of an operational runbook.
The five controls form a loop, not a checklist. Planning and preparation feed assessment, assessment feeds response, response feeds evidence collection, and evidence collection feeds learning, which then updates the plan. Practitioner guidance on the incident-management control set frames this loop as the thing auditors actually test, often by walking through a real incident or a tabletop exercise rather than reading documents in isolation. A binder full of policy language with no evidence the loop ever ran is the single most common finding in surveillance audits.
The Five Incident Management Controls, Explained Control by Control
Each control maps to a distinct phase of the incident lifecycle, and each one produces a specific artifact an auditor will ask to see. Skipping the artifact, even when the underlying activity happened, is functionally the same as skipping the control.
5.24, Incident Management Planning and Preparation. This control requires a documented policy defining what counts as an incident, who has authority to declare one, and how the organization will respond. It’s the foundation everything else builds on.
- A named Incident Management Team (IMT) with defined roles
- Written playbooks for common scenarios (ransomware, data exposure, denial of service, insider misuse)
- Communication channels and escalation paths, including after-hours contact
- Pre-approved templates for internal updates, regulator notifications, and customer communications
5.25, Assessment and Decision. Once something is flagged, someone has to decide fast whether it’s a genuine incident and how severe it is. This control asks for a repeatable classification method, not a judgment call made fresh every time.
- Log the triggering event with a timestamp and source
- Apply a severity classification (covered in detail below)
- Decide whether to formally declare an incident
- Record the decision and the time it took to reach it
5.26, Response. This is the operational core: contain the problem, remove the cause, restore normal service, and keep stakeholders informed the entire time. Auditors expect to see that containment steps didn’t wait on a full root-cause analysis. Speed matters more than completeness in the first hours.
5.27, Learning from Incidents. Every closed incident should generate a short review: what happened, why, what will change. This control is where a program either compounds its maturity or stalls. Organizations that skip this step end up re-running the same incident, sometimes with the same root cause, a year later.
5.28, Collection of Evidence. Logs, screenshots, memory captures, and communication records need a documented chain of custody from the moment they’re gathered. This matters even when litigation looks unlikely at the time of the incident, because that assumption is frequently wrong in hindsight.
The clause language in the 2022 edition is intentionally light on prescribing exact tools or formats. That flexibility is a feature for organizations that already run mature IT service management, and a trap for ones that interpret “flexible” as “optional.” Ismscalculator’s Annex A controls guide breaks down how these five controls relate to the rest of Annex A if you need the wider map.
Who Runs the Incident Management Team?
An IMT that exists only on an org chart is worse than no IMT at all, because it gives auditors a document to poke holes in. The team needs named individuals, defined authority, and a documented handoff process for when the primary contact isn’t reachable.
A functioning IMT typically includes:
- Incident commander — owns the decision to declare, escalate, or close an incident, and coordinates every other role during active response
- Technical lead — directs containment and eradication work across systems, often pulling in specialist engineers as needed
- Communications lead — drafts and clears internal updates, customer notices, and press statements before anything goes out
- Legal or compliance representative — decides when outside counsel or forensic specialists get engaged and tracks regulatory notification obligations
- HR or people representative — handles cases involving insider threats, employee misconduct, or disciplinary follow-up
Authority is the part organizations underdocument. Can the technical lead isolate a production server without a change-management ticket first? Can the incident commander authorize a customer notification before legal signs off, if speed matters more than polish? These answers need to live in the plan itself, not in someone’s memory of “how we usually handle it.”
Document delegation of authority the same way you’d document any other control: named person, scope of authority, effective date, and a signature or system record showing acknowledgment. Pair that with training records showing each IMT member has walked through at least one tabletop exercise in their role. Auditors ask for both, and a team with authority but no training evidence looks almost as unprepared as one with neither.
How Do You Classify Incident Severity?
Control 6.8 requires organizations to give personnel a clear, low-friction way to report suspected security events. If reporting requires three approvals and a ticket in a system nobody remembers the login for, people won’t report, and the whole incident-management loop starves at the source. Effective channels include a dedicated email alias, a phone hotline staffed around the clock, and integration into whatever chat tool employees already use daily.
Once a report lands, someone has to triage it fast. A two-axis severity matrix, business impact on one axis, confidence in the report on the other, gives responders a consistent way to do that without reinventing logic every time.
- High impact, high confidence → declare immediately, activate full IMT, target decision within 30 minutes
- High impact, low confidence → escalate to technical lead for rapid validation, decision within 2 hours
- Low impact, high confidence → handle through standard operational process, log and monitor
- Low impact, low confidence → log for pattern analysis, no immediate escalation required
The matrix does double duty. It gives responders a decision framework, and it gives auditors a visible, timestamped record of how fast the organization moved from report to decision, which is exactly the metric surveillance audits like to probe.
Pro Tip: Set your decision-clock targets before you need them under pressure. An organization that writes “respond appropriately” instead of “declare within 30 minutes for Tier 1” is giving itself room to explain away a slow response after the fact, and giving an auditor an easy finding.
Containment, Eradication, Recovery, and Parallel Communication
Response under control 5.26 has four moving parts that happen at overlapping times, not in strict sequence.
- Containment — isolate affected systems, throttle suspicious traffic, or apply temporary access restrictions to stop the bleeding without necessarily fixing the cause yet
- Eradication — remove malware, close the exploited vulnerability, revoke compromised credentials, and patch the underlying weakness
- Recovery — restore systems from clean backups, validate data integrity, and bring services back online in a controlled sequence
- Communication — running the entire time alongside the technical work, not bolted on afterward
The communication track is where technically sound responses go sideways. Internal updates need to reach leadership and affected teams on a set cadence, even when there’s nothing new to report, silence reads as loss of control. External communication, to customers, partners, or regulators, needs pre-cleared templates so nobody is drafting a breach notification from scratch under pressure at 2 a.m.
Pro Tip: Build your regulator and customer notification templates during the calm, well before an incident, and get legal sign-off on the boilerplate in advance. Editing a pre-approved template under deadline pressure is a fundamentally different task than writing one from a blank page while stakeholders wait.
Rollback planning belongs in the eradication phase, not as an afterthought. If a patch breaks a dependency or a credential revocation locks out a legitimate service account, you need a tested path back to the prior known-good state. For sector-specific sequencing, Ismscalculator’s incident response guide for banking ISMS environments walks through how regulated firms structure this handoff, and the framing translates to other regulated sectors with only minor adjustment. Playbook design generally benefits from treating each incident type as its own scenario rather than one generic template; operational playbook guidance for incident response makes a similar case for scenario-specific runbooks over a single catch-all document.
Collecting Evidence Without Slowing Down the Response
Control 5.28 asks organizations to identify, collect, acquire, and preserve evidence in a way that keeps it usable for investigation or regulatory submission later. That’s a documentation discipline layered on top of the technical response, and it’s easy to skip when the priority in the moment is getting systems back online.
Evidence worth capturing during almost any incident includes:
- System and application logs from the affected timeframe, exported before rotation deletes them
- Memory images or forensic snapshots for systems suspected of active compromise
- A timeline of actions taken, by whom, and when, including containment decisions
- Copies of internal and external communications sent during the response
Chain of custody doesn’t need to be elaborate. A simple log, who collected the evidence, when, where it’s stored, and who has accessed it since, satisfies most auditors, and it’s the kind of artifact Ismscalculator’s guide to evidence types for ISO 27001 audits walks through with concrete templates.
The real tension is speed versus integrity. Restoring a compromised server from backup can destroy the exact memory state a forensic investigator would want. The fix is a simple rule built into the playbook in advance: for any incident classified above a set severity threshold, pause before wiping or rebuilding a system long enough to capture a forensic image. That single checkpoint, decided ahead of time rather than negotiated mid-incident, prevents most evidence-destroying mistakes.
Turning Incidents Into ISMS Improvements
Control 5.27 is deceptively simple to describe and genuinely hard to execute well: review the incident, find the root cause, fix what let it happen, and prove the fix landed. Organizations that treat this as a formality write a one-page summary and move on. Organizations that treat it seriously use it to drive real ISMS change.
A post-incident review that holds up under audit scrutiny covers:
- What happened, in a factual timeline with no editorializing
- Root cause, distinguished clearly from contributing factors
- Corrective and preventive actions, each with a named owner and a deadline
- Which existing risk treatment or policy the incident exposed as inadequate
The step people skip is the last one. An incident report that never touches the risk register or policy set is a story, not an ISMS input. Auditors specifically look for the link between “this happened” and “here’s what changed in our documented controls as a result.” Without that link, even a well-written post-mortem does nothing for your certification.
What Do Auditors Ask For During Testing?
Certification bodies rarely accept a policy binder as sufficient proof the incident-management controls work. Common practice in surveillance audits involves walking through a real incident from the past cycle, or running a live tabletop exercise on the spot, to see whether the IMT actually knows its own playbook.
A reasonable testing cadence looks like one full tabletop exercise annually, covering a realistic scenario like ransomware or a third-party breach, plus targeted simulations for higher-risk areas identified in the risk assessment. Evidence to retain from each exercise:
- The written scenario and objectives
- Attendance and role assignments for participants
- Notes on decisions made and time taken to reach them
- A tracked list of corrective actions the exercise revealed, with follow-up status
When auditors ask for samples, they typically want a closed incident report showing the full loop from detection to lessons learned, a chain-of-custody record from an actual or simulated evidence collection, and training records proving IMT members have exercised their assigned roles. A practical incident response plan template can help structure these artifacts if you’re building from scratch. Ismscalculator’s certification checklist covers where these evidence types fit into the broader 80-step path to certification.
One thing ISO deliberately does not do: set breach notification deadlines. Those come from wherever the organization operates, U.S. state breach notification laws, HIPAA for health data, SEC rules for public companies. ISO’s incident controls govern the internal process, but the external clock runs independently, and mapping your internal decision timeline against those regulatory deadlines is a task the standard leaves entirely to you.
How ISMS Calculator Speeds Incident Management Readiness
Building the artifacts above from scratch, severity matrix, playbooks, evidence templates, is where most implementation timelines slip. A tailored readiness assessment identifies exactly which of the 5.24 through 5.28 controls already have working documentation and which are placeholder text, before an auditor finds the gap for you.
Ismscalculator’s maturity assessment across 14 ISO domains scores incident management alongside the rest of your ISMS, so you see whether it’s your weakest domain or a relative strength. Once gaps are mapped, the platform’s Gantt and timeline tools let you sequence the work: severity matrix first, IMT documentation second, a tested playbook third, evidence templates running in parallel.
The free readiness check takes about two minutes and returns a benchmark against organizations of similar size and industry, useful context when you’re deciding whether your current tabletop cadence is thin or roughly in line with peers. Compliance owners short on time tend to use it as a first pass, then dig into the domain-specific detail once they know where the real gaps sit.
Author Perspective: Incident Management as an Iterative Program
The maturity trap I see most often isn’t a missing control. It’s an implementation built entirely for the audit rather than for the incident. Teams write a beautiful 5.24 policy, run one tabletop the week before the assessor arrives, and then let the playbook sit untouched for a year. That passes certification. It does not survive a real ransomware event.
Start smaller and more honestly than that. Build a severity matrix with real thresholds, name an actual IMT with actual authority, and pressure-test one playbook until people can run it without the document open in front of them. Everything else, the evidence templates, the notification workflows, the regulatory mapping, gets easier once that core loop works under stress.
Treat every incident, real or simulated, as an input to the ISMS rather than a problem to close and forget. That’s the difference between a program that survives its first real test and one that only ever survived its audit.
— Martin
Start Your ISO 27001 Incident Management Readiness Check
Building the five incident-management controls from a blank page usually costs weeks of back-and-forth between compliance, IT, and legal before anyone knows what’s actually missing. Ismscalculator’s ISO 27001 Readiness Assessment shortcuts that by mapping your current documentation against 5.24 through 5.28 directly, flagging exactly where your severity matrix, IMT authority records, or evidence templates fall short.
The assessment takes about two minutes to start and returns a tailored gap report, a benchmark against similar organizations, and a timeline estimate for closing what’s missing. You get a PDF report you can share with leadership or an auditor, a prioritized list of action items, and the option to save your results and compare them against a future estimate once you’ve closed gaps. If you’d rather explore the full toolkit first, including the Gantt-based implementation planner, the ISMS Calculator platform is the place to start.
Sources
- ISO/IEC 27001:2022 - Information security management systems
- ISO 27001 Incident Management Controls for Response and Records