Penetration Testing vs Red Team: Differences and When to Use

Pentesting and Red Team get mixed up in tenders and hallway conversations as if they were the same thing, and they're not. They share tooling, professional profile and vocabulary, but they answer different questions, last different times, cost differently and leave the client with different outcomes. Confusing them leads to buying pentesting when the organisation actually needs Red Team, or the other way around (more expensive and more frequent). The operational difference is this: pentesting looks for flaws in specific assets; Red Team measures whether your defence notices and reacts when someone is already inside. This post lays out both definitions, compares them dimension by dimension and explains when each one fits, how they map to NIS2, DORA and TIBER-EU, and when combining them makes sense.

Quick definitions

Pentesting

A penetration test (or pentest) is an authorised, time-bound exercise on a defined set of assets (a web app, an API, an internal network, a cloud environment, a mobile app), where an offensive team looks for exploitable technical vulnerabilities, tries them within the limits the scope allows and delivers a technical report with each finding, its impact and the recommended remediation. The operational question it answers: what flaws exist in these assets and how serious are they?

More detail in what is a penetration test.

Red Team

A Red Team is a continuous and stealthy adversarial simulation that emulates a real attacker (including a specific APT group when threat intelligence is available) trying to compromise concrete business objectives without the defender noticing, over weeks or months, with a broad scope including technical, physical and sometimes social engineering. The operational question: could an adversary compromise the business without our defence noticing in time?

Differences dimension by dimension

Objective

• Pentesting. Find vulnerabilities in the assets in scope, evaluate them (CVSS, context), chain them when possible and deliver them with proof of concept and remediation.
• Red Team. Measure the defender's detection and response capability against a realistic adversary. Vulnerabilities are means, not end: if a single one is enough to reach the agreed business objective, the rest don't get documented at the same depth.

Scope

• Pentesting. Bounded and written before starting: list of URLs, IP ranges, repositories, cloud identities, time windows and excluded techniques. Usually covers one asset or a small set.
• Red Team. Broad and oriented to business objectives ("exfiltrate the customer database", "access the payment environment", "take control of the OT control room"). Techniques get chosen on the fly based on the defences encountered.

Duration

• Pentesting. Between 1 and 4 weeks of active execution, depending on size and complexity.
• Red Team. Between 4 and 16 weeks, with month-long campaigns in TIBER-EU exercises. Stealth requires a slow activity tempo to avoid burning the footprint.

Technical depth

• Pentesting. High depth within each asset. Walks the surface tree systematically.
• Red Team. Selective depth: enough to reach the objective. If the shortest path goes through phishing, that's prioritised; if it goes through a public web vulnerability, that's the route. Technique serves the objective, not the other way around.

Stealth

• Pentesting. Not stealthy. The defending team knows there is an exercise and when, and the exercise runs without hiding from detection tooling.
• Red Team. Stealth is a requirement. The defender (except a small group called White Team or Control Group) doesn't know the exercise is running. Detecting it is part of what gets measured.

Team profile

• Pentesting. Profiles specialised by surface: web, API, mobile, network, cloud, IoT/OT.
• Red Team. Versatile profiles focused on adversarial operations: emulation of TTPs of specific APTs, EDR evasion, post-exploitation, lateral movement, persistence, exfiltration. Heavy emphasis on MITRE ATT&CK as operational framework.

Output documentation

