To organise a cybersecurity tabletop exercise, you need to start with a realistic scenario, involve IT, management, legal, communications and critical suppliers, define roles and escalation procedures, simulate decision-making under pressure, and conclude with an operational debrief. The value of the exercise is not to ‘overcome’ the crisis, but to first identify what is missing.
I have been conducting tabletop exercises on ransomware scenarios in companies of various sizes for some time now, and there is one constant that recurs with a frequency that should be cause for concern: in most cases, the exercise does not fail in its crisis management. It fails earlier. It fails at the detection stage because it reveals the absence of an organisation structured around cybersecurity.
What happens if a cyber alert comes in at night?
If a cyber alert comes in at night and no one is on duty to read it, assess it and manage it, the technology loses much of its value. The problem is not the EDR itself, but the lack of a structured on-call system capable of turning an alert into a timely response.
If an EDR were to generate an alert at 2.30 am, it would be completely useless if that alert ended up in an email queue that nobody would check before 8 am. This is just one of many examples that could be given regarding the failure to manage alerts outside working hours and on non-working days. The reaction I observe is almost always the same: a mixture of embarrassment and surprise, because until that moment no one had ever formally considered how to handle an alert at 2 am when IT on-call arrangements are not structured but left solely to the availability and goodwill of IT staff – which, in such cases, offers little guarantee of continuity in the medium and long term.
If a company needs to keep its infrastructure operational 24 hours a day for business reasons, that infrastructure must be monitored with the same level of continuity. This is not a luxury but a necessity: it leaves an attack surface exposed for two-thirds of the day.
Does the IT provider really guarantee 24-hour security?
An IT provider does not automatically guarantee 24-hour security: it depends on the contract, the SLAs and the type of service purchased. Ticket-based infrastructure support is different from a continuous cyber monitoring, analysis and response service, particularly in the context of a ransomware attack.
In fact, a recurring finding during the exercises concerns the role of providers. Many SMEs rely on an IT provider to manage their infrastructure, implicitly assuming that this also covers security outside normal working hours. When I explicitly ask during the exercise, “Who responds if this alert comes in at 3 am?”, the most common response is silence, followed by “We’d have to call the provider”. Upon checking the support contracts, it turns out that the provider offers ticketed support with SLAs designed for issues during working hours, rather than a 24/7 security monitoring and response service. It is not the provider’s fault: it is simply a different service from the one the company thought it had purchased.
How can you tell if a ransomware attack is about to begin?
A ransomware attack can often be detected before encryption takes place by observing signs such as anomalous activity, privilege escalation, out-of-context access or preparatory behaviour. The problem is that these signs are of little use if no one analyses them in time and links them to a real attack scenario.
This is a key point that exercises continue to confirm: a significant proportion of ransomware attacks analysed during the post-incident phase showed signs of preparation that could have been detected well before encryption took place. The difference between an incident contained at an early stage and a successful ransomware attack is almost never the sophistication of the attacker: it is the presence or absence of someone capable of analysing the right signals at the right time, interpreting them correctly and responding accordingly.
Why can’t an IT department manage everything on its own?
An IT department cannot manage everything on its own because security requires time, expertise and continuity that are often incompatible with the day-to-day management of infrastructure, users, support tickets, backups, access controls and business systems. Without dedicated roles, security remains a theoretical responsibility.
This is a further structural issue that tabletop exercises lay bare, and it reflects the reality of the day-to-day work of IT departments in medium-sized companies. In most cases, the very same team that is supposed to oversee security also manages printers, user tickets, ERP maintenance, access requests, backups, the firewall and anything else generically labelled as ‘IT’. Asking this same team to devote time to security, even just during working hours, is often unrealistic: let alone on non-working days and outside working hours, when there is no one to demand preventive security measures until something actually happens.
Who should manage a ransomware crisis within a company?
A ransomware crisis should not be managed by IT alone. Management, legal, data protection, communications, HR and the board must all be involved, because an attack impacts business continuity, customers, employees, reputation, notification obligations and business decisions that go beyond the technical scope.
Too many companies continue to treat a ransomware attack as if it were solely an IT problem to be resolved without involving the rest of the organisation, without a communication plan and without a defined chain of command that extends beyond the technical sphere.
Why is a communication plan needed during a ransomware attack?
A communication plan is needed during a ransomware attack because customers, employees, the media and stakeholders start asking questions before the company has all the answers. Without pre-defined messages, roles and spokespersons, there is a risk of having to improvise at precisely the moment when control, clarity and coordination are most needed.
An incident I witnessed in the classroom – and which, unfortunately, is not an isolated case – illustrates this point well. During a discussion about external pressure (e.g. customers calling, the media starting to ask questions, employees noticing that something is amiss, etc.), a participant in a senior management role literally said, ‘Let’s not say anything to anyone’. This was not a communication strategy carefully considered with the legal team: it was the instinct of someone who views transparency as a risk rather than as a crisis management tool.
When, during the debrief, I pointed out that this statement would convey exactly the opposite – namely, a lack of control over the situation, disorganisation and, above all, the absence of any real crisis governance function – there was silence. The issue of communication is almost always conspicuous by its absence. There is no crisis communication plan, no designated spokesperson, and no pre-approved draft of a statement for clients or employees. Everything is improvised at the worst possible moment, under pressure, with the very real risk of saying the wrong thing to the wrong person at the wrong time.
What does a tabletop exercise really demonstrate?
A tabletop exercise demonstrates whether the company has genuinely envisaged what would happen during a cyber crisis. It serves not only to understand whether the technologies work, but also to verify whether roles, escalation procedures, governance, communication and decision-making processes have already been planned before the incident.
All in all, the evidence gathered during the exercises does not generally point solely to specific technical shortcomings. During a tabletop exercise, most organisations realise for the first time that they have not envisaged certain scenarios. They do not have a crisis plan that extends beyond the IT perimeter; they do not have an escalation process that takes non-working hours into account; and they have never involved HR, communications, legal and the board in a realistic simulation.
This is the value of the tabletop exercise beyond its specific outcome: it is not so much a tool for checking whether the organisation can respond effectively to an attack, but rather a tool for demonstrating whether it has considered what would happen in the event of an attack.
By Andrea Coli – Incident Response Manager, CYBEROO
