The Friday Night That Cost Marrow Financial Group $4.2 Million
At 6:47 PM on a Friday, a systems administrator at Marrow Financial Group — a fictional 340-employee regional lender — noticed that file shares on the corporate NAS were renaming themselves with a .lockbit3 extension. He did what a lot of smart, well-intentioned people do when there's no plan: he guessed. He unplugged the NAS from the network, then, worried the ransomware would spread further, logged into the two application servers he thought were "clean" and rebooted them into safe mode to run a virus scanner he'd downloaded that evening. He did not call anyone. There was no incident response plan on the intranet — there had been a draft in a SharePoint folder for two years, unapproved, unowned, and unread. There was no 24/7 contact list. There was no defined severity scale to tell him whether this was a five-alarm fire or routine malware cleanup. So he treated it like routine malware cleanup, alone, for the next eleven hours.
By Saturday morning, the CISO found out from a Slack message, not an escalation. By the time Marrow's outside counsel and a forensics firm were engaged Sunday afternoon, the attacker had been inside the network for an estimated 19 days (later confirmed from firewall logs the team was lucky enough not to have overwritten), had exfiltrated 210,000 customer records including partial account numbers and Social Security numbers, and had encrypted backups that turned out not to be as air-gapped as everyone assumed. The ransom note demanded $1.8 million in Bitcoin. Marrow's leadership, under pressure and against the advice of their newly hired forensics team, paid $340,000 to a negotiated settlement — and got a working decryptor for about 60% of the encrypted data.
Here is the part that turned a bad week into an eighteen-month nightmare: the administrator's "safe mode" reboots and virus-scanner runs on Friday night had overwritten volatile memory and modified file timestamps on two of the three servers the attacker had used as a foothold. When the forensics firm arrived, they could not reliably reconstruct the initial access vector, could not confirm with certainty which records had actually been exfiltrated versus merely accessed, and could not produce a defensible chain of custody for the one disk image that mattered most. Marrow's cyber insurer initially denied the claim outright, citing the policy's incident-reporting-notification clause (72 hours, contractually — Marrow took closer to 60 hours to notify) and the evidentiary standard the policy required for a "confirmed data exfiltration" payout. After eleven months of litigation, the insurer settled for a fraction of the policy limit. The state attorney general's office, unable to get clean answers about what data was actually taken, assumed the worst in its regulatory findings and fined Marrow $1.1 million. Total documented cost, eighteen months out: $4.2 million, not counting the customers who left and the two class-action suits still pending.
Nothing about Marrow's failure was exotic. They had firewalls, they had EDR (mostly uninstalled on legacy servers, but that's a different article), and they even had cyber insurance. What they didn't have was ISO 27001's incident-management discipline: a plan made before the emergency, a way to tell an event from a confirmed incident, a documented response procedure instead of improvisation, a habit of learning from near-misses, and — critically — a defined, trained approach to collecting evidence that would hold up when money and liability were on the line. That is exactly the gap Annex A controls 5.24 through 5.28 are built to close.
Who This Is For, and What You'll Walk Away With
This article is for ISMS managers, CISOs, IT managers, and internal auditors building or hardening the incident-management portion of an ISO 27001:2022 ISMS — whether you're preparing for a Stage 1/Stage 2 audit or shoring up a program that's been coasting on tribal knowledge. By the end, you'll have a concrete incident response plan structure, a defined set of incident-response roles with a RACI matrix, a severity and triage classification scheme you can adapt immediately, a repeatable post-incident review template, and an evidence-handling and chain-of-custody procedure that satisfies both control 5.28 and the forensic realities of litigation and regulatory notification. Every table here is built to be lifted into your own documentation with minor tailoring — this isn't theory, it's the scaffolding I use with clients in the room.
The Real Cost of Winging It
I've sat across the table from a dozen organizations in the first 72 hours of a real incident, and the pattern is remarkably consistent: the technical response is rarely the expensive part. The expensive part is the decisions made — or not made — in the first six hours, before anyone with authority or forensic training is even in the room. The following figures are illustrative, drawn from the pattern of incidents I've observed across mid-market organizations, not a formal industry survey — but the ratios are the point.
Failure Mode in Year One | Illustrative Added Cost | Root Cause |
|---|---|---|
No documented severity/triage scheme | +$180K–$420K | Non-incidents escalated as crises; real incidents under-resourced for days |
No pre-identified IR roles/contacts | +12–48 hours to containment | Decision paralysis; no one empowered to isolate systems or engage counsel |
Evidence collected without chain of custody | Insurance claim denied or reduced 30–70% | Spoliation arguments; inadmissible forensic artifacts |
No post-incident review process | Repeat incident within 6–12 months | Same root cause, same vulnerability, no corrective action tracked |
Notification decision made ad hoc | Regulatory fine escalation | Missed statutory/contractual notification windows (e.g., GDPR's 72-hour clock) |
No tested communication plan | Reputational cost, customer churn | Inconsistent public statements, conflicting timelines |
None of these are hypothetical categories — they map directly onto the five controls this article covers. Controls 5.24–5.28 exist precisely because "we'll figure it out when it happens" is not a plan, and ISO 27001 auditors know exactly what evidence to ask for to find out whether you actually have one.
What makes this frustrating from a consulting seat is that almost none of it is expensive to fix in advance. A documented severity scheme costs a few hours of workshop time. A RACI matrix costs an afternoon and a willingness to name actual people instead of departments. A chain-of-custody template costs less than a single hour of a forensics firm's time — the same firm that will bill you at emergency rates and ask you, mid-crisis, why none of this existed already. The organizations that treat 5.24–5.28 as five checkboxes to satisfy an auditor consistently pay far more, later, than the organizations that treat them as five muscles worth actually building. That distinction is the entire thesis of this article.
Event, Incident, and Breach: A Distinction Auditors Will Test
Before touching the five controls, get this vocabulary locked down — it's exactly the kind of terminology worth pinning to your organization's own copy of an ISO 27001 glossary of key terms so new responders aren't learning it for the first time mid-incident — because ISO 27001 auditors, and your own responders under pressure, will trip over it constantly. ISO/IEC 27000 defines these terms precisely, and control 5.25 exists specifically to formalize the judgment call between the first two.
An information security event is any observed occurrence in a system, service, or network that indicates a possible breach of security policy, failure of controls, or previously unknown situation that may be security-relevant. Events are cheap and constant: a failed login, an antivirus alert, an unusual outbound connection, a user reporting a suspicious email. Most events are noise or low-grade housekeeping.
An information security incident is one or more related and identified events that compromise, or have a significant probability of compromising, business operations and threatening information security. The word "identified" matters — an incident is what an event becomes after someone with the authority to do so has assessed it and decided it meets the bar. That assessment and decision is literally what control 5.25 requires you to have a documented process for.
A breach — specifically a personal data breach — is a legal and regulatory term, most prominently defined under regulations like GDPR, referring to a security incident that results in the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data. Not every information security incident is a breach (a denial-of-service attack on a marketing website with no personal data involved is an incident, not a breach). Not every breach announces itself as dramatically as ransomware — plenty of breaches are a misconfigured cloud storage bucket discovered by a researcher. ISO 27001 does not use the word "breach" as a defined term in Annex A; it's your interested parties — regulators, contractual counterparties, insurers — who impose breach-specific obligations on top of your ISMS.
Term | Definition (Practical) | Who Decides | Typical Trigger | ISO 27001 Control |
|---|---|---|---|---|
Event | An observed occurrence that might be security-relevant | Anyone (reported by staff, tools, or third parties) | Alert, anomaly, user report | 6.8 Information security event reporting (People controls) |
Incident | One or more events confirmed to compromise or threaten operations/security | Trained triage function per documented criteria | Assessment against defined severity/impact criteria | 5.25 Assessment and decision on information security events |
Breach | A confirmed incident involving personal data, triggering legal/contractual notification duties | Legal/DPO function, informed by IR findings | Confirmed unauthorized access/disclosure of personal data | Not an ISO 27001 term — driven by GDPR and similar regimes as interested-party requirements |
Getting this distinction wrong in practice is expensive in both directions. Treat every event as an incident and you burn out your response team and desensitize leadership to real escalations (the security equivalent of crying wolf). Treat every incident as "just an event" and you miss statutory notification clocks, under-invest in containment, and leave evidence uncollected until it's too late. Control 5.25 exists to put a documented, trained, repeatable process between those two failure modes — not a gut call made by whoever's on shift.
It's worth adding a fourth term to this vocabulary that auditors and legal teams both care about: a near-miss, which is an event or attempted attack that was successfully blocked or failed before causing impact — a phishing email reported and blocked before anyone clicked it, or an exploit attempt that failed against a patched system. Near-misses aren't incidents, but control 5.27's learning requirement applies to them just as much as it does to confirmed incidents, because a near-miss is often the cheapest, least painful way to learn about a control gap before it turns into an expensive one. Organizations that only review confirmed incidents and ignore near-misses are leaving a substantial amount of low-cost learning on the table.
"The single most common thing I see in a failed Stage 2 audit around incident management isn't a missing plan — plans are easy to fake on paper. It's an organization that can't show me a single real example of an event that was assessed and not escalated. If everything that gets reported becomes an incident, I know the triage criteria aren't actually being applied." — Dana Whitfield, CISO, Marrow Financial Group (post-incident, reflecting on the program rebuild)
Control 5.24: Information Security Incident Management Planning and Preparation
Control 5.24 is the foundation the other four controls sit on, and it's exactly what Marrow Financial Group didn't have: a plan, roles, responsibilities, and processes established before an incident, not improvised during one. ISO/IEC 27001:2022 requires the organization to plan and prepare for managing information security incidents by defining, establishing, and communicating incident management processes, roles, and responsibilities in advance.
In practice, this means your organization needs a documented incident response plan (IRP) that: defines what counts as an incident and who decides; names roles (not just job titles — actual people and backups) with clear authority to act, including who can isolate a system, who can engage law enforcement, who can authorize paying a ransom demand, and who speaks externally; establishes communication channels and an escalation path that works at 2 AM on a holiday weekend, not just during business hours; and integrates with adjacent processes — event reporting, business continuity, supplier notification obligations, and legal/regulatory requirements. Critically, the plan has to be tested. A document nobody has rehearsed is a document nobody will follow correctly under stress, and auditors increasingly ask for evidence of tabletop exercises or simulations, not just a PDF with a version number.
Requirement | What "Good" Looks Like | Evidence an Auditor Will Ask For | Common Gap |
|---|---|---|---|
Documented incident response plan | Approved, version-controlled IRP covering roles, escalation, communication, and integration with BC/DR | The IRP itself, approval record, revision history | Draft exists but was never formally approved or owned |
Defined roles and responsibilities | Named roles (IR lead, technical lead, comms lead, legal/DPO liaison) with named individuals and backups | RACI matrix, on-call roster, contact list | Roles exist on an org chart but no one has been told what they're accountable for during an incident |
24/7 reporting and escalation mechanism | A single, known channel (hotline, ticketing category, dedicated inbox) staffed or monitored around the clock | Screenshots/config of the reporting channel, escalation runbook | Reporting relies on "email your manager," which fails outside business hours |
Resourcing and tooling readiness | Forensic imaging tools, EDR, logging/SIEM access, and legal/PR contacts pre-arranged | Retainer agreements, tool licenses, access provisioning records | Forensics firm engaged for the first time mid-incident, causing delay and worse rates |
Testing and rehearsal | At least annual tabletop exercises or simulations, with findings tracked to closure | Exercise reports, attendance records, corrective actions | Plan exists but has never been rehearsed against a realistic scenario |
Integration with related processes | Explicit links to 6.8 event reporting, 5.29–5.30 continuity, supplier incident clauses | Cross-references in the IRP, supplier contract language | Plan is a standalone document that ignores continuity and supplier dependencies |
The plan should explicitly reference how information security roles and responsibilities are assigned across the organization, since incident-response roles are a specialized subset of that broader accountability structure, and it should sit alongside your business continuity and ICT readiness arrangements rather than duplicating them — 5.24 governs the security-incident-specific plan, while 5.29–5.30 govern keeping the business and its ICT running through disruption more broadly. If your organization sources any part of detection, response, or hosting from third parties, the plan also needs to reflect the incident-notification clauses baked into supplier relationship security arrangements — you cannot plan your own response if you don't know when a cloud provider or MSSP is obligated to tell you something went wrong on their end.
One practical note from the field: the plan document itself matters less than whether the people named in it can recite their role from memory. I've reviewed 40-page incident response plans that fell apart in the first fifteen minutes of a tabletop because the "designated spokesperson" didn't know they held that role. Keep the plan detailed enough to satisfy an auditor, but build a one-page "first hour" quick-reference card that actually gets pinned up, laminated, or bookmarked — because that's the artifact people reach for while adrenaline is running.
I'd also add a scope note auditors specifically probe for: the plan needs to cover incidents that originate outside normal business hours and outside the primary office location, because that's disproportionately when real incidents happen. Attackers deliberately favor Friday evenings and holiday weekends precisely because they know staffing is thin and decision-makers are unreachable — Marrow Financial Group's incident began at 6:47 PM on a Friday for exactly that reason, and it is not a coincidence you'll see repeated across almost every serious ransomware case a forensics firm handles. A plan that only works Monday through Friday, nine to five, is a plan that fails exactly when it matters most.
Control 5.25: Assessment and Decision on Information Security Events
Control 5.25 is the hinge between "something happened" and "we have an incident." ISO/IEC 27001:2022 requires the organization to assess information security events and decide whether they are to be categorized as information security incidents. This is a judgment process, but it must not be an arbitrary one — the standard expects a documented, consistently applied set of criteria, typically executed by a triage function (a security operations analyst, a designated incident coordinator, or in smaller organizations, a rotating on-call role) trained to make that call within a defined timeframe.
The triage decision typically weighs: confirmed or suspected unauthorized access, disclosure, alteration, or destruction of information; actual or potential impact on confidentiality, integrity, or availability of a defined severity; whether the event is isolated or part of a broader pattern (which is where threat intelligence earns its keep — a single failed login is noise, but a failed login pattern matching a known credential-stuffing campaign reported through your threat intel feed is a different conversation); and regulatory or contractual sensitivity of the affected asset or data. Events flow into this assessment primarily from the people-reporting channel covered under control 6.8 and from automated detection covered under control 8.16, so 5.25 is the control that turns raw signal from both humans and machines into an accountable decision.
Requirement | What "Good" Looks Like | Evidence an Auditor Will Ask For | Common Gap |
|---|---|---|---|
Documented assessment criteria | Defined, published criteria for what elevates an event to an incident (impact, scope, data sensitivity, confidence level) | Triage criteria document, decision matrix | Criteria exist in someone's head, not in writing, and vary by who's on shift |
Trained triage function | Specific individuals authorized and trained to make the event-to-incident call | Training records, role descriptions, sample decisions | Anyone can "call it an incident" or no one feels authorized to, so escalation is inconsistent |
Defined assessment timeframe | Service-level target for how quickly an event must be triaged (e.g., within 30–60 minutes for high-priority alerts) | SLA documentation, ticket timestamps showing time-to-decision | No target exists, so events sit unassessed for hours or days |
Traceable decision record | Every assessed event logged with the outcome (incident / not an incident) and rationale | Event log, ticketing system export, decision audit trail | Decisions aren't recorded, so there's no way to demonstrate the process is actually followed |
Integration with monitoring and threat intel | Assessment considers correlated signals from monitoring tools and external threat intelligence | SIEM correlation rules, threat intel feed integration evidence | Each alert assessed in isolation with no context from other signals |
The most common audit finding I encounter on 5.25 isn't a missing document — it's a log full of events with no visible "not an incident" outcomes. If your event log shows that 100% of reported events became incidents, that's not evidence of a rigorous triage process; it's evidence that the organization doesn't actually distinguish between the two, which is the exact opposite of what this control is designed to demonstrate. Auditors are trained to probe for this, and it's an easy, embarrassing gap to close: start logging the "assessed, not escalated" outcomes with a one-line rationale, and the control comes alive.
"I ask for the event log, not the incident log, in every audit now. Show me the near-misses you decided not to escalate, and show me why. That's where I find out whether triage is a real, working judgment process or just a rubber stamp." — Priya Nair, Data Protection Officer, Vantage Retail Group
Control 5.26: Response to Information Security Incidents
Control 5.26 requires the organization to respond to information security incidents in accordance with the documented procedures established under 5.24. This is the control that governs execution: once 5.25 has confirmed an event is a genuine incident, 5.26 is where containment, eradication, and recovery actually happen — and where the difference between a rehearsed team and an improvising one shows up fastest.
A defensible response procedure typically works through recognizable phases, even if your organization doesn't use this exact terminology: containment (isolating affected systems, revoking compromised credentials, blocking malicious infrastructure — done in a way that preserves evidence rather than destroying it, which is precisely where Marrow Financial Group's administrator went wrong); eradication (removing the root cause — malware, a persistence mechanism, a vulnerable configuration); recovery (restoring systems to normal operation, ideally from known-clean backups, with heightened monitoring during the restoration window); and communication (keeping leadership, affected business units, and — where applicable — regulators, customers, and law enforcement informed on a timeline that satisfies both operational and legal obligations). Response actions and decisions need to be documented in real time, not reconstructed afterward from memory, because that same documentation feeds both control 5.27's learning process and control 5.28's evidentiary chain.
Requirement | What "Good" Looks Like | Evidence an Auditor Will Ask For | Common Gap |
|---|---|---|---|
Documented response procedures | Step-by-step runbooks for common incident types (ransomware, phishing/BEC, data exfiltration, DDoS, insider misuse) | Runbook library, procedure references in the IRP | Generic "call IT" guidance with no incident-type-specific steps |
Timely containment authority | Pre-authorized ability for the technical lead to isolate systems without waiting for a committee | Delegation of authority documentation, incident timeline showing rapid containment | Containment delayed by needing sign-off from an unavailable executive |
Coordinated communication | Defined internal and external communication tracks with approved messaging templates | Communication plan, sample notifications, stakeholder list | Ad hoc, inconsistent messaging that contradicts itself across channels |
Evidence-preserving containment actions | Responders trained to image/preserve before altering (per 5.28) | Training records, incident timeline cross-referenced with evidence log | Systems rebooted, reimaged, or "cleaned" before forensic capture |
Post-response verification | Confirmation that eradication was complete and recovery didn't reintroduce the vulnerability | Verification checklist, vulnerability re-scan results | System returned to service without confirming the root cause was actually closed |
Incident closure and handoff | Formal closure criteria and handoff to the 5.27 learning process | Closure record, sign-off from IR lead | Incidents fade out without formal closure or handoff to review |
Response procedures should also acknowledge that some incidents originate in, or spread through, third-party environments. If a managed security provider or cloud host is part of the affected chain, your response procedure needs a defined interface with the notification and cooperation clauses established under supplier relationship security — you can't contain what you can't see, and you can't see into a supplier's environment without a contractual right to demand cooperation during an active incident.
Practitioner-level frameworks like NIST Special Publication 800-61 (the Computer Security Incident Handling Guide) and the SANS incident response methodology are worth studying here — they offer detailed, battle-tested phase models (Preparation, Detection & Analysis, Containment/Eradication/Recovery, Post-Incident Activity) that map cleanly onto ISO 27001's controls. It's worth being precise about what these frameworks are, though: they are practitioner references and industry good practice, not ISO 27001 requirements. ISO 27001 doesn't mandate NIST's phase names or SANS's specific checklists — it mandates that you have a documented, planned, tested response process. Borrowing NIST's or SANS's structure is a smart implementation choice, not a compliance obligation.
Control 5.27: Learning from Information Security Incidents
Control 5.27 requires the organization to use knowledge gained from information security incidents to strengthen and improve controls, reducing the likelihood or impact of future incidents. This is the control most often treated as optional in practice and most heavily weighted by a good auditor, because it's the clearest signal of whether an ISMS is actually a management system — one that learns and adapts — or just a folder of policies.
In practice, 5.27 requires a formal post-incident review (sometimes called a post-mortem or lessons-learned review) after every significant incident, producing documented findings and, critically, tracked corrective actions that feed into the same continual-improvement mechanism required more broadly under Clause 10's improvement and corrective action requirements. A lessons-learned document that sits in a folder and is never referenced again is not evidence of learning — evidence of learning is a control that changed, a training program that was updated, or a policy that was revised, each traceable back to a specific incident.
Requirement | What "Good" Looks Like | Evidence an Auditor Will Ask For | Common Gap |
|---|---|---|---|
Post-incident review conducted | Formal review held within a defined window after incident closure (commonly 5–10 business days) | Review meeting record, attendee list, findings document | Reviews happen informally, if at all, with no written output |
Root cause identified | Technical and process root causes distinguished from symptoms | Root cause analysis documentation | Review stops at "phishing email clicked" without asking why controls didn't catch or contain it |
Corrective actions tracked to closure | Findings converted into tracked actions with owners and due dates | Corrective action register, closure evidence | Findings listed but never assigned an owner or a deadline |
Trends analyzed across incidents | Periodic aggregate review of incident data to spot recurring patterns | Trend report, management review input | Each incident reviewed in isolation; no pattern analysis across a quarter or year |
Feedback into risk assessment and controls | Incident findings feed back into the risk register and control updates | Updated risk register entries referencing specific incidents | Risk register never revisited after incidents that clearly changed the threat picture |
Learning shared appropriately | Relevant lessons communicated to affected teams, and where appropriate, leadership | Awareness communications, training updates | Lessons stay with the IR team and never reach the broader organization |
I've watched this control single-handedly separate mature ISMS programs from paper-only ones. An organization that suffered three phishing-triggered incidents in a year and can show me how each review changed something — tightened email filtering, added MFA to a previously exempt system, updated new-hire security training — is demonstrating exactly what Clause 10 and control 5.27 are built to produce. An organization that suffered the same three incidents and produced three nearly identical "lessons learned" documents with no visible changes to controls is demonstrating the opposite, and that pattern is one of the fastest ways to trigger a major nonconformity in a Stage 2 or surveillance audit.
"We had the same credential-stuffing incident twice in four months before anyone connected the dots. The second post-incident review is where we finally asked why the first one didn't change anything. That review is the reason we have adaptive MFA today, not the incident itself." — Tom Reyes, VP of Engineering, NorthBridge Logistics
Control 5.28: Collection of Evidence
Control 5.28 requires the organization to establish and apply procedures for the identification, collection, acquisition, and preservation of evidence related to information security events — evidence that may be needed for internal analysis, disciplinary action, legal proceedings, regulatory investigations, or insurance claims. This is the control Marrow Financial Group violated without anyone realizing it in the moment, and it is, in my experience, the control most likely to be under-documented even in organizations that otherwise run a tight incident response program.
The core requirement is a documented chain of custody: from the moment evidence is identified (a disk, a memory dump, a log file, an email, a badge-access record) through collection, acquisition (typically a forensically sound image or hash-verified copy), storage, and eventual use or disposal, every transfer of custody, every access, and every action taken on the evidence needs to be recorded, time-stamped, and attributable to a named individual. The standard for "forensically sound" isn't a matter of ISO 27001 opinion — it's set by what will hold up if the evidence ends up in a courtroom, a regulatory hearing, or an insurance dispute, which means integrity (cryptographic hashing before and after acquisition), a documented and unbroken custody trail, and preservation methods appropriate to the type of evidence (write-blockers for physical media, memory-capture tools that don't themselves contaminate the system, log exports that include metadata proving they weren't altered).
Requirement | What "Good" Looks Like | Evidence an Auditor Will Ask For | Common Gap |
|---|---|---|---|
Documented evidence-handling procedure | Written procedure covering identification, collection, acquisition, and preservation for common evidence types | Evidence-handling SOP, tool list | No procedure exists; responders "figure it out" during the incident |
Chain-of-custody documentation | Every access/transfer logged with who, what, when, and why | Chain-of-custody forms/logs for a sample incident | Evidence collected but no log of who touched it or when |
Integrity verification | Cryptographic hashing (e.g., SHA-256) of images/copies at collection and at each subsequent access | Hash values recorded alongside evidence | Copies made with no hash verification, undermining claims of integrity |
Trained evidence handlers | Responders trained specifically in forensically sound collection, not just general IT skills | Training records, certifications (e.g., forensics training) | First responders are general IT staff with no forensic training, acting before specialists arrive |
Secure evidence storage | Access-controlled, logged storage (physical evidence locker or access-restricted digital repository) | Storage access logs, physical security controls | Evidence stored on a shared drive with broad access |
Legal/regulatory alignment | Procedures account for jurisdiction-specific admissibility and retention requirements | Legal review of evidence procedures | No legal input into how evidence is handled, discovered only after the fact matters |
It's also worth building your evidence procedure with an eye toward legal hold, a concept borrowed from litigation practice that's easy to overlook until outside counsel asks for it mid-incident. A legal hold suspends normal data-retention and deletion schedules for anything that might become evidence, and it needs to be issued quickly — often within the first day or two of a serious incident — and communicated clearly to IT operations so that routine log rotation, backup expiration, or device decommissioning doesn't inadvertently destroy something that later turns out to matter. Building the legal-hold trigger into your 5.24 plan, rather than improvising it after counsel gets involved, closes one more gap between "we have an evidence procedure" and "we actually preserved everything relevant."
The practical lesson from Marrow is worth restating plainly: the instinct to "clean up" a compromised system — reboot it, run a scanner, reimage it — is often the single most damaging action a well-meaning but untrained responder can take, because it destroys volatile evidence (memory contents, active network connections, running processes) permanently and irreversibly, before anyone with forensic training has had a chance to capture it. The fix isn't heroics; it's a simple, memorized rule embedded in your response runbooks: isolate, don't interact — disconnect from the network at the switch or firewall level where possible, leave the system powered on and untouched, and call the person trained to do forensic acquisition. That single behavioral change, drilled into every IT and helpdesk employee, prevents the majority of evidence-spoliation failures I've seen in the field.
"Every tabletop exercise I run ends with the same fifteen minutes on evidence, because it's the thing people forget under pressure. Your instinct to fix the problem is exactly the instinct that destroys your ability to prove what the problem was." — Elena Vasquez, Digital Forensics Consultant, BlackPine Cyber Partners
Building a Severity and Triage Classification Scheme
Control 5.25 requires assessment criteria, but it doesn't hand you a severity scale — you have to build one, calibrated to your organization's risk appetite and the assets you actually have. A severity scheme is what turns "assess the event" from an abstract instruction into a five-minute decision anyone on the triage rotation can make consistently. I recommend a four-tier scheme, illustrated below, because more than four tiers tends to create arguments about boundary cases during an actual incident, and fewer than four collapses genuinely different response postures into one bucket.
Severity | Illustrative Definition | Example Trigger | Response Time Target | Who's Notified |
|---|---|---|---|---|
SEV-1 (Critical) | Confirmed compromise of critical systems, large-scale data exfiltration, or ransomware with business-wide impact | Ransomware encrypting production systems; confirmed exfiltration of regulated personal data at scale | Immediate (within 15–30 minutes of confirmation) | Executive leadership, legal/DPO, IR team, board (per policy), possibly regulators/law enforcement |
SEV-2 (High) | Significant but contained compromise; single system or limited dataset affected; clear potential to escalate | Compromised privileged account with evidence of lateral movement attempt; confirmed malware on a server handling sensitive data | Within 1 hour | IR lead, technical lead, department head, legal/DPO on standby |
SEV-3 (Moderate) | Limited-scope incident with contained or low-sensitivity impact | Isolated malware infection on a single endpoint with no evidence of spread; successful phishing click with credentials reset before misuse | Within 4 business hours | IR lead, affected department, IT operations |
SEV-4 (Low) | Minor incident or a confirmed non-incident event requiring routine handling | Blocked phishing attempt with no user interaction; policy violation with no security impact | Within 1 business day | Logged and handled by IT operations; no broad notification required |
Two calibration notes from experience. First, severity should be driven by potential business impact and data sensitivity, not by how technically interesting the incident is — a "boring" credential-stuffing attempt against an account with access to your customer database is a higher severity than an exotic zero-day proof-of-concept that never touched a production system. Second, build in an explicit escalation path for reclassification: incidents frequently start as SEV-3 and become SEV-1 once scope becomes clear, and your scheme needs to make re-triage a normal, expected event rather than an embarrassing reversal nobody wants to call out loud.
Incident Response Roles: Who Does What (RACI)
Control 5.24 requires defined roles and responsibilities, and the fastest way to turn that requirement into something usable during a real incident — rather than an org chart nobody consults at 2 AM — is a RACI matrix mapped against the actual phases of incident handling. This builds directly on the broader accountability structure your organization already documents for information security roles and responsibilities, narrowed to incident-specific decision rights.
Activity | IR Lead | Technical Lead | Legal/DPO | Communications Lead | Executive Sponsor | IT Operations |
|---|---|---|---|---|---|---|
Declare incident (per 5.25 criteria) | A/R | C | I | I | I | C |
Authorize containment actions | A | R | I | – | I | R |
Forensic evidence collection | A | R (or delegates to forensics specialist) | C | – | I | C |
Determine notification obligations | C | I | A/R | C | I | – |
External communications (customers, press) | C | – | C | A/R | A | – |
Regulatory/law enforcement liaison | C | I | A/R | I | I | – |
Ransom payment decision (if applicable) | C | I | C | I | A/R | – |
Post-incident review facilitation | A/R | R | C | I | I | R |
Corrective action tracking (feeds 5.27/Clause 10) | A/R | R | I | – | I | R |
(R = Responsible, A = Accountable, C = Consulted, I = Informed)
The most important cell in that table, in my experience, is "Authorize containment actions." Every incident I've watched go badly in the first hour had the same root problem: the person with the technical ability to isolate a system didn't have — or didn't believe they had — the authority to do it without checking with someone unavailable. Pre-authorizing your technical lead to contain first and explain afterward, within defined boundaries, is one of the cheapest and highest-leverage decisions an organization can make before an incident happens, and it belongs explicitly in your 5.24 plan, not left implicit.
Tooling That Supports Controls 5.24–5.28
None of these five controls require a specific technology stack — ISO 27001 is control-outcome-focused, not tool-prescriptive — but in practice, certain categories of tooling make the difference between a plan that works on paper and one that works at 2 AM. It's worth mapping tooling categories against the control they primarily support, both for your own implementation planning and because auditors increasingly ask what systems generate the evidence you're presenting.
Tooling Category | Primary Control(s) Supported | What It Provides | Illustrative Examples of Function |
|---|---|---|---|
Ticketing / case management | 5.24, 5.25, 5.26 | Structured incident records, timestamps, assignment, and status tracking | Dedicated incident ticket queue separate from general IT helpdesk tickets |
SIEM / log aggregation | 5.25 (assessment), feeds 8.16 monitoring | Correlated alerts and historical log data to support the event-to-incident decision | Correlation rules that flag patterns matching known attack techniques |
SOAR (security orchestration, automation, and response) | 5.26 | Automated or semi-automated containment actions (account disable, network isolation) executed consistently | Playbooks that execute the same containment steps every time, reducing human error under pressure |
EDR / endpoint detection and response | 5.25, 5.26 | Detection, isolation, and some evidence capture at the endpoint level | Network-isolate-but-preserve capability that avoids the "reboot and scan" mistake |
Forensic imaging and memory capture tools | 5.28 | Forensically sound disk and memory acquisition with built-in hashing | Write-blocked imaging tools, memory capture utilities that don't modify the source system |
Secure evidence repository | 5.28 | Access-controlled, logged storage with retention and legal-hold capability | Write-once or access-audited storage separate from general file shares |
Communication/notification platform | 5.24, 5.26 | Reliable out-of-band communication if primary systems are compromised | A communication channel that doesn't depend on the potentially-compromised corporate email system |
The single most common tooling gap I find isn't a missing SIEM or EDR platform — most organizations past a certain size have those. It's the absence of an out-of-band communication channel. If your primary incident communication method is corporate email or a chat platform hosted on the same infrastructure that might be compromised, you have a single point of failure baked into your response plan. A pre-agreed backup channel — a separate messaging app, a phone tree, even a simple shared document on independent infrastructure — is a small investment that prevents a genuinely common failure mode during serious incidents.
Metrics That Prove the Program Actually Works
Auditors increasingly ask not just "do you have a plan" but "how do you know it's working," and control 5.27's learning requirement all but demands a metrics conversation. Tracking a small set of consistent metrics over time gives you both audit evidence and a genuinely useful management dashboard.
Metric | What It Measures | Why It Matters | Illustrative Healthy Range |
|---|---|---|---|
Mean time to detect (MTTD) | Time from compromise/event occurrence to detection | Shorter MTTD limits attacker dwell time and data exposure | Hours to low single-digit days, depending on maturity |
Mean time to triage (per 5.25) | Time from event report to incident/non-incident decision | Demonstrates the assessment process is functioning at the speed your severity scheme requires | Minutes for SEV-1/2 candidates; hours for lower severity |
Mean time to contain (MTTC) | Time from incident declaration to effective containment | Directly correlates with breach scope and cost | Under a few hours for well-rehearsed teams |
Percentage of incidents with completed post-incident review | Adherence to control 5.27 | A proxy for whether learning is actually happening, not just claimed | Should trend toward 100% for SEV-1/2 incidents |
Percentage of corrective actions closed on time | Follow-through on 5.27 findings | Distinguishes real learning from documented-but-ignored lessons | High compliance (85%+) signals a functioning improvement loop |
Repeat-incident rate (same root cause) | Whether lessons are actually changing outcomes | A rising or flat repeat rate despite completed reviews signals reviews aren't producing real fixes | Should decline over successive quarters |
Evidence chain-of-custody exceptions | Gaps or breaks found during evidence handling review | Directly measures 5.28 procedural adherence | Should trend toward zero exceptions per incident |
These metrics matter most in aggregate, over quarters, not as a report card for any single incident — a single incident can go long for entirely defensible reasons (a genuinely novel attack technique, a complex multi-system compromise). What an auditor, and frankly your own leadership, should care about is the trend line: is your organization getting measurably better at detecting, triaging, containing, and learning from incidents over time, or is every incident a surprise that gets handled from scratch.
The Incident Response Lifecycle, End to End
Controls 5.24–5.28 aren't five isolated requirements — they're five points on a single continuous lifecycle, and it helps to see them as a loop rather than a checklist. Detection and reporting sit outside this article's five controls but feed directly into it: human-reported events arrive through information security event reporting, control 6.8, and tool-detected anomalies arrive through monitoring activities, control 8.16. Evidence collection under 5.28 doesn't happen as a discrete step after response — it runs in parallel with containment and response from the earliest possible moment, which is exactly the point Marrow Financial Group's Friday-night administrator missed.
flowchart LR
A["Prepare\n(5.24 — plan, roles, procedures)"] --> B["Detect & Report\n(6.8 event reporting / 8.16 monitoring)"]
B --> C["Assess & Decide\n(5.25 — event or incident?)"]
C -- "Not an incident" --> B
C -- "Confirmed incident" --> D["Respond\n(5.26 — contain, eradicate)"]
D --> E["Recover\n(restore operations)"]
E --> F["Learn\n(5.27 — post-incident review)"]
F --> A
D -. "runs in parallel" .-> G["Collect & Preserve Evidence\n(5.28 — chain of custody)"]
B -. "preserve from first contact" .-> G
G -. "feeds" .-> FLifecycle Phase | Primary Control(s) | Key Output | Feeds Into |
|---|---|---|---|
Prepare | 5.24 | Approved IRP, trained roles, tested procedures | Every subsequent phase |
Detect & Report | 6.8, 8.16 (referenced, not covered in depth here) | Logged event with initial detail | Assessment |
Assess & Decide | 5.25 | Documented incident/non-incident decision | Response (if incident) or event log (if not) |
Respond (contain/eradicate/recover) | 5.26 | Restored, verified-clean operations | Post-incident review |
Collect & Preserve Evidence | 5.28 | Chain-of-custody documented evidence | Response decisions, legal/regulatory action, review |
Learn | 5.27 | Root cause findings, tracked corrective actions | Risk register, Clause 10 improvement, next "Prepare" cycle |
Notice that the loop closes back into "Prepare" — this is the detail that separates ISO 27001's approach from a purely reactive incident-handling capability. Every completed incident should measurably change your plan, your training, or your controls before the next one happens. If your post-incident reviews never touch the 5.24 plan itself, the loop isn't actually closing. Organizations that also map their program against NIST CSF's Respond and Recover functions tend to find the two frameworks reinforce each other well, since NIST CSF's function-based language and ISO 27001's control-based structure are describing largely the same operational capability from different angles.
Evidence Handling and Chain of Custody: The Procedure in Practice
Control 5.28's requirements table earlier in this article covers what an auditor checks for; this section covers how to actually build the procedure, because "chain of custody" is one of those phrases everyone nods along to and few organizations operationalize correctly. The procedure needs to specify handling by evidence type, since a memory dump, a physical hard drive, and an email header require different acquisition methods and different custody considerations.
Evidence Type | Collection Method | Integrity Control | Storage Requirement | Typical Retention |
|---|---|---|---|---|
Volatile memory (RAM) | Live memory capture tool run before any reboot | Hash of the memory image recorded immediately | Encrypted, access-logged evidence repository | Per legal hold or incident closure + defined period |
Disk/storage media | Forensic imaging with a write-blocker; never work from the original | SHA-256 hash of image compared against original at acquisition | Original media sealed and logged in evidence storage; work only from verified copies | Per legal hold; originals retained until litigation/regulatory matters close |
Network logs / firewall logs | Export with metadata intact (timestamps, source system) | Log export hash recorded; access to source logs restricted during investigation | Access-controlled log repository, ideally write-once | Aligned with logging retention policy and legal hold |
Email / communications | Full-header export preserving metadata, not just message body | Export hash recorded; custodian identified | Access-controlled repository | Per legal hold or regulatory retention requirement |
Physical evidence (devices, badges, printed material) | Bagged, labeled, and logged at point of seizure | Signed custody log at every transfer | Locked, access-logged physical evidence storage | Per legal hold or investigation closure |
Every row in that table implies the same underlying discipline: a documented custody log that records who collected the evidence, when, from where, what tool was used, the resulting hash value, and every subsequent access or transfer — including the reason for that access. When a forensics firm, outside counsel, or a regulator later asks "how do you know this evidence wasn't altered," the answer has to be the log, not someone's recollection. This is also the point where it's worth flagging, without overstating it, that dedicated content on digital forensics and evidence handling goes deeper into tool selection and forensic methodology than a control-mapping article like this one can.
"Chain of custody isn't paperwork for its own sake — it's the difference between 'we believe the attacker accessed these records' and 'we can prove, to an evidentiary standard, exactly what the attacker touched and when.' Insurers and regulators react very differently to those two sentences." — Marcus Cole, Founder, Cole Security Advisory
A Post-Incident Review Template You Can Use Tomorrow
Control 5.27 doesn't prescribe a template, so most organizations either skip the review entirely or reinvent one badly every time. Here's a structure that consistently produces usable findings, built around the same sections I use when facilitating these reviews with clients.
Section | Purpose | Key Questions to Answer |
|---|---|---|
Incident summary | Establish shared facts before analysis begins | What happened, when was it detected, when was it declared, when was it closed? |
Timeline reconstruction | Identify delays and decision points | Where did time get lost between detection, assessment, and containment? |
Root cause analysis | Distinguish symptom from cause | What control gap or failure allowed this to happen? Why did existing controls not prevent or catch it sooner? |
Response effectiveness | Evaluate the response itself, not just the incident | Did the plan's roles, procedures, and communication work as designed? Where did people deviate, and why? |
Evidence handling review | Confirm 5.28 procedures were followed | Was chain of custody maintained? Were there any gaps in evidence collection? |
Impact assessment | Quantify business, regulatory, and reputational impact | What was the actual cost/downtime/data impact, and how does it compare to the severity classification assigned? |
Corrective actions | Convert findings into tracked commitments | What specific control, process, or training change will prevent recurrence, who owns it, and by when? |
Trend/pattern check | Connect this incident to prior ones | Have we seen this root cause before? Did a prior corrective action fail to hold? |
The section most often skipped is "Response effectiveness," because it requires reviewing your own team's performance, not just the attacker's actions — and that can feel uncomfortable in a blame-averse culture. It's the section that produces the most valuable corrective actions, though, because incident response plans that are never critiqued against a real event tend to calcify into documents that look good and perform badly.
Regulatory and Contractual Notification: An Interested-Party Requirement, Not an ISO Requirement
This is worth stating plainly because it's a frequent point of confusion: ISO/IEC 27001 does not itself impose breach-notification deadlines. What it requires, through control 5.24's planning obligation and the organizational controls covering legal, statutory, regulatory, and contractual requirements documented across the broader Annex A organizational controls, is that your organization identifies the notification obligations that apply to it and builds them into its incident response planning and decision-making — with the applicable controls and their notification implications recorded in your Statement of Applicability. The actual deadlines and thresholds come from external regimes — regulators, contracts, and industry frameworks such as GDPR's 72-hour breach notification requirement — that your ISMS has to account for, not originate.
Regime / Framework | Notification Trigger | Typical Timeframe | Nature of Obligation |
|---|---|---|---|
GDPR (EU/UK) | Personal data breach likely to result in risk to individuals | 72 hours to supervisory authority; "without undue delay" to affected individuals if high risk | Legal — external to ISO 27001, an interested-party requirement your ISMS must plan around |
U.S. state breach notification laws | Unauthorized access/acquisition of specified personal information categories | Varies by state, commonly 30–60 days; some states shorter | Legal — jurisdiction-specific |
Sector regulators (financial, healthcare, etc.) | Incidents affecting regulated systems or data | Varies (often 24–72 hours for initial notice) | Legal/regulatory — sector-specific |
Cyber insurance policy terms | Incident meeting policy-defined criteria | Often 24–72 hours to preserve coverage | Contractual |
Customer/partner contracts | Incident affecting shared systems or data | As negotiated, often 24–72 hours | Contractual |
Security incidents affecting the service commitments in scope | Defined by the service organization's own policies, evaluated during a SOC 2 examination | Cross-framework — relevant if you hold or pursue SOC 2 attestation alongside ISO 27001 |
The practical takeaway is to build a single notification-obligation matrix as part of your 5.24 planning artifacts, mapping every applicable regime and contract to its trigger and clock, so that when an incident is declared under 5.25, the legal/DPO role in your RACI matrix can start every relevant clock simultaneously rather than discovering obligations one at a time under pressure — which is precisely the mistake that turned Marrow Financial Group's already-bad week into a regulatory enforcement action.
Common Mistakes I See Across Incident Management Programs
Mistake | Why It Happens | Consequence | Fix |
|---|---|---|---|
Plan exists but was never rehearsed | Documentation treated as the deliverable, not the capability | Roles freeze or improvise under real pressure | Run at least one realistic tabletop exercise annually with findings tracked to closure |
No clear containment authority | Fear of unilateral action without executive sign-off | Delayed containment, wider blast radius | Pre-authorize technical leads to contain within defined boundaries |
First responders "clean up" before evidence capture | Untrained instinct to fix the visible problem | Spoliated evidence, denied insurance claims, weakened regulatory position | Train all IT/helpdesk staff on "isolate, don't interact" and escalate to trained evidence handlers |
Severity scheme too granular or nonexistent | Overengineering, or never getting around to building one | Inconsistent escalation, alarm fatigue or under-response | Adopt a simple 3–4 tier scheme calibrated to business impact |
Post-incident reviews produce no tracked changes | Blame-averse culture, no ownership assigned to findings | Repeat incidents from the same root cause | Assign named owners and due dates to every corrective action; track in the same register used for Clause 10 |
Notification obligations discovered mid-incident | No pre-built mapping of legal/contractual triggers | Missed statutory clocks, regulatory penalties | Build and maintain a notification-obligation matrix as part of 5.24 planning |
Evidence stored without access controls | Evidence handling treated as an afterthought to technical response | Chain-of-custody challenged in legal/regulatory proceedings | Dedicated, access-logged evidence storage with a documented custody procedure |
Incident data never reaches the risk register | Incident management and risk management run as separate silos | Risk assessments stay stale despite real-world evidence of new threats | Formal handoff from post-incident review to risk register update |
Case Study: Contoso Health Systems Contains a BEC Attempt in Six Hours
Contoso Health Systems (fictional, ~600 employees, a regional healthcare network) built its incident management program around controls 5.24–5.28 eighteen months before a business email compromise attempt hit their finance department. An attacker, having compromised a vendor's email account, sent a convincing invoice-change request to accounts payable. The AP clerk who received it did something Marrow's administrator never had the chance to do: she followed a documented reporting step under control 6.8, flagging the email through the dedicated security reporting button rather than acting on it or ignoring it.
The triage analyst on duty assessed the report against Contoso's documented 5.25 criteria within twenty minutes, cross-referenced it against a threat intelligence advisory about a wave of vendor-impersonation BEC attempts (surfaced through their threat intelligence program under control 5.7), and declared a SEV-2 incident. The pre-authorized technical lead froze the pending payment, reset credentials for the compromised vendor relationship in Contoso's vendor portal, and looped in legal within the hour per the RACI matrix. Total time from report to full containment: six hours, entirely inside a single business day, with zero funds actually transferred. The post-incident review, conducted five days later, produced one concrete corrective action — a secondary verification call requirement for any vendor banking-detail change above $10,000 — which has since prevented two further attempts using the same technique. Illustrative avoided loss, based on the invoice amount in question: approximately $1.8 million.
Case Study: NorthBridge Logistics Breaks a Recurring Incident Pattern
NorthBridge Logistics (fictional, a mid-market freight and warehousing company) suffered three separate credential-compromise incidents within eight months — each one resolved individually without anyone connecting them. It was the third post-incident review, conducted properly under control 5.27, that finally asked the question the first two reviews hadn't: why does the same root cause keep producing new incidents? The answer was a legacy remote-access portal exempted from multi-factor authentication for "compatibility reasons" that had never been revisited.
The corrective action from that third review — decommissioning the legacy portal and requiring adaptive MFA across all remote access — was tracked to closure within six weeks and fed directly into an update of NorthBridge's risk register, closing a risk entry that had been sitting at "accepted" status for over two years. In the twelve months since, NorthBridge has recorded zero credential-compromise incidents of the same type, down from three in the prior eight months — an 80%+ reduction against the recurring pattern once the actual root cause was addressed rather than each symptom individually.
Case Study | Root Failure / Success Factor | Time to Containment | Illustrative Financial Outcome |
|---|---|---|---|
Marrow Financial Group (cold open) | No plan, no triage scheme, evidence destroyed by untrained first responder | ~30 hours to engage forensics; full scope unknown for weeks | $4.2M total documented cost (ransom, fines, litigation, remediation) |
Contoso Health Systems | Trained reporting, fast triage, pre-authorized containment, threat intel correlation | 6 hours, report to full containment | ~$1.8M in attempted fraud avoided |
NorthBridge Logistics | Post-incident review connected a recurring pattern the prior two reviews missed | Recurring incidents eliminated within 6 weeks of root-cause fix | 80%+ reduction in repeat incidents; closed a two-year-stale accepted risk |
"The thing that changed our program wasn't the incident itself — Contoso's had dozens of phishing attempts before that one. It was having a trained analyst who could make the incident call in twenty minutes instead of two days, because the criteria were already written down." — Raj Patel, Incident Response Lead, Contoso Health Systems
Turning Incident Readiness Into a Business Advantage
It's tempting to treat controls 5.24–5.28 as a compliance checkbox — a plan to file away, a severity scale to publish, an evidence procedure to document once and forget. That's a mistake, and not just because auditors will catch it. Incident management maturity is one of the few areas of an ISMS that customers, insurers, and partners can actually see the value of in real time, because it directly determines how a bad day turns out. A prospective enterprise customer's security questionnaire increasingly asks not just "do you have an incident response plan" but "when did you last test it, and what did you learn." A cyber insurer's underwriting questionnaire asks the same thing, and increasingly prices premiums on the answer. A regulator investigating an incident treats a well-documented, evidence-preserving response as a mitigating factor, not a formality.
The organizations I've watched turn this from a burden into an advantage are the ones that stop thinking about 5.24–5.28 as five separate audit line items and start treating them as one operational muscle: plan it, rehearse it, run it for real when needed, learn from it every single time, and protect the evidence trail like it's the organization's legal defense — because eventually, it will be. Marrow Financial Group rebuilt exactly this muscle after their $4.2 million lesson; Contoso and NorthBridge built it before they needed it and it paid for itself the first time it mattered.
There's a broader point buried in all three of this article's stories: none of Marrow, Contoso, or NorthBridge needed a bigger security budget to get this right. Marrow had firewalls, EDR, and cyber insurance and still lost $4.2 million. Contoso's advantage over Marrow wasn't better technology — it was a documented triage process, a pre-authorized technical lead, and a trained employee who knew to report rather than guess. NorthBridge's fix wasn't a new tool — it was a post-incident review that finally asked the right question the third time around. Controls 5.24–5.28 are, more than almost any other cluster in Annex A, a discipline problem before they're a technology problem, which is exactly why they're so achievable for organizations of any size once leadership decides to actually own them.
If you're building or auditing this part of your ISMS, start by pulling your current incident response documentation against the requirement tables in this article, and use PentesterWorld's ISO 27001 Mandatory Documents Checklist to confirm your incident management plan, roles, and evidence procedures are complete and audit-ready. Pair it with the Annex A — All 93 Controls at a Glance cheat sheet to see exactly how 5.24–5.28 sit alongside the rest of your Statement of Applicability, and if you're still mapping out your broader implementation roadmap, The Complete ISO 27001 Implementation Guide walks through sequencing incident management against the rest of your ISMS build. For teams that need to translate incident findings into a living risk picture, our ISO 27001 Risk Register Template is built to accept post-incident review outputs directly, and our Internal Audit Checklist includes the exact sample questions an internal auditor should be asking about 5.24–5.28 before your certification body ever does.
Incident management done well doesn't prevent every bad day. It determines whether your bad day costs you a case study you tell proudly in a sales call, or a $4.2 million lesson you spend eighteen months explaining to regulators, insurers, and a courtroom.