• Pentesting. Exhaustive technical report with each finding: severity, proof of concept, request/response, impact, remediation, retest after fixes.
• Red Team. Narrative report with the attack chain, the points where defence detected (and the points where it didn't), detection metrics (MTTD), recommendations by defensive layer and, if contracted, a follow-up Purple Team exercise to train the defence.

Cost

Without going into closed proposals, the order of magnitude is different. A mid-complexity web application pentest in Spain runs around 5,000-15,000 €; a serious Red Team starts from 30,000-50,000 € and a full TIBER-EU exercise ranges between 80,000 and 250,000 €. Figures are market ranges, not closed proposals: they depend on scope, emulated adversary and assigned time. More on pricing logic in penetration testing pricing in Spain.

Practical differences in day-to-day project life

The differences show up most clearly in five operational aspects.

Rules of Engagement

Pentesting has detailed and restrictive ROE (what can be touched, in which window, with what intensity). Red Team has broad and objective-oriented ROE: the team decides the concrete technique within agreed legal and ethical limits, and the White Team keeps the authority to activate safe words if something gets out of hand.

Communication with the audited organisation

In pentesting, there is an open channel with technical leads during the project: scope questions, real-time finding validation, coordination of tests that might affect production. In Red Team, the channel is restricted to the White Team and only activates for critical decisions or emergencies.

Defender detection and reaction

In pentesting, if the SOC detects the offensive team, the normal response is to let them work (notified in advance). In Red Team, if the SOC detects the offensive team and reacts, that is the result of the exercise: how far the attacker got before being stopped.

Evidence and reproducibility

In pentesting, every finding ships with reproducible PoC, screenshots, exact commands. In Red Team, evidence concentrates on the key points of the chain: initial entry, escalation, lateral movement, exfiltration. The full chain matters more than each isolated flaw.

Risk to production

Pentesting seeks to minimise risk on production (bounded scope, controlled windows, calibrated tooling). Red Team assumes a real attacker doesn't respect windows, so it operates carefully but without constraining itself: if a realistic technique could cause disruption, it gets avoided out of common sense, not contractual restriction.

When you need pentesting (and not Red Team)

Six scenarios where pentesting is what fits, without discussion.

1. Validate a release or significant change. New web application, API about to go live, freshly built cloud environment. You need a complete map of the technical surface before customers come in.
2. Meet a regulatory requirement for technical evidence. NIS2 article 21, DORA technical sections, ENS, ISO 27001 (control A.8.8), PCI DSS (req. 11.4) demand periodic testing. A pentest report is the evidence.
3. Provider due diligence. Check the technical security of a product before adopting it.
4. Low or medium technical maturity. Without an in-house SOC or solid detection, hiring Red Team is premature: the offensive team will reach the objective without effort and the exercise adds little beyond confirming the obvious.
5. Audit after an incident. To identify the exploited vulnerability and rule out more in the same asset.
6. Tight budget. Most SMEs cover their technical evidence need with annual pentesting, without entering Red Team territory.

When you need Red Team (and not pentesting)

Five scenarios where Red Team is the right answer.

1. High defensive maturity and own or managed SOC. You want to measure whether the defensive investment detects a realistic adversary.
2. Regulated financial sector under DORA. The TLPT (Threat-Led Penetration Testing) section in significant entities mandates TIBER-EU-style exercises, which are structured Red Team.
3. Essential service operators with critical surface. Energy, healthcare, water, telcos: test real detection and response capability.
4. Internal exercise after major incidents. Verify that corrections deployed after a real compromise work in adversarial conditions.
5. Defensive investment validation. Justify (or challenge) budget on EDR, SIEM, SOC, threat intelligence with empirical data on what they detected or didn't.

How they fit NIS2, DORA and TIBER-EU

The three frameworks demand technical testing, but with different nuances.

NIS2

Article 21 requires technical and organisational measures supported by periodic testing, without specifying it must be pentesting or Red Team. In the Spanish market practice, periodic pentesting is accepted as reasonable evidence for standard essential and important entities; Red Team remains best practice for entities of higher criticality and mandatory reference only when the entity falls under the DORA TLPT regime.

DORA

The European financial regulation distinguishes two levels:

• Basic technical testing (article 25): pentesting, vulnerability scanning, continuity testing. Mandatory for entities in scope.
• TLPT (articles 26-27): advanced Red Team-style testing with threat intelligence, mandatory for significant financial entities designated by the competent authority, with a cadence of at least once every 3 years.

TIBER-EU

The methodological framework published by the ECB for banking TLPT. It is not binding in itself, but it is the framework DORA recognises as reference for TLPT. It distinguishes three phases: Preparation, Testing (Threat Intelligence + Red Team) and Closure (reports, replay with the defender). For significant financial entities in Spain, the TIBER-ES flow (with the Bank of Spain as authority) implements the model.

Frequent mistakes when choosing between pentesting and Red Team

Patterns we see in poorly framed tenders and proposals.

1. Ask for Red Team and describe pentesting. "Do a Red Team on our web application for one week." That's not Red Team, that's pentesting. Using the right term avoids misunderstandings on budget and deliverables.
2. Ask for pentesting when the question is detection. "I want to know if our SOC works". A visible pentest doesn't answer that: the SOC knows there's an exercise, it's not comparable proof against a real attacker.
3. Hire Red Team without defence to measure. If there is no SOC or EDR, the Red Team will reach the objective in hours. The report comes down to "there is no defence", which was already known without spending the budget.
4. Vague objectives for Red Team. "See how far you get" is not an objective: it's a blank cheque. Well-defined objectives are concrete, measurable and tied to business impact.
5. Skip the Purple Team after Red Team. The real Red Team value materialises when, after the exercise, the offensive team sits down with the defensive one and reproduces the attack chain step by step to train detections. Without that session, the exercise stops at a report.
6. Same provider year after year on Red Team. Same technique, same footprint, same findings. The Red Team value lies in simulating different adversaries. Rotating providers every one or two cycles keeps the exercise useful.

Do pentesting and Red Team happen together?

Yes, and in mature programmes they coexist with different cadences:

• Pentesting on critical assets: annual or after significant change. Frequency driven by technical change rhythm and regulatory requirements.
• Red Team on business objectives: every 1-3 years, depending on maturity and regulatory obligations.
• Continuous Red Team / Adversary Emulation automated: more and more companies combine human exercises with breach and attack simulation platforms that test detections continuously. They don't replace human Red Team, they complement it between campaigns.

Frequently asked questions

What's the main difference between pentesting and Red Team?

Pentesting looks for technical vulnerabilities in concrete assets during 1-4 weeks with bounded scope and open communication with the defender. Red Team measures detection and response capability against a realistic adversary during 4-16 weeks with broad scope and full stealth. In one sentence: pentesting answers "what flaws exist"; Red Team answers "if we got attacked, would we notice?".

Is Red Team more expensive than pentesting?

Yes, for two reasons. First, it lasts much longer: a typical Red Team ranges between 4 and 16 weeks vs 1-4 weeks for pentesting. Second, it requires more senior profiles (adversary emulation, EDR evasion, own C2 infrastructure). Spanish market ranges: mid-complexity web application pentest around 5,000-15,000 €; Red Team starts at 30,000-50,000 €; full TIBER-EU between 80,000 and 250,000 €.

Does my company need Red Team or is pentesting enough?

Pentesting is the reasonable choice if: you don't have an in-house or managed SOC, defensive maturity is medium-low, the main goal is to meet basic regulatory requirements or validate releases. Red Team makes sense if: you have a SOC, EDR, measured defensive indicators, or you're required by DORA TLPT, or you want to empirically validate defensive investment. Most Spanish SMEs cover their need with annual pentesting; Red Team shows up more from mid-sized companies upwards with their own defensive function.

Is pentesting enough to comply with NIS2 and DORA?

NIS2: yes, periodic pentesting is interpreted as sufficient technical proof for article 21 in standard essential and important entities. DORA: yes for basic technical testing in article 25, no for TLPT in articles 26-27, which demand Red Team-style exercises with threat intelligence and are mandatory for financial entities designated as significant.

What is a Purple Team exercise?

A Purple Team is the collaborative session between the offensive (Red) and defensive (Blue) teams that happens after or during a Red Team, where the adversary's techniques get reproduced step by step so the defensive team learns to detect them. The moment where the formative value of the exercise materialises. Without Purple Team, Red Team stops at a report; with Purple Team, real detection capability improves.

How often should I run pentesting or Red Team?

Pentesting: annually on critical assets, plus a test after significant changes (releases, infrastructure refactor, cloud migration). Some regulated sectors (PCI DSS, financial) demand specific cadence. Red Team: every 1-3 years depending on maturity; in DORA TLPT entities, minimum every 3 years; in large essential services or financial operators, annual is common.

Can the same provider do pentesting and Red Team?

Yes, and it's common when the provider has capacity for both. What should rotate (at least on Red Team) is the emulated adversary and, every one or two cycles, the team itself, to prevent the exercise from repeating the same footprint and the same findings. Diversity of approach is part of the exercise value.

Related resources

• What is a penetration test
• Penetration testing pricing in Spain
• DORA compliance guide for financial entities 2026
• NIS2 in Spain: a compliance guide for 2026
• What is MITRE ATT&CK: tactics, techniques
• What is EDR (Endpoint Detection and Response)
• White-box vs black-box vs grey-box testing

Offensive testing at Secra

About to contract an offensive exercise and not sure whether yours is pentesting or Red Team? At Secra we review the context (defensive maturity, regulatory obligations, business objectives) and propose the exercise that actually answers the question you have. Get in touch through contact and we'll work out what fits best.