Incident response tabletop: how to prove the plan works
An incident response plan is useful only when the team can use it. A short tabletop shows whether people know who decides, where contacts live, and how to document the impact on data or services.
Autor: Marco Zoratto, founder of Splnit.eu
Choose a realistic scenario
You do not need a full-day crisis simulation. Choose a scenario that matches your operations: a compromised admin account, data leak from support tooling, ransomware on shared storage, or outage of a critical SaaS supplier.
The goal is not to catch people out. It is to find gaps in contacts, roles, decisions, and evidence. The exercise should end with concrete actions, not only a feeling that the topic was discussed.
- who leads the incident and who talks to customers
- where technical logs are and who can access them
- who decides whether to notify an authority or customer
- how decisions, timeline, and follow-up actions are stored
What to record during the exercise
Keep a simple timeline: when the incident was detected, who was escalated, which information was missing, and which decisions were made. For personal data, record how the team assessed notification duty and risk to data subjects.
Afterwards, store the notes, action items, owners, and next review date. This is evidence that the plan exists and has been tested.
What a good result looks like
A good exercise does not mean zero findings. It should reveal weak spots before a real incident does. The important part is that every gap has an owner, a deadline, and a follow-up control.
Related regulation overview
Open overview: GDPR →Turn incident response into a tested process
Splnit.eu keeps roles, scenarios, decisions, evidence, and follow-up actions together so the plan is not just a document in a folder.
Open the GDPR overview