A tabletop is a walkthrough, not a drill. Nobody touches production. Someone narrates events in order with the clock running, and everyone says out loud what they would do, on which channel, with which account. The point is not to pass. The point is to find the things that only become obvious when a plan meets a timeline. We found three.

The scenario

08:47. An engineer reports that their laptop is renaming files on its own, in the on-call channel, because that is where you report odd things. A colleague finds a ransom note on their machine. 09:05. Five more devices show symptoms, seven in total. Then the part that makes it a real exercise: sign-in through the identity provider starts failing, which takes our chat, email and ticketing tools with it. And one of the affected devices had, that week, temporary access to a data extract belonging to a customer. So the question is no longer just "are we down". It is "is this reportable".

What held

Most of the plan did what it said. The incident manager is a named director, with a named deputy, and the declaration happens on sight of the first report, not after confirmation. Device isolation and remote wipe run through our device management platform using administrator accounts that are separate from anyone's daily login, so a compromised daily account does not take the admin path with it. If every company device were gone, a personal device with one of those admin accounts can still reach the management console and shut things down.

The part customers ask about most is whether a compromised laptop can reach their environment. The honest answer is that it should not be able to, and the reasons are specific rather than reassuring. There are no secrets on the laptop: credentials and infrastructure state live in a cloud vault. Every customer environment requires multi-factor authentication. And changes go through a pipeline, so a laptop cannot run an apply against production even if it wanted to. Afterwards, the state file's write times in the customer's own storage and the vault's login alerts show whether anything was touched. That is evidence, not assurance.

Recovery is restore from backup and do not pay, which is also the government's advice. "Back to normal" is signed by at least two directors, after an engineer has confirmed it technically, because it is a governance decision with legal weight, not a feeling.

The three things we only learned by running it

1. The backup channel has to be tested while the main one is up

Everyone's instinct was to coordinate in the chat tool. The scenario takes the chat tool away in the first twenty minutes, because an identity outage takes everything that signs in through it. We have an out-of-band channel for exactly this, on a service that does not depend on our identity provider. We had never sent a message on it under pressure. We did, live, in the exercise. It worked. Had it not, we would have found out at 09:06 on the real day. Test the channel you hope never to use, and test it when nothing is wrong.

2. The regulatory clock starts earlier than the technical one

The 72-hour window for notifying the ICO of a personal data breach starts when you become aware, not when you have finished investigating. In the scenario, awareness is 08:47. The decision on whether a breach is reportable is taken by two named people, and the plan now says a draft notification can be produced inside the window whether or not the investigation is complete. The technical team's instinct is to know everything before saying anything. The clock does not share that instinct.

3. "Back to normal" is a decision, and someone has to own it

The engineering view of recovery is that systems are restored and checks are green. The business view is that two directors have signed, the record is written, the customer has been told and the lessons are in the backlog. Until we wrote down who signs and what has to be true first, those were two different definitions of "over", and the gap between them is where incidents get reopened.

None of the three was a failure of the plan. Each was a place where the plan was correct and nobody had yet watched it meet a clock. That is what the exercise is for, and it is why we would rather publish what we found than publish the certificate.

What we changed

The out-of-band channel is now a tested control with a date against it, not a group chat someone set up once. The reportability decision has named owners and a draft notification template. The recovery sign-off has a checklist with the technical confirmation first and the directors' approval after. The whole exercise, with its timeline, gaps and remediations, is recorded in our ISMS as evidence, which is where an auditor will find it, and also where we will find it next year when we run it again.

Where we fit

If you are choosing a provider to run production for you, ask them about their last tabletop, not their certificate. Ask what broke on paper. Ask how a compromised laptop at their end is prevented from reaching your environment, and ask to see the controls rather than hear them described. Our answers are in our due-diligence pack, alongside the ISO 27001 and Cyber Essentials Plus certificates, the data processing terms and the sub-processor list, and the security and compliance page sets out the framework they sit in.

And if you are a customer who would like to run the same exercise with your environment in the scenario, say so. We would rather find the gaps together on a Tuesday afternoon than separately at 08:47.

Frequently asked questions

What is a ransomware tabletop exercise?

A walkthrough of a ransomware scenario with the people who would actually respond, run against the clock, without touching production. Someone narrates the events in order, a laptop misbehaving, a ransom note, more devices, the identity provider failing, and the team says out loud who does what, on which channel, with which account. The value is in the gaps that appear when a plan meets a timeline.

Can ransomware on an MSP's laptop reach a customer's cloud environment?

It should not be able to, and the controls that make that true are specific. No secrets on the laptop: credentials and infrastructure state live in a cloud vault, not on disk. Multi-factor authentication on every customer environment. Changes only through a CI/CD pipeline, so a compromised machine cannot run an apply against production. Afterwards, state write times and vault login alerts show whether anything was touched. Ask your provider to show you these, not describe them.

Does Critical Cloud share its incident response documentation with customers?

Yes. Our due-diligence pack includes the incident response process, the ISO 27001 and Cyber Essentials Plus certificates, the data processing terms and the sub-processor list, and the tabletop exercise is recorded as evidence in our ISMS. If you are a customer and want to run a joint exercise that includes your environment, ask us.

Sources