Red team vs pentest — engagement shape

TL;DR: A penetration test is a breadth-first hunt for vulnerabilities across an agreed scope, optimised for coverage and a remediation backlog. A red team is a narrow, goal-oriented adversary simulation that tests detection and response, often runs for months, and stays covert from the blue team. Purple team merges the two for collaborative tuning, and tabletop exercises are paper-only walkthroughs. This note compares them so you can scope the right engagement; pair with pentest-proposal-and-scoping and purple-team-feedback-loop.

Why it matters

Customers regularly request “a pentest” when they actually need an adversary simulation, or buy a “red team” when their controls are not mature enough to benefit. Selling the wrong engagement wastes budget, frustrates the blue team, and produces a report nobody acts on. Understanding the shape of each option lets you push back during scoping and align deliverables with the buyer’s maturity. It also matters for the tester: pentest pacing (find, prove, move on) is very different from red-team pacing (slow, deliberate, opsec-aware), and mixing the two leads to burned tooling and shallow findings. See burnout-and-pipeline for the personal-cadence side of this.

Engagement axes at a glance

Objective

Pentest — enumerate vulnerabilities in scope, prove impact, hand over a prioritised list. Coverage matters more than stealth.
Red team — achieve a defined objective (steal “crown jewels”, reach a specific dataset, demonstrate ransomware-equivalent impact) while exercising detection and response.
Purple team — collaborative; attacker shows TTP, defender tunes, repeat (purple-team-feedback-loop).
Tabletop — discussion-only walkthrough of a scenario with stakeholders; no live systems touched.

Scope

Pentest — broad but bounded: a web app, an internal /24, a mobile app, an external perimeter. Out-of-scope assets are off-limits.
Red team — goal-bounded rather than asset-bounded. Anything reachable in pursuit of the objective is usually fair game, subject to a rules-of- engagement (RoE) document and legal carve-outs (no patient-safety systems, no production payment rails without safety nets, etc.).
Purple team — scoped to specific ATT&CK techniques or kill-chain phases.
Tabletop — scoped to a scenario narrative.

Engagement length

Pentest — 1-4 weeks of testing plus 1-2 weeks reporting.
Red team — 1-6 months end-to-end; recon and infrastructure stand-up alone can take weeks.
Purple team — sprints of days to a couple of weeks per technique batch.
Tabletop — half a day to two days.

Stealth and opsec

Pentest — overt. Scanners are loud, exploitation is announced in advance, the SOC is told to expect traffic from listed IPs.
Red team — covert. Infrastructure is dedicated and burned after use, payloads avoid noisy syscalls, exfil is paced. See detection-engineering-pyramid-of-pain for why this matters.
Purple team — overt by design; both sides watch the same screen.
Tabletop — n/a.

Authorisation and blue-team awareness

Pentest — blue team and IT are usually informed; sometimes only a small “trusted agent” list knows for an “announced but unmonitored” test.
Red team — blue team is blind. A small “white cell” of executives, legal, and a single SOC trusted agent holds the authorisation letter (“get out of jail” card) and can call off the engagement.
Purple team — everyone knows.
Tabletop — everyone in the room knows.

Reporting

Pentest — vulnerability-centric: finding, CVSS, evidence, remediation. Pattern in report-writing-for-pentesters.
Red team — narrative-centric: timeline of the operation, kill-chain diagram, detections that fired vs missed, recommendations for the defenders’ programme, not just patches.
Purple team — per-technique scorecards: detected / partially detected / missed, with the SIEM rule diff that closed each gap.
Tabletop — minutes, decisions, action items.

MITRE ATT&CK alignment

