Dit artikel is momenteel in het Engels beschikbaar. Als je het liever samen in het Nederlands bespreekt, nemen we dat graag mee in een gesprek.

Buyers often ask for a red team when what they need is a penetration test. Sometimes the opposite happens too: they ask for a pentest while quietly expecting answers about detection, response, identity movement, and business impact. Nobody is usually trying to be difficult. The market has made the words messy.

The cleanest way to separate the two is not by tooling, seniority, or how exciting the proposal sounds. It is by the question you need answered.

Penetration test Red team
Buying question What can be broken in this defined scope? Can an attacker reach this objective, and would we respond well?
Scope Application, API, network segment, cloud area, or another agreed target. A path across people, process, identity, endpoints, cloud, suppliers, and defenders.
Noise level More visible activity is acceptable when coverage is the goal. Activity is shaped around realism, safety, and what defenders would normally see.
Main output Reproducible findings, impact, evidence, and remediation guidance. Attack narrative, detection gaps, response decisions, and path-breaking actions.
Best timing Before release, after major change, for assurance, or when a known area needs depth. After enough basics are understood that the exercise can test response instead of rediscovering hygiene.

A penetration test answers a scoped weakness question

A penetration test is the right tool when you want to know whether a defined part of your environment can be broken in ways that matter. The scope might be a web application, an API, an internal subnet, an exposed VPN, a cloud workload, a mobile app, or a specific identity boundary. The work is adversarial, but it is bounded. You are paying for coverage and technical depth inside a known area.

The best pentests do not stop at "we found vulnerabilities". They explain what was exploitable, how the tester reached it, what the likely impact is, and what to fix first. They also make the limits of the work visible. If a production constraint prevented destructive testing, if one role was not available, if a third-party integration was out of scope, the report should say so plainly.

A red team answers an objective and response question

A red team exercise starts from a different place. The question is not just "what is vulnerable?" It is closer to: could an attacker reach a meaningful objective, and what would our defenders actually see along the way? The objective might involve sensitive data, privileged identity, a critical business process, a payment path, backup infrastructure, or another outcome leadership cares about.

That changes the work. A red team may ignore a medium-risk application bug if it does not help reach the objective. It may spend more time on identity, operational habits, trust relationships, endpoint visibility, and decision-making than on classical vulnerability enumeration. The value is in the path and the response, not in the length of the finding list.

Noise means different things

A pentest can tolerate more noise because discovery is part of the job. Scanning, fuzzing, manual probing, role testing, and repeated validation may all be appropriate when the goal is technical coverage. The client usually knows the test is happening, and the system owner often wants as much useful detail as possible.

A red team is more selective. Noisiness can destroy the thing you are trying to measure. If defenders are told exactly where to look, or if the attacker creates unrealistic volume, the exercise stops measuring normal detection and response. That does not mean stealth at all costs. It means the activity should match the objective and the agreed safety boundaries.

The sponsor is usually different

Penetration tests are often bought by the team responsible for a system: application owners, infrastructure teams, cloud teams, product security, or compliance. Red-team exercises need broader sponsorship because the outcome crosses team boundaries. A realistic path may involve endpoint, identity, network, cloud, SOC, incident response, legal, suppliers, and business owners.

This is one of the early signs that a buyer is asking for the wrong thing. If nobody can approve activity outside one application, it is probably not a red team. If the real question is whether the SOC can detect movement from initial access to a critical objective, a narrow application pentest will not answer it.

The deliverables should look different

A good pentest report is finding-driven. It should be clear, reproducible, prioritised, and practical for engineers. A good red-team report is path-driven. It should explain the objective, the route taken, the assumptions tested, the signals defenders saw or missed, the decisions that mattered, and the changes that would make the path harder next time.

If a provider sells a red team but delivers a long vulnerability spreadsheet, you probably bought the label more than the exercise. If a provider sells a pentest but gives only a high-level story with little technical evidence, engineering teams may not have enough to fix the problem.

Which should come first?

Start with a penetration test when the main uncertainty is asset security. A new application. A high-risk external surface. A cloud migration. A sensitive API. An internal network segment. An annual assurance requirement. A known system that needs technical depth. In those cases, bounded testing is not "less mature". It is the right instrument.

Start with a red team when the organisation already has some grasp of the basics and wants to test a realistic path across detection, escalation, and response. That does not require perfection. It does require enough maturity that the exercise will not spend most of its time rediscovering obvious hygiene failures.

The expensive mistake

The expensive mistake is buying a red team before the environment is ready for one. If exposed assets have not been reviewed, identity paths are unknown, endpoint visibility is thin, and patching fundamentals are weak, a red team can become a costly way to prove what a smaller assessment could have shown. That is not a failure of red teaming. It is a sequencing problem.

The opposite mistake is staying with narrow pentests forever because they feel easier to procure. At some point, leadership needs to know whether controls work together under pressure. Vulnerability management does not answer that by itself.

A practical sequence

For many teams, the strongest path is targeted assessment first, broader simulation second. Test the exposed systems. Review the identity paths. Fix the avoidable routes. Improve visibility around the most important services. Then run a simulation that tests what remains when the obvious noise has been reduced.

That sequence also makes the red team more interesting. The exercise stops being about easy wins and starts testing defender visibility, process, and attacker choices in an environment that has already done some homework.

A quick buying test

Before approving either engagement, ask one sentence internally: what decision should we be able to make after this work? If the answer is "we need to know what to fix in this system", you are probably closer to a pentest. If the answer is "we need to know whether an attacker can reach this objective and whether we would respond well", you are closer to a red team.

That sentence will not solve every scoping detail, but it will prevent a lot of expensive confusion.

If you are deciding between a scoped assessment and a broader simulation, talk it through with us. A short scoping call usually saves more time and budget than any generic package page ever will.