A re-executed attack technique that alerted last quarter now produces nothing. What do you do?

## Why this is not the same finding as a miss An emulation that was never detected tells you about **coverage**: nobody built this, or it was built wrong. An emulation that *was* detected and now is not tells you about **change**: something in the chain moved. The two go to different owners, imply different remediation, and — the part candidates usually miss — differ in what they say about the past. ## Step one: prove the failure before you report it An absent alert is ambiguous. Confirm the operator actually executed the technique and that it succeeded on the target — the session in the management console, the local audit trail on the appliance, the operator's own notes. Then check whether the record exists at the source, and if it does, whether it arrived at the platform. Establishing *where* the chain stops is the whole diagnosis: at the source (audit category, configuration reset), in transport (forwarder, certificate, firewall, collector), or after ingest. A preventive control that now blocks the action entirely is also a possible explanation, and that outcome is a pass, not a regression. ## Step two: scope by dependency, not by rule The strongest lead you have is that this worked before. Whatever changed is likely shared. If the appliance stopped emitting a category, every detection over that category is dead; if a collector moved, everything through it is dead. Enumerate the detections that name the same source, category, field or collector, and re-execute a sample of them rather than assuming this was the only casualty. Scoping by ATT&CK tactic or by rule author is the common wrong instinct — those groupings have nothing to do with the plumbing that broke. ## Step three: size and act on the blind window This is what separates a strong answer. Between the change and today, this behaviour was not detectable. That period is not a hypothetical: if an adversary had done this then, you would not know. So establish the change date, state the window, and decide two things. 1. **Do you hunt it?** Pick a source that survived the change and look for the behaviour retrospectively, within whatever retention covers the window. If no surviving source can answer it, say so plainly — that is a real limit, not a formality. 2. **What must be qualified?** Any statement you made about coverage during that window — to leadership, to an auditor, to a customer questionnaire, in a previous validation report — was made on the strength of a test result that has since been shown not to hold. Correcting it is uncomfortable and non-optional. A new gap carries no such retraction, because you never claimed the coverage. ## Step four: report it to the owner who can prevent the next one A coverage gap is queued as detection engineering work. A regression is a finding about the change path: an input to a security control was altered without anyone re-validating what depended on it. The remediation has two halves — restore the telemetry, which the source or platform owner does, and close the process hole, which usually means the dependency being named on the change ticket so the next upgrade fires the test. Reporting a regression as *the detection team has a gap* points the fix at the only party that could not have prevented it. ## Step five: prove the fix by execution, not by inspection When the configuration looks restored, re-execute the technique. A configuration that reads correctly is the same evidence you had before this failure, and it was wrong then. The only acceptable close is an alert produced by a real action after the fix. ## Tone in the report A regression is normal in a live estate and should not be written as a scandal or as a failure of the platform owner, who was doing their job. What it demonstrates is that validated coverage decays silently, and that the decay is invisible until somebody executes the behaviour. That argument, made with a concrete example and a dated blind window, is far more persuasive than any general appeal for more validation capacity.