A purple-team test proved a technique went undetected: what are the routing options for that gap?

## What a proven gap is An adversary-emulation or purple-team exercise finishes with a list of executions and, for each, what the defence actually did: blocked it, alerted on it, wrote a record nobody looks at, or nothing at all. A **proven gap** is an execution where the defence did nothing useful. That evidence is much stronger than a theoretical finding — it is not a claim that a technique might work in your estate, it is a record that it did work, on your hosts, on a date, with an operator you can name. And it is worth almost nothing until somebody decides where it goes. Most exercise findings die inside the report, which is why interviewers probe this step rather than the execution. ## The three destinations ### Detect Write a rule over the records the technique touched, so the next occurrence produces an alert. A detection stops nothing. It converts an invisible action into a signal that a human or an automation must then act on, and its worth is measured in what you can do in the time it buys you. It is normally the cheapest and fastest destination, and — importantly for routing — it is often the only one the security team can land on its own authority, because the security team owns its own rules. Deciding that a rule is the answer is routing; choosing which record to write it over and expressing the logic is a separate discipline. ### Prevent Change a configuration so the technique no longer works at all. After a preventive change the behaviour is not alarming-but-visible; it is gone. That is strictly better, and normally more expensive: it can break legitimate work, it needs a rollout, and it usually belongs to a platform or infrastructure team that did not run the exercise and did not break anything. ### Accept Sometimes the fix costs more than the risk, or the owning team genuinely cannot land it this quarter. Accepting is a legitimate third outcome — but an acceptance is a decision, and a decision carries a name, a reason and a revisit date. A gap nobody wrote down is not accepted; it is forgotten, and it will be rediscovered by the next exercise at full cost. ## Both, and neither The answer is frequently *both*. A preventive control that needs exceptions leaves a residual path, and the residual is exactly where a detection belongs. A prevention that takes a quarter to roll out leaves a quarter of exposure, and an interim detection covers it. Occasionally the answer is *neither*, and that is the accept row. ## What a routed row carries Four things, and a row missing any of them will not close: | Field | Why it exists | | --- | --- | | Owner | A person on the team that owns the system, not the team that found the gap | | Decision | detect / prevent / accept, chosen deliberately, not defaulted | | Date | When the decision is expected to be delivered or revisited | | Closure evidence | What will prove it worked | The last one is the security-specific part. For a proven gap, the evidence that closes the row is **re-executing the technique** and observing the new outcome. A ticket moved to Done proves someone believes they fixed it; running the behaviour again proves the defence changed. ## Who owns the fix Almost never the purple team. The team that proved the gap owns the evidence, the routing recommendation and the re-test; the team that owns the system owns the change. That asymmetry is the whole difficulty of this step, because you are handing work to people who broke nothing and who do not report to you. ## Common wrong answers - **Everything becomes a detection.** It is the cheapest destination for the finder and the most expensive one for the estate, because every rule is a permanent obligation to triage its output. - **The report is the deliverable.** A finding with no owner and no date has not been routed. - **Acceptance is failure.** It is the honest name for a decision that would otherwise be made silently by nobody.