Red Team vs Penetration Test: Which Does Your Company Need?

A penetration test finds and validates as many vulnerabilities as possible inside a defined scope, and the report is a list of what an attacker could do. A red team exercise is objective-driven and stealthy: a small team picks a goal, such as reaching a specific dataset, and pursues it while trying not to be caught, which makes the deliverable a story about your detection and response rather than a list of flaws. Both are useful. Only one of them is useful to a company that cannot see an attacker in its own logs, and that population is larger than the market admits: in a 2022 assessment of a large critical infrastructure organization with what it described as a mature cyber posture, CISA's red team gained persistent access, moved laterally across multiple sites and reached systems adjacent to sensitive business systems, and the organization did not detect the activity even when the team deliberately tried to trigger a response (CISA Red Team Shares Key Findings to Improve Monitoring and Hardening of Networks, February 2023). Read that as the prerequisite argument it is, not as a sales pitch for red teaming.

This article sets out what each exercise actually buys, the readiness test that decides which one you should purchase, the middle option most companies should consider instead, and the narrow set of cases where a regulator makes the decision for you.

Key takeaways

• A penetration test measures your vulnerabilities. A red team measures your detection and response. Buying the second without the first tells you almost nothing you can act on.
• CISA's own red team went undetected through an entire assessment at an organization with a mature security posture, and multi-factor authentication was what stopped it reaching one sensitive system.
• The readiness test is concrete: working detection someone actually watches, a rehearsed response plan, and a completed penetration test with the findings closed.
• Purple teaming, where attackers and defenders work together with the exercise visible to both, is usually the better step after a penetration test and before a red team.
• Regulated financial entities are the main exception. DORA Article 26 puts threat-led testing on the entities supervisors identify as mature and systemically important, and exempts microenterprises.

Two different questions

The clearest way to tell these apart is to ask what a successful engagement produces.

A penetration test produces coverage. The tester works methodically through the agreed scope, following something written down such as PTES or the OWASP Web Security Testing Guide, and the goal is to find as much as possible in the time available. Your team usually knows the test is happening. Nobody is trying to evade your monitoring, because evasion would spend hours that could go toward finding the next issue.

A red team produces a narrative. The team picks an objective, chooses a plausible starting point, and works toward the goal while attempting to stay below your detection thresholds, usually emulating techniques catalogued in MITRE ATT&CK. Scope is broader and depth is narrower: they need one path that works, not every path that exists. Most of the organization does not know it is happening, which is the point, because the thing under test is the people and tooling that should catch it.

So the deliverables answer different questions. A pentest report says: here are the doors that are unlocked. A red team report says: we walked through this one, here is exactly when your team could have noticed and did not.

The readiness test, stated as a checklist

Before buying a red team, three things need to be true. Not aspirationally true. Actually true.

You have detection that a person watches. Endpoint detection deployed to most endpoints, logs centralized somewhere searchable, and a named human or service whose job includes looking at alerts within a defined time. A red team against an environment with no monitoring produces a report saying you were not monitoring, which you could have written yourself.

You have a response plan someone has rehearsed. Not a document. A plan whose steps have been walked through in a tabletop exercise, with the phone numbers checked. If the exercise triggers a real response, that response is half of what you are paying to test, and an unrehearsed one produces noise instead of signal. Our piece on when to call an incident response firm covers the readiness side of that.

You have already run a penetration test and closed the findings. A red team that gets in through an unpatched perimeter service has taught you something a much cheaper engagement would have. If your last test produced findings that are still open, close them before spending on the more expensive exercise.

The CISA assessment is the argument for taking the first item seriously. That organization was mature by its own assessment and by CISA's description, and it still did not see a red team that spent weeks in its network and eventually stopped hiding. The advisory's own recommendations lead with establishing a baseline of normal activity, tuning appliances to detect anomalous behavior, and enforcing phishing-resistant multi-factor authentication, which was the control that blocked access to one sensitive system. Those are things to build, and building them is not what a red team engagement does.

Purple teaming: the step most companies should buy instead

Between the two sits an exercise that is undersold because it is less exciting to describe.

In a purple team engagement the offensive testers and your defenders work in the same room, or the same channel, and the attack is visible to both as it happens. The testers execute a technique. The defenders check whether it produced telemetry, whether an alert fired, and how long it took to reach a human. If nothing fired, the tuning happens on the spot, and the technique is run again.

The economics are better than a red team for most companies. A red team tells you that you missed something, once, after several weeks. A purple team tells you which of thirty techniques you can see, in days, and improves your coverage during the engagement rather than in a report afterward. You lose the realism of an unaware defender, which matters when the question is whether your team will perform under genuine surprise. For a company still building coverage, that is not yet the question.

When a regulator decides for you

A minority of organizations do not get to sequence this, and it is worth knowing whether you are one.

Under the EU's Digital Operational Resilience Act, Article 26 places threat-led penetration testing on financial entities that supervisors identify as ICT-mature and systemically important, with microenterprises exempted and simplified frameworks excluded from the requirement. Identified entities run the exercise at least every three years, and the tester rule is more specific than the alternation it is often described as. A financial entity that is permitted to use internal testers must contract external testers every three tests, so two in-house exercises can be followed by an external one, not one and one. Credit institutions classified as significant under Article 6(4) of Regulation (EU) No 1024/2013 do not get the choice at all and must use external testers every time. Budget the cadence off that rule rather than off an alternating one. If you are in scope, the exercise is not optional and the sequencing question is answered. Whether DORA reaches you at all, including through vendor contracts rather than direct supervision, is covered in does DORA apply to US companies.

