The traditional red team model and its blind spot
The classic red team engagement has a simple structure: an external team of attackers, operating with minimal constraints, attempts to compromise your organisation. At the end of the engagement — typically two to four weeks — they hand over a report detailing what they found, how they got in, and what they accessed.
The report is valuable. It shows you what a real attacker could do. It demonstrates the business impact of a successful breach. It gives your leadership something concrete to point to when making the case for security investment.
But here's the problem: most of the value is in the report. Your defenders — your blue team, your SOC analysts, your detection engineers — learn what happened after the fact. They see the findings. They don't experience the attack.
The result is that traditional red team engagements tend to produce findings that get fixed, but they rarely improve your organisation's ability to detect and respond to the next attack.
What purple teaming changes
Purple teaming flips the model. Instead of adversarial secrecy, the engagement is collaborative. The red team operates transparently alongside the blue team — executing attack techniques, pausing to check whether they were detected, and working together to understand why certain things were visible and others weren't.
This changes the output fundamentally. Instead of a list of vulnerabilities and a set of recommendations, you get:
Empirical data on your detection coverage. For each technique executed, you know whether your SIEM generated an alert, whether that alert fired, and whether an analyst noticed it. This is coverage data — not assumed, not inferred, but measured.
Actionable detection improvements. Because the red and blue teams are working together, gaps in detection logic can be addressed during the engagement. A SIGMA rule tuned on the last day of an exercise is immediately operational, not sitting in a remediation backlog.
Institutional knowledge that stays. Your analysts see the attack techniques live. They watch the indicators appear in their tooling. They understand why certain artefacts matter. That knowledge doesn't leave with the red team's report — it stays with your people.
When red teaming still makes sense
Purple teaming is not a universal replacement for traditional red team engagements. There are scenarios where the adversarial model still delivers the most value:
High-maturity blue teams that need to test their detection capability under realistic conditions — without the red team telegraphing their moves — benefit from the opacity of a traditional engagement. If your analysts can detect a well-executed covert campaign without any prior knowledge, that's a meaningful validation.
Testing specific business scenarios — like "can an attacker move from our corporate network to our OT environment?" — sometimes requires an unconstrained engagement to get a realistic answer.
Board-level demonstrations of risk often land harder when leadership can see what an attacker actually accomplished in their environment, rather than what techniques were tested and detected.
But most organisations aren't at the maturity level where a traditional red team engagement produces better outcomes than a collaborative exercise. Most organisations have significant detection gaps, limited SIEM tuning, and blue teams that have never actually seen the attack techniques being tested against their infrastructure.
For those organisations — which is most of them — purple teaming delivers more security improvement per engagement.
The MITRE ATT&CK framework as the common language
One of the practical advantages of purple team exercises is that MITRE ATT&CK provides a shared vocabulary that both red and blue teams can use.
When we plan a purple team exercise at CYSMIQ, we start by identifying which ATT&CK techniques are most relevant to the threat actors your organisation faces. For a financial services firm in South Africa, that might mean focusing on the initial access and credential theft techniques favoured by financially motivated threat actors active in the region. For a manufacturing company, it might mean focusing on lateral movement and OT network access.
We then build a test plan around those techniques — mapping each one to the detection data sources that should theoretically catch it, and using the exercise to validate whether those detections actually work.
The output is an ATT&CK navigator heat map showing your coverage — green for detected and alerted, orange for detected but not alerted, red for no detection at all. That heat map becomes a prioritisation tool for your detection engineering programme.
Running your first purple team exercise
If you've never run a purple team exercise, here's what to expect:
Preparation takes longer than the exercise itself. A well-structured exercise requires a clear scope, a mapped scenario, and agreement between red and blue team leads on how the exercise will run. Budget time for this — a rushed planning phase produces a poorly structured exercise.
Start with technique-level testing, not full scenarios. Your first exercise should be methodical — execute a technique, check for detection, tune or create a rule, move to the next technique. Full attack scenarios can come later once you have baseline coverage mapped.
Your blue team needs to be in the room. Purple teaming only works if your defenders are engaged and empowered to tune their tools during the exercise. If your SOC analysts are watching passively while someone else does the detection tuning, you're losing half the value.
Prioritise the techniques that matter for your threat landscape. Don't try to cover all of ATT&CK in a single exercise. Pick the ten to twenty techniques most relevant to your industry and threat actors, and cover those well.
CYSMIQ designs and delivers purple team exercises aligned to the MITRE ATT&CK framework, producing detection engineering outputs your blue team can act on immediately. Contact us to discuss an exercise for your organisation.