31 October 2026 · 11 min read · By Michael van Mameren, Lead Penetration Tester (OSCP)
Red team vs penetration testing: the difference, when each is appropriate, and how a mature programme sequences them
Both are performed by offensive security specialists, both end in a report, and both are called 'a hack' by the board. Beyond that they answer different questions. A penetration test asks how many weaknesses exist in a defined system. A red team asks whether a determined adversary can reach a specific objective without being stopped. This guide sets out the differences that matter when you are deciding which to commission.
Two disciplines with the same tools and different questions
A penetration test is a coverage exercise. The client defines a scope (an application, a network segment, a cloud account, an API), the tester is told about it, and the tester's job is to find as many exploitable weaknesses in that scope as the time allows and to document each with evidence and a remediation path. Breadth is the point. The test is announced, the defenders usually know the dates and source addresses, and the tester makes no attempt to hide. A good penetration test of a web application finds the injection flaw, the broken access control and the misconfigured session handling, and tells you how to fix all three.
A red team engagement is an objective exercise. The client defines a goal that matters to the business (read the board's email, transfer funds from the treasury system, reach the SCADA network, exfiltrate the customer database) and the red team is given the freedom an actual adversary would have to reach it: phishing, physical entry, exploiting the perimeter, abusing a supplier relationship, chaining low-severity weaknesses across domains. Depth along one path is the point, and so is realism. Most of the organisation does not know the test is happening; the detection and response teams are being tested as much as the systems.
The practical consequence is that the two produce different findings. A penetration test tells you that twelve things are wrong with the finance application. A red team tells you that an attacker who phished one accounts-payable clerk could have moved to the domain controller in four days, and that the security operations centre raised one alert on day three and closed it as a false positive. Both are valuable. They are not substitutes.
Red team vs penetration testing: side by side
The comparison most buyers need, in one table. Rows describe typical practice; individual engagements can be designed differently.
| Dimension | Penetration testing | Red teaming |
|---|---|---|
| Primary question | What vulnerabilities exist in this scope, and how severe are they? | Can a realistic adversary achieve this objective, and would we detect and stop them? |
| Goal | Coverage: find as many exploitable weaknesses as possible within scope | Objective: reach a defined business-critical target by any viable path |
| Scope | Defined and bounded (an application, a network, an account); usually a list of assets | Broad; the organisation, with agreed exclusions; attack paths cross technical, physical and human domains |
| Knowledge given to testers | Usually grey box: documentation, accounts, architecture | Usually black box plus threat intelligence; the team builds its own picture as an attacker would |
| Awareness inside the organisation | Announced; system owners and the SOC are informed | Covert; only a small control group (the white team) knows |
| Noise and stealth | Noisy by design; speed and coverage matter more than evasion | Stealthy by design; detection evasion is part of the test, and getting caught is a finding |
| Duration | Typically 1 to 3 weeks of testing | Typically 4 to 12 weeks including reconnaissance, with TLPT engagements longer |
| Blue team role | Usually informed and stood down, or testing detection in a separate exercise | Measured: detection and response are evaluated; purple-team replay often follows |
| Deliverables | Findings report by severity with evidence, remediation and retest | Attack narrative, timeline, detection and response assessment, control gaps by kill-chain phase, strategic recommendations |
| Frameworks referenced | OWASP WSTG, OWASP ASVS, PTES, NIST SP 800-115, OSSTMM | MITRE ATT&CK, TIBER-EU, DORA Art. 26-27 (TLPT), CBEST, iCAST |
| Right maturity stage | Every organisation, from the first security programme onward | Organisations with a detection capability worth testing (in-house SOC or MDR), after regular penetration testing is embedded |
| Cost drivers | Scope size, depth, test type, tester seniority, reporting | Duration, number of objectives, stealth requirements, threat-intelligence phase, physical and social components, team size |
The differences that decide which one to buy
Six dimensions behind the table, with what each means for your decision.
Objective-based versus coverage-based
A red team stops exploring once it has a working path to the objective; a penetration test keeps going until the scope is covered. If you need to know every weakness in a system before a release or an audit, you need coverage. If you need to know whether your organisation would survive a targeted intrusion, you need an objective.
Scope and knowledge
Penetration testers are told what to test and given access to be efficient. Red teams are told what to achieve and left to discover how, starting with open-source reconnaissance of the organisation, its people and its suppliers. The reconnaissance alone often surfaces exposures no scoped test would find, such as leaked credentials in a public repository or a forgotten subsidiary domain.
Duration
A web application test takes days; a red team takes weeks because stealth is slow. Password spraying that would take an hour in a penetration test is spread over days to stay under lockout and alerting thresholds. Command-and-control traffic is shaped to look like business traffic. The timeline is part of the realism, and part of the price.
Detection evasion versus noisy testing
In a penetration test, triggering an alert is irrelevant or even helpful. In a red team, being detected is a result: it tells you the control worked, at which phase, and how the response team handled it. Red teams use living-off-the-land techniques, custom tooling and operational security that penetration testers do not need, which is also why red-team operators are a different and scarcer skill set.
Blue team involvement
A penetration test usually asks the SOC to stand down. A red team measures the SOC, often without their knowledge, and the most valuable part of the engagement is the debrief where red and blue walk through the timeline together. That debrief frequently turns into a purple-team exercise: replaying each technique with the defenders watching, tuning detection until it fires.
Deliverables
A penetration test report is organised by finding and severity, built for a remediation backlog and an auditor. A red team report is organised by attack phase, built for a CISO and a board: what the objective was, how it was reached, where detection should have fired and did not, what the response looked like, and which strategic gaps (identity, segmentation, monitoring coverage, awareness) made the path possible.
When each is appropriate, by security maturity
The question is rarely which is better. It is which one your programme is ready to learn from.
Starting out, or no regular testing yet: penetration testing
If the organisation has never had its internet perimeter, core applications and internal network tested by professionals, a red team will succeed quickly and teach you little that regular testing would not have shown you at far lower cost. Start with external and internal penetration tests, fix the findings, retest, and repeat annually. This is also what ISO 27001 A.8.8, PCI DSS Req. 11.4, SOC 2 and most customer contracts actually ask for.
Regular testing embedded, detection capability in place: first red team
Once annual penetration testing is routine, the serious findings are fixed within the window, and there is a SOC, an MDR provider or an in-house detection function with something to measure, a red team becomes worth its cost. The first engagement is usually assumed-breach (starting from a compromised workstation) with one or two objectives and a modest stealth requirement, so the organisation learns how to run a white team and a debrief.
Mature programme, regulated sector: full-scope red team and TLPT
Financial entities designated under DORA Article 26 must run threat-led penetration testing at least every three years under the TIBER-EU framework (TIBER-NL in the Netherlands, coordinated by DNB). TLPT is a red team by law: a separate threat-intelligence provider builds the scenarios, the red team executes on live production systems against critical or important functions, and the supervisor attests the result. Comparable regimes exist in the UK (CBEST) and Hong Kong (iCAST). Outside finance, organisations in critical infrastructure under NIS2 increasingly run red teams to demonstrate Article 21(2)(f) effectiveness assessment.
Continuous improvement: purple teaming and adversary emulation
Once a red team has shown where detection fails, the efficient next step is not another red team six months later but a purple-team programme: short, collaborative exercises in which specific MITRE ATT&CK techniques are executed while defenders watch, detection logic is written or tuned, and the technique is re-run until it fires. This converts red-team findings into measurable detection coverage and is the most cost-effective way to raise the bar before the next full red team.
How a mature programme sequences pentest, red team and purple team
The sequence that works, and that we see in organisations with a sustained reduction in real incidents, runs in a cycle. Penetration testing is the foundation and never stops: every internet-facing and business-critical system is tested at least annually and after significant change, findings are fixed and retested. That removes the easy paths and gives the red team something worth attacking.
A red team is then run every twelve to eighteen months (every three years at minimum where TLPT applies), each time with objectives chosen for business impact rather than technical convenience and with a threat model matched to the adversaries that actually target your sector. The outcome is a short list of strategic gaps and a precise record of where detection and response succeeded or failed.
Between red teams, purple-team exercises take each failed detection and turn it into a tuned alert and a tested playbook, typically one or two days per month. Vulnerability scanning runs continuously underneath all of it to catch regressions between tests. By the next red team the question is no longer whether the adversary gets in, but how far they get and how quickly the response contains them; that is the metric a board can track year on year.
Cost drivers in plain words, for both
Neither engagement has a list price; both are scoped. These are the variables that move the number, so you can read a proposal and know why two quotes differ.
- Penetration test: number and complexity of assets in scope (applications, roles, hosts, cloud accounts), test type and position, grey or white box, tester seniority and certification, reporting depth and compliance mapping, retest included or not
- Red team: engagement duration (the largest driver, because stealth is slow), number and difficulty of objectives, whether a formal threat-intelligence phase is required (mandatory for TLPT), stealth level and the custom tooling it implies, inclusion of physical intrusion and social engineering, team size, and the debrief and purple-team follow-up
- Both: on-site days and travel, out-of-hours testing, regulatory liaison (for TLPT the supervisor engagement adds months of calendar time if not consultant days), and the number of reporting audiences (technical, executive, regulator)
- What does not change the price but should change your choice: a red team against an organisation with no detection capability is a very expensive penetration test with a thinner report
What HackersHub offers on both sides
HackersHub delivers penetration testing and red teaming as separate services with separate scoping, because they answer separate questions and are staffed differently. Our penetration tests are led by OSCP-certified consultants named in the report, cover web, API, mobile, cloud, network and hardware scope, and include a retest. Our red-team engagements are built on MITRE ATT&CK, start from a documented threat model, and are run by operators with red-team-specific tooling and operational security experience, with a white-team protocol agreed in writing before the first reconnaissance action.
For financial entities we provide the red-team component of TLPT under TIBER-EU alongside an external threat-intelligence provider, and for organisations between those two points we design assumed-breach red teams and purple-team programmes that fit the detection capability you have today. In every case we will tell you plainly if we think a red team is premature and a penetration test would teach you more. After 10+ years of offensive security work we have found that the honest recommendation is also the one that brings clients back.
Frequently asked questions
Not sure which one your programme needs?
Tell us where your testing and detection capability stand today and we will recommend the engagement that teaches you the most, whether that is a scoped penetration test, an assumed-breach red team or a TIBER-aligned TLPT.