This is a checklist for the four weeks before a cyber exercise. It is not a checklist for buying one, and it is deliberately not a maturity assessment. Its only job is to make sure that when the session starts, the exercise tests your response rather than your logistics.
Work through it in order. Anything you cannot answer is not a reason to postpone; it is a finding you have discovered for free, before the session rather than during it.
Before you start: the honest precondition
There is one thing worth checking before anything else, and it is uncomfortable. Do you have a written incident response plan?
If the answer is no, you are in the majority. Only 25% of UK businesses and 19% of charities have a formal incident response plan. Among micro businesses it is 21%; among large businesses it is 76%.
If you do not have one, run the exercise anyway. A first exercise is one of the most efficient ways to discover what your plan needs to contain, and writing a plan in the abstract usually produces a document that describes an incident nobody will ever have. Just be clear with yourself about which you are doing: testing a plan, or drafting one under pressure. Both are valuable. Confusing them is not.
Four weeks out: scope and people
Decide what the exercise is for
Pick one. Not three.
- Discovery. You want to find out where your response breaks. Best for a first exercise.
- Validation. You have a plan and want to know whether it survives contact.
- Evidence. You need documented proof that response arrangements have been tested, for an auditor, insurer or customer.
- Team building. A legitimate goal, but say so, because it changes the scenario and the measures.
The purpose determines the scenario, the room and the report. Organisations that skip this step usually end up with a session that half-serves all four.
Choose the scenario around your actual exposure
The scenario should be the thing that would genuinely hurt you, not the thing that is in the news.
A useful prompt: what single system, if unavailable for a week, would stop you serving customers or paying staff? What supplier has access to it? What data would be most damaging in public?
Supply chain deserves particular attention because so few organisations look at it. Just 15% of businesses review the cyber risks posed by their immediate suppliers, and only 6% look at the wider supply chain. If your scenario begins at a supplier rather than inside your own network, you are exercising a route most organisations have never thought about, and that is where the interesting findings are.
Build the room around decisions
List the decisions the scenario will force, then invite whoever can make them. Working backwards from decisions rather than forwards from job titles is the single highest-value thing on this list.
You are looking for:
- Someone who can authorise unplanned spend
- Someone who can speak to legal and regulatory obligations
- Someone who owns customer and staff communications
- Someone who owns the affected operation
- One or two technical people to answer questions of fact
- A deputy for anyone genuinely unavailable, because deputies are who you get at 11pm anyway
Aim for eight to twelve. Note who declines, because a decision-maker who cannot spare ninety minutes for a scheduled exercise is unlikely to be available for an unscheduled crisis.
Set the ground rules in writing
Three of them, and they should go in the invitation:
1. No preparation is required and none is expected.
2. Nothing said in the room is used in any performance context.
3. Saying "I do not know who decides this" is a successful contribution, not a failure.
The third rule is the one that makes the exercise work. Without explicit permission to be uncertain, senior people will improvise authority they do not have, and you will learn nothing.
Two weeks out: scenario and logistics
Pressure-test the scenario against your own organisation
Read the scenario as a sceptic and ask, at each stage, whether someone in the room can end it early with a single obvious action. If they can, the scenario needs another constraint. The commonest early-exit is "we would just restore from backup", so decide in advance whether backups are available, partially available or of uncertain integrity, and be ready to say so.
Confirm the practical details
- Date, time and duration, with the finish time protected
- Room or video call, with a plan for anyone dialling in
- Who facilitates, and who observes and records
- Whether the session is recorded, and if so who has access and for how long
- A stated safety valve: the word that stops the exercise if something real happens
That last point is not theatre. Exercises do get interrupted by genuine incidents, and everyone should know in advance how to stop cleanly.
Decide your measures now, not afterwards
Measures chosen after the event are chosen to flatter it. Write down before the session what you will capture:
- Time from first indicator to a declared incident
- Time to the first decision that changed the course of events
- Whether the regulatory assessment happened, when, and who raised it
- Decisions made, decisions deferred, decisions never surfaced
- Which control areas the scenario actually exercised
One week out: the quiet checks
- Does anyone need an accessibility adjustment? Ask privately, and ask before the day.
- Is anyone in the room new? Brief them on the ground rules separately so they are not learning the culture and the scenario simultaneously.
- Has anything changed? A new supplier, a system migration or a reorganisation since you wrote the scenario may have made it stale or, better, more relevant.
- Who is writing the record? Someone other than the facilitator, capturing decisions with timestamps. This is the raw material for the report and for any evidence you later need.
On the day
- Start on time, even if someone is missing. Their absence is data.
- Restate the three ground rules out loud before the first inject.
- Let the silences run. The instinct to rescue a quiet room destroys the finding.
- Capture decisions as they are made, not from memory afterwards.
- Stop on time. An exercise that overruns teaches people that exercises overrun.
- Take fifteen minutes at the end for immediate reactions while they are unfiltered.
Before anyone leaves the room
This is the step most often skipped and it costs more than any other omission.
Convert each finding into a named owner and a date. Not a recommendation, not an action for "the security team". A person and a deadline, agreed out loud while everyone is present. Then book a thirty-minute review six weeks out.
The evidence for why this matters is uncomfortable: 61% of organisations that suffered a real breach took action afterwards, which means nearly four in ten changed nothing even after a genuine incident. A simulated incident has less natural urgency, so the follow-up has to be engineered rather than hoped for.
After: turning the session into evidence
If the exercise needs to serve as assurance, the report should be able to answer three questions for a third party:
1. What was tested, and how realistically?
2. What was decided, by whom, and when?
3. What changed as a result, and by when?
A timestamped decision log plus a record of which control areas were exercised is substantially stronger evidence than a statement that an exercise took place. The Cyber Governance Code of Practice, published by DSIT and the NCSC in April 2025, expects response and recovery plans to be tested at least annually and a post-incident review process to capture lessons learned. A report structured around those three questions maps onto that expectation directly.
The short version
If you only do five things: pick one purpose, choose a scenario that reflects your real exposure rather than the headlines, build the room from decisions rather than titles, decide your measures before you start, and do not let anyone leave until every finding has a name and a date attached to it.
Everything else on this list is useful. Those five are what separate an exercise that changes something from an exercise that happened.