Red teaming vs penetration testing: which do you need?
If you have never had an internal test, buy the penetration test. It is cheaper, it finds more defects per pound, and it produces the document your customers and auditors keep asking for. A red team answers a different question: whether your organisation would notice and cope with someone competent already inside. That question is worth money, but only once there is somebody whose job it is to notice.
What is the actual difference?
The success condition. A penetration test asks whether a defined system can be broken into and enumerates the ways, working breadth-first across everything in scope. A red team is given an objective an attacker would care about, such as approving a payment, reading a named dataset or obtaining cluster-admin, and reaches it by the quietest route available. The first produces a list of weaknesses. The second produces a rehearsal of an incident.
That shows up in method. A tester runs noisy tooling deliberately, because coverage is the product and being detected does not matter. A red team abandons techniques that work but announce themselves, spends most of its time on discovery and credential access rather than exploitation, and will happily leave five exploitable flaws untouched because the objective was reachable without them. A red team report is therefore an incomplete inventory by design, which surprises buyers who expected both.
The test to apply to any proposal: ask what counts as success. If the answer is a list, you are buying a penetration test whatever the cover page says. If the answer is a sentence describing something an attacker achieves, and there is a plan to record what your defenders did while it happened, you are buying a red team.
Why do most buyers want the cheaper one?
Because the thing they actually need to produce is evidence, and a red team does not produce it. Customer security questionnaires, ISO 27001 audit conversations and PCI DSS testing requirements all expect scoped technical testing with defined coverage and a remediation trail. A red team report says an objective was achieved through one path, which satisfies nobody asking whether your payment application was tested.
The economics point the same way. A red team runs over weeks of elapsed time, needs a small group of insiders managing it, consumes senior attention at the debrief, and returns fewer fixable defects than a fortnight of application testing would. Paying red team rates to discover an unpatched edge device is an expensive way to learn something a scan would have told you.
There is also an ordering problem. If your patching is behind and your logging is partial, a red team will succeed quickly through the first weak thing it finds, and the report will describe that path rather than your organisation. You will have paid for a narrative when you needed a backlog.
The sequencing argument follows from that. Scoped testing produces a backlog you can work through, and working through it is what changes the outcome of a later red team. Organisations that run application and infrastructure testing for two or three cycles first tend to get red team reports about their monitoring rather than about their patching, which is the report they were trying to buy in the first place.
What does each engagement actually produce?
Different artefacts, aimed at different readers. The comparison below is the one worth putting in front of whoever is approving the spend, because the mismatch between what was bought and what was needed is usually visible in the last column.
| Engagement | Success looks like | Typical elapsed time | What it does not tell you |
|---|---|---|---|
| Vulnerability scan | A current inventory of known issues | Continuous, automated | Whether anything is reachable or exploitable |
| Web or external penetration test | Ranked findings with reproduction steps | One to three weeks | Whether anyone would notice the attempt |
| Internal or assumed-breach test | Paths from a foothold to sensitive access | Two to three weeks | How your response team performs under pressure |
| Purple team exercise | Detections written and re-tested | Days per technique, ongoing | Whether a real adversary would choose that technique |
| Red team | Objectives reached, with a defender timeline | Four to twelve weeks | A complete list of your vulnerabilities |
| Threat-led test under a regulator framework | Scoped emulation, evidenced to a supervisor | Months, including scoping | Anything you were not required to include |
Where does container and cloud testing fit?
Mostly on the penetration test side, and it is the gap in most programmes. An image scanner and a Kubernetes benchmark tell you about packages and configuration. Neither tells you whether an attacker who gets code execution in one pod can reach the rest of the cluster, and that is the question that decides how bad a single vulnerable dependency turns out to be.
The chain a red team exercises is specific. Execution inside a workload, then container and resource discovery, then the service account token mounted into the pod, then whatever the associated role permits: listing secrets, creating pods, or running commands in other containers. Beside that sits the escape route, a host path mount or an over-permissioned security context, and the node's own cloud credentials via the instance metadata service. Every link is individually defensible, which is why scanners do not model it and why the chain survives.
Run the cheap version of this test yourself this week. Pick one production namespace, and from a shell in a running pod check three things: what the mounted service account is permitted to do against the API, whether the cloud metadata endpoint answers, and whether any of it appears in an audit log you can query afterwards. If the third answer is no, you have learned that a red team would go undetected, and you learned it for free.
What does a red team cost beyond the fee?
A small group of people who must know and cannot tell anyone. Someone senior has to authorise it, at least one trusted contact has to be reachable to confirm activity is yours, and both have to keep the exercise from leaking to the team being measured. Organisations that cannot hold that arrangement for six weeks should run an announced assumed-breach test instead, which loses some realism and none of the technical value.
There is operational risk too. Live testing occasionally breaks something, and the mitigations are contractual and procedural rather than technical: stop conditions, out-of-band contact, and an agreed blast radius. Budget for the possibility that a genuine incident happens mid-engagement and the exercise has to pause while everyone works out which of the two events they are looking at.
There is also the cost of scope you cannot authorise. Modern estates run on other people's systems, and every SaaS tenancy, managed endpoint contract and payment provider in the path is a boundary the testers must respect. Mapping those boundaries and obtaining consent where it is available takes weeks of somebody's time before any testing starts, and it is the most common reason a start date slips.
The last cost is the one people underestimate. Half the value of a red team sits in a joint debrief where the attack timeline is put beside the defender timeline and the gaps are read off. If nobody can free the relevant people for a day, buy something else.
How do you tell what a proposal is really offering?
Read how it is priced. Per IP address, per application or per day of testing is penetration test pricing, and that is fine as long as the label matches. Red team proposals price the objective and the elapsed window, because the effort is spread thin over weeks rather than concentrated on a target list.
Then look for four things a real red team proposal contains: objectives written as outcomes rather than systems, a description of the command and control infrastructure and how it will be kept separate from your production traffic, a named deconfliction contact and stop conditions, and a report structure that includes a timestamped narrative of every action taken. The narrative is the tell. Without it, no detection assessment is possible, and the detection assessment is the reason to buy the thing.
Ask who will actually be on the engagement. This is a small-team craft, and the difference between people who have run covert operations against monitored estates and people who do application testing under a new label shows up in conversation rather than in a brochure. Ask for names, ask what they did on their last three engagements, and ask what got them caught.
Finally, ask what the supplier will do if they achieve the objective in the first week. A good answer involves resetting to a new starting position and going again to test a different detection surface. A weak answer involves writing the report early.
Common questions
- Is red teaming better than penetration testing?
- No, they answer different questions. A penetration test enumerates weaknesses across a defined scope and produces the coverage evidence auditors and customers ask for. A red team pursues a single attacker objective by the quietest available route and measures whether your organisation detects and responds. If you have no team whose job is to notice, the red team result is predictable and the penetration test is the better purchase.
- How much more does a red team cost than a penetration test?
- Enough that the comparison is rarely useful, because the units differ. Penetration tests are priced per application, per IP range or per tester day and run for one to three weeks. Red teams are priced against an objective over an elapsed window of four to twelve weeks, and the fee excludes the internal cost of a trusted contact, an authorising executive and a full debrief with your response team.
- Does a red team satisfy audit or compliance testing requirements?
- Usually not on its own. Frameworks that require technical testing generally expect defined scope, stated coverage and a remediation trail, and a red team deliberately provides an incomplete inventory. Some financial regulators do require threat-led testing, which is a distinct and heavily scoped exercise. Check what your specific obligation names before assuming a red team substitutes for scoped penetration testing.
- Can a red team test Kubernetes and container workloads?
- Yes, and it is where the technique differs most from scanning. The interesting chain is execution in one pod, then discovery, then abuse of the mounted service account token, then whatever its role permits, then escape to the host or use of the node's cloud credentials via the metadata service. Scanners assess each link separately and so never report the chain, which is why it commonly remains open.
- What is the difference between red teaming and vulnerability scanning?
- A scanner matches installed software against vulnerability databases and reports every match, with no knowledge of reachability. A red team ignores most of that output and pursues one objective by the path least likely to be noticed. The scanner tells you what is present. The red team tells you what an attacker would do with it and whether anybody would see them doing it.