A pentest report can be tagged with ATT&CK techniques but rarely needs to be; CVSS and CWE carry more weight for the remediation backlog.
A red team report should map every action to ATT&CK and note which detections fired. This lets the defender update their detection coverage matrix and feed siem-detection-use-case-catalog and edr-rules-as-code-from-attack-patterns.
Purple team sprints are usually organised by ATT&CK tactic (Initial Access -> Execution -> Persistence -> …), running atomic tests (atomic-red-team-emulation-deep) and tuning detections per technique.
Threat-intel-led red teams (TIBER-EU, CBEST, CORIE) require the scenario to be derived from a real adversary profile — see apt-tradecraft-russian-svr-fsb, apt-tradecraft-chinese-mss, apt-tradecraft-dprk-lazarus, apt-tradecraft-iranian-irgc, or ransomware-affiliate-playbook depending on the industry.

When each is appropriate

Pick a pentest when

The asset is new or recently changed and has not been tested.
Compliance (PCI DSS, SOC 2, ISO 27001) requires periodic testing — see pci-dss-4-implementation, soc2-vs-iso27001.
The buyer wants a remediation backlog they can hand to engineering.
The security programme is young; there is no SOC to test yet.

Pick a red team when

The buyer already runs a SOC and has tuned detections.
Leadership wants evidence that controls work end-to-end, not that patches are applied.
A regulator mandates threat-led testing (TIBER-EU, CBEST, CORIE, DORA TLPT).
Recent incidents (or peers’ incidents — see case-study-snowflake-2024, case-study-okta-2023-support-system, case-study-3cx-supply-chain) motivate testing the response playbook.

Pick a purple team when

The SOC exists but coverage is uneven and the buyer wants measurable improvement, fast.
A red team has just finished and the gaps need closing before the next one.
Engineering capacity exists to write detections in the same week the technique is demoed.

Pick a tabletop when

The decision-making chain has never rehearsed an incident.
A new regulation (NIS2, nis2-implementation; GDPR breach notification, gdpr-incident-implications; HIPAA, hipaa-security-rule) changes who must be called and when.
Budget or legal constraints prevent live testing of a system (life-safety, OT, certain financial rails).

Defensive baseline (buyer-side)

Before commissioning a red team, run a siem-detection-use-case-catalog gap review and at least one atomic-red-team-emulation-deep sprint. Otherwise the red team will produce a report of “we did everything, nothing fired”, which is true but unactionable.
Maintain a single RoE template that covers both pentest and red team, with carve-outs (no DoS, no destructive actions, safe-list of life-safety systems). See pentest-proposal-and-scoping.
Keep an out-of-band channel (signed PDF authorisation letter + named contacts at security, legal, and exec) so a covert engagement can be paused in minutes when a real incident overlaps.
Track detections-as-code so purple-team outputs survive staff turnover (edr-rules-as-code-from-attack-patterns).

Workflow to study

Read your last three pentest reports. Count findings vs detections that fired during testing. If detections fired but findings still got proved, that is a pentest result, not a red-team result — note the difference.
Pick one APT report relevant to your sector and design a red-team scenario from it. Compare its scope and stealth requirements against your last pentest scope to feel the gap.
Run an atomic test for one ATT&CK technique end-to-end: execute, observe SIEM, tune, re-execute. That is one purple-team loop.
Draft a one-page tabletop scenario for a ransomware impact day. Walk it through with a friend playing CFO. Notice how different the questions are from a pentest debrief.
Re-scope a real RFP from “we want a pentest” to either pentest, red team, or purple team based on the buyer’s maturity. Defend the choice in a paragraph — that paragraph is the skill this note is teaching.

References

MITRE ATT&CK — Adversary Emulation Plans: https://attack.mitre.org/resources/adversary-emulation-plans/
TIBER-EU framework (ECB): https://www.ecb.europa.eu/paym/cyber-resilience/tiber-eu/html/index.en.html
CREST — Red Team Guide: https://www.crest-approved.org/membership/crest-defensible-penetration-test/
NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment: https://csrc.nist.gov/publications/detail/sp/800-115/final
CISA Tabletop Exercise Packages (CTEPs): https://www.cisa.gov/cisa-tabletop-exercise-packages
Red Canary — Atomic Red Team: https://atomicredteam.io/