Incident Response: The Plan You Need at 3 A.M.

It’s 3:17 on a Tuesday morning when the page fires. Part 3’s SIEM feed — the one you built for the enterprise customer’s SOC — has flagged an export job running against forty tenants from a session that doesn’t look like any of their admins. The alert has fired a hundred times before and been noise ninety-nine of them. This time it’s not. Everything this series has built so far exists for this night: the controls from Parts 1 through 4 are the prevention, the SOC 2 report from Part 5 is the promise. Incident response is what happens between the promise and the proof.

The uncomfortable premise of this part: you will have this night. Palo Alto’s Unit 42 responded to over 750 major incidents last year and found that in more than 90% of them, the breach was enabled by preventable gaps — limited visibility, inconsistently applied controls, excessive identity trust — not by attacker brilliance. The question was never whether your controls are perfect. It’s whether the organization that wakes up at 3:17 A.M. has rehearsed what to do next, or is inventing it live.

The clock started before you knew

The first thing to understand about breach response in 2026 is that it runs on legal clocks, and the clocks are unforgiving about when they start: at awareness, not at certainty, not at containment:

• 24 hours — NIS2’s early warning and DORA’s initial notification (DORA applies to EU financial entities and their ICT providers since January 2025). The early warning doesn’t require answers; it requires the humility to say “something happened, details to follow.”
• 72 hours — GDPR’s authority notification, the deadline that defined modern breach response. The EU’s Digital Omnibus proposal would stretch this to 96 hours and merge GDPR, NIS2, and DORA filings into a single portal, but that’s a proposal aimed at mid-2027 — the 72-hour rule is what you rehearse for today. GDPR filings crossed 400 per day in 2025; regulators can tell a practiced notification from a panicked one.
• 4 business days — the SEC’s material-incident disclosure, now in active enforcement. “Material” is doing heavy lifting in that sentence, and the determination itself must be defensible.
• Coming — CIRCIA’s final rules, expected late 2026, add 72-hour incident and 24-hour ransomware-payment reporting for US critical infrastructure. The direction everywhere is shorter clocks, more sectors, personal accountability — NIS2 makes boards responsible.

And behind the legal clocks runs a worse one: the attacker’s. IBM’s 2025 numbers put the average breach lifecycle at 241 days — 181 to identify, 60 to contain. The 72-hour GDPR clock starts when you notice; the attacker, on average, has been inside for six months. Unit 42 adds the mechanism: identity played a material role in nearly 90% of their investigations — attackers increasingly log in with stolen credentials and tokens rather than break in — and data from SaaS applications was relevant to 23% of their cases, up from 18% the year before. You are the SaaS application in someone else’s statistic.

The first hour decides the postmortem

Every retrospective on a badly handled incident traces the damage to the first hour — not the technical complexity of the breach, but the improvisation at the start. The sequence that works is short enough to fit on one page, which is exactly where it should live:

1. Declare — someone says “this is an incident” and becomes the incident commander. Not a committee, not a Slack thread with seventeen opinions: one person with the authority to wake anyone, spend anything, and make the call to pull a system offline. The most common first-hour failure is the hour spent wondering if it’s real.
2. Move comms out-of-band — if the incident involves credentials or email, assume your normal channels are read by the attacker. A pre-registered fallback (a separate chat workspace, a phone tree) decided now, not during.
3. Preserve before you touch — the instinct to shut down, wipe, and rebuild destroys the evidence that answers the questions regulators and customers will ask: when did it start, what was taken, how. Snapshot the disk, export the logs, then remediate. This is where Part 3’s architecture pays for itself: hash-chained, tenant-scoped audit events mean your timeline is evidence, not recollection — and it can be shown to a regulator without trusting your own word.
4. Scope by tenant — the multi-tenant discipline from Part 1 becomes your blast-radius query: every event carries tenant_id, so “which customers are affected” is a SELECT, not a panic. The difference between “one tenant’s compromised API key” and “platform incident” is the difference between a Tuesday and a quarter.
5. Contain — now you act: revoke the sessions and tokens (Part 2’s inventory of credential types is suddenly the checklist), rotate the secrets, isolate the segment. Containment that starts at step five is fast; containment attempted at step one is thrash.

Containment is a business decision

The textbook says eradicate and recover. Reality adds a wrinkle: sometimes you watch. If the attacker doesn’t know they’ve been detected, immediate eviction can tip them off before you’ve scoped the full access — and they’ll return through the second door you hadn’t found yet. The alternative — quietly monitoring an active intruder — is a decision involving legal counsel, customer obligations, and risk appetite. That is precisely why it cannot be made by an engineer alone at 4 A.M. The IR plan’s job is to pre-authorize who makes that call and with what information, so the 4 A.M. engineer’s job is to escalate, not to gamble.

The same logic applies outward. Customer notification, status-page updates, the regulator filing, the cyber-insurance hotline (call it early — many policies require it before costs count), law enforcement — each is a pre-drafted template and a pre-assigned owner. IBM’s data adds a number to the last one: involving law enforcement correlates with $990K lower breach costs. Templates drafted on a calm afternoon are clear and accurate; templates drafted during an incident are neither, and they go out under your logo anyway.

The plan is the cheapest control you own

Here is the most striking number in IBM’s 2025 report: a tested incident response plan correlates with $2.66M lower cost per breach — the single largest cost reducer they measure, ahead of AI tooling, ahead of zero trust. Not a perfect plan. A tested one. The mechanism is no mystery: breaches contained within 200 days cost $3.87M on average; beyond that, $5.01M. Speed is worth $1.14M, and speed comes from rehearsal, not heroics. Breaches identified by internal teams resolve fastest of all — your own monitoring finding your own incident is the best-case scenario money can buy.

“Tested” means tabletop exercises — gather the people who would actually be paged, narrate a scenario (“a contractor’s token with production read access just appeared in a public gist”), and walk the first hour out loud. Every real exercise surfaces something embarrassing: the fallback channel nobody can log into, the customer-notification owner who left the company, the runbook referencing a tool you migrated off. An hour of embarrassment per quarter is the entire cost of finding these on a Tuesday instead of at 3 A.M.

And this closes the loop with Part 5: incident response is a SOC 2 control family (CC7), which means your tabletop notes, your declared severity levels, and your post-incident reviews are audit evidence. The auditor will sample them — 2–5 instances of a quarterly exercise, per Part 5’s sampling math. The compliance automation platforms can remind you to run the exercise; they cannot run it for you. That asymmetry, as with everything in this series, is the point: tools collect, humans rehearse, and the night eventually arrives to grade the difference.

Where the series goes next

Current thinking for the next door: abuse — the quieter attack that never pages anyone: trial farming, free-tier resource theft, and account-takeover-as-a-feature of your growth funnel. Key management and encryption — KMS, envelope encryption, and what BYOK buyers actually want — is the other strong candidate. As before: the order is decided when we get there.

Practice

1. Write the one-page IR card today: incident commander (primary and backup), the out-of-band channel, the first five steps in order, and the three legal clocks that apply to your customers. If it doesn’t fit on one page, it won’t be read at 3 A.M.
2. Run a 45-minute tabletop this month: “a forged billing webhook (Part 4) upgraded 200 accounts, and we noticed via a customer’s support ticket.” Walk the first hour out loud and write down everything you couldn’t answer. That list is the real deliverable.
3. Pre-draft two artifacts now: the customer breach-notification email (facts, impact, what you’re doing, what they should do) and a regulator-notification skeleton with placeholders. Then check your cyber-insurance policy for the notification clause — the one that voids coverage if you call late.