Inside our incident response playbook — and the tabletop exercise that changed it

Incident response playbooks are written by people who have thought carefully about incidents they have not yet experienced. That’s unavoidable — the alternative is waiting for incidents to happen and then writing playbooks, which is too late. The gap between a playbook built from careful theoretical preparation and a playbook that has been tested against a realistic scenario is something most organizations only discover when an actual incident exposes it.

We run tabletop exercises quarterly. In Q1 2026 we ran the most consequential one we’ve done since we formalized our IR program, and it changed two structural assumptions in our playbook that we had considered well-reasoned. This is an account of the original playbook, the synthetic scenario we ran, and what we learned.

The original playbook

Our incident response process is structured around the NIST 800-61 Rev. 2 IR lifecycle: Preparation, Detection and Analysis, Containment, Eradication, Recovery, and Post-Incident Activity. We’ve followed that lifecycle as the organizing framework for our playbook since we built the initial version, and it continues to be the right structure.

The Detection and Analysis phase is where most IR programs have the most gaps, and we invested heavily in it. Our detection instrumentation includes: transfer anomaly alerts (volume, timing, recipient anomaly), authentication event monitoring (failed auth rates, geographic anomalies, device-compliance failures), integrity verification on file contents at the ingest boundary, and API access pattern monitoring for token-based automation access.

For the Containment phase, our playbook distinguished three severity tiers with different containment actions:

Tier 1 (isolated credential compromise, no evidence of data exfiltration). Immediate credential revocation and session invalidation for the affected identity; notification to the workspace owner; investigation of access logs to bound the scope of access. No service disruption to unaffected workspace members.

Tier 2 (evidence of limited data exfiltration, single workspace). Containment of the affected workspace (read-only mode, no new transfers), notification to the workspace owner and their security team, engagement of our external IR partner, and coordination on breach notification obligations. Preservation of audit logs under legal hold.

Tier 3 (evidence of cross-workspace impact or platform-level compromise). Emergency isolation of affected infrastructure components, engagement of executive leadership and legal, activation of our external IR retainer, and consideration of broader customer notification.

The playbook assigned clear ownership of each step, defined escalation thresholds, and specified communication templates. On paper it was comprehensive. The tabletop showed us two things we had gotten wrong.

The tabletop scenario

The Q1 2026 tabletop was written by our external IR partner, deliberately without input from the SEND-SECURELY.COM security team. The scenario was entirely synthetic and fictional — no real customers, no real attackers, no real incidents.

The scenario: imagine an attacker who has spent three weeks conducting low-and-slow reconnaissance against a mid-market financial services organization that uses our platform. This is purely hypothetical. The attacker — call them the threat actor — has harvested a legitimate automation token from a CI/CD configuration file that was briefly exposed in a public repository before being removed. The token has workspace-level read access, issued originally for a reporting workflow.

The threat actor begins using the token in a pattern designed to avoid anomaly thresholds: small batches of file access, distributed across the week, at times consistent with the automation workflow’s normal schedule. The access pattern falls just below every configured alert threshold. Over three weeks, the threat actor builds a complete picture of the workspace contents without triggering any automated detection.

In week four of our fictional scenario, the threat actor escalates. They’ve identified through their reconnaissance that the workspace contains files with naming conventions suggesting signed contracts and financial records. They begin incremental exfiltration — still staying below volume thresholds but slightly above their earlier access rate.

The scenario injection: a customer security analyst reviewing logs notices an anomaly in week four — not a threshold alert, but a pattern they spotted manually while doing routine log review. They contact our support channel. The scenario begins at that point.

We ran the scenario with eight participants: our CISO, our VP of Engineering, two members of the security team, our legal counsel, our customer success lead, our head of communications, and our external IR partner. We followed the playbook step by step and tracked every decision.

The two assumptions the tabletop broke

Assumption 1: We would know the scope of exfiltration from our logs.

Our playbook’s Tier 2 containment phase assumed that when a customer reported a suspected incident, we would be able to determine the scope of exfiltration — what was accessed and whether data left the platform — from our audit logs. This assumption was reasonable: we log all transfer events, all API accesses, and all download events with the identity, timestamp, and file metadata.

