Red team or penetration test: choosing the right engagement

Red team is the phrase clients use when they want the most serious assessment on the menu. Sometimes that is exactly right. More often the organisation would learn more, faster, from a well scoped penetration test, and the red team budget would be better spent six months later when there is something worth testing against. The two engagements are not tiers of the same product.

Confusing them produces the two failure modes we see most often: a red team that surfaces a handful of issues an ordinary test would have found in a week, or a penetration test stretched into a stealth exercise until nobody is testing anything thoroughly. Deciding well takes about twenty minutes of honest conversation before the scoping call.

Coverage against objective

A penetration test is a coverage exercise with a defined scope and a defined method. PTES and the OWASP Web Security Testing Guide exist so that two competent testers working the same application arrive at broadly the same map of it. Noisy is fine. The tester enumerates, tries the whole class of injection, authorisation and session issues, and reports everything found within the window. A red team engagement inverts the priorities. There is an objective, agreed with a very small group: reach this dataset, get a payment approved, prove access to that environment. Everything else is subordinate to reaching it without being stopped.

What a penetration test is good at

If any of the following describe your situation, a penetration test is the engagement that will pay for itself.

• A new application or a significant release is going live and nobody outside the build team has assessed it against a standard such as OWASP ASVS.
• You need assurance with a defined scope for a customer, a regulator or an insurer, and the deliverable has to state exactly what was covered.
• The environment has never been assessed, so a first pass will find plenty without any need for stealth.
• You want a baseline you can retest against after remediation, which requires a repeatable method rather than an opportunistic one.

What a red team engagement is good at

A red team engagement tests detection and response as much as it tests technology. It earns its cost when the defensive side of the house is mature enough for the result to mean something.

• You have a monitoring capability, in house or outsourced, and you want evidence of what it catches rather than what it is configured to catch.
• Your controls are tuned and the last few tests came back thin, so the remaining risk sits in chains of small things rather than in single findings.
• You need to exercise incident response end to end, including the decisions people make under pressure at two in the morning.
• You want coverage described against a threat model, with the operation mapped to MITRE ATT&CK so gaps are expressed in the same language your detection engineers already use.

When a red team is money badly spent

Running a full adversary simulation against an estate that has never had an internal test is theatre. The operator will reach domain admin in the first two days through a misconfiguration any internal assessment would have caught, the report will say so, and you will have paid a premium for that finding. The same applies where there is no detection capability to test: an unmonitored network cannot fail a detection exercise. And if the result cannot be acted on, because the team that owns the systems has no remediation budget and no warning, the exercise generates anxiety rather than improvement.

An unmonitored network cannot fail a detection exercise. It simply has no answer to give.

The options in between

Most of the useful work sits between the two extremes. An assumed breach assessment starts the tester on a workstation inside the network with ordinary user rights, skips initial access entirely, and answers the internal question in days rather than weeks. A purple team exercise runs known techniques openly, alongside the defenders, so detections can be written and validated in the same session. Threat led testing frameworks used in finance, TIBER-EU among them, formalise the same middle ground with intelligence driving the scenarios. All of them cost less than a covert operation and produce more usable output for an organisation still building its defences.

The question we ask before scoping anything is what decision the result is meant to inform. If the answer is whether an application is safe to release, that is a penetration test with a standard behind it. If it is whether anyone would see a patient operator working slowly through the estate, that is a red team engagement, and it needs an objective, a small group who know it is happening, and a defensive capability worth measuring. When a client is genuinely unsure, we suggest the coverage work first, because it is cheaper and it removes the findings that would otherwise end a simulation on day two.