Red Team vs Penetration Test: Which Does Your Business Need?

The two terms get used interchangeably at conferences and in vendor pitches. They are not the same thing. Using the wrong one is an expensive mistake, not because the other is bad, but because each answers a different question.

A penetration test asks: what vulnerabilities exist and how bad are they?

A red team assessment asks: could a skilled, patient attacker achieve a specific objective against us, and would we notice?

That distinction sounds subtle. In practice it changes everything about how the engagement is scoped, staffed, executed, and what you do with the results.

What a penetration test actually looks like

A penetration test is a structured, time-boxed effort to find as many security weaknesses as possible within a defined scope.

The tester — or small team — is given a target: a web application, an IP range, a mobile app. Their job is to find what is exploitable. They use a combination of automated tooling and manual analysis. The methodology is usually drawn from a recognized framework like the OWASP Testing Guide or PTES. The objective is completeness: find everything worth finding within the agreed scope.

Typical duration: one to two weeks per defined scope. A web application test, an internal network test, and an external perimeter test are different scopes and often run separately.

The output is a report. Good ones have a risk-rated list of findings with evidence, a reproduction path, and remediation guidance. Bad ones are glorified scanner output. The quality gap between providers is large.

Your security team is usually aware the test is happening. They may be involved in scoping and given contact details in case the tester hits something sensitive. That is intentional — the goal is finding vulnerabilities, not testing your people.

What a red team assessment actually looks like

A red team assessment is an adversarial simulation designed to test whether your organization can detect and respond to a real attack.

The red team is given an objective, not a scope. Something like: gain access to the finance system, exfiltrate the customer database, or demonstrate the ability to disrupt production. They have weeks or months to achieve it using whatever a real attacker would use — phishing, physical access attempts, supplier impersonation, technical exploitation, social engineering.

Critically, the test is covert. Your IT and security team do not know it is happening. Only a small group at board or executive level (the “white cell”) is aware. The entire point is to evaluate whether your detection and response capabilities actually work, not just whether vulnerabilities exist.

The red team stops when they achieve the objective, are detected by the blue team, or time runs out. The report covers what they did, what worked, what your team caught, and what they missed. A good red team report is as much about your detection gaps as your technical weaknesses.

The common misconception

People assume a red team is a penetration test with more budget and a bigger team. That framing misses the point.

A penetration test is about finding weaknesses. A red team is about testing whether you could survive someone exploiting them. They require different skills, different timelines, and produce different outputs.

A penetration test where the security team knows what is coming will find more vulnerabilities than a blind red team assessment. That is not a flaw. The goal of a pentest is to find them. The goal of a red team is to see if anyone catches the attempt.

You can have a technically tight environment — few exploitable vulnerabilities — and still fail a red team assessment because your detection is poor and your incident response team has never handled a real intrusion. You can also have obvious vulnerabilities and a security operations center that catches attempts quickly. Both outcomes are worth knowing, and they require different engagements to reveal them.

How to decide which one you need

This depends more on where your security program sits than on your budget.

If you have not done a penetration test before, start there. A red team assessment run against an environment with unpatched systems and no security monitoring is not a test of your defenses — it is an expensive way to confirm that obvious problems exist.

If you are trying to meet a compliance obligation, a penetration test is almost always what is required. GDPR Article 32 refers to “regular testing, assessing and evaluating the effectiveness of technical and organisational measures.” NIS2, which Belgium transposed in late 2024, includes vulnerability testing requirements for organizations across 18 sectors. In both cases the expectation is a structured technical assessment with documented findings.

DORA and TIBER-EU are the exception. The Digital Operational Resilience Act, in force for EU financial institutions since January 2025, mandates Threat-Led Penetration Testing (TLPT) for significant financial entities. In Belgium and across the EU, TLPT runs under the TIBER-EU framework: a supervised, intelligence-driven red team assessment based on current threat intelligence. If your organization is classified as significant under DORA, this is not optional. It has a defined methodology, supervision structure, and engagement with the NBB or FSMA.

If you have a mature security program and want to know whether your defenses hold up against a real attacker, a red team assessment is the right question. You have done penetration testing, you patch regularly, you have a security operations center or MDR service, and you want to know if any of it would stop someone who is patient and skilled. That is the scenario red teaming is designed for.

The two also work well in sequence. Penetration testing finds and fixes the vulnerabilities. Red team exercises test whether your controls and detection hold once those vulnerabilities are addressed. The gap between where most Belgian organizations are and that second stage is wider than most expect.

The practical differences

A penetration test has a defined target. A red team assessment has a defined objective.

Penetration tests typically run one to three weeks per scope. Red team assessments usually run six to twelve weeks.

Your security team knows about a penetration test. They do not know about a red team assessment — that is the point.

A penetration test produces a vulnerability list with risk ratings. A red team assessment produces an attack narrative with detection and response findings.

Penetration tests cost less in absolute terms. Red team assessments cost more and require more internal preparation.

A penetration test tells you what is broken. A red team assessment tells you whether you would survive.

Where most Belgian organizations actually sit

Most Belgian organizations subject to NIS2 have not run a penetration test against their current environment in the last twelve months. Some have never done one on their current setup.

The priority is a penetration test. External network and web application testing for public-facing systems is the right starting point. Internal network testing follows. That work will find things that matter, produce a remediation list you can act on, and give you evidence of due diligence for regulators and insurers.

A red team assessment makes sense after that work is done and the findings addressed. Most organizations are not there yet, and that is fine — the point is to know where you are.

For financial institutions, the TIBER-EU conversation should start earlier than the regulatory deadline requires. The lead time on a properly supervised TLPT engagement — finding an accredited provider, engaging with the NBB or FSMA, developing threat intelligence profiles — is longer than most organizations plan for.

After the engagement

Whichever type you do, the report is not the end.

For penetration tests: triage findings with your technical team, prioritize remediation based on actual business impact rather than generic severity scores, and schedule a retest to confirm fixes. Build the retest into your contract before signing.

For red team assessments: run a debrief that includes both the red team and your detection and response team. The most useful output is usually the conversation about what the blue team saw — or did not see — during the engagement. That conversation does not happen without planning for it.

Findings that sit in a PDF and get referenced at the next audit are compliance artifacts. Findings that are triaged, remediated, and used to improve detection rules are something else.

Where to start

If your organization has not run a penetration test against its current environment, that is the place to start. External network and web application testing on your public-facing systems answers the most immediate question: what could an external attacker reach today?

If you are a financial institution working through DORA obligations, start the TIBER-EU conversation now, before the deadline pressure arrives.

If you want to talk through what type of assessment makes sense for your situation, or what a realistic scope looks like, we are happy to walk through it.