Most business continuity plans are tested for the first time by a real incident. A desktop exercise exists to make sure the first test happens in a meeting room instead, where the cost of discovering a gap is an action point rather than an outage. If your organisation has a plan that has never been exercised, or your auditor has started asking about clause 8.5 of ISO 22301, here is what a desktop exercise involves, and what separates a useful one from theatre.

The shape of the session

A desktop exercise, sometimes called a tabletop, is a structured walkthrough of a disruption scenario. No systems are switched off and nothing is simulated technically. The people who would manage a real incident sit in a room, are presented with a developing situation, and work through their response using the plans as written. A typical session runs two to three hours: a short briefing that sets the ground rules, the scenario delivered in stages, and a structured debrief.

The most important ground rule is stated at the start: the exercise tests the plan, not the people. Without that, participants defend rather than explore, and the gaps stay hidden until a real incident finds them. The facilitator introduces the scenario and then feeds in developments, called injects, every ten to fifteen minutes: the incident escalates, a key person is unreachable, a journalist calls, a regulator deadline appears. Injects are where the learning happens, because they test the plan's assumptions rather than its table of contents, and they force decisions on imperfect information, which is the defining condition of every real incident.

Who needs to be in the room

The people with decision authority in a real incident, not their delegates. That usually means the incident or crisis management team: operations, IT, HR, communications, and a senior leader empowered to make spend and communication decisions. The most common exercise failure is discovering that everyone in the room would, in reality, be waiting for someone who is not. The second most common is the reverse: a senior voice dominating so completely that the plan itself never gets opened, which is a finding in its own right.

This is also the practical argument for an external facilitator. When the continuity manager runs the exercise, the person who knows the plan best spends the session keeping time instead of being tested. An outside facilitator lets every senior person participate fully, applies pressure evenly regardless of seniority, and keeps the debrief candid in a way that is difficult when the facilitator reports to half the room.

What a good scenario looks like

Plausible, specific to your organisation, and designed to stress the parts of the plan you are least sure about; the best starting points are your own business impact analysis and risk register. A cyber incident with extended system unavailability is the contemporary default for good reason, but loss of premises, supplier failure, and loss of key people all earn their place depending on your dependencies. What does not work: disaster movie scenarios so extreme that the only honest answer is improvisation. The exercise should sit at the edge of what your plan claims to handle, because that edge is what you are trying to find.

The outputs, which are the point

An exercise without documented outputs is a conversation. A proper desktop exercise produces three things:

Frequency, and the honest minimum

ISO 22301 requires exercises at planned intervals and after significant change; in practice, annually is the defensible minimum, with high-dependency organisations exercising twice a year and rotating scenarios. The honest minimum is different and simpler: if your plan has changed, your people have changed, or your systems have changed since the last exercise, the plan you have is not the plan you tested. For most organisations, a well-run half-day each year is the difference between a continuity capability and a continuity document.

Ready to test the plan before an incident does?

We design and facilitate desktop exercises built around your own dependencies and risk register, with the decision log, findings report, and action plan included. See how our BC desktop exercises work, or explore the wider business continuity testing programme.