To run a crisis tabletop with Pingpong, choose one specific incident, then put your incident response plan, the roles and contact list, key customer contract terms, your insurance notice requirements, and the board's escalation rules into one request. Instruct Pingpong to write the scenario as a sequence of timed developments, each one adding pressure: a first alert, a customer demand, a reporter's email, a contractual deadline. Your team writes down what it would decide at each step. Then send those decisions back and ask Pingpong to find where the plan was unclear, where two people thought they owned the same call, and where the board heard too late.
This page is for chief executives, executive teams, and directors who want to rehearse a security breach, a major outage, a product harm report, a misconduct allegation against a senior leader, or the sudden loss of a large customer. It also works after a real incident, to replay the timeline and test what the team would do differently. Executive starting points live under Pingpong for executives.
How a tabletop runs
- Pick one scenario. A specific incident with a start time beats a general category.
- Write the developments. Pingpong drafts six to ten timed developments, each revealing new information.
- Decide in the room. The team answers each one in writing: who decides, what they decide, who is told.
- Review the decisions. Pingpong compares the answers against the plan and against each other.
- Assign the fixes. Every gap gets an owner and a date.
Questions the exercise should answer
- Who declares a crisis, and on what evidence?
- Who decides what customers are told, and by when?
- When is the board told, and by whom?
- How does the team communicate if normal systems are down or compromised?
- Which decisions belong to counsel, the insurer, or an outside firm?
A worked example
This example is illustrative and does not describe a customer. A 500-person business data platform runs a tabletop with its executive team, general counsel, and the audit committee chair. The scenario is ransomware that encrypts production systems at 11 p.m. on a Sunday.
Pingpong writes eight developments. At 2 a.m., an extortion note claims customer data was copied. At 7 a.m., the largest customer's security team asks whether its data is affected. At 10 a.m., a trade reporter emails asking for comment. That afternoon, the team learns that several customer contracts require notice within 72 hours of a suspected breach. On Tuesday, the cyber insurer asks which forensic firm has been engaged.
The team answers each development, and Pingpong reviews the answers. The response plan names the chief technology officer as incident lead and as the person who briefs the board, so the board briefing waits until the technical work slows down, about 30 hours in. Two executives both believed they decided what customers would be told. The plan assumes coordination by company email, which in this scenario sits on affected systems. The insurer requires a firm from its approved panel, but the company has a standing agreement with a different firm. There is no agreed process for deciding whether to engage with an extortion demand.
The team assigns fixes. A separate executive acts as liaison to the board and customers, so the incident lead can focus on recovery. Customer notification decisions sit with one named executive, with counsel advising on contract and legal deadlines. The company sets up a backup communication channel that does not depend on its own systems. Finance confirms which forensic firm the insurer will accept and puts a retainer in place. The audit committee agrees that it will be told within four hours of any top-severity incident. Counsel owns the questions on extortion demands and legal notification, and the plan says so. The team schedules a second tabletop in six months on a different scenario.
A request you can copy
Below are our incident response plan, roles and contacts, key customer contract terms, insurance notice requirements, and board escalation rules. Write a tabletop scenario for this incident as eight timed developments, each adding new information and pressure. Stop after the scenario so our team can answer each development. When we send our answers, compare them with the plan and with each other. List unclear ownership, missed deadlines, communication gaps, late board notice, and questions that belong with counsel or our insurer.
How Pingpong runs the tabletop
The web review app sends your request through several models in order. Each later model receives the original request and every earlier answer, with instructions to assess the work so far. Run the scenario in one review and the debrief in a second. For the steps inside the app, see running your first review.
What a model can't rehearse
A model does not know how your people behave under stress, what your systems will actually do, or how a real attacker, reporter, or customer will act. It cannot tell you your legal obligations in an incident. Counsel, your insurer, and your incident response firm own those answers.
When crisis readiness goes to the board, see war-game a decision before the board meeting. More guides live under work decisions before you commit.