Red team versus penetration testing: how they differ

Half the time somebody says “we want a red team engagement”, what they actually want is a penetration test. Both work from an attacker’s perspective and both end in a report of problems found, but a red team engagement and a penetration test answer entirely different questions — and they differ sharply in price and in prerequisites.

This article sets out the difference and offers a decision rule: given where you are now, which one buys more information. It also covers where scoping goes wrong, which frequently matters more than the choice between the two.

One looks for flaws, the other tests whether you would notice

The goal of a penetration test is coverage: find as many exploitable weaknesses as possible inside an agreed scope, and prove they are exploitable. A good penetration test produces a list where every item carries reproduction steps. The methodology can be checked against the OWASP Web Security Testing Guide and NIST SP 800-115.

The goal of a red team engagement is validating the defensive process: emulate a specific adversary’s behaviour and see whether detection, escalation and response actually function on a real timeline. A red team often reaches its objective using a single weakness, because it does not need to find them all. The question it answers is: while somebody is attacking us, how long until we know, and what do we then do?

Put simply: a penetration test examines your systems; a red team engagement examines your team and your process. The first produces a remediation list, the second a detection-gap list.

Criterion by criterion

The last two rows are the ones most often skipped. A company with no detection capability that commissions a red team engagement will almost certainly be told “never detected” — a conclusion available for free, and one that does not tell you what to fix.

When a penetration test is the right purchase

The cost-benefit clearly favours a penetration test in these situations:

• Before a new system goes live. The point is to find exploitable weaknesses before exposure, not after.
• A customer or auditor has asked for a test report. Questionnaires and contract clauses almost always mean this kind.
• Immediately after an architecture change. For example, once remote access has been migrated and the exposure needs confirming — the same verification step described in choosing a VPN replacement and planning the migration.
• Acceptance of outsourced development. Acceptance criteria can cite OWASP ASVS items directly, which removes most of the argument.

If you currently have no way to notice an attack in progress, the answer is in this section and there is no need to read further.

When a red team engagement is worth it

Three preconditions have to hold at once before the engagement returns anything valuable.

1. Detection is already running. At minimum centralised logging and endpoint detection, with somebody who reads the alerts.
2. A penetration test has been done and remediated. Otherwise the red team takes the cheapest path available and you pay a premium for findings you already had.
3. Leadership accepts having the process examined. What a red team exposes is usually not technical — it is that nobody acted on the alert that fired on a Friday evening.

Engagement playbooks are normally mapped to MITRE ATT&CK technique identifiers, and the public adversary emulation plans work well as templates, which also makes the post-engagement comparison against your own detection rules straightforward. The path a real attacker takes is described in the ransomware attack chain.

Scanning, testing and red teaming are three layers, not three options

The layers build on one another. Scanning tells you a version has a known vulnerability. A penetration test tells you the vulnerability is genuinely exploitable in your environment and reaches this far. A red team engagement tells you how long it took you to notice.

Skipping a layer usually means paying a lot for a conclusion you already had. While the scan report still holds a hundred unaddressed high-severity items, a red team engagement is not the next step.

The four scoping mistakes that cost the most

No retest. If post-remediation retesting is not in the contract, you have bought a list of problems. Retesting should be included, or at least priced in advance.

Systems named, identities not. “Test these three hosts” and “starting from an ordinary employee account, test what becomes reachable” are different engagements, and only the second measures real lateral movement.

Exclusions left vague. Social engineering, physical intrusion and denial-of-service testing normally need separate agreement. Left unstated, the mismatch in expectations surfaces mid-engagement.

Prioritising by CVSS score alone. CVSS describes the severity of a vulnerability, not the conditions in your environment. A CVSS 9.8 issue reachable only from a specific internal management interface may rank below a 7.5 exposed to the internet. Asking the report to state actual reachability in your environment is more useful than asking for scores.

The value starts after the report arrives

An unremediated report is just a risk record — and after an incident it becomes evidence that the issue was known and left open. So require three things at acceptance:

• Ranking by real risk rather than by score, with the ranking logic explained.
• An actionable remediation step per finding. “Strengthen access control” does not qualify; “remove public access to this port and require authorised connections instead” does.
• A retest and written confirmation after remediation. That confirmation is also the strongest attachment you can give a customer questionnaire.

If you would like to talk through which one fits and how to scope it, our red team and penetration testing service page sets out the engagement flow and deliverables.

Terms and further reading

One sentence: commission a penetration test to learn where the holes are, and a red team engagement to learn whether you would notice someone using one. Not the other way round — starting with the second usually buys an answer you already had.