Tabletop exercise vs red team exercise: which to buy

Tabletop exercise vs red team exercise: which one answers your question

A tabletop exercise tests whether your plans, roles and decisions hold up under pressure, while a red team exercise tests whether your technical detection and response work against a covert attacker. Choose the tabletop when a board member or regulator asks whether the incident response plan is understood and followed by the people who would run it. Choose the red team when the question is whether attackers can get past your controls without anyone noticing. The two questions sound similar but produce different evidence, so the answer you need determines the format.

A tabletop is a discussion-based walkthrough of an incident scenario. According to NIST SP 800-84, it does not involve deploying equipment or other resources and typically lasts two to eight hours, depending on the audience, topic and objectives. It exposes gaps in escalation paths, decision authority, legal and communications sign-off, and contact lists for the people who hold them. A red team exercise is covert, runs against production systems under written rules of engagement, and can take weeks. Its output is a record of which techniques reached an objective and whether the security operations team detected them. Confirm with any provider how it will handle scope, legal authorization and safety controls before testing begins.

Running both is common when the incident response plan has been tabletop tested but the monitoring has never been challenged, or the reverse. A practical order is to run a tabletop first when the plan is new or has not been validated, so that the red team does not spend its time on failures that a plan review would have caught. Run the red team first when monitoring is the open question and the plan is already exercised. In either case, the joint review afterward should decide what changes. Ask your provider how findings from one exercise will feed the other, and which regulator expectations apply to your sector.

Side-by-side: tabletop exercise and red team exercise

This table compares a discussion-based tabletop with a covert red team exercise across goals, participants, live systems, disruption, deliverables and cost drivers. Read each row as a question to put to a provider, then use the last rows to decide what your own staff must supply. The main takeaway is that the two formats answer different questions, so buyers often need both rather than picking one.

Dimension	Tabletop exercise	Red team exercise
Primary goal	Test whether plans, roles and decisions work under a scenario, such as an incident response plan	Test whether defenders detect and respond to a covert attack that pursues a defined objective
What is tested	Decision making, escalation, communication, role clarity and plan content	Technical prevention, detection and response, plus people and process as attackers exploit them
Method at buyer level	Facilitated discussion of a written incident scenario with injects and discussion questions	Covert, objective-driven attack campaign run by testers under written rules of engagement
Participants	Decision makers, incident response leads, communications, legal and business owners	Provider testers, a small number of trusted contacts, and the defenders who are not told the exercise is running
Live systems involved	None. No equipment or live resources are deployed, per NIST SP 800-84	Production or agreed live systems, with the risk the rules of engagement accept
Duration basis	NIST SP 800-84 says a tabletop typically lasts two to eight hours, depending on audience, topic and objectives	Confirm the active testing window in the written scope; no duration is set by the supplied facts
Disruption to operations	Low. Staff time away from normal work during the session	Potentially high if testers reach production systems or trigger real alerts; agree stop conditions in advance
Deliverables	Facilitator notes, gaps in the plan, action items and an after action report	Attack narrative, detections achieved and missed, findings with evidence and remediation guidance
Skills required of the provider	Facilitation, scenario design and knowledge of incident response plans	Offensive security tradecraft, detection engineering insight and safe rules of engagement management
What the buyer's staff must supply	Current plans and playbooks, named decision makers, and time for a full session	Signed authorization, named escalation contacts, a clear objective, and a decision on who knows about the test
Regulator references	DORA Article 25(1) lists scenario-based tests as a possible element of a resilience testing programme	TIBER-EU and DORA threat-led testing require red-team-style tests; confirm whether your authority requires one
Main cost drivers	Number of sessions, scenario complexity, facilitator preparation and the number of participants	Scope of objectives and systems, length of the campaign, social engineering inclusion and reporting depth; confirm in the written quote

What a tabletop finds and misses, and what a red team finds and misses

A tabletop tests whether people, plans and decisions hold up under a scenario, while a red team tests whether technical controls and defenders react to a covert attack. Each format has blind spots, so the cards below separate what each one can surface from what it cannot.

Gaps in plan content and roles

A tabletop walks decision makers through a scenario and shows where the incident response plan is silent, out of date or assigns a task to someone who has left or lacks the access to do it. Facilitators can check whether each named role has a current contact, a documented duty and a fallback when that person is unavailable. A tabletop can confirm that the plan names the right people, but it cannot confirm that those people can execute the steps on a live system. Ask for the list of plan gaps raised and the owner and date assigned to each one.

Unclear decision authority

