A penetration test looks for vulnerabilities inside an agreed scope and ends with a list of them plus proof of exploitation. A red team exercise asks whether the organisation detects and stops an adversary pursuing an objective, so its output is an assessment of defensive capability rather than a catalogue of technical defects.
Quick Overview
What you’ll learn:
- How goal, scope and the form of evidence differ between the formats
- When a red team exercise is premature and wastes budget
- What role an adversary technique catalogue plays in planning an exercise
- What threat-led testing is and which entities are required to run it
Who this article is for:
- People commissioning offensive security services
- Security team leads and infrastructure administrators
- Compliance owners in financial services and other regulated entities
Reading time: 7 minutes
Goal, Scope and Evidence: The Axes of Difference
A penetration test has its scope stated up front: addresses, applications, a network segment, sometimes test accounts. The testing team is expected to find as many vulnerabilities inside that scope as possible and to demonstrate what can be done with them. Success means covering the scope, and the evidence is a findings list with reproduction steps.
A red team exercise inverts those quantities. The technical scope is broad or unstated, while the objective is narrow and expressed in business terms: reach specific data, obtain privileges in a specific system, execute a financial operation. Success is not a count of vulnerabilities but an answer to whether the defence noticed the activity, and at which point. The evidence is a timeline of actions set against what the defensive teams logged and escalated.
A further difference follows, and it is the one most often missed at commissioning: how many people inside the organisation know the exercise is happening. A penetration test is frequently visible to the operations team, because surprise is not its purpose. A red team exercise loses its meaning once the defence knows the date — which is exactly why it needs a written mandate from someone able to authorise it over the unawareness of their own teams.
When a Red Team Exercise Is Premature
The exercise tests detection and response capability. If an organisation collects no endpoint logs and has neither an on-call rota nor an escalation procedure, the answer is known before the start: nobody will notice. Spending on adversary simulation then buys confirmation of a state that a configuration review would have established.
The order that usually pays off runs like this: configuration review and vulnerability management first, then penetration testing of selected areas, then building monitoring and response, and a red team exercise only once the defence has something to respond with. Inverting that order is not a methodological error but a pricing one: you pay for the most expensive format to learn the cheapest available fact.
A narrow exception justifies an early exercise: when the organisation asserts that monitoring works and nobody has verified the claim. The exercise is then a test of a declaration rather than a test of capability.
How an Adversary Technique Catalogue Structures an Exercise
The knowledge base at attack.mitre.org documents tactics and techniques used by real attackers, arranged into a matrix of operational stages. In planning it serves two purposes: selecting the set of techniques a simulated adversary genuinely uses, and recording results in a language the defence can translate into detection rules.
The adversary emulation material on attack.mitre.org goes further and publishes ready scenarios that mirror specific groups. The value of such a plan is that the exercise stops depending on the supplier’s imagination and starts depending on the threat profile relevant to the commissioning organisation’s sector — a bank and a manufacturing plant face different adversaries and different attack paths.
It also answers the question of what remains after the exercise. A report written purely as a narrative of events is hard to act on. A report mapped onto catalogue techniques points at specific detection gaps and converts into work items for the defensive team.
Threat-Led Testing and the Regulatory Duty
In financial services part of this discussion is already settled in law. Regulation (EU) 2022/2554, known as DORA and published on eur-lex.europa.eu, introduces advanced threat-led penetration testing for designated financial entities, set out in Articles 26 and 27, together with requirements for the testers and a duty to cover critical functions in live production environments.
For the commissioning entity the consequence is twofold. First, such a test is not an ordinary penetration test and cannot be discharged with a scanner report. Second, it requires organisational preparation: arrangements with the supervisory authority, threat intelligence for the entity’s own profile, and tight risk control over the test itself, since it runs against live systems.
For entities outside that duty the construct still works as a template. The control set published by cisecurity.org likewise treats penetration testing as a control in its own right, with named scope, rules of engagement and remediation of findings — which is to say that documented scope and written rules of engagement are good practice whether or not a regulation demands them.
Read Also
- Penetration Testing: Where to Start as a Company — how a first engagement is scoped and what its report contains
- OWASP Top 10 Risk by Risk: A Guide for IT Leaders — the application-layer risks usually tested separately
- Web application security: OWASP Top 10 in practice — where application testing sits next to adversary simulation
Build Your Skills
This topic is developed in the Adversary Simulation with Atomic Red Team and MITRE ATT&CK and Penetration testing — methodology, reconnaissance, exploitation and reporting courses. The first works on simulating adversary techniques, the second on test methodology and reporting. Contact us to match the scope to the maturity of your defence.
Frequently Asked Questions (FAQ)
In practice, how does a penetration test differ from a red team exercise?
In the reference point for success. A penetration test is settled by scope coverage and a vulnerability list; a red team exercise by whether the objective was reached and how the defence behaved on the way. They also differ in visibility: a test is often announced, while an exercise loses its value once the defence knows the date.
What drives the price of such an engagement?
Scope, duration and the required level of stealth. A penetration test is usually priced in days against an agreed scope. A red team exercise costs more because it includes reconnaissance, infrastructure preparation and activity spread over time, as well as risk control against production systems.
What is purple teaming, and does it replace either format?
It replaces neither; it changes the working mode. Purple teaming is an arrangement in which offensive and defensive teams work together in real time: the attack is executed openly and the defence builds and verifies detection rules immediately. It costs less than a full exercise and works better when the goal is raising detection coverage rather than testing the organisation.
Is threat-led testing the same thing as red teaming?
Methodologically it is close, but it is a regulated format: prescribed phases, requirements for the tester, supervisory involvement and a mandatory scope of critical functions. A voluntarily commissioned red team exercise may be narrower and less formal, whereas an entity under the duty cannot demonstrate compliance with an exercise alone, without that formal scaffolding.