Red Team vs Pentest: When to Use Each One and Why the Difference Matters

Two disciplines, two objectives

Pentesting and Red Team are frequently used as synonyms in the Spanish market, but they are distinct disciplines with very different objectives, methodologies and time cycles. The confusion is not harmless: commissioning a Red Team while expecting a pentest — or the other way round — produces frustration, unsuitable deliverables and mistaken investment decisions. And in 2026, with the Esquema Nacional de Seguridad (ENS, Spain's National Security Framework) requiring periodic audits [1] and DORA obliging certain financial entities to run tests based on real threats [2][3], understanding the difference is no longer purely a technical question: it is a compliance question.

This article updates and expands our original guide with the current regulatory framework, practical procurement steps and the questions security and compliance leads ask us most often.

Precise definitions

Pentesting

A pentest is a scoped technical exercise whose objective is to identify and demonstrate the exploitability of as many vulnerabilities as possible within a defined scope (an application, an internal network, an API, an infrastructure segment). It typically runs over windows of 1 to 4 weeks, with the defending team having prior knowledge of the scope, and it produces a closed deliverable: a technical report, findings classified by severity, proof-of-concept exploits and prioritised remediation recommendations.

A pentest answers the question: "How many doors are open, and how easy is it to get through each one?"

Red Team

A Red Team is a realistic adversary simulation whose objective is to achieve a defined business goal — exfiltrating the customer database, accessing a payments system, deploying controlled ransomware in a critical environment — using the tactics, techniques and procedures (TTPs) of a real actor, usually mapped against the MITRE ATT&CK framework [8]. The scope is the whole organisation (people, processes, technology), the typical duration runs from 2 to 6 months, the defending team knows neither the timing nor the entry vector, and the deliverable assesses the organisation's full defensive capability following the Detect, Respond, Contain cycle.

The Red Team answers a different question: "If a real attacker tries this without our knowledge, do we detect it, do we contain it, and how long does that take?"

Regulatory framework: what the rules actually require

This is where most of the confusion (and most of the compliance risk) arises. We go through what each regulation says, with links to the official source.

ENS (Esquema Nacional de Seguridad — RD 311/2022)

Real Decreto 311/2022 (Royal Decree 311/2022) [1] regulates the ENS for the Spanish public sector and its suppliers. It establishes three categories (basic, medium, high); under its article 31.1, systems in the MEDIUM and HIGH categories are subject to a regular audit at least every two years verifying compliance with the ENS, while systems in the BASIC category only require a self-assessment for their conformity declaration, per article 38.1 [1]. Within Annex II, the monitoring measure op.mon.3 "System monitoring" incorporates Reinforcement R6 (Penetration testing), which the regulation itself requires only in the HIGH category (op.mon.3 + R1+R2+R3+R4+R5+R6); in the MEDIUM category the same control applies without that reinforcement (op.mon.2 + R1+R2), so RD 311/2022 does not impose a mandatory periodic pentest for the medium category through this route. In no case does the ENS by itself require a Red Team in the sense described above: the op.mon.3.R6 reinforcement requires periodic penetration tests, i.e. a pentest, and only in the high category. It is worth confirming with the certifying auditor whether CCN-STIC guides (CCN-CERT technical security guides) issued after this royal decree extend or qualify this requirement for the medium category.

NIS2 (Directive (EU) 2022/2555)

NIS2 [6] requires essential and important entities to manage cybersecurity risk proportionately, including periodic security testing and audits, but the text of the directive does not specify that this must be a formal Red Team: the type of test (pentest, configuration audit, Red Team) is defined in national transposition measures and associated technical guides.

Important and evolving fact: as of this publication, Spain has not completed the transposition of NIS2 into national law. The transposition deadline expired on 17 October 2024. As of this writing, the European Commission maintains an open infringement procedure against Spain over incomplete transposition of the NIS2 Directive; the exact status of the procedure (including any possible referral to the CJEU) can be checked directly in the European Commission's Infringement Decisions Register (ec.europa.eu/atwork/applying-eu-law) or at ec.europa.eu/commission/presscorner [5]. This means NIS2's specific obligations are not yet directly enforceable in Spain as national law in their own right, although the ENS, DORA (for financial entities) and other sector-specific rules already are.

DORA (Regulation (EU) 2022/2554) and TIBER-EU

DORA, which is a regulation directly applicable since January 2025 (it does not require transposition), sets out in its article 26 the advanced testing based on TLPT (Threat-Led Penetration Testing) [2]. The technical development of this article arrived with Delegated Regulation (EU) 2025/1190, of 13 February 2025, published in the Official Journal and directly applicable since July 2025 [3]. This rule:

• Defines the criteria for identifying which financial entities are required to carry out TLPT (not every entity subject to DORA, only those identified as significant by size, interconnectedness and systemic criticality).
• Requires that TLPT be carried out following the TIBER-EU framework of the European Central Bank [4], which defines how the regulator, the entity, the threat-intelligence provider and the Red Team must work together.
• Sets a minimum frequency of every three years for entities under the obligation.
• Governs the use of internal testers and mutual recognition between supervisors of different Member States.

DORA's TLPT is, in essence, a highly structured Red Team supervised by the regulator. TIBER-EU has also been adopted by the Banco de España (Bank of Spain) [4], so Spanish financial entities identified as significant fall under this framework.

International equivalents

Outside the EU, the most cited reference framework is CBEST from the Bank of England [7], a threat-intelligence-led penetration testing programme for systemic entities in the British financial sector, voluntary but strongly recommended by the regulator. TIBER-EU was partly inspired by its design.

When to use pentest

• Before a deployment of a new application or piece of infrastructure, to detect exploitable vulnerabilities before it goes into production.
• Recurring regulatory compliance: ENS high category (op.mon.3.R6 reinforcement) [1], PCI-DSS, contractual requirements from clients.
• Due diligence in acquisition or merger processes, to assess the target's exposure surface.
• Technical maturity baseline before considering more advanced exercises such as Red Team.

When to use Red Team

• High defensive maturity: the organisation already has a SOC (in-house or outsourced SOCaaS/MDR), EDR deployed and documented incident response processes.
• Validating real capabilities: checking whether the SOC would detect an advanced persistent threat (APT) actor operating with real, not announced, TTPs.
• Incident response testing with real escalation: an exercise that reaches senior management and tests the decision-making process under pressure, not just the technical side.
• Specific regulatory obligation: TLPT under DORA/TIBER-EU for significant financial entities [2][3][4], or equivalent voluntary frameworks such as CBEST outside the EU [7].

"A pentest tells you whether the lock is good. A Red Team tells you whether, even if the lock is good, someone will eventually get in — and how long it takes your team to notice." — Analogy used in Hodeitek training sessions.

Purple Team: the bridge between the two

Purple Team is not a third, independent type of exercise, nor purely a marketing term: it is a collaboration methodology in which the Red team and the Blue team work in parallel, with joint sessions where Red executes specific TTPs (mapped to MITRE ATT&CK [8]) and Blue observes in real time whether it detects them, tuning detection rules on the fly. The goal is to improve defensive coverage incrementally and measurably, not to determine who "wins".

When to use Purple Team

• After a Red Team with significant detection findings: to close specific gaps in a targeted way, technique by technique.
• When deploying new technology (a new EDR, a new SIEM, a new SOAR integration): validating real coverage against MITRE ATT&CK before relying on the tool.
• As an ongoing activity — quarterly or half-yearly — in organisations with high maturity that want to maintain, not just demonstrate, their detection capability.

Practical steps to choose and commission the right exercise

1. Assess your current defensive maturity before requesting a quote. If you don't have a SOC (in-house or outsourced), EDR and at least one tested incident response runbook, start with pentest + remediation.
2. Identify whether you have a specific regulatory obligation. The ENS requires a periodic audit every two years for all systems within its scope and, in the high category, the op.mon.3.R6 penetration testing reinforcement [1]; significant financial entities under DORA may be required to run TLPT every three years [2][3]. Confirm with your compliance advisor whether your organisation meets those criteria — don't assume.
3. Define the business objective, not just the technical scope, if you're commissioning a Red Team. "Check whether we can exfiltrate the customer database without being detected" is a valid objective; "run a Red Team on the network" is not.
4. Decide the level of prior knowledge the defender will have. A Red Team that warns "only Monday to Friday, only this application" stops being a Red Team: it becomes a pentest with a bigger budget and less value.
5. Require the provider to map the TTPs executed against MITRE ATT&CK [8] in the final report, so detection coverage can be measured objectively and compared over time.
6. Plan Purple Team as a later phase, not a substitute: use it to close the detection gaps the Red Team revealed, with joint sessions and concrete improvement targets per technique.
7. Document the result as compliance evidence, not just as an internal technical report: keep it dated, with scope, methodology and the sign-off of the responsible person, because it may be requested by an ENS auditor, a DORA supervisor or a client during a due-diligence process.

Common procurement mistakes

Mistake 1: requesting a Red Team without sufficient maturity

An organisation with no formal SOC, no EDR and no response runbooks doesn't get value from a Red Team. The exercise turns into a "demonstration" where the Red team gets in within a few days and no one notices, because no one is watching. The value obtained is low relative to the cost; an internal pentest with targeted remediation would have generated a better return.

Mistake 2: restricting the Red Team as if it were a pentest

Limiting the Red Team to "Monday to Friday only, this application only, with notice before each phase" removes its main value: measuring the response to the unexpected. A real adversary doesn't follow those rules, and the exercise stops answering the question it was meant to answer.

Mistake 3: using a pentest report as evidence of organisational resilience

A clean pentest (with no critical findings) demonstrates that a specific application or network resists known attacks at that point in time. It does not demonstrate that the SOC detects an intruder, that the team escalates an incident correctly, or that the organisation contains an attack in progress. These are evidence of different things, and no serious auditor should accept one in place of the other.

Mistake 4: ignoring the applicable regulatory framework before defining scope

Commissioning a generic Red Team when the real obligation is a TLPT under TIBER-EU (with the participation of a certified threat-intelligence provider and coordination with the supervisor) produces an exercise that doesn't serve as regulatory evidence, even if it is technically sound. Before defining scope and provider, confirm what the rule that applies to you actually requires.

Callout — quick decision criterion:

• If your defensive maturity is low (no SOC, no EDR, no runbooks): pentest + remediation.
• If you have a 24/7 SOC (in-house or MDR), EDR deployed and rehearsed response: Red Team.
• If you're a financial entity identified as significant under DORA: TLPT under TIBER-EU, with a provider and scope compliant with Delegated Regulation (EU) 2025/1190 [3].
• If you want to improve detection coverage with a specific team after a Red Team: Purple Team.

Frequently asked questions

Does a pentest satisfy the ENS? It depends on the category. RD 311/2022 (Royal Decree 311/2022) requires a regular audit at least every two years (art. 31.1), and within Annex II the op.mon.3.R6 reinforcement (penetration testing) is required only in the HIGH category, not MEDIUM [1]. A documented pentest is usually submitted as evidence of that reinforcement, but it does not replace the full conformity audit. It is worth confirming with the certifying auditor whether CCN-STIC guides qualify this requirement for the medium category.

Does DORA require all financial entities to run a Red Team? No. DORA's TLPT, regulated by Delegated Regulation (EU) 2025/1190 [3], applies only to entities identified as significant under that regulation's criteria (size, interconnectedness, systemic criticality). The remaining entities subject to DORA have lighter testing obligations under articles 24-25 of the Regulation [2].

What happens if Spain still hasn't transposed NIS2? As of this publication, Spain has not completed the transposition of NIS2. The European Commission maintains an open infringement procedure against Spain over incomplete transposition of the NIS2 Directive; the exact status of the procedure can be checked directly in the European Commission's Infringement Decisions Register (ec.europa.eu/atwork/applying-eu-law) or at ec.europa.eu/commission/presscorner [5]. This does not remove the future obligation, nor does it exempt organisations from other rules already in force (ENS, DORA, sector-specific rules); it only delays the direct enforceability of NIS2's specific obligations until national law exists.

How much does a Red Team cost compared with a pentest? We do not publish generic price figures: cost depends on scope, duration, the number of authorised vectors and whether the exercise must run under a regulated framework such as TIBER-EU. Any serious estimate requires a commercial proposal with a defined scope.

Can I request a Red Team if I don't have my own SOC? It's possible, but the value is limited: without detection-and-response capability (in-house or outsourced, for example SOCaaS/MDR) the exercise will tend to reveal that the organisation doesn't detect the adversary, something that was probably already suspected. At that maturity stage, a pentest with targeted remediation tends to generate more return per euro invested.

Does Purple Team replace Red Team? No. Purple Team is a way of running offensive and defensive work in explicit collaboration (joint sessions, immediate feedback), not an independent type of exercise. It is used as a complement to a Red Team, to close detection gaps it uncovered, or as an ongoing activity; it does not replace the blind validation of a Red Team when that is precisely the objective of the exercise.

Conclusion

Pentest, Red Team, TLPT and Purple Team are different tools in the same arsenal, each with a different regulatory framework and a different maturity target. Commissioning them at the wrong moment — or without checking what the applicable rule actually requires, whether that's the ENS, DORA or (once it is finally transposed) NIS2 — wastes budget and can leave the organisation without the evidence an auditor, a supervisor or a client will demand. Choosing well, by contrast, multiplies the value of the exercise and generates defensible evidence for regulators, clients and the board itself.

Sources

[1] Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad — BOE-A-2022-7191. https://www.boe.es/buscar/act.php?id=BOE-A-2022-7191

[2] Reglamento (UE) 2022/2554 (DORA), artículo 26 — pruebas avanzadas basadas en TLPT. https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX:32022R2554

[3] Reglamento Delegado (UE) 2025/1190 de la Comisión, de 13 de febrero de 2025, sobre normas técnicas de regulación relativas al TLPT bajo DORA. https://eur-lex.europa.eu/eli/reg_del/2025/1190/oj

[4] Banco Central Europeo — TIBER-EU Framework. https://www.ecb.europa.eu/paym/cyber-resilience/tiber-eu/html/index.en.html

[5] Comisión Europea — Nota de prensa: referencia de España, Irlanda, Francia y Países Bajos al Tribunal de Justicia de la UE por no transponer NIS2, 8 de julio de 2026. https://ec.europa.eu/commission/presscorner/detail/en/ip_26_1499

[6] Directiva (UE) 2022/2555 (NIS2), artículo 21. https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX:32022L2555

[7] Bank of England — CBEST Threat Intelligence-Led Penetration Testing framework. https://www.bankofengland.co.uk/financial-stability/operational-resilience-of-the-financial-sector

[8] MITRE ATT&CK — matriz de tácticas, técnicas y procedimientos. https://attack.mitre.org/

Sources

• [1] Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad — BOE-A-2022-7191. https://www.boe.es/buscar/act.php?id=BOE-A-2022-7191
• [2] Reglamento (UE) 2022/2554 del Parlamento Europeo y del Consejo (DORA), artículo 26 — pruebas avanzadas basadas en TLPT. https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX:32022R2554
• [3] Reglamento Delegado (UE) 2025/1190 de la Comisión, de 13 de febrero de 2025, sobre normas técnicas de regulación relativas al TLPT bajo DORA. https://eur-lex.europa.eu/eli/reg_del/2025/1190/oj
• [4] Banco Central Europeo — TIBER-EU Framework (marco europeo de red teaming basado en inteligencia de amenazas). https://www.ecb.europa.eu/paym/cyber-resilience/tiber-eu/html/index.en.html
• [5] Comisión Europea — Procedimiento de infracción contra España por transposición incompleta de la Directiva NIS2. https://ec.europa.eu/atwork/applying-eu-law/infringements-proceedings/infringement_decisions o https://ec.europa.eu/commission/presscorner
• [6] Directiva (UE) 2022/2555 (NIS2), artículo 21 y considerandos sobre gestión de riesgos y pruebas de seguridad. https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX:32022L2555
• [7] Bank of England — CBEST Threat Intelligence-Led Penetration Testing framework. https://www.bankofengland.co.uk/financial-stability/operational-resilience-of-the-financial-sector
• [8] MITRE ATT&CK — matriz de tácticas, técnicas y procedimientos (TTPs) de referencia para ejercicios de Red Team. https://attack.mitre.org/