Under a simulated incident, the discussion often stalls on who can take the system offline, approve a customer notice or engage outside counsel. A tabletop surfaces these stalls quickly because participants must state their own decisions aloud. Note the decisions that cannot be made at the table, such as the authority to halt a payment flow overnight, and confirm them with the business owner. A red team does not test this layer, since its operators never need an executive to decide anything during the engagement.

Communication and escalation gaps

Tabletops expose how information moves between the security operations team, IT, legal, communications and the board when a scenario is unfolding. Typical gaps include no after-hours call tree, unclear thresholds for escalating to the chief executive, and no agreed channel when email is compromised. Facilitators should record each handoff and time it against the plan's own targets. A tabletop cannot prove that the notification channel works in practice, so confirm the paging and out-of-band tools with the operations team separately.

Untested assumption that detection will fire

Tabletop participants often assume that an attack would trigger an alert, a page or a containment playbook. The discussion accepts that assumption because no one runs the attack. A tabletop therefore cannot tell you whether a SIEM rule fires, how long the alert takes to reach an analyst, or whether the analyst has the access to act. CIS Safeguard 18.4 asks that security measures be validated after each test so that detections cover the techniques testers used, which points to a technical exercise as the follow-on test.

Detection gaps a red team can surface

A covert red team tests whether defenders notice the attack at all. It can reveal log sources that never reached the SIEM, rules that were tuned out of coverage, and attacker activity that went unreviewed for the length of the engagement. Ask the red team to report which techniques were detected, which produced an alert with no response, and which passed silently. A red team does not evaluate whether executives would choose the right response under pressure, so the detection findings need a separate decision review.

Lateral movement and unmonitored assets

Because a red team chains techniques across the environment, it can show which credentials, trust relationships and network paths let an attacker move from an initial foothold to sensitive systems. It can also find hosts, cloud accounts or service accounts that were never enrolled in monitoring. These findings are concrete and fixable, but the test only covers the paths the team had time and scope to reach. Confirm the rules of engagement and the objectives in advance, since a tabletop cannot surface these paths at all.

How a tabletop and a red team run from start to finish

The two exercises follow different sequences, but both start with agreed objectives and end with a written record that leadership and the security team can act on. The tabletop tests decisions and plans in discussion, while the red team tests whether defenders detect and respond to a covert attack.

Set objectives and confirm the audience
The sponsor and exercise lead agree on what the tabletop should test, such as an incident response plan, escalation paths or a specific decision point, and who needs to attend, such as executives, legal, communications and operations. The output is a short written objectives statement that every later step is checked against. The step is complete when the sponsor signs off on the objectives and the invited roles are confirmed. NIST SP 800-84 describes tabletops as validating the content of plans such as contingency and incident response plans, so the objectives should name the plan sections under test.
Design the scenario and discussion injects
The facilitator builds a realistic incident narrative, then breaks it into timed injects, which are new facts introduced at set points to force decisions. Teams can start from a ready-made package such as the CISA Tabletop Exercise Packages, which provide template objectives, scenarios and discussion questions that can be adapted to the organization. The output is a scenario document with injects, expected decision points and a facilitator guide. It is done when the sponsor has reviewed the scenario against the objectives and removed anything that would require technical testing.
Run the facilitated discussion
Participants talk through the scenario in the room or on a call, using their own plans and contact lists. The facilitator asks questions about who decides, what gets reported and to whom, and which plan step applies, and a scribe records gaps and disagreements. Nothing is deployed or attacked, so the session produces no technical evidence. The step is complete when every planned inject has been addressed or deliberately skipped and the scribe's notes are collected. NIST SP 800-84 notes that a tabletop is discussion-based only and typically lasts two to eight hours depending on the audience, topic and objectives.
Write the tabletop after action report
The exercise lead turns the notes into an after action report that lists what worked, the gaps found in plans, roles and decisions, and an owner and due date for each corrective action. CISA's packages include an after action report template that can be adapted for this purpose. The report is done when the plan owners accept their actions and the sponsor has reviewed the list. Ask your provider to confirm how they track corrective actions after the session, since the report alone does not fix gaps.
Agree rules of engagement and scope
For a red team, the sponsor and the testing team agree in writing on the objective, such as access to a named data set, the systems and people in scope, the techniques that are off limits, and the legal authorization. The rules of engagement also define how the team stops the test and who the emergency contacts are. NIST SP 800-115 provides a rules of engagement template in Appendix B that many teams adapt. This step is done when the rules are signed and a small group of trusted contacts knows the test is happening. PTES's pre-engagement stage is a useful analogy here, since it treats scoping as its own phase before any technical work begins.
Gather threat intelligence and set the objective
The red team researches the threat actors most relevant to the organization and selects a realistic path to the agreed objective. Sources can include the organization's own threat profile and public reporting, mapped to MITRE ATT&CK tactics and techniques, where the Enterprise matrix supplies a shared vocabulary. The output is an attack plan that lists the intended tactics, the decision points and the points at which the team will pause for approval. The step is done when the sponsor accepts that the plan is within the rules of engagement.
Execute the covert attack
The team carries out the plan against live systems and people within the agreed boundaries, without announcing itself to the defenders being tested. Its activity is logged so that every action can be matched to what the security team saw. Defenders run their normal processes throughout, which is what makes the result meaningful. The step ends when the objective is reached, the team is stopped under the rules of engagement or the time window closes. Ask the provider how they record actions and how they handle a live incident that might be caused by the test.
Debrief and report the red team results
After the operation, the team and the blue team review the attack step by step, comparing what the attackers did with what defenders detected, escalated and contained. The written report covers the attack path, the evidence, the detection gaps and recommended fixes, and it should be tied back to the original objective. The step is complete when both sides have reviewed the report and corrective actions have owners. TIBER-EU also expects purple teaming in its process, so a joint review is a common next step where regulated organizations apply that framework.

