Field Notes / Offensive Security
Red team exercise vs penetration test: which one answers the question your board is asking
A penetration test tells you which weaknesses in a defined scope an attacker can use. A red team exercise tells you how far a determined attacker gets towards one objective, and whether anyone on your side notices. Here is what each one hands you, how they differ in scope, secrecy and length, and how to choose.
01 What a penetration test hands you
penetration tester starts with a list: the applications, hosts and accounts in scope, and the ones off limits. They map that scope from the outside, attack what they find, prove which weaknesses open a door, and follow each foothold to show what it reaches. Your IT team usually knows the test is running, so nobody wastes a night chasing it.
You walk away with coverage. Every finding is a named weakness with proof: the request that worked, what it reached, and the fix. Where the tester could not get through, the report says so and shows why. A defined scope usually takes a working week to a fortnight of testing, with the report following within a few days.
Auditors and customers ask for this test by name. PCI DSS v4.0, for example, requires external and internal penetration testing at least once every twelve months PCI DSS v4.0, 11.4 . Security questionnaires and cyber insurers ask the same question. A penetration test is how you answer it with evidence.
Testers work inside those edges by design. They do not phone your help desk unless that is in scope, and they do not try to stay hidden from your monitoring, so the test tells you little about whether your team would spot a real intruder.
02 What a red team exercise hands you
red team starts with a goal. You name what would hurt most: the customer database, the payment system, a director’s mailbox. The operators then try to reach it the way a criminal group would, by whichever route works against you, and they move quietly so your monitoring has a fair chance to catch them.
Red team operators take wider routes than a penetration tester. They phish your staff, call the help desk with a pretext, take a foothold, escalate through Active Directory, test the roles and keys in your cloud, and try the trusted path through an IT provider. Where you put it in scope, someone tries the doors of your building. Only a small group on your side knows the exercise is running.
You walk away with the attack chain, in order, with timestamps, each step marked against what your monitoring caught and what it missed. That gives your board a straight answer to how far an attacker gets, and your security team a list of the gaps in detection and response. Many teams map each step to a MITRE ATT&CK technique so the findings feed straight into their detection engineering MITRE ATT&CK .
03 Side by side
Read the two across the dimensions that decide which you need. Both put an operator in the attacker’s seat. They part ways on almost everything else.
| Penetration test | Red team exercise | |
|---|---|---|
| Core question | Which weaknesses in this scope can an attacker use? | Can an attacker reach this objective, and would we notice? |
| Scope | Defined systems: applications, hosts, cloud accounts | The whole organisation: people, network, cloud, buildings, suppliers |
| Who knows | Usually your IT and security team | A small control group; most staff do not |
| Routes | Technical, inside the agreed scope | Any agreed route, including phishing, pretext calls and physical entry |
| Stealth | Not a goal | Part of the test: operators avoid your monitoring |
| Typical length | A working week to a fortnight of testing | Longer; set by the objective and the routes in scope |
| You get | Proven findings, ranked, with fixes and a retest | The attack chain with timestamps, marked against what your team detected |
| Asked for by | Auditors, customers, insurers, PCI DSS | Boards, mature security teams, CBEST, TIBER-EU, DORA TLPT |
Look hardest at the row about who knows. A penetration test measures your systems. A red team exercise measures your systems, your people and the team that is supposed to notice, all at once.
04 Which one you need first
If you have never had a penetration test, start there. It finds the obvious doors faster and for less, and a red team that walks through an unpatched server on day one teaches you nothing a penetration test would not have.
You are ready for a red team when these hold true:
- You pass your penetration tests and fix what they find
- Someone, in-house or outsourced, watches your alerts and is expected to respond
- Your board wants a straight answer to how far an attacker gets
- A client, insurer or regulator has started to ask whether you have been red teamed
- You built a zero trust architecture and have never seen it attacked
Between the two sit two narrower options. Adversary simulation replays one named threat group’s playbook to grade your detection technique by technique. Purple teaming puts attackers and defenders in the same room to tune detections together. Our note on adversary simulation vs red teaming sets out which question each answers. If your estate includes an AI model or agent, our note on AI red teaming vs penetration testing covers the same choice for that layer.
05 When a regulator asks for a red team
Financial regulators were the first to ask for red teaming by name. The Bank of England runs CBEST, a threat intelligence-led assessment for firms that matter to UK financial stability Bank of England . The European Central Bank publishes TIBER-EU, a framework for intelligence-led red teaming of live production systems ECB TIBER-EU .
DORA turned that practice into law for EU financial services. Article 26 requires the financial entities designated for it to carry out threat-led penetration testing at least every three years, following TIBER-EU DORA Art. 26 . Despite the name, the test is a red team exercise: intelligence-led, covert and run against live systems.
Outside those regimes, nobody hands you a mandate. A red team becomes the evidence you choose to collect because your board, your clients or your own security team want to know what a determined attacker could do.
Our red teaming services start with an objective you name and end with the attack chain, marked against what your team caught, and the fix for every step. To scope one, book a scoping call with an operator.
Questions readers ask
What is the difference between a red team exercise and a penetration test?
A penetration test works through a defined scope, such as a web application, a network range or a cloud account, and proves which weaknesses in it an attacker can use. Your team usually knows it is happening. A red team exercise picks one objective, such as the customer database or a director’s mailbox, and attacks the whole organisation by any route to reach it: people, network, cloud, buildings and suppliers. Most of your staff do not know it is running, so it also measures whether your monitoring and response notice. The penetration test gives you coverage. The red team gives you realism.
Is red teaming better than penetration testing?
Neither is better; they answer different questions. If you have never had a penetration test, start there, because it finds the obvious doors faster and for less. A red team earns its cost once the known weaknesses are fixed and you want to know whether your detection, your people and your response hold against a determined attacker.
How long does a red team exercise take compared with a penetration test?
A defined penetration test scope usually takes a working week to a fortnight of testing, with the report following within a few days. A red team runs longer because it covers more routes and moves quietly to avoid detection. The length depends on the objective and the routes in scope, and we tell you the timeline before you commit.
Does a red team exercise include social engineering and physical access?
It can, and usually should, because real attackers often start with a person. Phishing, a pretext call to the help desk and, where you put it in scope, an attempt at physical entry are all routes a red team may take. Every route is agreed in the rules of engagement and signed off before testing starts.
Do compliance frameworks require a penetration test or a red team?
Most frameworks ask for penetration testing. PCI DSS v4.0, for example, requires external and internal penetration tests at least once every twelve months. Red teaming is required by name in a narrower set of regimes, mainly in financial services: the Bank of England’s CBEST, the ECB’s TIBER-EU framework, and threat-led penetration testing under DORA Article 26, which applies at least every three years to the financial entities designated for it.
What is purple teaming?
Purple teaming puts the attackers and defenders in the same room. The red team runs techniques openly while the defenders watch, tune their detections and confirm the alerts fire. It trains your team and closes detection gaps quickly, where a covert red team exercise measures what your team catches without warning.
References
Sources
- PCI Security Standards Council. PCI DSS v4.0, Requirement 11.4: external and internal penetration testing. pcisecuritystandards.org
- Bank of England. CBEST threat intelligence-led assessments: implementation guide. bankofengland.co.uk
- European Central Bank. TIBER-EU framework for threat intelligence-based ethical red teaming. ecb.europa.eu
- European Parliament and Council. Regulation (EU) 2022/2554 (DORA), Article 26: advanced testing by means of threat-led penetration testing. eur-lex.europa.eu
- MITRE. ATT&CK Enterprise Matrix. The MITRE Corporation. attack.mitre.org
- CISA and FBI. Joint Cybersecurity Advisory AA23-320A: Scattered Spider. Published 16 November 2023, updated 29 July 2025. cisa.gov
