CASE STUDY · CYBER INCIDENT RESPONSE EXERCISING
Two organisations, the same ransomware, three hours each
In September 2026 ICA Consultancy ran the same ransomware scenario, for two very different organisations: a UK specialist bank and a national multi-site leisure and retail operator. Thirty-seven timed injects, two rooms, twenty-one findings. Only four of those findings were technical.
2
organisations exercised, September 2026
37
timed injects delivered across the two sessions
21
findings raised, each with a named owner
4
of those findings were technical control gaps
Capable teams. No framework around them.
Most organisations that buy an incident response exercise expect to discover that their people are not ready. That is almost never what happens.
In both engagements the technical discussion was strong. Both teams understood that encryption happens at the end of an attack, not the beginning. Both assumed exfiltration had already occurred. Both refused to restore from backup before containment was established, which mattered, because restoration integrity is important.
What slowed both rooms down was the same thing, and it was not technical. It was the moment a decision needed authority that had never been written down, or information that lived on the platform the incident had just taken out.
“Whenever a decision carried business impact, the group had no defined route to take it. That pattern repeated at containment, at communications, at third-party notification and at recovery sequencing.”
EXERCISE REPORT — THE OPERATOR
Scenario
A single scenario spine, rewritten for each organisation around its own estate, its own named business services, its own data platforms, its own regulators. The attacker has been inside the organisation for weeks before the room learns anything.
D-90
An unpatched internet-facing service is exploited. The CVE has been public for weeks and a working exploit is documented. No detection.
D-60
Lateral movement to domain admin. Sensitive data staged, the customer database queried. Command and control over HTTPS.
D-10
A second persistence mechanism is planted on a domain controller. Backup directory structures are tampered with.
D-0
Encryption fires. The exercise begins, and the room learns its first fact.
Triage
Helpdesk calls. Login failures. Systems slow. IT is treating it as a network fault. The first engineer on scene finds unfamiliar file extensions on a machine still powered on and still on the network.
Detection & containment
Encryption confirmed and spreading. A ransom note naming the attacker. A customer-facing service goes down. The crisis team asks for a restoration time, and a regulatory position within the hour.
Forensics & scope
Beaconing over HTTPS. The attacker toolkit identified. Customer records queried under a legitimate account. A second persistence mechanism on a system that had looked clean.
Eradication & recovery
A clean restore point five days before encryption. Recovery begins, and the first two restored systems are reinfected inside the hour, because eradication missed what had already pointed at.
Aftermath — regulatory close-out
Day thirty. Services stable for nine days, but the impact tolerance was breached for twenty-one. The regulator wants a written account. Individuals want to know what happened to their data. The board wants to know whether it can happen again.
UK Specialist Bank
FORMAT
Twenty injects, four phases plus a regulatory close-out, approximately three hours
IN THE ROOM
Information security including third-party risk, technical services, infrastructure and networks, server engineering, IT service, and a compliance officer
DRIVER
Annual scenario testing commitment against a critical service under the bank's business impact assessment
STARTING POSITION
Materially better prepared than most organisations of its size. Endpoint isolation documented, practised and available to several people in the room. Immutable backups analysed daily for anomalies. Cyber insurance understood down to the callback times. Direct relationships with the regulator at three levels.
WHAT THE EXERCISE FOUND
Eleven findings. The authority to contain existed in practice for two named individuals but was not written down, so response speed depended on who was on shift and how much personal risk they were willing to absorb. The playbook predated the current endpoint platform and a SOC provider onboarded six weeks earlier. Every piece of response material lived on the corporate platform a ransomware incident is most likely to remove.
A national leisure and retail operator
FORMAT
Seventeen injects, four phases, approximately two and a half hours
IN THE ROOM
Information security, IT operations, platforms and networks, service desk and end user compute
DRIVER
First exercise of an intended annual programme, delivered under an ICA Consultancy Fractional CISO engagement
STARTING POSITION
A technically capable team with deep knowledge of its estate and a healthy willingness to challenge one another. Triage was proportionate, the incident was correctly held at P2 pending evidence, then escalated decisively the moment encryption was confirmed. Evidence preservation was raised by the room, not the facilitator.
WHAT THE EXERCISE FOUND
Ten findings, of which one was a technical control gap. A crisis management team had been named as the escalation point in the incident management process and had never been established. There was no on-call rota and no duty manager, out-of-hours response depended on whether the right people happened to see a message. Communications audiences were identified correctly, but live in the room rather than drawn from anything prepared.
What both rooms had in common
Authority to act, written down and communicated, so a capable engineer can contain at 02:00 without weighing their job against the incident. Response material held somewhere the incident cannot reach. Communications drafted before they are needed rather than during. Recovery proven rather than assumed. And an executive layer that has rehearsed the first seventy-two hours of not knowing, before it lives through them.
How an ICA Consultancy exercise runs
Five stages, from scoping conversation to prioritised plan.
What an exercise is, and what it is not
A tabletop exercise is a discussion-based test of readiness. No technical testing, configuration review or evidence gathering is performed, and the findings describe stated readiness rather than the verified effectiveness of any control. That is a limitation worth stating plainly, and it is also the point. The controls in both of these organisations may well have detected or contained this attack earlier than the scenario allowed. The exercise deliberately assumes they did not, because no control set is complete, and what follows a control failure is the part that is almost never rehearsed.
When you need the controls tested too
A tabletop tests the response. It does not test whether the attack would have been caught, and both of these exercises said so plainly, the scenario assumes the controls were bypassed, because that is the part nobody rehearses.
The other half of the picture is technically led. Red teaming runs a real intrusion against your live estate, initial access, lateral movement, privilege escalation, data staging, and measures what your detection actually saw and how your responders actually reacted, rather than what everyone believes would happen. Where a tabletop surfaces gaps in authority and documentation, a red team surfaces gaps in visibility, telemetry and time to detect.
ICA Consultancy delivers red teaming and adversary simulation alongside its exercise programme, working with specialist offensive security partners. The two work well in sequence: a tabletop first to fix what is cheap to fix, then a red team to find out whether the detection and response those decisions depend on holds up under a real intrusion.