The controls in a DDoS response are tested by traffic. The decisions are not, and the decisions are usually where the time goes.
A DDoS tabletop exercise is a facilitated, discussion-based rehearsal in which the people who would run a real DDoS response work through a written attack scenario, minute by minute, and make the decisions they would have to make, without sending any traffic at all. It is for incident leads, network and platform engineers, communications, legal and compliance, and the executives who hold the authority nobody else does. In the UK it is also one of the cheapest ways to exercise a severe but plausible scenario against an important business service before a regulator or an attacker asks the question.
What it produces is not a pass mark. It produces a timed decision log, a list of authority gaps, and a set of assumptions that a live test can then go and measure.
What is a DDoS tabletop exercise, and how is it different from a DDoS test?
A tabletop tests decisions; a live test tests controls. Both are needed, and neither can stand in for the other.
A live DDoS test sends attack-shaped traffic and measures what the scrubbing tier, the WAF and the origin actually did. How such a test is scoped, authorised and run is the subject of the complete guide to DDoS testing, and none of it is repeated here.
A tabletop sends nothing. It puts the scenario on paper, releases it in timed pieces called injects, and records what each person decides, when, with what information, and on whose authority.
| Tabletop exercise | Live DDoS test | |
|---|---|---|
| What it exercises | Decisions, authority, communication, escalation | Mitigation controls, capacity, configuration |
| Traffic sent | None | Controlled attack traffic, under written authorisation |
| Main output | Timed decision log and authority gaps | Measured time to mitigation, availability floor, layer of first failure |
| Typical length | 90 minutes to half a day | A scheduled test window |
| Who must attend | The people who decide | The people who operate and observe |
| What it cannot tell you | Whether the controls actually work | Whether anyone can authorise the response in time |
The bottom row is the reason to run both.
Why a DDoS deserves its own tabletop
Most incident tabletops are written around a breach: someone got in, what do we disclose. A DDoS raises a different set of questions, and several of them are unusual enough that a team has never had to answer them before the day.
Nobody is inside the network. Nothing has been stolen. The question is how much of your own service you are willing to break, and for whom, to keep the rest of it running.
Which decisions does a DDoS force that a team rarely rehearses?
The decisions that cost the most time are the ones that harm some real customers to protect the others, and the ones that need someone outside the engineering team to say yes.
Moving a rule from count to block
A WAF rule in count mode logs; in block mode it refuses. Moving a broad rule to block during an attack will reject some legitimate traffic, possibly a payment partner's callbacks or an aggregator's polling.
The question for the room is who can accept that, and how they find out what it broke.
Blocking a country your customers live in
Geo-blocking is fast and blunt. If a third of the attack comes from one country and two per cent of your customers do too, someone has to own the decision to cut them off, and someone has to tell them.
Asking the provider to divert traffic
Many organisations run some protection on demand: traffic is routed to a scrubbing centre only when someone asks. The provider will act on a request from a named, verified contact.
The exercise tests whether that contact is reachable at 07:40 on a Tuesday, whether a deputy is on the provider's list, and whether anyone remembers the procedure for proving who they are.
Responding to a ransom note
A ransom DDoS arrives with a deadline. The decisions are whether to engage, who reports it and to whom (in the UK, Action Fraud or Police Scotland, the NCSC, and for a regulated firm, its supervisor), and whether to treat the threat as credible before any traffic has arrived.
Those are board and legal decisions. Engineering should not be the first group to see the email.
Deciding what to say, and where
Customers will notice before the status page changes. If the status page, the help centre and the login page sit behind the same edge as the service under attack, the comms plan has a dependency on the thing that is failing.
Deciding whether this is the real incident
A flood can cover something quieter: credential stuffing, fraud, or an intrusion attempt happening while the team watches the bandwidth graph. Someone needs to own the question "what else is happening right now", and that person should not be the one running the mitigation.
How do you write a severe but plausible DDoS scenario?
Start from your own important business service and its tolerance, then make the scenario hard in the ways real attacks are hard, not in the ways films are.
What "severe but plausible" and "impact tolerance" mean in the FCA and PRA operational resilience regime is set out in DDoS testing in the UK. For a scenario writer, the useful reading is this: the scenario has to be bad enough to threaten the tolerance, and ordinary enough that nobody in the room can dismiss it.
Pick one service and one tolerance
Name the service ("customers can log in and see balances") and write its tolerance on the first page in minutes. An exercise against "the website" never reaches a decision, because nobody knows what the website is allowed to lose.
Make it plausible with things that have actually happened
The ingredients of a severe scenario are all routine:
- Multi-vector. A volumetric layer the provider absorbs, and an application-layer flood against the login endpoint that it does not. See multi-vector attacks.
- Sector-wide timing. Politically motivated campaigns tend to hit a sector in waves, so your peers are under attack the same morning and your provider's support queue is long.
- A dependency hit at the same time. A third-party DNS provider, a payment gateway or an identity provider slows down, and it is not clear whose problem it is.
- Bad timing. The attack starts during a salary-day peak, a product launch, or the first morning after a change freeze ends.
- A second wave. The attack stops, the team stands down, and it resumes forty minutes later on a different vector.
Make it severe by removing people, not by adding gigabits
The quickest way to find an authority gap is to take a key person out of the scenario. The on-call network engineer is on a flight. The named provider contact left in August and nobody updated the portal. The CIO is unreachable for the first hour.
A tabletop where everyone needed is in the room and available tests a company that does not exist.
Keep the numbers inside what you have measured
If you have run a live test, use its numbers for the scenario: how long the provider actually took to divert, how long mitigation cutover actually took. If you have not, write the timings as assumptions and mark them so. That list is what the next live test will check.
What does an inject schedule look like?
An inject is a short piece of new information released at a set time: an alert, a phone call, an email, a tweet, a message from the provider. The schedule controls the pace, and the pace is what makes it an exercise rather than a conversation.
Here is a worked schedule for the example service above, with a tolerance of 120 minutes. The timings are illustrative.
| Time | Inject | The decision it forces |
|---|---|---|
| T+0 | Synthetic login checks fail from two regions; error rate on /login at 30% | Is this an incident, and who is leading it? |
| T+10 | Provider dashboard shows a volumetric attack mitigated; login still failing | Is the provider's mitigation enough, or is there an application-layer component? |
| T+20 | Ransom email to the press office claims the attack and names a deadline | Who owns the ransom question, and who reports it? |
| T+30 | Provider asks for verified authorisation to change mitigation; the named contact is on leave | Who else can authorise, and can they prove it? |
| T+45 | Block rule deployed; payments partner reports declined callbacks | Accept the collateral, narrow the rule, or roll back? |
| T+60 | Customer complaints trending on social media; the status page still says "operational" | What do we publish, and on which channel? |
| T+75 | Fraud team sees a rise in password-reset requests | Is the flood covering something else? |
| T+125 | Login error rate back to normal; team proposes to stand down | Stand down, or hold the mitigations in place? |
| T+165 | Attack resumes on a new vector | Who is still here, and what did we keep? |
Two things make a schedule like this work. The injects arrive whether or not the room has finished arguing about the last one, which is how incidents behave. And each one forces a decision with an owner, rather than inviting discussion.
Rules for the facilitator
- No assumed fixes. "We'd just turn on the scrubbing" earns the follow-up question: who, how, and how long does that take?
- Run the clock. Read the time aloud at every inject. Write down when each decision was made, not just what it was.
- Answer only what the scenario knows. If someone asks for information the real incident would not provide yet, the answer is "you don't know".
- Do not rescue the room. Silence after an inject is a finding.
Who should be in the room, and who should not?
The people who hold the decisions, plus their deputies, a facilitator who holds none of them, and a scribe whose only job is the clock.
The roles
- Facilitator. Owns the scenario and the injects. Should not be someone who would make decisions in the real incident.
- Incident lead. Coordinates, and owns the question of declaring and closing the incident.
- Network and edge engineer. Owns the mitigation actions: rules, rate limits, diversion requests.
- Provider liaison. Holds the contracts, the contact list and the escalation path to the mitigation provider. Often nobody has this role until the exercise shows it is missing.
- Communications. Status page, customers, press, staff.
- Legal and compliance. Regulatory notification, ransom, law enforcement.
- Executive decision-maker. Accepts collateral damage, approves spend, decides on public statements.
- Scribe. Records every decision with a timestamp, and who made it.
Run two versions
A technical tabletop lasts two to four hours and goes deep: which rule, which provider ticket, which runbook step. A board version lasts sixty to ninety minutes and stays on the decisions only the board can make: accepting customer harm, the ransom question, public statements, and whether the tolerance itself is realistic.
Mixing the two wastes both audiences. Engineers wait while executives ask what a WAF is, and executives wait through a debate about rate-limit keys.
Leave out the vendor
Unless the scenario tests the provider escalation itself, the mitigation provider does not need to attend. Have the facilitator play them, using the response times in the contract. If the contract does not say, that is a finding.
What evidence should a DDoS tabletop produce?
A timed decision log, a list of gaps with owners and dates, and a list of assumptions that need a live test to confirm.
The decision log
One row per decision: the time, the decision, who made it, what they knew when they made it, and how long it took after the inject that prompted it. This is the record that shows whether the organisation can decide inside its tolerance.
The chart is the worked example, not data. Its point is the shape: no step looks dramatic on its own, and the total still crosses the line. In this example the diversion request alone lost twenty-two minutes waiting for someone with authority.
The gap list
Each gap gets an owner and a date: the provider contact list that needs a deputy, the status page that sits behind the same edge as the service, the rule that should have been pre-approved for block mode. A gap list without owners will be found again in next year's exercise.
The assumptions list
Every time someone says "the provider will divert in ten minutes" or "the block rule won't touch payments", write it down. These are claims about controls, and a tabletop has no way to check them.
Where the evidence goes
For a UK firm in scope of operational resilience, the decision log and gap list belong in the evidence behind the written self-assessment. For EU operations, DORA's testing programme lists scenario-based tests among the tests a firm can run; how an availability test fits that programme is covered on DORA DDoS testing. A tabletop is not a threat-led exercise and should not be presented as one; the difference is set out on CBEST and DDoS testing.
How do a tabletop and a live test feed each other?
The tabletop produces assumptions; the live test measures them; the measured numbers go back into the next tabletop as inject timings.
The assumptions list is the bridge. If the room assumed the provider diverts in ten minutes, the live test measures time to mitigation with a real diversion. If the room assumed the block rule is safe for payments, the live test checks it against real partner traffic in a controlled window. The planning for that test, scope, abort criteria and success criteria, belongs in a DDoS test plan.
Then the loop closes. The next tabletop uses measured numbers instead of guesses, and the discussion moves from "how long would that take" to "it took twenty-six minutes last time; is that acceptable".
The order matters less than the loop. Some teams start with a tabletop because it costs nothing in traffic and surfaces the authority gaps first. Others start with a live test because they want real numbers in the scenario. Either way, a tabletop that never leads to a test is a discussion, and a test that never feeds a tabletop leaves the decision side unmeasured. A DDoS readiness assessment treats both sides together; the tabletop is the part of that work you can run on your own, on any Tuesday.
How do you run a DDoS tabletop exercise? A checklist
- Choose one important business service and write its impact tolerance in minutes on the first page.
- Name the roles and their deputies, and confirm which decisions each one holds before the day.
- Write the scenario with a multi-vector attack, a dependency failure, bad timing and at least one key person missing.
- Build the inject schedule with times, sources and the decision each inject forces. Use measured timings where you have them; mark the rest as assumptions.
- Brief the facilitator and the scribe, and agree the rules: no assumed fixes, the clock runs, unknowns stay unknown.
- Run the technical session, recording every decision with its time and owner.
- Run the board session on the decisions only executives can make.
- Write up within a week: the decision log, the gap list with owners and dates, and the assumptions list.
- Hand the assumptions to the live test and plan it, then use its numbers in the next exercise.
- Repeat after any major change to the service, the provider or the team, and at least once a year.
FAQ
What is a DDoS tabletop exercise?
It is a facilitated, discussion-based rehearsal of a DDoS incident. The people who would respond work through a written scenario released as timed injects, and record each decision they make, when and on whose authority. No traffic is sent.
How long should a DDoS tabletop exercise take?
A technical session usually runs two to four hours. A board session should stay within sixty to ninety minutes and cover only the decisions that need executive authority. Preparation, mainly writing the scenario and inject schedule, takes longer than either.
Does a tabletop exercise count as DDoS testing?
It tests the response, not the controls. It can show whether the organisation can decide fast enough, but it cannot show whether a mitigation provider, WAF or origin actually holds under load. That needs a live, authorised test. The two are complementary.
Who should facilitate a DDoS tabletop exercise?
Someone who would not make decisions in the real incident, so they can keep the clock and withhold information without being pulled into the response. That can be an internal risk or resilience lead, or an external facilitator.
How often should we run one?
At least annually for each important business service, and again after a significant change: a new mitigation provider, a re-architected service, or turnover in the people who hold the decisions.
The clock belongs to the people
Every DDoS response has two clocks running. One is set by the attack and the controls, and a live test can measure it to the second. The other is set by people finding each other, establishing who is allowed to say yes, and agreeing what to tell customers.
The second clock is usually longer, and almost nobody measures it. A tabletop is the instrument for that clock. It costs an afternoon and sends nothing, and a first run usually turns up at least one decision that nobody in the room is sure they are allowed to make.