Ransomware Tabletop Walkthrough

A tabletop exercise is a structured, no-stakes walkthrough of an incident: the team sits down, someone narrates a scenario unfolding step by step, and at each step the participants say what they would actually do, with what tools, and what evidence they'd produce. Tabletops are where backup and recovery programs get stress-tested before a real incident — and where the gap between "we have backups" and "we can recover" becomes visible.

This video walks through a ransomware tabletop end to end: detection, the moment the team realizes production data is encrypted, the discovery of which backups survived, and the restore decision. Watch for where the plan meets reality — the assumptions that don't hold up, and the controls from the previous lesson (immutability, isolation, restore testing, RTO/RPO) that decide whether the company recovers or pays.

The scenario, step by step

The tabletop follows a mid-size SaaS company through a realistic ransomware incident. Each phase has a decision point worth pausing on.

1. Detection. Monitoring flags mass file modifications and failed application health checks at 02:14. The first question is not "how do we pay" — it's "what is the scope, and is it still spreading?" The team isolates affected systems to stop lateral movement. Decision point: do you have the telemetry to scope the blast radius quickly?

2. Confirmation and containment. Production databases and an application file store are confirmed encrypted; a ransom note demands payment. The team revokes credentials, isolates the production account, and convenes the incident commander, legal, and comms. Decision point: is there a documented incident plan with named roles, or is this being improvised at 2 a.m.?

3. The backup question. The pivotal moment: which backups survived? The same-region backup copy was reachable from the compromised account and was also encrypted by the attacker. The immutable, off-account copy — Object Lock with a 35-day retention — is intact and untouchable. This is the single fact that determines whether the company can refuse to pay. Decision point: is there a copy the attacker genuinely could not reach or delete?

4. The restore decision. With a clean immutable copy confirmed, the team decides to restore rather than pay. Now the numbers matter: the RPO determines how much data was lost (back to the last clean backup — about 45 minutes), and the RTO is tested for real as they estimate restore time for the dataset. Decision point: does the restore actually complete within the RTO the business committed to — and has anyone ever measured that before today?

5. Recovery and validation. Data is restored to a clean environment, integrity-validated, and the application is brought back online. The post-incident review captures what worked (immutable backup, fast isolation) and what didn't (the same-region copy was pointless against this threat; the restore took longer than assumed). Decision point: do you turn the incident into improved controls, or file the report and move on?

What the tabletop reveals

Tabletops consistently surface the same failure patterns, and they map directly to the controls from the previous lesson:

• The reachable backup is worthless against ransomware. A backup the production environment can reach and delete gets encrypted along with everything else. Only the isolated, immutable copy mattered.
• Untested restores hide nasty surprises. Restore time, data completeness, and dependency order are all things teams assume and rarely verify. The tabletop (and ideally a real restore test) is where those assumptions get corrected.
• RTO/RPO become concrete under pressure. "RTO 4 hours" is an abstraction until the team is watching a restore progress bar. The exercise turns the numbers into a tested reality.
• The plan is a control too. Named roles, decision authority, and communication paths are what keep a 2 a.m. incident from becoming chaos — and "we have a tested incident plan" is itself auditable evidence.

What to carry forward

A ransomware tabletop turns the abstract backup controls into a tested sequence of decisions: scope and contain, find the copy the attacker couldn't touch, restore within RTO, validate, and improve. The recurring lesson is that only an isolated, immutable, restore-tested backup is a ransomware control — everything else gets encrypted along with production. And the exercise itself is reusable audit evidence that recovery is practiced, not merely promised.

In the next lesson you'll design a ransomware-resilient backup strategy for a large 100 TB dataset — making the RPO/RTO, immutability, isolation, and restore-testing decisions concrete against real constraints of scale and cost.