Running Tabletop Exercises for Breach Response Readiness

Section 8(6) requires intimation of a personal data breach to the Data Protection Board and affected Data Principals, with the Rules contemplating a fast initial notice followed by a more detailed report. That timeline leaves little room for the team to be figuring out who does what for the first time during a real incident.

A tabletop exercise is a low-stakes way to discover, before an actual breach, where the plan has gaps — an undefined decision-maker, an unclear notification threshold, a vendor contact list that's out of date — while there's no live exposure riding on the outcome.

Avoid scenarios that are too clean. A scenario where the breach is immediately obvious and fully contained doesn't test the hardest parts of real incidents: ambiguous scope, a vendor who is slow to confirm details, or a question about whether the incident even meets the notification threshold at all.

Vary the scenario type across exercises — an internal error, a third-party processor incident, a targeted attack, a lost device with unencrypted data — since each pulls on a different part of the response plan and a different set of stakeholders.

Keep the group small enough to move quickly but broad enough to include everyone who would actually be pulled in: security, legal, the DPO, a communications lead, and a business owner for the affected system. Walk the scenario forward in stages, deliberately introducing new facts partway through to simulate how real incidents evolve rather than presenting the full picture upfront.

Time the exercise against the actual regulatory clock. If the group can't agree on whether the Board needs to be notified within the time the Rules effectively require, that's the most valuable finding of the exercise, not a footnote.

Every tabletop should end with a short list of concrete gaps and owners, not just a debrief conversation that evaporates afterward. Common findings include missing or outdated contact lists, unclear authority to declare an incident, and vendor contracts that don't flow down notification timelines fast enough.

Re-run the exercise on a fixed cadence, ideally at least annually and after any material change to systems or vendors, so the plan stays tested against your current environment rather than the one that existed when it was first written.

The Breach Response Planner on this site gives you a structured plan to run your tabletop exercise against, and the Timeline Explorer is useful for checking the exercise's decisions against the notification timelines the Rules expect.