Comparable frameworks exist for regulated finance elsewhere, including the European Central Bank's TIBER-EU framework and the Bank of England's CBEST scheme, both of which run intelligence-led exercises against systemically important institutions. The common feature is that they apply to institutions that already run mature detection programs. The regulators are testing the top of the maturity curve, not creating it.

For everyone else, including nearly every venture-backed software company, no framework requires a red team. CMMC Level 3 requires annual penetration testing including ad hoc human testing under enhanced NIST SP 800-172 practices, which is a different and lesser thing.

What a red team costs you beyond the invoice

Even when you are ready, the invoice is not the whole cost, and buyers routinely underestimate the rest.

The exercise runs for weeks rather than days, and your defenders spend real hours investigating activity that turns out to be authorized. A trusted agent inside your organization has to know the exercise is happening, hold the authorization letter, and be reachable at any hour to stop the exercise if a genuine incident occurs during it. Legal and executive sign-off is heavier, because the rules of engagement contemplate social engineering against your staff and, sometimes, physical access attempts.

And the debrief is the deliverable. A red team report that is read once and filed has wasted the entire engagement, because the value is in the timeline reconstruction: at which step could we have seen this, what would have had to be true, and what are we changing. Budget the days for that conversation before you book the exercise. If a firm's proposal does not include a joint debrief with your defenders, it is selling you the fun part and skipping the useful part.

For the actual pricing conversation, including where red team engagements sit relative to standard testing, our penetration testing cost breakdown is the only page on this site that publishes ranges, deliberately.

When you should not buy either

The uncomfortable version.

If you have no security program at all, meaning no multi-factor authentication rollout, no patching cadence and no centralized logging, neither exercise is your best next dollar. Both will produce reports confirming what you already suspect, at consulting rates. Spend on the fundamentals, then test.

If you have a program but have never had a penetration test, buy the penetration test. This is the most common case we see and the answer is not close.

And if someone has proposed a red team to you because your competitors buy them, or because it sounds like the mature choice, ask a specific question: what will we do differently if the team is not detected? If the honest answer is "build detection", then build detection, and spend the exercise budget there. We have talked companies out of red team engagements for exactly this reason, and it is a better outcome than a report nobody can act on.

Where Top Floor fits

Our penetration testing practice covers network, application, API, cloud, social engineering, wireless and physical assessments, scoped and stated in writing before anyone quotes. That is the engagement most companies asking about red teaming actually need first, and we will say so on the scoping call.

Where the honest answer is that you need detection before you need an adversary, that is program work rather than testing work: our vCISO engagements build the monitoring and response capability, and our incident response practice covers the plan and the rehearsal that make any adversary simulation worth running. The related question of whether a retainer earns its keep is treated in is an incident response retainer worth it.

How to decide this week

Ask your team one question and time the answer: if an attacker logged in with valid credentials from an unusual location an hour ago, how would we know? If the answer involves a system nobody watches, you have your sequencing.

Then look at your last penetration test report. If findings from it are still open, closing them is worth more than any new engagement, and it is the prerequisite for the next one being meaningful.

If both of those are in good shape, price a purple team exercise alongside any red team proposal, and compare what each promises to leave you with. One leaves a narrative. The other leaves tuned detections.

Frequently asked questions

What is the difference between a red team and a penetration test?

A penetration test is coverage-driven: testers work through a defined scope to find and validate as many vulnerabilities as possible, usually with your team's knowledge, and the deliverable is a prioritized list of findings with evidence. A red team exercise is objective-driven and stealthy: a small team pursues a specific goal, such as reaching a particular dataset, while trying to evade detection, typically emulating techniques from MITRE ATT&CK, and the deliverable is a narrative of how they got there and where you could have caught them. The first measures your vulnerabilities. The second measures your detection and response.

Do we need a red team for compliance?

Almost certainly not. No mainstream framework requires one for ordinary commercial organizations. SOC 2's criteria never require penetration testing (the words appear only in a point of focus under CC4.1), PCI DSS requires internal and external penetration testing rather than adversary simulation, and CMMC Level 3 requires annual penetration testing including ad hoc human testing. The main exception is regulated finance: DORA Article 26 places threat-led penetration testing on entities that supervisors identify as ICT-mature and systemically important, and comparable schemes such as TIBER-EU and CBEST target systemically important institutions. If a vendor tells you a red team is a compliance requirement, ask which requirement number.

What should we have in place before a red team exercise?

Three things, all of them literally true rather than planned. Detection someone watches, meaning endpoint tooling deployed broadly, logs centralized and searchable, and a named person or service reviewing alerts on a defined schedule. A response plan that has been rehearsed in a tabletop exercise, with the contact details verified. And a completed penetration test whose findings are closed, so the exercise does not spend its budget walking through a door you already knew was open. Without those, the report will tell you that you were not monitoring, which is a conclusion you can reach for free.

Is a purple team exercise a good substitute?

For most companies below enterprise scale, yes, and often a better purchase. In a purple team engagement the testers and your defenders work together with the activity visible to both, so each technique is checked for telemetry and alerting as it runs, and gaps are tuned during the engagement rather than reported afterward. You give up the realism of an unaware defending team, which is exactly what a red team is for, but you gain measured coverage across many techniques in a fraction of the time. The usual sequence is a penetration test first, purple teaming next, and a red team once detection is good enough that being missed would be genuinely surprising.