Why findings die in the handoff
A red-team engagement usually ends the same way. A report gets delivered, a debrief gets scheduled, everyone nods at the executive summary, and the document goes into a shared drive. Three months later nobody can say with confidence whether the technique that worked during the test would still work today. The test bought a moment of insight, and then let it evaporate.
The traditional red-versus-blue model treats testing and defence as sequential rather than connected. The red team runs the engagement, writes it up, and briefs the blue team weeks later, by which point organisational memory of the engagement has already started to fade. When the two functions operate in silos, findings pile up in a document nobody revisits, not because they were not valid, but because nobody owned the handoff from "we found this" to "we now detect this".
Every finding becomes a detection, in one view
A finding that only reaches a report dies in the handoff. A finding scored live, with an owner attached the moment the gap is found, becomes a rule.
- Red team finishes, writes a report, moves on
- Blue team is briefed weeks later, the context already cold
- Findings sit in a document nobody revisits
- No second pass to check the fix actually worked
- Red and blue watch the same telemetry live
- Every technique scored detected, partial or missed, as it happens
- Gaps land in the existing tracker with an owner attached immediately
- Retested on the next scheduled session
That is the actual argument for purple teaming, and it has nothing to do with colour-coordinated org charts. In a mature programme purple is not a separate team. It is an operating model in which red and blue share telemetry, attack steps and tuning decisions in real time, so every simulated technique ends in one of two states: a confirmed detection, or a shipped detection-engineering fix. There is no third state where the finding just sits in a document.
The rule: a detection, or a documented reason why not
"Every finding should become a detection" sounds absolute, and it is meant to. It is not a promise that every gap gets fixed instantly. Some techniques cannot be reliably detected with current telemetry. Some need a data source that is not onboarded yet. Some genuinely are not worth the engineering time relative to the risk. The rule is not that every finding produces a rule. It is that every finding produces a decision, on the record, made by someone with the authority to make it.
That is the same logic modern detection-coverage tooling has converged on: every uncovered technique sorts into one of two buckets. Deploy a detection today, because the telemetry already exists. Or onboard the missing data source first, because the gap is a blind spot rather than an unbuilt rule. Either way the next move is specific, never "we should look into that". Coverage that has to be manually reconstructed every time someone asks whether a technique is covered is not visibility. It is overhead disguised as a quarterly briefing. Treat MITRE ATT&CK technique coverage as a living state, not a slide that goes stale the day after it is presented.
Where the bridge gets built
The single biggest lever for closing the gap between finding and detection is timing. A purple-team exercise only works if red and blue operate in the same room, watching the same alerts, in real time, not red team first, then a report, then a blue-team meeting weeks later. When an analyst correlates the resulting alerts across the SIEM and endpoint detection live, as the red team executes each technique, the feedback loop that used to take weeks compresses to hours.
That compression changes what the exercise produces. Instead of a narrative report handed off cold, the engagement generates a live scorecard: every technique mapped to MITRE ATT&CK and marked detected, partially detected or missed, as it happens. Gap findings land directly in the team's existing tracker with an owner attached the moment the gap is found, not after someone reads the report later. There is a teaching effect too, and it is not incidental. When the blue team is handed the red team's own playbook, tunes a rule, and then watches the identical attack get caught on a second pass, that is a stronger learning signal than a training slide.
The feedback loop that used to take weeks compresses to hours when red and blue watch the same telemetry live.
What a finding needs to carry to be buildable
A finding that reaches detection engineering as "the red team got domain admin" is not actionable. Detection engineers need the execution context, not the outcome: the specific commands run, the log artefacts those commands produced, and the network signatures they generated, because that is what a rule gets written against. A finding ready to become a detection carries the exact technique mapped to MITRE ATT&CK, not a narrative description; the specific commands, tools or payloads used, the literal artefact a rule needs to pattern-match against; the log source that captured it, or should have, whether that is Windows event logs, endpoint telemetry, authentication logs or cloud audit trails; what fired, what did not, and why, as a real gap analysis rather than just "not detected"; and an owner and a due date, attached the moment the gap is confirmed rather than assigned during a later triage meeting.
A rule only earns trust once it has been proven against a real attack chain and tested again after the environment changes, because environments drift, and a detection that worked one quarter is not guaranteed to still fire the next.
Making it a habit, not an event
None of this holds up as a once-a-year exercise. A single annual red-team test cannot keep pace with attackers who weaponise a new vulnerability within days of disclosure. The gap between a technique becoming known and a detection existing for it has to be measured in a programme's release cadence, not its audit calendar. Programmes that treat purple teaming as continuous, testing on an ongoing schedule instead of saving everything for one annual event, are the ones where the rule is enforceable, because there is always a next session to check the last one's homework.
The practical version does not need to start at full scale. Before the engagement, the blue team writes down its detection hypothesis: what it believes it would catch, what it is unsure about, what it already knows is uncovered. During the engagement, red and blue watch the same telemetry live, and every technique is scored as it happens, not reconstructed afterwards from memory. At the close of the engagement, every miss becomes a ticket with an owner and a technique ID before anyone leaves the room. After the engagement, the new or tuned detections get retested, either in the next purple session or through a scheduled test, because a detection that is not retested after the environment changes is a detection you are only assuming still works.
Where to begin
Take the last red-team or penetration-test report filed. For each finding, write down which of the two buckets it falls into today, deploy or onboard, and who owns that decision if nobody has claimed it yet. Then run one purple-team session on the technique that worried you most, and count how many of its steps your detection actually saw. That number is the starting point, and the only one that matters.
Every red-team finding should become a detection, or a documented reason, owned by a named person, for why it is not one yet. A finding with neither outcome is a paragraph nobody will remember reading.
