Tabletop Exercise vs Red Team: Which Test Do You Need?
Tabletop exercise vs red team, pen test, purple team and BAS: what each tests, when to use which, how they feed each other, plus a combined annual plan.
A tabletop exercise tests people, processes and decisions: a group talks through a simulated incident and nothing is attacked. A red-team exercise tests technical controls and detection: specialists attack real systems, often without most defenders knowing, to see whether they get in and whether anyone notices. One rehearses the response; the other tests the defences.
They are complements, not alternatives. A red team can show that an attacker would reach your backups undetected; only a tabletop shows whether your executives would know who authorises taking the business offline once they found out. This guide compares tabletops with red teaming, penetration testing, purple teaming and breach and attack simulation, and shows how to combine them in one annual plan.
What each type of test actually tests
Tabletop exercise
A facilitated, discussion-based exercise. Players receive a scenario and staged injects, and describe what they would do. It tests roles, decision rights, escalation, communication, legal and regulatory processes, and the assumptions behind the incident-response plan. Nobody touches a keyboard. See how to run a tabletop exercise.
Penetration test
A scoped, time-boxed technical assessment that looks for exploitable vulnerabilities in a network, application or cloud environment. The goal is breadth of findings within the scope, usually with defenders aware of the test. Output: a list of vulnerabilities with severity and remediation advice.
Red-team engagement
An objective-driven adversary emulation. Rather than finding every vulnerability, the red team pursues a goal (reach the payment system, exfiltrate a sample dataset, obtain domain administrator rights) using the tactics a real attacker would, often including phishing and physical or social engineering where agreed. Usually only a small group of trusted people knows it is happening. It tests prevention, detection and the SOC's response to a live intrusion.
Red-team engagements need careful rules of engagement: what is in and out of scope, which systems must never be disrupted, how the engagement is paused if a real incident starts, and who in the control group can confirm to the SOC that an alert is part of the test. Those rules are themselves something worth rehearsing, as described below.
Purple-team exercise
A collaborative session in which red and blue work side by side. The red team executes specific techniques, often mapped to MITRE ATT&CK, and the blue team checks each one: prevented, detected, alerted, investigated? Detections are tuned on the spot. It is the fastest way to improve detection coverage, but it removes surprise.
Breach and attack simulation (BAS)
Automated tools that continuously run safe simulations of attacker techniques against your controls, for example testing whether endpoint protection blocks a known technique or whether a simulated exfiltration triggers an alert. BAS gives frequent, repeatable measurement of control effectiveness. It does not replace human red teaming, and it says nothing about the human response.
Comparison table
| Tabletop exercise | Penetration test | Red team | Purple team | BAS | |
|---|---|---|---|---|---|
| Primary question | Do we respond well? | Where are we vulnerable? | Can a real attacker reach their goal, and would we notice? | Do our controls prevent and detect these techniques? | Are controls still working today? |
| What is tested | People, process, decisions, plans | Technical vulnerabilities in scope | Prevention, detection and SOC response end to end | Detection engineering, control coverage | Control configuration and effectiveness |
| Systems touched | None | Yes, within scope | Yes, broad | Yes, agreed techniques | Yes, safe simulations |
| Defenders aware? | Yes, it is an exercise | Usually | Usually not | Yes, collaborating | Yes |
| Participants | Executives, IR, legal, comms, IT, business | Testers plus system owners | Red team plus a small control group | Red and blue teams together | Security engineering |
| Typical duration | 90 minutes to 4 hours | Days to weeks | Weeks to months | Days | Continuous |
| Relative cost | Low | Moderate | High | Moderate | Tool licence plus upkeep |
| Main output | Decision and process gaps, improvement plan | Vulnerability report | Attack narrative, detection gaps | Detection improvements, coverage map | Control effectiveness dashboard |
| Tests executives? | Yes | No | Rarely | No | No |
When to use which
Use a tabletop when your plan is new or changed, you have never tested who decides what, leaders have not rehearsed ransom or disclosure decisions, or a regulator or auditor expects evidence that incident response has been tested. PCI DSS requirement 12.10.2, for example, expects the incident response plan to be tested at least every 12 months, and a documented tabletop is a common way to meet it.
Use a penetration test when you are launching a new application or environment, need assurance for a customer or certification, or want a broad picture of technical weaknesses in a defined scope.
Use a red team when your basic hygiene is in good shape, you have a functioning SOC, and you want to know whether a determined, realistic adversary would be detected before reaching a critical objective. Running a red team against an organisation with no monitoring mostly confirms what everyone already knows.
Use purple teaming when you want to improve detection coverage quickly, validate new detections, or turn red-team findings into concrete detection rules.
Use BAS when you want continuous assurance that controls have not drifted, especially in large or fast-changing environments.
Some regimes require specific forms. Under DORA, certain financial entities must carry out threat-led penetration testing (TLPT) as part of their digital operational resilience testing programme, alongside testing of ICT business continuity plans and crisis communication. See tabletop exercise compliance requirements for a broader overview.
How they complement each other
The most useful programmes connect technical tests and tabletops rather than running them in separate silos.
Feed red-team findings into a tabletop
A red-team report is a ready-made, organisation-specific scenario. It tells you exactly how an attacker got in, what they reached and when (or whether) they were detected. Convert it into a tabletop:
- Take the attack narrative and its timeline as the backbone of the scenario.
- Stop the story at the moment of detection, or at the moment a real attacker would have caused impact if nobody detected them.
- Write injects from that point onwards: the SOC's alert, the escalation, the discovery of what was accessed, the business impact, the regulator's deadline. The inject design guide covers how.
- Run it with the people who would handle the real thing, including those who did not know the red team was active.
This has a powerful effect on engagement. When the scenario is "this is what our red team actually did last quarter", nobody argues that it could never happen here.
Rehearse the response to a red-team scenario before it runs
Before a covert red-team engagement, the small control group should run a short tabletop on how they will handle the moments when the engagement collides with reality: the SOC escalates a red-team action as a real incident, a real attacker appears during the engagement, or the red team triggers an outage. Who can deconflict, and how quickly? This protects the organisation and makes the engagement safer.
Use the tabletop to question technical assumptions
Tabletops constantly surface assumptions: "EDR would catch that", "we'd see the exfiltration", "backups are immutable". Log each one and hand them to the purple team or BAS programme to verify. A tabletop assumption that fails a purple-team test is one of the most valuable findings you can report.
Close the loop with the same scenario
After fixes are in place, rerun the red-team technique through purple teaming or BAS to confirm detection, and rerun the tabletop to confirm the response process now works. Retesting is what turns findings into assurance.
A combined annual plan
This example suits a mid-sized organisation with an in-house SOC or a managed detection provider. Adjust the frequency to your size and risk.
| Quarter | Technical testing | Tabletop and response exercises | How they connect |
|---|---|---|---|
| Q1 | External and web application penetration tests; BAS running continuously | Technical tabletop: phishing and credential theft | Pen-test findings on exposed services inform realistic initial-access injects |
| Q2 | Covert red-team engagement with a defined objective | Pre-engagement deconfliction tabletop for the control group | Rehearses what happens if the SOC escalates red-team activity |
| Q3 | Purple-team sessions replaying the red-team's techniques | Executive tabletop based on the red-team narrative, e.g. extended into ransomware | Detection gaps closed in purple teaming; leaders rehearse the business response |
| Q4 | BAS validation of fixed detections; targeted retest of critical pen-test findings | Cross-functional tabletop retesting the year's top gaps | Confirms both technical and process improvements |
Throughout the year, track findings from all activities in one improvement register. The tabletop exercise programme guide covers how to manage cadence, triggers and metrics.
Tabletop vs simulation
"Simulation" is used loosely. It can mean:
- A digitally delivered tabletop, in which injects arrive on screens instead of being read aloud. It is still a discussion-based exercise. You can run one with the free exercise runner, which pushes injects to players' phones and captures decisions for the report.
- A functional exercise with a simulation cell, in which teams use real tools in real time and a control group simulates attackers, customers and regulators.
- A cyber range, an isolated technical environment where analysts respond to simulated attacks hands-on.
- Breach and attack simulation, the automated control testing described above.
The first is a tabletop. The others test more technical capability and are covered in types of security exercises.
Common mistakes
- Treating a clean pen test as proof of readiness. It shows that particular vulnerabilities were not found in that scope, not that the organisation would respond well.
- Running a red team with no plan to use the findings. The report sits on a shelf. Schedule the purple-team and tabletop follow-ups when you commission the engagement.
- Running tabletops that never question technical claims. If nobody verifies "we would detect that", the tabletop is built on sand.
- Keeping findings in separate registers. Technical and process gaps usually interact. One register, one owner per item.
Related
Frequently asked questions
What is the difference between a tabletop exercise and a red team exercise?
A tabletop exercise is a facilitated discussion in which people talk through how they would respond to a simulated incident; it tests plans, roles and decisions, and no systems are touched. A red-team exercise is an authorised, realistic attack against real systems by specialists emulating an adversary; it tests whether technical controls and detection stop or spot the attack. One tests the response, the other tests the defences.
Is a tabletop exercise the same as a penetration test?
No. A penetration test looks for exploitable vulnerabilities in systems or applications within a defined scope and time, and reports them with remediation advice. A tabletop exercise does not test systems at all: it rehearses how people and processes respond once an incident happens. Many organisations do both, because a clean pen-test report says nothing about whether the crisis team can make decisions under pressure.
What is a purple team exercise?
A purple-team exercise is a collaborative session in which offensive testers (red) and defenders (blue) work together openly. The red team runs specific attack techniques, the blue team checks whether they were prevented, detected and alerted on, and both improve detections on the spot. It is faster at improving detection coverage than a covert red-team engagement, but it does not test surprise or the wider organisational response.
Should we do a tabletop exercise or a red team first?
For most organisations, a tabletop first. It is cheaper, it needs no technical scope or rules of engagement, and it clarifies who decides what during an incident. That makes a later red-team engagement more useful, because the organisation knows how it will escalate and respond when the red team is detected. Mature organisations then use red-team findings as the basis for future tabletops.