Most organisations that run a cyber exercise get something out of it. Very few get what they paid for. The difference is rarely the scenario or the facilitator. It is a handful of structural mistakes made before anyone sits down, each of which quietly converts a test into a demonstration.
This matters more than it used to. Only 25% of UK businesses have a formal incident response plan, and among micro businesses it is 21%. Most organisations are therefore exercising something that does not fully exist yet, which makes the quality of the exercise the only thing standing between a plan on paper and a plan that works.
Here are the five mistakes we see most often, why each one destroys the value of the session, and what to do instead.
Mistake 1: Telling the room what is coming
The single most common failure, and the most understandable. Someone wants the session to go well, so the scenario is circulated in advance, or the agenda names the attack type, or a well-meaning manager tells the team to "read up on ransomware before Thursday".
The moment that happens, you are no longer testing your response. You are watching a rehearsal. People arrive with answers prepared, the awkward pauses disappear, and the exercise produces a comfortable feeling and no information.
The awkward pauses are the product. When a room goes quiet because nobody is certain who has authority to take a customer-facing system offline, that silence is the finding. It is worth more than any slide in the report.
What to do instead. Tell participants the date, the duration, the fact that it is a cyber scenario and that no preparation is required. Nothing else. If someone insists on knowing more, that insistence is itself worth noting. Brief the facilitator, the exercise sponsor and anyone with a genuine safety or availability concern, and nobody else.
Mistake 2: Filling the room with technical people
Cyber exercise, so invite IT. It is an intuitive decision and it is usually wrong.
Think about what actually goes wrong in a real incident. The technical team generally knows what to do; their problem is that they cannot get a decision. Do we take the platform down? Who tells customers? Are we obliged to notify the ICO, and when does the 72-hour clock start? Do we pay? Who signs that off at 11pm on a Friday?
None of those are technical questions. They are questions for whoever can commit the organisation, and if those people are not in the room, the exercise cannot test the thing most likely to fail.
The survey data supports this. After a breach, 81% of businesses inform directors or trustees, so leadership is involved when it is real. Yet only 31% have a board member with explicit responsibility for cyber security. The people who get pulled into a crisis are frequently not the people who prepared for one.
What to do instead. Build the room around the decisions in the scenario, not around job titles. A useful default is: someone who can authorise spend, someone who can speak for legal or regulatory obligations, someone who owns customer and staff communications, someone who owns the affected operation, and one or two technical people to answer questions. Keep it under about twelve. Above that, people stop contributing and start attending.
Mistake 3: A scenario that cannot go wrong
A scenario written to be completed is not a scenario. If every inject has an obvious correct response and the team reaches a tidy resolution by the scheduled finish, the exercise has tested nothing but the participants' patience.
Real incidents are not like this. They are defined by incomplete information, options that are all bad in different ways, and the fact that early decisions constrain later ones in ways nobody anticipated.
The pattern to aim for is escalation that punishes vagueness. If the team agrees at minute fifteen to "monitor the situation and reconvene", minute forty should present the consequence of having monitored rather than acted. That is not a facilitator being unfair. It is the only honest way to show a leadership team that a non-decision is a decision.
What to do instead. Include at least one inject with no good answer, one that arrives via a channel nobody expected such as a journalist or a customer on social media, and one that contradicts information given earlier. Write down the decision each inject is designed to force before you write the inject itself. If you cannot name the decision, cut the inject.
Mistake 4: Measuring the mood instead of the decisions
Ask most organisations how their last exercise went and you will hear that feedback was positive and engagement was good. Both may be true. Neither tells you whether you are any readier than you were.
"Feedback was positive" measures whether people enjoyed an afternoon away from their inbox. It is a satisfaction score for an event, not an assessment of a capability.
The measures that mean something are almost all about time and traceability. How long from the first indicator to somebody declaring an incident? How long to the first decision that actually changed the course of events, rather than requesting more information? Was the regulatory clock identified, and by whom? Could you now reconstruct, from a written record, who decided what and when?
That last one matters beyond the exercise. A timestamped decision log is the artefact that turns a session into evidence for an auditor, an insurer or an enterprise customer's due diligence questionnaire.
What to do instead. Decide your measures before the exercise and capture them live. Time to declare, time to first material decision, time to regulatory assessment, and the number of decisions that were made, deferred or missed entirely. Compare against your own previous run rather than an industry benchmark, because the only trend that matters is your own.
Mistake 5: No follow-up, so the same findings recur
The exercise ends, everyone agrees it was useful, a report arrives a fortnight later, and it is filed. Twelve months on, the next exercise produces substantially the same findings.
There is evidence this is a real pattern rather than a cynical one. 61% of organisations that suffered a breach took some action afterwards, which is encouraging until you consider that it means nearly four in ten changed nothing after a live incident. If a real breach does not always produce change, a simulated one certainly will not unless the follow-up is designed in.
What to do instead. Before the session ends, while everyone is still in the room, convert each finding into a named owner and a date. Not a recommendation. An owner and a date. Anything without both is a paragraph in a report that nobody will action. Then put a thirty-minute review in the calendar for six weeks out, and make the first agenda item of the next exercise a review of the last one's actions.
The sixth mistake: treating it as an annual event
Running one exercise a year and calling it done is a compliance posture, not a readiness posture. Teams that exercise annually have usually forgotten the lessons by the following summer, and the composition of the room has changed anyway.
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, with a post-incident review process that captures lessons and feeds them back in. Read that as a floor, not a target.
A stronger rhythm is one substantial facilitated exercise a year, supported by short quarterly drills of twenty to thirty minutes that test a single decision each. The drills are cheap, they keep the muscle memory alive, and they surface the changes in your organisation between the big sessions.
What good actually looks like
A good exercise is mildly uncomfortable and completely safe. Nobody is caught out personally; the organisation is. People leave with a clear sense of one or two things that would genuinely have gone wrong, and the specific change that would prevent it.
The test is simple. A week later, ask a participant what they would do differently. If they can answer without hesitating, the exercise worked. If they say it was interesting, it did not.
The bottom line
None of these five mistakes is about the scenario being insufficiently dramatic. They are all about structure: who is in the room, what they know in advance, whether the scenario can punish a bad decision, what you measure, and what happens afterwards.
Fix those and a modest exercise will outperform an elaborate one. Leave them unfixed and no amount of production value will save the session.