Picture a composite scenario, assembled from the failure modes that show up in real after-action reports. At 2:07 a.m., an alert fires on suspicious activity in a production cloud workload. The SOC analyst on shift sees it within minutes, which turns out to be the last thing that goes smoothly tonight. The one engineer with rights to isolate that workload isn't answering. The cloud provider's escalation path is, at this hour, a support ticket in a queue. Legal's standing guidance says preserve evidence before anyone changes the system, and nobody on the call can say with confidence which logs even exist, let alone who's allowed to export them.
Detection worked. Everything after detection is now a negotiation. So, who can actually isolate the workload? Who can authorize breaking something on purpose? Who speaks to the provider, and does the provider know that person exists? If those answers live in someone's head rather than a tested plan, the org chart has stopped answering, and it's 2:07 a.m.
Every cloud program has the diagram: provider handles the infrastructure, customer handles what they build on it, with the boundary sliding around depending on whether you're consuming IaaS, PaaS, or SaaS. The diagram is true, as far as it goes. It's also not a response plan. Your contract moves that boundary. So does your architecture, and so do the controls you did or didn't actually configure, none of which the laminated version has any way of knowing. There's a reason the Cloud Security Alliance's incident response framework spends its pages on coordination instead of labels.
Here's the part that stings. On paper, a team can own workload isolation outright and still be stuck at 2 a.m. Maybe the one person holding the permission is asleep. Maybe the break-glass account has never once been exercised. Or nobody ever wrote down who's allowed to disrupt production, so what should be an action becomes a debate. That's the gap a June 2026 U.S. GAO review of cloud security practices keeps circling: across four federal agencies and eight selected cloud systems, implementation was uneven, with agencies failing to review the monitoring deliverables their providers owed them, leaving response and recovery coordination undefined, not measuring response time, skipping tests of their own procedures, and lacking enforceable service-level metrics. Four agencies, eight systems, so resist the urge to generalize it to everyone. But if agencies with formal frameworks and incident response guidance written for them are missing these seams, it's worth asking what an unexercised commercial program is missing.
Incident command needs something the responsibility diagram never provides: for each critical action, a named decision owner, an operator who can execute, a backup for both, and an honest note about what the action depends on the provider to do.
The working artifact this article wants you to leave with is a table, and it's deliberately boring. Down the rows: isolate the workload, disable an identity, revoke credentials, preserve data, export logs, rotate keys, fail over, notify the provider, begin external communications. Across the columns: decision owner, operator, backup, approval threshold, required access, provider dependency, evidence impact, and target time.
Filling it in is where the discoveries happen. "Evidence impact" forces the conversation legal always wanted: which containment actions destroy the very logs or volatile state you'll need later? "Approval threshold" drags out the question nobody wants to ask in daylight. Can the on-call engineer kill a revenue-generating service on their own say-so? If that call needs a VP, fine, but which VP, and does the escalation tree actually reach them at 2 a.m., or do we just assume it does? "Required access" is where technical capability and permission finally get separated, because plenty of engineers could isolate the workload and rather fewer may.
One more constraint worth writing down: don't assume the normal identity plane survives the incident. If the tenant admin account is what's suspected, your matrix needs a path that doesn't route through it, break-glass credentials stored and tested outside the environment under investigation. A matrix that assumes trustworthy identity infrastructure is a matrix for someone else's incident.
Evidence is the part of cloud response most likely to be assumed and least likely to be checked. The inventory covers both planes. Control-plane side, you've got identity and administrative logs. Below that sit workload and service logs, network telemetry, snapshots and key-management events, plus whatever notices the provider publishes about its own side of the house. And for every one of those sources, "does logging exist?" is the wrong tabletop question. Ask the operational ones instead. How long is it retained? Do the timestamps line up well enough to defend a timeline? What does export actually involve, and who signs off on access? Is any of it immutable, or merely present?
Then run the ugly case, since that's the one you'll actually get. If the tenant administrator account is suspected, can anyone still reach the logs without touching it? If the telemetry you need lives on the provider's side of the boundary, what exactly is the request path, and what does the standard service actually entitle you to?
A safety boundary the exercise should respect: the tabletop validates paths and decision rights, not improvised forensics. Volatile data and legal privilege are both remarkably easy to destroy with confident amateur work at 2 a.m., which is why the procedures themselves belong to incident response and legal specialists, defined and rehearsed before anyone needs them.
The seam your runbook controls least is the one between your team and the provider's, and "contact the provider" is either a usable procedure or a hopeful sentence. The exercise finds out which. What support tier does the contract actually buy, and does it include after-hours security escalation with a named route, or a general queue? Whose severity definitions apply, yours or theirs, and what happens when support classifies the case one level below what your team believes it is? Who on your side is authorized to make requests of the provider, and does the provider have that authorization on file?
GAO's review found that agencies hadn't defined how response and recovery would be coordinated with providers and weren't measuring response times at all, which is precisely the kind of gap that stays invisible until a real clock is running. For covered federal cloud services, FedRAMP's updated incident communications procedures now put timed, impact-based expectations on provider communications. Those rules bind FedRAMP-authorized providers, not the private sector at large, but they're a useful model of what "we'll hear from the provider" looks like when someone bothered to attach a clock to it. Your version of that clock lives in SLA language and escalation contacts, and the tabletop should test the fallback too: what's the move when the normal channel is down or simply slow, and who decides business impact while the provider is still confirming scope?
SecureWorld has already made the general case for practicing the response plan under realistic constraints; the cloud-specific 2 a.m. version narrows the target. Every inject tests exactly one authority, evidence, or coordination dependency, and every inject ends with a decision record: who decided, on what authority, with what evidence, and how long it took. CISA's tabletop exercise packages are a solid scaffold to adapt; the injects below are the cloud-ownership additions.
Start with the alert, not the answer
Give participants only what the SOC would actually have at 2:07: the first observable signal plus the affected service and its business context. No incident name, no scope, no attacker narrative. Make the room identify the incident lead, the initial evidence to preserve, and the containment options on the table, in that order, out loud.
Remove the person or system everyone relies on
Then take something away. The incident commander is unreachable. The tenant admin account is itself suspect. One log source is delayed. The usual chat platform is in scope and can't be trusted. Each removal tests whether backups and delegated authority exist on paper or in practice, and the difference is the finding.
Make the provider boundary ambiguous
Finally, make the seam misbehave: the provider can't yet confirm scope, support classifies the case below your severity, or the evidence you want sits outside the standard service. The required output is a documented escalation and a business decision made with incomplete information, because that's the actual job at 2 a.m.
Score the gaps, not the people
The tabletop's product is a scorecard, not a verdict on whoever froze. Watch four clocks above everything else: how long it takes to reach a named owner, then a first containment decision, then a provider acknowledgement, then evidence you could actually stand behind. And keep a running list of what broke along the way. An access path that failed. An approval with no documented threshold behind it. A reporting duty two people each assumed the other one owned. A recovery step everyone trusted and nobody had tested.
Then convert friction into work: each finding gets one named owner and a verification date, and the failed handoff gets rerun, not just discussed, once the fix lands. This is where the earlier federal incident-response gaps GAO documented in 2023 become instructive rather than depressing: the new review narrows the lens to selected cloud systems and finds the same pattern at the provider seams, which suggests the gaps don't close from being pointed at; they close from being retested.
Here's the durable rule: every critical incident action needs a named primary and a named backup, a pre-agreed authority boundary, an access path that's been used recently, a known evidence effect, a provider escalation route, and a fallback for when the route fails. A team name in the owner column is a blank field wearing a badge. And if one of those fields is blank at 2 p.m. on a quiet Tuesday, it will not fill itself in at 2 a.m. during the incident; it will just introduce itself, at the worst possible moment, as the finding you could have had for the price of a conference room and two hours of preparation.