A ransomware note on a Tuesday morning does not care whether your organization has a documented incident response policy. What it cares about is whether your team already knows who has authority to isolate a subnet, who calls outside counsel, and who starts the clock on regulatory notification. ISO/IEC 27001:2022 addresses that gap through five Annex A controls, 5.24 through 5.28, plus a supporting people control at 6.8. Together they form the only part of Annex A that assumes something has already gone wrong. This article walks through what each control actually requires, how auditors verify it, and how it lines up with the US notification deadlines that will be running in parallel the moment an incident is confirmed.
What “Incident Management” Means Under ISO 27001
ISO/IEC 27002:2022, which supplies the implementation guidance behind Annex A, draws a line between three terms that get used interchangeably in most organizations and shouldn’t be. An information security event is any observed occurrence in a system, service, or network that indicates a possible breach of policy or control failure, a failed login spike, an unfamiliar process running on a server, a firewall alert. Most events are noise. An information security incident is one or more related events that have actually compromised, or have a significant probability of compromising, business operations and threatening information security. A weakness is different again: a vulnerability or gap that hasn’t been exploited yet but could be, and 27001 expects weaknesses to be reported through the same channel as events rather than quietly patched and forgotten.
That distinction matters because it defines where Annex A 5.25 sits in the workflow. Not every event needs a full incident response, and treating every anomaly as a five-alarm incident burns out the team that’s supposed to handle the real ones. The standard’s answer is a documented assessment step, not gut instinct, that decides which events cross the threshold into “incident.”
The Five Annex A Controls That Make Up Incident Management
The 2022 revision consolidated what used to be a scattered set of ISO 27001:2013 clauses under 16.1 into five sequential organizational controls, plus one people control that feeds the whole system.
ISO 27001:2022 Annex A Incident Management Controls
| Control | Name | Function |
|---|---|---|
| 5.24 | Incident management planning and preparation | Preventive/administrative – build the policy, team and playbooks before anything happens |
| 5.25 | Assessment and decision on information security events | Detective – triage events and classify which ones are incidents |
| 5.26 | Response to information security incidents | Corrective – contain, eradicate, recover, communicate |
| 5.27 | Learning from information security incidents | Corrective/preventive – root cause analysis feeds back into the ISMS |
| 5.28 | Collection of evidence | Corrective/legal – preserve evidence for investigation, litigation or regulatory proof |
| 6.8 | Information security event reporting | People control – every employee’s channel for flagging something wrong |
Five controls, one continuous loop. 5.24 sets up the machine, 6.8 feeds it raw material from the whole workforce, 5.25 filters signal from noise, 5.26 does the actual work, 5.28 protects the paper trail while that work happens, and 5.27 makes sure the next incident is handled a little better than this one. An auditor testing this control set is really testing whether the loop closes, not whether each control exists in isolation.
Employee awareness and reporting responsibilities are also covered in our ISO 27001 People Controls guide.
Annex A 5.24: Planning and Preparation
5.24 requires a documented incident management approach that exists before it’s needed, covering roles, responsibilities, and procedures. In practice, auditors look for three things: a named Incident Management Team with defined authority, a policy that’s been communicated and acknowledged, and playbooks specific enough to survive a 2 a.m. phone call.
The team composition question trips up more organizations than any other part of 5.24. A workable Incident Management Team is multi-disciplinary by design: technical leads for forensics and containment, legal and compliance for regulatory notification, senior management with authority to approve emergency spend, and HR or communications for staff and external messaging. Leaving legal out of the initial response, rather than bringing them in only once notification is imminent, is one of the most common gaps auditors flag, because 5.24 explicitly expects coordination with legal, regulatory, and sector-specific requirements to be built into the plan, not bolted on afterward.
Generic incident response plans satisfy the letter of 5.24 but not the intent. A plan that says “isolate the affected system” is not a playbook; a playbook names the specific commands, the specific systems, and the specific decision points for ransomware, account takeover, and SQL injection scenarios separately, because the technical response to each looks nothing alike. One detail that’s easy to overlook until the invoice arrives: a pre-authorized emergency spending limit for the CISO, tied to a dedicated accounting code, so forensic consultants and emergency hardware don’t get stuck behind a normal procurement cycle while the incident is still live.
Testing is not optional under 5.24 in any meaningful sense, even though the control text doesn’t specify a frequency. Annual tabletop exercises, at minimum, plus a re-test whenever infrastructure or the threat landscape changes materially, is the de facto standard auditors expect to see evidence of.
Annex A 5.25: Assessment and Decision
Once 6.8 or automated monitoring surfaces an event, 5.25 governs what happens next: a documented process for deciding whether it’s actually an incident. This is where a severity matrix earns its keep. A workable matrix scores events on two axes, likely business impact and confidence that the event is real, and maps the combination to a response tier with a defined time-to-decision.
Example Severity Classification Matrix
| Tier | Criteria | Decision Window | Escalation |
|---|---|---|---|
| Critical | Confirmed unauthorized access to production data or systems | 15 minutes | Full IMT activation, executive notification |
| High | Suspected compromise, active malware, or credential exposure | 1 hour | Technical lead + compliance notified |
| Medium | Policy violation or anomaly with limited scope | 4 hours | Security team triage |
| Low | Isolated event, no confirmed impact | 24 hours | Logged, reviewed at next team sync |
The decision itself, and who made it, needs to be logged. Auditors sampling this control almost always ask for a specific event that was assessed and not escalated, and expect to see the reasoning recorded somewhere other than someone’s memory.
Annex A 5.26: Response to Information Security Incidents
5.26 is the operational core: once something is classified as an incident, the response has to follow documented procedure, not improvisation. Most organizations that have adopted NIST SP 800-61r3 already run something close to the sequence 5.26 expects: containment to stop the bleeding, eradication to remove the cause, recovery to restore normal operation, and communication running alongside all three rather than as a final step tacked on at the end.
That communication piece is where 5.26 differs most from a purely technical incident response plan. It requires coordinated messaging with internal stakeholders, affected customers, regulators, and in some cases law enforcement, and it requires that messaging to be consistent with whatever legal and regulatory obligations apply, which is precisely why legal needs a seat at the table from 5.24 onward rather than a briefing after the fact.
Closing out an incident under 5.26 means producing an incident report or log entry documenting what happened and what was done, and that record should surface at the next management review or security team meeting. If the review finds the documented procedure wasn’t actually followed, that’s a signal the policy itself needs revision, not just a training reminder, and that finding routes directly into 5.27.
Annex A 5.28: Collection of Evidence
5.28 is easy to underweight because it reads like a legal formality, but it’s frequently where incident response falls apart under scrutiny. The control requires procedures for identifying, collecting, acquiring, and preserving evidence in a way that maintains its integrity, whether the eventual use is internal investigation, litigation, or a regulatory submission.
Chain of custody is the operative concept. Every person who touches a piece of evidence, a disk image, a log export, a memory dump, needs to be recorded, along with when they touched it and what they did with it. A forensic image taken by an engineer who then continues working on the live system, overwriting volatile memory in the process, has compromised the very evidence that would have explained how the attacker got in. This is why 5.28 works best when it’s operationalized before an incident, not improvised during one: pre-approved forensic tooling, a designated evidence custodian, and write-once storage for images and logs.
Digital evidence handling in most mature ISMS programs draws on ISO/IEC 27037 for the technical detail 27001 itself doesn’t spell out, covering identification, collection, acquisition, and preservation of digital evidence specifically. Referencing 27037 in your incident management procedure is a common way to demonstrate to an auditor that evidence handling has a technical standard behind it, not just a policy statement.
Annex A 5.27: Learning From Information Security Incidents
5.27 is the control most often implemented in name only. It requires that knowledge gained from incidents be used to strengthen the ISMS, through updated risk assessments, revised controls, or modified procedures, and that this happens through a documented process rather than an informal retrospective conversation that never produces a written change.
A post-incident review under 5.27 should produce a specific artifact: root cause, timeline, what worked, what didn’t, and a list of concrete follow-up actions with owners and deadlines. The review should also quantify cost, because 5.24’s emergency spend tracking exists specifically so that when an incident closes, the organization can tell its board and its auditors exactly what the breach cost in forensic fees, legal fees, and remediation, which in turn justifies the budget for whatever 5.27 recommends fixing.
The output of 5.27 belongs in the risk register and, where relevant, the Statement of Applicability. If an incident exposed a gap that an existing control should have caught, the SOA justification for that control needs updating to reflect the real-world test it just failed.
Annex A 6.8: Where Incidents Actually Start
6.8 sits in the people controls category, not organizational, and it’s easy to treat as a footnote to 5.24-5.28. That’s a mistake, because 6.8 is the control that determines how early the clock actually starts. It requires that all personnel have a clear, accessible mechanism for reporting observed or suspected events, and that they’re trained to use it without hesitation.
The gap that shows up most often in practice isn’t a missing reporting channel, it’s a slow one. An employee who notices a suspicious email or an unfamiliar login two weeks before mentioning it to anyone has quietly consumed most of a state breach notification window before the organization even knows a clock is running, since most US notification deadlines are measured from discovery, not from the underlying event. A short, mandatory, low-friction reporting mechanism, ideally a single button, form, or address that reaches the right people immediately, does more for actual incident response speed than almost any technical control in Annex A 8.
Many incident response capabilities rely on the technical safeguards covered in our ISO 27001 Technological Controls guide.
The US Regulatory Clock: SEC, HIPAA, State Law, and CIRCIA Running at Once
ISO 27001 doesn’t prescribe notification timelines; it prescribes the process for handling incidents that will, in the US, trigger several notification clocks simultaneously, each with its own trigger, threshold, and recipient. This is where a well-built 5.24-5.28 program earns its value, because none of these deadlines are forgiving of an organization that’s still figuring out who’s in charge.
US Regulatory Notification Timelines Relevant to Incident Management
| Framework | Trigger | Deadline | Recipient |
|---|---|---|---|
| SEC Cybersecurity Disclosure Rule | Determination that an incident is material (public companies) | 4 business days | Form 8-K via EDGAR |
| HIPAA Breach Notification Rule | Breach of unsecured PHI, 500+ affected | 60 days from discovery | HHS, affected individuals, media |
| California (Civil Code 1798.82, SB 446) | Breach of computerized personal information | 30 calendar days | Affected residents; AG within 15 days if 500+ affected |
| Texas (Bus. & Comm. Code 521.053) | Breach of sensitive personal information | 60 days | Affected residents; AG if 250+ affected |
| Florida (Information Protection Act) | Breach of personal information | 30 days | Affected residents and AG if 500+ affected |
| GLBA Safeguards Rule | Breach affecting 500+ customers (financial institutions) | 30 days | FTC |
| CIRCIA (critical infrastructure) | Covered cyber incident or ransom payment | Timeframes set under the 2026 final rule | CISA |
Two details in that table cause the most trouble for multi-state organizations. First, there is still no single federal breach notification law; a company operating in a dozen states owes separate notices under each affected resident’s state law, and the tightest deadline among them governs the whole response. Second, HIPAA’s 60-day allowance is the outlier, not the norm: several states now sit at 30 days, and the clock starts at discovery, which is exactly why 6.8’s reporting speed and 5.25’s decision windows matter as much as the technical response itself. An incident management program built only around a generic “reasonable time” standard will fail the moment a California resident is among those affected.
What Auditors Actually Check: Evidence and SOA Language for 5.24–5.28
Certification and surveillance audits against 5.24-5.28 rarely start with a document review. They start with a request for a real incident, or a real tabletop exercise, and a walk through what happened against what the policy says should have happened. The documentation an auditor typically asks to see includes the incident management policy itself, the incident log or ticketing history, at least one closed incident report with root cause and remediation actions, evidence of IMT training or tabletop testing within the last twelve months, and the chain-of-custody records for any incident that generated forensic evidence.
In the Statement of Applicability, incident management controls are almost never marked not applicable, since every organization with an ISMS scope handles information and therefore has incident exposure. The justification language that holds up under scrutiny names the specific mechanism, not the control text back at the auditor: “Incidents are logged and triaged via [ticketing system], escalation follows the severity matrix in [document], and post-incident reviews are documented in [template] and reviewed at quarterly management review,” rather than a restatement of what 5.26 says an organization should do.
A gap that surfaces repeatedly in surveillance audits is a policy that exists and reads well but hasn’t been tested against an actual event in the certification period. Annex A 5.24 through 5.28 is one of the few control clusters where a clean paper trail with zero real activity is itself a finding, because it suggests the process has never been stress-tested, or that incidents are happening and simply not being logged.
Effective incident response begins with strong ISO 27001 access control requirements to prevent, detect, and contain unauthorized access.
Frequently Asked Questions
What is the difference between an information security event and an incident under ISO 27001?
An event is any observed occurrence that might indicate a policy violation or control failure, most of which turn out to be nothing. An incident is one or more events that have actually compromised, or have a high probability of compromising, business operations or information security. Annex A 5.25 governs the assessment process that decides which events cross that line.
Which ISO 27001 controls cover incident management?
Five Annex A controls: 5.24 (planning and preparation), 5.25 (assessment and decision), 5.26 (response), 5.27 (learning from incidents), and 5.28 (collection of evidence), supported by 6.8 (event reporting) in the people controls category.
Does ISO 27001 require a specific incident response timeline?
No. ISO 27001 requires a documented, tested process rather than fixed deadlines. US regulatory deadlines, such as the SEC’s 4-business-day rule or state breach laws ranging from 30 to 60 days, run independently and typically dictate the actual operational clock once an incident is confirmed.
Who should be on an ISO 27001 Incident Management Team?
A multi-disciplinary group: technical leads for containment and forensics, legal and compliance for regulatory notification, senior management with authority to approve emergency spend, and HR or communications for internal and external messaging. Leaving legal out until notification is imminent is a common and costly gap.
What does Annex A 5.28 require for evidence collection?
A documented procedure for identifying, collecting, acquiring, and preserving evidence in a way that maintains its integrity for investigation, litigation, or regulatory use. Chain-of-custody records showing who handled evidence and when are what auditors typically sample.
How often should incident response plans be tested?
At minimum annually and again whenever infrastructure or the threat landscape changes materially. Auditors treat a policy with no tabletop or real-incident evidence in the certification period as a finding in itself, since it suggests the process has never actually been exercised.
How does ISO 27001 incident management relate to NIST SP 800-61?
They describe the same operational lifecycle in different language. NIST SP 800-61r3 uses preparation, detection and analysis, containment/eradication/recovery, and post-incident activity; ISO 27001’s 5.24-5.27 maps onto that sequence almost directly, which makes 800-61 a practical technical reference for implementing what 27001 requires at a governance level.
Conclusion
Incident management is the one part of ISO 27001 that gets tested by reality rather than by an auditor’s checklist. A program built around 5.24-5.28 succeeds or fails based on whether the right person makes the right call in the first hour, not on how the policy reads on a quiet Tuesday. If there’s one place to start, it’s the severity matrix and the reporting channel in 6.8, since those two pieces determine how much of the notification clock has already run by the time anyone else finds out. Building or auditing an incident management program against these controls, and against the US regulatory deadlines stacked on top of them, is core material in GAICC’s ISO/IEC 27001 Lead Implementer and Lead Auditor certifications.