How regulators expect scenario-based testing

Regulators treat scenario-based testing as one tool inside a wider testing programme, and a tabletop alone does not meet their red team or threat-led requirements. Under DORA Article 25(1), scenario-based tests are among the tests a digital operational resilience testing programme can include, alongside vulnerability assessments, open source analyses, source code reviews where feasible and penetration testing. Article 26 goes further for entities their competent authority identifies: those entities must run threat-led penetration testing at least every 3 years. A discussion-based walkthrough cannot stand in for that live, covert test, because the regulation is looking for evidence that detection and response work against an adversary, not only that the plan reads well.

TIBER-EU, the ECB's framework (January 2025 edition), shows what a threat-intelligence-based red team test looks like in practice. It runs in preparation, testing and closure phases, requires at least 12 weeks of active testing and includes mandatory purple teaming. The ECB states that these tests produce no pass or fail result, so the output is a set of findings about people, processes and technology that the institution must act on. For a team comparing a tabletop with a red team, the practical question is whether the scenario has been validated against live controls. Ask your regulator or auditor whether your entity falls under DORA Article 26 or a national scheme, and whether scenario-based tests alone satisfy your current obligations.

If you are a high-baseline federal system or are mapping to NIST controls, check the CA-8 red team enhancements. NIST SP 800-53 Rev. 5 control CA-8 Penetration Testing includes an enhancement for red team exercises, and SP 800-53B Release 5.2.0 selects CA-8 and CA-8(1) only in the high baseline. Confirm with your assessor which baseline your systems fall under before you scope a red team, and document the scenario that will be tested, the decision makers involved and the detection evidence you will collect. Use the tabletop to rehearse roles and decisions first, then commission the live test to verify that the plan works against real controls.

What you receive from each exercise

This table lists the artifacts each exercise type leaves behind, so you can judge what your team will hold after the event. Read the rows in pairs, and note that the joint review is where most of the value appears in both formats.

Deliverable	Tabletop exercise	Red team exercise
Objectives and scope	Tabletop objectives and a scenario package with injects, discussion questions and expected decision points	Rules of engagement agreed in writing, covering targets, permitted techniques, time windows, stop conditions and named contacts
Facilitation and control	Facilitator notes and a discussion record capturing who decided what, and where the plan was unclear	Attack narrative and activity log showing the path the testers took, with timestamps kept by the testers
Evidence	Participant feedback forms and the discussion record, which show intent and reasoning rather than system behavior	Technical evidence such as captured access, affected hosts and data samples, handled under the agreed rules of engagement
Detection and response	Gaps in roles, escalation paths and communications as described by participants	Detection and response timeline showing which actions the defenders saw, when they saw them and what they did
Findings and remediation	Improvement items tied to plan sections, owners and due dates, recorded in the after action report	Findings with severity, reproduction steps and remediation advice, which should be validated after fixes are applied
Written summary	After action report, where CISA's Tabletop Exercise Packages provide a template	Final report and debrief, with the attack narrative and timeline reviewed alongside findings
Improvement plan	Improvement plan tracking changes to the incident response plan and training	Remediation plan and retest scope for controls that failed or were not detected
Where value is realized	Joint review of the discussion record and after action report with decision makers	Joint review of the timeline with defenders, confirming which techniques were detected and which were not

