Penetration test vs red team

A penetration test asks what is wrong with a system. A red team asks whether your organisation would notice and stop someone pursuing a specific objective. The first produces a list of things to fix; the second produces an answer about your defences — and it is close to worthless until the first kind of list has already been worked through.

What a penetration test is for

A penetration test is bounded by scope and measured by coverage. You name the systems — an application, an API, a network range, a cloud environment, a mobile build — and testers work a methodology against them for an agreed period, looking for everything they can find inside that boundary. The defenders usually know. Source addresses are often allowlisted. Nobody is trying to be quiet.

That openness is deliberate rather than a compromise. Stealth costs time, and time spent avoiding detection is time not spent testing. If the question is "what weaknesses exist in this system?", being loud is more efficient: a tester can hammer an authorisation matrix, iterate on an injection point and retry a failed attempt forty times without worrying that attempt three raised an alert and got them blocked.

The output reflects that. A good test report is a prioritised set of findings, each with the evidence establishing it, the conditions under which it applies and what to change. It is a work queue: hand it to engineering, track it, fix it, retest. It also answers coverage questions — we examined these roles against these operations, these services on these hosts, these parameters on these endpoints, and here is what we found.

The distinguishing work is depth within the boundary: authorisation testing across every role pairing, business logic that exists only in your system, chained findings that are individually unremarkable. None of it requires stealth; all of it requires time and comprehension. A test gives you a defensible statement about a defined thing at a defined moment — what you need before a launch, after an architectural change, or when a customer asks.

What it does not tell you is anything about your organisation: whether your logging captured what happened, whether anyone was paged, whether the on-call engineer knew what to do, or whether your EDR would have stopped the activity had it not been allowlisted. Those questions were excluded by design, because answering them costs coverage.

What a red team is for

A red team engagement is bounded by objective rather than scope. Instead of "test this application", the mandate is something like: obtain access to the customer database; reach a position from which a payment could be authorised; demonstrate administrative control over production; exfiltrate a marked set of records. The route is left open — whether it runs through an application weakness, a phishing email, a credential exposed in a public repository, a supplier or a physical visit to reception is the red team's problem to solve.

Two things follow. The first is that coverage is abandoned on purpose. A red team does not enumerate your estate; it finds one path and walks it. The report may contain very few findings, and they may look minor. The deliverable is a narrative, not a list: here is what we did, in order, with timestamps, and here is where it ended.

The second is that detection and response become the subject. Because the activity is conducted with realistic tradecraft against defenders who are not expecting it, every step generates evidence of whether your organisation saw it, and that evidence is the product. A mature red team report reads as two parallel timelines — what the attacker did, and what the defenders observed, alerted on, investigated and concluded — with the gaps highlighted. The gaps are the findings: the technique that generated no telemetry, the alert closed as benign, the alert that fired correctly into a queue nobody reads at the weekend, the escalation that took most of a day because the right team had no runbook.

This requires real infrastructure and discipline: the team's own tooling and command-and-control, a plan for operating without tripping the controls under test, a very small group of informed sponsors, deconfliction so a genuine incident is not mistaken for the exercise, and agreed stop conditions. It also needs defenders worth testing. Running an adversary simulation against an organisation with no monitoring produces a predictable answer at considerable expense.

Side by side

Which one do you actually need

The triggers are reasonably clean once the question is framed as "what do I not know?" rather than "what sounds more advanced?".

You need a penetration test if: you are launching something that handles money, personal data or regulated decisions; you have changed an authentication or authorisation model, or added tenancy or privilege levels; a customer, insurer or auditor wants independent assurance about a named system; nobody outside the build team has ever assessed the application; your last test is over a year old and the system has moved; or you have no current list of what is wrong. Anything that sounds like "is this safe to ship?" is a test.

You need a red team if: you have a security operations function whose effectiveness has never been measured by anyone other than itself; you have invested in detection tooling and want to know what it catches rather than what the datasheet claims; you have closed your recent test findings and the remaining uncertainty is about response rather than configuration; your board or regulator is asking whether the organisation could withstand a targeted attack rather than whether a system has bugs; or you have run tabletops and want to know whether the plan survives contact. Red teaming is the right purchase when the question is about your people and processes under pressure, and you are prepared to hear an uncomfortable answer.

