Pen test vs. BAS vs. red team vs. tabletop: What does your team need?

• Pen tests find exploitable holes at a point in time. Threat emulation and breach and attack simulation (BAS) check whether your detections fire on known attacker techniques. Red teams test detection and response end to end, under real pressure. Tabletops test your plan, your people, and how they make decisions. 
• Pen tests run on their own track, typically dictated by compliance requirements. For testing detection and response, scale by operational maturity: start with an operational tabletop exercise, then graduate to BAS or threat emulation, and culminate in a full-scope red team. 
• Skipping foundational steps means paying red team rates to discover stale escalation contacts and unmapped service accounts, rather than evaluating how effectively your security operations center (SOC) detects and responds to real threats.
• Finally, complete the feedback loop: transform verified attack paths from the red team engagement into realistic scenarios for executive tabletop exercises. This lets leadership practice high-stakes decisions against an attack that actually worked in your environment. 

Tabletop exercises test your plan and your people. BAS and threat emulation test your detections. Penetration tests uncover technical vulnerabilities in isolation, whereas red team engagements evaluate the entire defensive stack under real-world pressure. Pen tests follow their own compliance-driven schedule. For everything else, most teams should baseline with tabletops and threat emulation or BAS before moving to a full-scope red team, because each step makes the next one worth more.

The four options at a glance

Read left to right and cost generally goes up. Apart from the pen test, so does scope: each exercise tests more at once. That’s great when you’re ready for it. When you’re not, you pay premium rates to learn what a cheaper exercise would have told you.

For definitions of each category, start with our explainer on what breach and attack simulation is. This post is about choosing.

Tabletop exercise: Test your plan and your people

A tabletop exercise is a guided walk-through of an incident. Someone describes a scenario, like a compromised admin account at 4pm on a Friday, and the team talks through what they’d do. Who gets paged? Who decides to take a server offline? Who calls legal, and who updates the CEO?

There’s no tooling, no lab, and nothing touches production. A tabletop surfaces the problems no scanner will ever find, like an IR plan that lists an escalation contact who left last spring, or a comms plan that assumes Slack is up during an outage that takes Slack down.

The limit is that a tabletop tests what people say they’ll do. It’ll still expose technical gaps, like a detection handoff nobody owns or a log source nobody can query, but it can’t tell you whether your endpoint detection and response (EDR) tool will actually alert on credential dumping.

If you’ve never run one, our guide to incident response tabletop exercises covers the basics. Oh Noes!, our free tabletop game, runs in under two hours without an outside facilitator. Real-world tabletops frequently uncover critical technical integration gaps, detection handoff issues, and tooling visibility deficiencies, so they shouldn’t be overlooked. Tabletops scale, too. A two-hour walk-through with the SOC is cheap. A cross-functional exercise with executives, legal, and comms ties up your most expensive calendars, so save that one for later.

Threat emulation and BAS: Test your detections 

Breach and attack simulation (BAS) is continuous, automated tool-based testing of your security controls. Threat emulation is targeted, human-led adversary simulation mapped to specific threat actors. 

Threat emulation means simulating a realistic attacker, with the focus on what happens after they get in. Our SOC uses it to train analysts. We map exercises to the MITRE ATT&CK framework, run techniques like credential dumping and lateral movement over Windows Remote Management (WinRM), and watch whether the alerts fire and whether analysts can follow the trail. We wrote up why we love threat emulation exercises and how to build your first one.

BAS is the repeatable, often automated version. A BAS tool runs a library of known techniques against your environment on a schedule and reports which controls caught them. Threat emulation is usually hands-on and scenario-driven. BAS is built for frequency.

Either way, you come out with a coverage map, showing which techniques trigger an alert and which slip through.

The limit runs the other way from a tabletop. Threat emulation and BAS tell you whether your tools see known techniques. They say much less about whether your people make good calls once the alert lands.

Penetration test: Find exploitable weaknesses

A penetration test is a time-boxed engagement where testers try to find and exploit weaknesses inside an agreed scope, like an external web app, an internal network segment, or a cloud account. You get a report of what they found, ranked by severity, with steps to reproduce.

Your industry may require them. Either way, a pen test measures what the testers could do, not what your defenders saw. Many pen tests run with the SOC told to stand down, so the report says nothing about whether anyone would have noticed. That’s fine if you want a fix list. It’s a gap if you assumed the pen test also checked your detection and response.

Pen testing asks, “Where are the holes?” The other three ask, “What happens when someone uses one?” That’s why pen testing runs on its own schedule, often set by compliance.

The catch: a pen test is a snapshot. It shows where the holes were during the test window, not whether anyone would notice someone using one next month. 

Red team engagement: Test everything under pressure

A red team engagement is an objective-driven attack simulation. Instead of cataloging vulnerabilities, it tests whether your team can detect, investigate, and respond to a realistic adversary. Findings can feed a purple team loop, where attackers and defenders work together to tune detections. 

The red team gets a goal, like obtaining a VIP’s credentials, reaching a segmented part of your network, or pulling customer data out, and uses whatever realistic path gets them there.

Your defenders respond as if it’s real, because to them it looks real. That’s what makes red teaming the most complete test of the four. It exercises detection, investigation, remediation, and communication together, and it shows how they hold up under stress.

The questions worth measuring come straight from the response side. How long did it take to spot the red team, and at what MITRE ATT&CK tactic? How long to remediate, and what got in the way? As we’ve written before, the emphasis of a red team should be on response.

It’s also the most expensive option, and it needs real setup: clear objectives, rules of engagement, and a deconfliction process so your team can confirm whether suspicious activity is the red team or an actual attacker.

How to sequence security exercises by maturity 

Build up by maturity, which also happens to mean cheapest first. Each exercise clears out the obvious failures, so the next, more expensive one finds problems you couldn’t have found a cheaper way.

Skip that and the red team report ends up telling you things a two-hour tabletop would have. We see this from the SOC side. We treat red team activity in a customer environment like a real threat, and we’ve waited more than 12 hours for confirmation that something we found was authorized testing. That’s a deconfliction gap, and a tabletop would have caught it for the cost of a conference room.

Remediation is the other common miss. A red team moving laterally with a service account (call it sql_boss) looks like an easy win: disable the account. But what does sql_boss run? Is it the backend of a business-critical app? Teams that haven’t talked through that question beforehand either freeze or break something.

Here’s the order we’d recommend:

1. Tabletop exercise. Start with an operational walk-through to fix the plan: owners, escalation paths, communication, and deconfliction. Save the executive version for later.
2. Threat emulation or BAS. Confirm your detections fire on the techniques that matter to you, and close the gaps.
3. Penetration test. This one runs on its own track, on whatever cycle compliance or risk demands. It can overlap with the others.
4. Red team engagement. Go in with clear objectives and a tested response process, so the findings are worth the price.

Then loop. Use the red team’s attack path as the scenario for the next tabletop exercise. Running these on a schedule turns one-off exercises into a cybersecurity simulation training program.