What drives cost and effort for each exercise

A tabletop and a red team exercise are paid for in different ways. Tabletop cost follows the people in the room and how much planning material already exists, while red team cost follows how much ground the testers cover and how long they operate unseen. The cards below separate the drivers for each format and list what to request in a written quote.

Tabletop participants and seniority

Cost rises with the number of people in the room and with how senior they are, because executives and board members take time away from other work. A tabletop with a small technical group costs far less to stage than one that brings in legal, communications, operations and leadership. Ask the provider how many roles the scenario covers and whether senior participants will attend the full session or a shortened version.

Tabletop scenario and facilitation time

A more complex scenario, with injects that branch across systems, vendors and regulators, needs more design and more facilitator hours before the session. NIST SP 800-84 describes tabletops as typically lasting two to eight hours depending on audience, topic and objectives, so the session length itself is a cost lever. Ask who writes the injects, how many facilitators attend and whether an after action report is part of the quote.

Tabletop preparation against existing plans

If incident response and contingency plans are current, the tabletop mainly tests them, and preparation is short. If the plans are outdated or missing, the exercise turns into a planning workshop and costs more in staff time and provider effort. Ask whether the quote includes a gap review of your plans, and whether CISA's publicly available Tabletop Exercise Packages will be used as a starting point to reduce custom design.

Adding a cyber range to a tabletop

A cyber range adds hands-on technical environment, which is a separate cost layer on top of the discussion format. It brings environment build, test data, instructor roles and staff time for technical teams. The cost is largely one-time for building the range and recurring for each run. Ask whether the range is provisioned in your infrastructure or the provider's, and who maintains it between exercises.

Red team scope and engagement depth

Red team cost follows the systems, physical sites and social engineering components in scope. Each added path, such as phishing, phone pretexts or site access, adds planning, authorization and testing time. Ask for the list of in-scope systems, the rules of engagement and whether physical or social engineering is priced separately, since NIST SP 800-115 includes a rules of engagement template in its Appendix B that is useful for comparing quotes.

Red team duration, testers and threat intelligence

Longer engagements, larger tester teams and deeper threat intelligence work all raise cost, and they also raise the value of the output. Threat-led programs such as TIBER-EU require at least 12 weeks of active testing, so schedule and staffing are fixed by the framework rather than negotiable. Ask how many testers will be assigned, how much of the threat intelligence is supplied by you and whether reporting and debriefs are included.

How to combine a tabletop and a red team in one program

Run the tabletop first. A covert red team exercise is a poor place to discover that the escalation contact list is out of date or that nobody knows who can approve isolating a production host. NIST SP 800-84 describes tabletop exercises as discussion-based, typically lasting two to eight hours, and suited to validating the content of incident response plans. Use that session to confirm named roles, escalation paths, decision authority for containment and the point at which legal or regulatory notification is considered. Ask each participant to demonstrate how they would reach their counterpart after hours. Gaps found here are cheap to fix. The same gaps found mid-engagement consume the red team's time and blur the question the exercise is meant to answer, which is whether defenders notice and respond.

Feed the red team's findings back into the next tabletop. The useful outputs are the attack path the testers took, the techniques that went unnoticed, the moments when defenders hesitated, and the time between the first malicious action and the first internal alert. Turn that attack path into the next tabletop scenario, and write discussion questions around the decisions it forced. Illustrative example: if testers moved from a service account to domain administrator without an alert, the next tabletop can ask who approves a credential reset at 2 a.m. and whether the on-call engineer has the access to do it. The CISA Tabletop Exercise Packages include scenario, discussion question and after action report templates that you can adapt, so the scenario stays tied to what the red team actually showed.

Treat the red team as one technique within a broader assessment. NIST SP 800-115 notes that organizations often combine techniques to reach an in-depth assessment at an acceptable level of risk, so a tabletop, a scheduled penetration test and a covert exercise can each cover a different question. For cadence, CIS Safeguard 18.5 asks for penetration tests at least annually, and Safeguard 18.4 asks that security measures be validated after each test so that detections cover the techniques the testers used. Confirm with your regulator, auditor or contract owner whether an annual test satisfies your obligations or whether a more frequent cadence applies. In any quote, ask who writes the after action report for each exercise, how findings move into the next scenario, and whether retesting after remediation is included.

Questions buyers ask before hiring outside help

How much does a tabletop exercise or red team engagement cost?

