"We need a Red Team." – "Have you done a pentest yet?" – "What's the difference?"
This conversation happens every day. In board meetings, in tenders, in first calls with security vendors. The terms Red Team, penetration test, Purple Team, Blue Team circulate — often used interchangeably, often misunderstood, almost always wrongly commissioned.
This isn't a minor issue. Whoever commissions a penetration test when they actually need a Red Team engagement gets a list of CVEs — but no answer to whether their SOC would detect an ongoing attack. Whoever commissions a Red Team engagement when their security program still has no foundation burns budget on an exercise that delivers no usable result.
This post is both a glossary and a decision framework. Every color gets its definition, its purpose, its prerequisites — and a clear answer to the question: What do I actually need?
The most common misconception: "A Red Team is basically just a more thorough pentest." That's wrong. A pentest answers: What vulnerabilities exist? A Red Team engagement answers: Can an attacker reach their goal despite all countermeasures? Two fundamentally different questions.
Red, Blue, Purple, Black, Green: What each team does — and what it doesn't
- Simulates a real, targeted attacker with a concrete goal (e.g. access to production data)
- Operates covertly — the Blue Team doesn't know when or how the attack will take place
- Uses every available vector: physical, digital, social engineering, combined
- Measures success not by vulnerabilities found, but by whether the goal was achieved
- Timeframe: weeks to months. Result: proof of real resilience or a lack of detection
- Prerequisite: a functioning Blue Team that can actually be tested
- Operates and monitors the security infrastructure: SIEM, EDR, firewalls, IDS/IPS
- Detects, analyzes, and responds to security incidents (incident response)
- Maintains threat intelligence, detection rules, and security runbooks
- Carries out vulnerability management and patching processes
- Is the team that responds in a real event — and the one tested during Red Team exercises
- Run in-house or outsourced as MSSP / SOC-as-a-service
- Not a standalone team — rather a way of working where Red and Blue train together
- Red demonstrates live: "This is how I attacked." Blue analyzes: "What did we see? What didn't we see?"
- Goal: close detection gaps, improve alerting rules, develop playbooks
- Transparent and collaborative — no hide-and-seek between attacker and defender
- Ideal for teams that want to specifically build up their detection capabilities
- Prerequisite: a Blue Team in place and ready for the learning curve
- Specializes in physical attack vectors: building access, tailgating, lock picking, rogue devices
- Operates with zero prior knowledge of the target organization (black box / zero knowledge)
- No briefing, no floor plans, no internal contacts — a pure outside view, just like a real attacker
- In some organizations also: the team that runs operational physical security (guards, access control)
- Closely related to the Red Team — the difference lies in scope: Black = physical-first, with no prior information
- Result: the most realistic assessment of physical resilience, without home-turf advantage for the target company
- Implements the recommendations from pentests and Red Team engagements
- Translates security findings into development and infrastructure tasks
- Closes the gap between "vulnerability found" and "vulnerability fixed"
- Often not a standalone role — but dev and ops teams with a clear security mandate
- Without a Green Team, pentest reports are documents with no impact
- Measures success via Mean Time to Remediate (MTTR) of critical findings
Purple Teaming isn't a compromise between Red and Blue. It's a learning methodology. Whoever confuses Purple Teaming with a Red Team engagement expects an attack simulator and gets a workshop. Both are valuable — but they're not the same thing.
Why a penetration test is not a Red Team engagement
The penetration test is the most commonly commissioned security format — and the most commonly misunderstood. Not because it's bad, but because it was built for a specific purpose that has little in common with the purpose of a Red Team engagement.
What a penetration test is
A penetration test is a structured vulnerability search within a defined scope. The tester systematically looks for weaknesses in systems, applications, or physical environments — and documents them with a rating, proof of concept, and recommendation. The test has a clear start, a clear end, and a clearly defined scope.
Typical question: "What vulnerabilities exist in our web server / our access control / our internal network?" That's a technical inventory question. The answer is a prioritized list.
What a Red Team engagement is
A Red Team engagement is a goal-oriented attack simulation against a company's entire security architecture. The Red Team has a concrete goal — for example: access to financial reports, compromise of the domain controller, physical access to the data center. How it reaches that goal is open. Which vectors it uses is unknown. Whether it's even detected is the actual metric.
Typical question: "Could a targeted attacker reach their goal despite all our measures — and would we even notice?" That's a resilience question. The answer is a narrative with evidence.
| Characteristic | Penetration Test | Red Team Engagement |
|---|---|---|
| Goal | Find and document vulnerabilities | Achieve or fail a concrete attack objective |
| Scope | Clearly defined, limited | Open — all vectors allowed (within the rules of engagement) |
| Blue Team aware? | Usually yes (announced) or partially (unannounced) | No — covert operation is a core component |
| Vectors | Defined area (e.g. network only or physical only) | All: physical, digital, social engineering, combined |
| Duration | Days to a few weeks | Weeks to months |
| Metric | Number and severity of vulnerabilities found | Goal achieved yes/no, detection time, detection gaps |
| Result | Prioritized vulnerability list with remediation | Attack narrative, TTP mapping, detection gaps |
| Prerequisite | No specific security maturity required | Functioning Blue Team required |
| Cost | €5,000–50,000 (depending on scope) | €30,000–200,000+ (depending on duration and complexity) |
A Red Team engagement without a functioning Blue Team is pointless — there's nobody who could be detected or missed. If you don't yet have basic protective measures in place, you need a pentest first — not a Red Team.
From Yellow to White: What the other teams mean
Beyond the five core colors, an extended color spectrum has become established in the security community. Not all terms are standardized — they vary by organization — but the most important ones have taken hold as shared vocabulary.
The color terminology isn't a standard with an ISO number — it's a communication framework. What one organization calls a "Black Team," another calls "Physical Red Team." More important than the color is clarity about which question is meant to be answered.
What do I need, and when? The maturity model for security testing
The most important question isn't "What's the difference between a Red Team and a pentest?" — it's: "What do I need right now, at my current security maturity level?" The answer depends on what's already in place at the company and which question needs to be answered.
The most common misinvestment: a company at level 1–2 commissions a Red Team engagement because it "sounds impressive." The result: the Red Team finds trivial vulnerabilities that a simple pentest would have found more cheaply — and the Blue Team, which doesn't even run a SOC yet, can't answer the detection questions at all.
The second most common misinvestment: a company at level 3–4 commissions only a standard pentest each year because "that's enough for compliance." The result: vulnerabilities are found, but the actual question — do we detect an ongoing attack? — remains unanswered.
Decision tree: What should you commission?
- You don't know what vulnerabilities you have: Start with a vulnerability scan followed by a penetration test. First find out what's broken — then test whether anyone can exploit it.
- You've fixed vulnerabilities and want to know whether more exist: A penetration test with an expanded scope. Annually, after major changes to infrastructure or applications, and following regulatory requirements (NIS2, ISO 27001).
- You have a SOC or MSSP and want to know whether it would detect a real attack: A Red Team engagement. Define a goal, set the rules of engagement, tell the Blue Team nothing — and measure what happens.
- You want to specifically improve your detection capabilities: Purple Teaming. Not as a one-off exercise, but as an ongoing workshop process that improves detection rules, playbooks, and response times.
- You want to test physical security: A physical pentest with or without a social-engineering component. Can be commissioned as a standalone test or as part of a Red Team engagement — more on that in the post on Physical Pentesting.
- You need proof of compliance: A penetration test with a written report and CVSS rating. For NIS2, ISO 27001, PCI-DSS, or insurance requirements. A Red Team report is not a compliance document — it's a resilience report.
How physical security fits into this color landscape
Physical pentesting is not a standalone color team — it's a vector that can be embedded in several formats. A physical pentest in the classic sense is level 2: a structured search for physical vulnerabilities within a defined scope. A physical Red Team attack is level 3: a covert attack simulation in which physical access is one means among several to achieve a concrete goal.
The difference in practice: a physical pentest asks "Which doors can we open?" A physical Red Team engagement asks "Can we compromise the server room — and if so, by what route, and does anyone notice?" Same techniques, fundamentally different questions.
In our engagements, we combine both formats: a physical pentest delivers the vulnerability list, and a Red Team engagement built on top of it tests whether those vulnerabilities can be exploited in a real attack simulation — and whether the SOC or security personnel respond. More on the individual vectors in the posts on Visitor Management, REX Sensor Attacks, Rogue Devices, and Remote Recon to Physical Breach.
Physical security isn't a niche topic reserved for high-security facilities. It's the most commonly underestimated attack vector — because it sits outside the SIEM, generates no log, and triggers no EDR. A Red Team that ignores physical vectors is simulating an attacker from 2015.
Conclusion: The right color is the one that answers your current question
Red, Blue, Purple, Yellow, Black, White, Orange — the color landscape of security teams isn't an end in itself. It's a vocabulary for precise communication about which question is being answered by which method. Whoever understands the vocabulary can commission more precisely, budget more accurately, and better explain why a given investment is necessary.
The key takeaway: no format replaces another. A pentest doesn't answer the questions of a Red Team engagement. A Red Team engagement is no substitute for Purple Teaming. And a vulnerability scan is not a pentest. Whoever understands this hierarchy builds a security program that grows — instead of one that repeats the same pentest every year and wonders why resilience isn't improving.
Further reading: why an ISO audit doesn't replace any of these formats is explained in the post on ISO 27001 vs. Physical Pentest. What a physical pentest concretely tests is covered in the full series on physical attack vectors on this blog.
Which format do you need — and why?
We'll help you define the right engagement for your maturity level: from your first physical pentest to a full Red Team program. Free initial consultation.
Request a consultation →