While scoping an intrusion you find an alert closed as a false positive nine months ago — what do you do?

## Why this find is worth more than it looks A closed case surfaced during scoping is simultaneously the best evidence in the investigation and the most uncomfortable entry in your metrics. It is the best evidence because it is dated, structured, and describes what the estate looked like at a moment you would otherwise have to reconstruct from raw logs. It is uncomfortable because someone on your team looked at this activity, formed a verdict, and got it wrong. Handle it in that order — evidence, then record — because the evidence is perishable and the record is not. ## Evidence first: the timeline moved The practical consequences of an earliest-activity date moving back nine months are immediate: - **Retention.** Most estates retain hot, queryable logs for far less than nine months. Check, per source, what still exists for the new window before you plan any query. Cloud and SaaS audit trails, endpoint telemetry and network flow records will typically have different windows, and the case record itself usually outlives all of them. - **Scope.** Everything derived from the old start date is now provisional: which accounts were involved first, which host was patient zero, which access path was used. Re-run scoping queries against the extended window rather than assuming the earlier activity is simply `more of the same`. - **Preservation.** Whatever survives in the older window should be preserved now, before an automated lifecycle policy removes it mid-investigation. - **What the old case already gives you.** The matched fields at the time of firing, the analyst's note, the enrichment attached to it and any artefacts collected are often the only surviving record of that period. Read the note carefully: it usually names the reasoning that has to be re-examined. In a slow-drip exfiltration through a sanctioned file-sync client, the note might read that the user confirmed by chat that they were setting up a new laptop. That is a specific claim you can re-test today: was the confirmation from the user or from someone in the user's account; did the device that was set up match the device that kept downloading; did the downloading continue after the stated setup date. ## Then the record: correct it, and be precise about the failure The disposition currently asserts `false positive` about activity now known to be part of an intrusion. Leave it and every count derived from dispositions is wrong — including the per-rule quality numbers that might otherwise get the rule retired for being noisy. Be exact about where the failure was. A rule fired: coverage worked. What failed was the adjudication. That distinction matters because the fixes are disjoint: - a coverage failure is fixed by telemetry or by new detection logic; - an adjudication failure is fixed by enrichment that puts the missing context in front of the analyst, by closure criteria that forbid closing on a user's self-report alone, or by a review step on a class of case where the cost of being wrong is high. Writing `detection gap` in the record when the rule fired sends the remediation effort to the wrong place and, worse, produces new rules that will be closed the same way. ## Handle the analyst carefully, and deliberately Correct the record; do not retro-judge the person. A verdict is judged against the evidence available at the time, and analysts working a queue against a clock will always have less than a full investigation does. The reason this is a professional obligation rather than a kindness is behavioural: teams where a reclassification becomes a performance finding stop closing cases decisively, and the backlog — where genuinely uncounted misses accumulate — grows instead. What is legitimate is asking what would have had to be on screen for the verdict to differ, and whether that is buildable. ## Feeding the miss count Record this as one known miss with its discovery channel: the back-timeline of a later investigation. That label is not bureaucracy — it is the only thing that lets you read the count later. A back-timeline discovery is conditional on your having eventually caught something else, which means the channel is structurally blind to intrusions that never escalated into anything you detected. One find through this channel implies nothing about how many similar cases sit in the closed-case archive with the same wrong verdict. That implication does suggest one concrete follow-up: a targeted review of historically closed cases matching the same rule, actor pattern or closure reason. It is a bounded, cheap sweep and it is the only way to convert a single retro-read into more than one observation.