You probably need neither yet if: critical findings from your last assessment are still open; you have no reliable inventory of what you expose; nobody reviews cloud configuration; or you have no monitoring to speak of. Fix the hygiene layer first — vulnerability assessment costs a fraction of either engagement and removes the findings that would otherwise consume both.

There is a middle option worth knowing, because it suits more organisations than either extreme. A purple-team exercise runs known attacker techniques openly, with the defenders in the room, to establish which produce telemetry and which do not. You lose the realism of surprise but gain systematic coverage of detection gaps in a fraction of the time, fixing them as you go. Where monitoring has never been tested, that is usually a better first purchase than a covert operation, and it makes the eventual red team far more informative.

The mistake buyers make

The dominant error is buying a red team too early: commissioning an adversary simulation while the organisation still has a backlog of known, unfixed issues and little or no detection capability.

It happens for understandable reasons: red teaming sounds like the senior version of testing, so it reads as a natural progression and an easier story for a board. The result is predictable and expensive. The operators find a path quickly, because an estate with unresolved findings offers several. Nothing detects them, because there is nothing doing the detecting. The report says the objective was achieved in short order with no alerts raised — which the sponsor already suspected and which does not tell anyone what to do on Monday. You paid a premium for an answer you could have reasoned your way to, and you still lack the finding list you needed.

Worse, the engagement consumed the budget that should have fixed the problem. A red team is a measuring instrument: it tells you how good your defences are. Pointed at defences you already know are immature, it measures nothing useful. Each stage makes the next meaningful — find and fix what is wrong, build the monitoring, verify it catches known techniques, and only then ask whether a capable adversary can get past it uncaught.

Two related errors are worth naming. The first is buying a red team and then evaluating it like a test — counting findings, asking why the estate was not covered, treating a thin report as poor value. That mismatch is created at scoping, usually inside the buyer's own organisation: if security wants a detection assessment and compliance wants a coverage statement, one engagement satisfies neither.

The second is running a red team that is not actually covert — informing the operations team "so they are not alarmed", allowlisting the operators' infrastructure, or excluding the techniques most likely to work. Each concession is individually reasonable and collectively fatal: you pay red-team prices for an objective-driven penetration test, and the detection results are meaningless because the defenders were primed. If the concessions are unavoidable, say so and scope the engagement as what it is — often a perfectly good purchase.

How the two work together across a year

Run well these are stages of one programme rather than alternatives, and the order is not arbitrary.

Testing is the recurring layer, placed where change concentrates risk: a new product before it takes real customers, an application when its authorisation model changes, infrastructure when the architecture does. Each test produces a work queue, each queue gets closed, each fix gets retested so you know it landed. Over a few cycles this moves you from "we have unknown unfixed problems" to "we know what is wrong and we are working through it" — the precondition for everything else.

Detection capability is built in parallel and verified openly: known-technique coverage, logging that reaches wherever alerts are generated, alerts that reach a human, and a human with a runbook. Purple-team work belongs here — cheap relative to what it fixes.

Red teaming is the periodic validation on top, placed once there is something to validate. Its findings feed back into the detection layer rather than into engineering: a technique that produced no telemetry becomes a logging change and a new rule, an alert closed as benign becomes triage guidance, a slow escalation becomes a process fix. The next exercise then tests whether those changes hold.

The handovers are where programmes leave value on the table. Give the red team your recent test reports and remediation status — a serious team would rather spend its time on routes you have not examined, and will tell you honestly if the estate is not ready. In the other direction, anything a red team finds that is a system weakness rather than a detection gap belongs in next year's test scope, because it was touched once, in passing, in service of an objective, and nobody examined it properly.

The short version: a test tells you what to fix; a red team tells you whether fixing it was enough and whether you would see someone trying. Buy them in that order, and make sure either report ends in work rather than a filing cabinet. Our findings report shows the evidence standard we hold both engagement types to.