Red, purple and blue teams explained

A red team, a blue team and a purple team are three ways to test and improve an organisation's defences. A red team simulates a real attacker and tries to reach an agreed objective without being caught. A blue team is the defence itself: the people, processes and technology that have to detect and stop an attack. A purple team is not a separate team but a way of working in which red and blue collaborate in the same session, so that every attack step immediately produces an improvement on the defending side. The difference between the three is not a question of who is best. It is a question of what your organisation needs now, and that depends on where you stand.

This is the difference, and this is how you decide what you need. The rest of this piece works out the three types, sets out side by side what they measure, and ends with the question that drives the choice: how does your detection and response function stand right now.

What does a red team do?

A red team takes on the role of the attacker. Not in theory, in practice. The team is given an objective, often a crown jewel: access to a specific dataset, a production system, a domain controller. It then tries to reach that objective the way a serious adversary would, including evading detection, abusing legitimate access, and moving through the network without raising an alarm. Lateral movement, the sideways movement of an attacker who is already inside, is part of the standard repertoire.

That makes a red team something different from a pentest. A pentest inventories vulnerabilities within a defined scope and reports what can be found. Valuable, but it measures how vulnerable a bounded part of your attack surface is, for example a website or a web application, not your resilience. A red team measures something sharper: do you see it when someone really tries, and do you stop it in time. The MITRE ATT&CK framework, which systematically describes attack techniques, is a common language in which a red team can describe its actions in a testable way.

The outcome of a good red team engagement is not a list of findings. It is an answer to a question: which attack path worked, at what moment you could have seen it, and why you did not. That answer is only worth something if there is someone on the other side who can act on it. That is the blue team function.

What does a blue team do?

A blue team is the defence itself. Not a project, but a function that runs every day: monitoring, detection engineering, incident response, hardening, managing the rules and the telemetry that let you see an attack at all. Where a red team comes in every now and then and leaves again, a blue team is permanent. Its quality determines what a red team encounters.

There is a fallacy here that recurs in many organisations. A red team test is seen as the way to demonstrate security, while the defending function is not yet in order. In that case you buy proof of a gap you already knew about without any simulation. In the Dutch mid-market there is, moreover, not always a dedicated detection and response function; the work is done on the side by an IT team or handed to an external party that reports what it sees, not what it misses. In its Threat Landscape, ENISA repeatedly notes that rapid detection and response determine the impact of incidents. Without a blue team function that difference cannot be influenced, no matter how many tests you have carried out.

The blue team is therefore not a cost item alongside the offensive side. It is the side that determines the return on every test. A red team without a blue team that can adjust course produces a report. A blue team without testing produces an assumption. Bringing those two together is where the purple team begins.

What is a purple team and when do you choose it?

A purple team is the way of working in which the offensive and the defensive work happen not one after the other, but alongside each other. Red executes a technique, blue watches to see whether detection fires, and if it does not the rule is adjusted on the spot and the technique is run again. Not a separate team with its own budget line, but a way of collaborating. The gain lies in the immediacy: an attack step leads within the same session to a demonstrable improvement on the defending side, instead of to a finding that lands in an improvement plan months later.

A purple approach suits the situation when two conditions are met. One, there is a defending function that can actually adjust course during the exercise, not just watch. Two, you have already established that this function has blind spots and you want to close them in a targeted way rather than take inventory again. Purple is not a first acquaintance with your own resilience. It is the way to describe a specific, measurable effect once that acquaintance has been made.

The three types relate to one another as follows:

Blue team. The permanent defending function. Without this there is nothing to test and no one to hand an outcome to. This is the foundation, not the afterthought.

Red team. The test of whether that function holds up under realistic pressure. Delivers the most once blue is in place, and little before that.

Purple team. The way of working that removes the distance between attack and improvement. Suits the situation when blue is in place, has been tested, and has to improve faster than an annual test cycle allows.

Which type of team suits your maturity stage?

This is the question that drives the choice, and elsewhere it is rarely put this way. The answer does not follow from budget or from what a vendor offers. It follows from a sober assessment of where your defending function stands now.

No detection and response function, or a function that is done informally on the side: then red and purple are not yet the first step. The first investment is the blue team side. In that situation a red team tests something that does not yet exist, and the report confirms what you already knew. The Dutch National Cyber Security Centre stresses in its guidance that detection and response are an established capability, not a by-product of a tool purchase.

Detection is in place, but has never been tested under realistic conditions: then a red team is the right step. You know what you have built, you do not know whether it works when someone seriously tries to evade it. A red team engagement gives the answer, provided it is measured against a framework such as MITRE ATT&CK and does not end in a story without reproducibility.

Detection is in place, has been tested, but improves too slowly: then a purple approach is worth the most. The problem is then no longer that you do not know where the gaps are. The problem is the lead time from gap to closed gap, and that is exactly what a purple way of working shortens.

The underlying position is the same in all three cases: the test is a diagnostic instrument, not an objective. The question is never which team you would best hire. The question is which outcome you need, which measurement demonstrates that outcome, and which function turns the result of that measurement into something lasting. Reverse that order and you buy a report and keep a problem.

What this means for the choice you make

For the CISO opening this conversation internally: the usable summary is that the three types are not a menu from which you pick the most impressive, but a sequence that is prescribed to you. To operational teams the message is that blue has to be in place before a red test yields anything. To the board or the CFO the message is more businesslike: a test without a function to act on the outcome is spending without return, and the choice between the three is a choice about where the money removes the most risk.

The logical next step is not to request a quote for a red team, but first to establish honestly where your defending function stands. That diagnosis determines which of the three types, if any of them apply at all, actually adds value. Set your own situation alongside the trade-off in this piece: if the blue team side is not yet in place, that is the conversation you have to have first, internally and possibly with someone who takes a look at it.