Cost depends on who is paid for what, and the written scope drives most of it. For a tabletop, the main components are facilitator preparation, scenario design tailored to your incident response and continuity plans, the session itself, and the after action report. For a red team, the main components are planning and rules of engagement, reconnaissance, the attack phase itself, reporting, and debrief. Ongoing retainers add recurring cost on top of any one-time work. DeployOpen does not publish a price list, so ask for a fixed-scope quote with deliverables and timelines written out, and compare quotes on the same scope. Ask each provider which items are included and which are optional.

How long does a tabletop exercise take compared with a red team?

NIST SP 800-84 says a tabletop typically lasts two to eight hours depending on the audience, topic and objectives, though preparation and the after action report take additional time. A red team runs far longer and its duration is set in the scope, not by a standard figure. Duration depends on the objectives, the size of the target environment, whether the team must reach an objective through social engineering or physical access, and how much time your defenders need to be tested fairly. Ask for the planned phases, the active testing window and the reporting window in the written scope before you commit.

What does a tabletop or red team need from our staff?

Both need named decision makers and technical owners, but the time and access they require differ. A tabletop needs the incident response lead, IT operations, legal, communications and business owners in the room for the full session, plus a reviewer for the plan documents. A red team needs a small set of sponsors who approve the rules of engagement, a point of contact who can stop testing, and a trusted group who knows the exercise is happening so they can respond without being warned in advance. Ask the provider what access, accounts and documents they expect before the work starts.

Can we run a tabletop exercise ourselves using CISA packages?

Yes, many teams do. CISA offers over 100 Tabletop Exercise Packages with template objectives, scenarios, discussion questions and references, plus templates for invitations, slides, feedback forms and an after action report. These packages cover cybersecurity, physical security and cyber-physical convergence. An internal run works best when someone experienced in facilitation owns the schedule, keeps discussion on decisions rather than technical detail, and captures gaps as tracked actions. An outside facilitator adds value when leadership wants an independent view or when internal staff are also the people being assessed. Confirm the package fits your sector and your plans before you use it.

Does a red team exercise need regulator approval or a legal authorization letter?

A written authorization from the organization that owns the systems is the baseline, and a legal authorization letter is standard practice before any covert testing begins. Whether a regulator must approve the exercise depends on your jurisdiction and sector. Under DORA, threat-led penetration testing applies to entities their competent authority identifies, and the TIBER-EU framework sets out how regulated firms run threat intelligence-based tests. Ask your regulator and your legal team which requirements apply to your entity before scoping. Your provider should also confirm how cloud providers, hosting providers and third-party systems are handled, since their permissions may be needed separately.

Which should we buy first, a tabletop exercise or a red team?

For most teams that have not tested their incident response plans recently, a tabletop comes first. It is discussion-based, requires no deployed equipment, and tests whether plans, roles and decisions hold up. A red team makes more sense once your detection and response capability has been validated at a basic level, because a covert attack against an immature program mainly shows known gaps. If you are a regulated entity facing a scenario-based or threat-led testing requirement, your regulator's expectations may set the order. Many organizations run a tabletop, fix the plan gaps, and then scope a red team against the scenarios the tabletop uncovered.

How DeployOpen scopes, delivers and supports these exercises

DeployOpen plans, runs and documents tabletop and red team exercises against your own environment and decision makers, not a generic template. Each engagement starts from a written scope that sets the objectives, the systems and the rules for what testers and facilitators may and may not do.

How we scope

Written scope fixes objectives, participants, in-scope systems and out-of-scope boundaries before any work starts.
Tabletop scenarios are agreed against your incident response and contingency plans so decisions can be tested directly.
Red team rules of engagement cover authorization, contacts, stop conditions and any social engineering limits you approve.

How we build

We design the scenario, injects and discussion questions, or the covert attack path, around the objectives you agreed.
Red team preparation confirms logging and alerting sources so the team knows what evidence the exercise should produce.
Testing runs against the systems in scope, and exercise activity is recorded so findings can be traced back to specific steps.

How we hand over

Deliverables include an exercise report, timeline of decisions or attacker actions, and findings ranked for remediation.
We walk through results with plan owners and technical teams, separating process gaps from detection and response gaps.
Documentation is handed over in your formats so your team can rerun the exercise without depending on DeployOpen.

How we support

Remediation support and retesting can be agreed in the original written scope or added as a separate piece of work.
Ongoing exercise programs, upgrades and continuous testing are available as retainers, priced from the written scope.
Confirm with us during scoping which follow-up work, retention of evidence and reporting formats you need from the start.

Tabletop exercise vs red team exercise