In short: A tabletop exercise in IT plays through a security incident at the table: a facilitator provides new information about the situation step by step, the participants decide as they would in an emergency, and the outcome is a list of concrete improvements. For web servers, a scenario modelled on PHP2Shell is suitable, because it touches technology, decisions under uncertainty, data protection and communication at the same time.
Why a plan only works through practice
Many companies now have an emergency plan. Whether it works only becomes clear when someone uses it under time pressure. Is the right phone number in it? Does management know that it has to decide on a shutdown? Does the service provider know the access details? An exercise at the table settles such questions in a few hours.
The October week of 2026 demonstrated how quickly a situation can escalate: advance notice from php.net on 20 October, patches on 21 October at 4 p.m. German time, BSI (German Federal Office for Information Security) warning level orange, public websites taken offline according to media reports. Anyone who had rehearsed this sequence once beforehand had less to improvise. The sequence is described in detail in the chronology of PHP2Shell. How to build the plan itself is covered in Creating an IT emergency plan for web servers; this page is about practising.
Tabletop exercise in IT: roles and preparation
A good exercise needs little material but clear roles. The facilitator leads through the script, introduces information and keeps time. They do not join the discussion but ask questions. A recorder notes decisions, open questions and every point where someone says “I wouldn’t know that right now”. Optionally, another person observes how communication goes.
The participants are the people who actually act in an emergency: management, internal IT or external service provider, data protection officers, communications and, if needed, purchasing or the legal department. It is important that deputies take part, because incidents do not respect holiday schedules.
Preparation includes: the current emergency plan on paper, the contact list, an overview of the websites and servers and a room without interruptions. Establish beforehand that the aim is learning, not grades. Anyone afraid of embarrassment will not say what they do not know.
A ready-made script: critical PHP vulnerability on a Friday afternoon
The following scenario is fictional but follows the pattern of a real situation. Adapt systems and names to your environment. Each inject gets ten to twenty minutes of discussion.
| Step | Facilitator inject | Guiding question to the group |
|---|---|---|
| 1 | Trade press reports a critical vulnerability in PHP; patches are announced but not yet available. | Who hears about it first, and who needs to be informed? |
| 2 | The patches appear in the afternoon. The BSI recommends an immediate update, otherwise temporary shutdown. | Which of our systems are affected, and how do we know? |
| 3 | The host does not respond. One of our own servers runs a PHP version with no official update. | Patch, shut down or wait, and who decides? |
| 4 | The shop is due to run a promotion at the weekend. Sales insists on not switching anything off. | How do we weigh revenue against risk, and how do we document the decision? |
| 5 | On Monday an admin finds an unknown PHP file in the upload folder. | What do we do first, what do we deliberately leave? Who preserves evidence? |
| 6 | It is unclear whether customer data has been leaked. | Who assesses a possible notification duty, and when does the deadline start? |
| 7 | A journalist asks why the website is offline. | Who speaks externally, and what do we say while we know little? |
Step 6 touches on the GDPR. In the exercise it is enough to clarify the process: who involves the data protection officers and when. The legal assessment stays with specialists; the basics of the deadline are in Art. 33 GDPR.
Typical findings and how to record them
Certain gaps appear in almost every first exercise. There is no complete list of which websites run on which servers with which PHP version. The host's contact details are outdated or stored only in a mailbox that is not reachable in an emergency. Nobody knows for certain whether management may order a shutdown itself or whether someone has to approve.
Record each finding in three parts: what we found, what we change and who completes it by when. A finding without an owner, experience shows, gets left lying. Order the items by impact: a missing emergency number is quickly fixed and helps immediately, whereas a new monitoring solution needs planning.
The same approach as after a real incident is suitable for the structured evaluation after the exercise. It is described in the article Lessons learned: getting better after an incident. The contact list, which usually shows weaknesses in the exercise, is covered in Emergency contacts: who must be informed, and when?.
Repeat the exercise after six to twelve months with a different scenario, for example a hacked website with redirects to third-party sites. That way you check whether the actions from the first round were really implemented.
How does PHP SOS help?
- We adapt the script to your actual websites, servers and service providers and prepare the injects.
- We facilitate the exercise remotely or by video conference and hold back on assessments until the group has decided.
- Afterwards we deliver a record with findings, actions, owners and deadlines.
- On request, we then practise the technical part, meaning inventory, patch and search for traces, the way our incident response works through it in an emergency.
Conclusion
A tabletop emergency exercise is the cheapest way to find the weaknesses of an emergency plan before a real incident does. An afternoon, a realistic script and an honest evaluation are enough to start with. What matters is that every finding becomes a task with a name and a date.
Frequently asked questions
What is a tabletop exercise?
An exercise in which participants talk through an incident together at the table, without working on real systems. A facilitator introduces new information step by step, and the group decides and gives reasons. This makes gaps in the plan, responsibilities and contact lists visible.
Who should take part in an emergency exercise?
Everyone who decides or acts in an emergency: management, IT or service provider, data protection, communications and, where available, the person responsible for insurance matters. More than eight to ten people make the round unwieldy.
How long does a tabletop exercise take?
For a first run, two to three hours including evaluation are enough. More important than length is that the results are recorded and actions are assigned with deadlines.
Does the scenario have to be realistic?
It should suit your environment but need not be right in every detail. A scenario modelled on a real situation such as PHP2Shell seems credible and steers the discussion towards decisions rather than technical details.