The tabletop broke it. In the scenario, the threat actor’s access was from a valid automation token, executing operations that were individually authorized and consistent with the token’s historical behavior. Each access event was logged correctly. But reconstructing the complete picture of what was accessed required correlating thousands of individual log events across three weeks of access history, cross-referenced against file content metadata, and then comparing the resulting access inventory against what the workspace contained to identify what had been accessed but not transferred versus what had been potentially exfiltrated.

This correlation analysis — which our playbook assumed would take “a few hours” — actually took our security team, working in the tabletop, approximately nine hours to complete for even the simplified scenario dataset we’d prepared. In a real incident with a real workspace containing years of accumulated files and a month of access history, our estimate was 3–5 days for a thorough scope analysis.

The implication: our playbook told customers we would provide a preliminary scope assessment within four hours of incident declaration. That commitment was not achievable for token-abuse incidents involving extended reconnaissance periods. We had implicitly assumed scope determination would be straightforward when detection was early; the scenario showed a case where detection was late and scope determination was the hard problem.

The fix: the playbook now distinguishes scope determination complexity by incident type and sets tiered preliminary assessment commitments: four hours for credential compromise with discrete access window, 24 hours for token abuse with extended access history, 48–72 hours for platform-complexity incidents. Customer communication templates were rewritten to reflect this tiering.

Assumption 2: The customer’s security team would be immediately available.

Our playbook’s escalation sequence assumed that when we notified a customer of a Tier 2 incident, their security team would be available to receive the notification and begin collaborative investigation. The playbook specified a two-hour window for us to receive acknowledgment from the customer’s designated security contact before escalating to secondary contacts.

In the tabletop, the fictional mid-market financial services organization had a three-person security team. The scenario was set on a Thursday afternoon. The security team lead was traveling, one analyst was out sick, and the third analyst received our notification — but had no authority to make the containment decisions the playbook assumed the customer would make.

We sat in limbo for the simulated two-hour window while the analyst worked their internal escalation chain. Our playbook had two options at the two-hour mark: wait for acknowledgment or unilaterally apply Tier 2 containment to the workspace. Neither option was clean. Unilateral workspace containment (read-only mode) would break operational workflows for a customer who hadn’t explicitly authorized it; waiting extended the exfiltration window.

The discussion that followed was the most valuable part of the exercise. We had not written a clear policy for unilateral containment — the playbook deferred to customer authorization at Tier 2. The tabletop forced us to decide what we actually believe.

We believe the right answer is: we will apply unilateral workspace containment for Tier 2 incidents after a two-hour notification window without acknowledgment, with immediate notification to all workspace contacts and executive contacts, and we will document the containment decision and the basis for it. This is a customer-data-protection decision that prioritizes data integrity over operational continuity in ambiguous situations. We updated our terms of service and customer agreements to reflect this explicitly, so it is no longer a surprise.

The fix also included a new escalation path: our playbook now includes a mandatory step to verify that each customer’s IR contact list is current before the incident, not after. As part of our quarterly security review cycle, we ask customers to confirm the current IR contact and provide a secondary. We also extended our two-hour window to four hours for Tier 2 incidents during business hours and gave explicit policy authority to the on-call security lead to authorize unilateral containment after that window.

The revised playbook

The post-tabletop playbook retains the NIST 800-61 Rev. 2 lifecycle structure and the three-tier severity model. The specific revisions:

Detection and Analysis phase additions. New detection signature for low-and-slow token access patterns: behavioral baseline comparison over 30-day rolling windows, flagging tokens whose access pattern shifts by more than two standard deviations from their historical baseline even when absolute volume thresholds aren’t exceeded. This addresses the reconnaissance pattern in the tabletop scenario.

Containment phase revisions. Tiered scope determination timeline commitments replace the single four-hour commitment. Explicit unilateral containment authority and policy, documented in customer agreements. Extended acknowledgment window from two to four hours for business-hours incidents.

Customer IR contact verification. Added to quarterly security review cycle. Customers are asked to confirm IR contact and provide secondary. This is now a tracked compliance item, not an optional recommendation.

Tabletop cadence. We were running quarterly tabletops with internally written scenarios. We are now committing to at least two tabletops per year written by our external IR partner, without our team’s input on scenario design. The externally designed scenario surfaces assumptions we can’t see from the inside.

If you run a SEND-SECURELY.COM workspace and want to participate in a future tabletop exercise as a customer — we’ve had several customers express interest in joint IR exercises — reach out to your account team. The most useful tabletop is one that exercises the full response chain, including the customer side.