An unopened cloud detection is 94 days old and your control-plane logs retain 90. What now?

## What has actually expired Two different things carry the word *alert*. The **detection record** lives in the case-management system and can persist for years: rule name, timestamp, severity, a handful of fields the rule copied out. The **evidence** — the control-plane trail, the sign-in records, the flow logs, the endpoint telemetry — lives in a searchable index for a fixed window. When the item passes that window unopened, the row is still clickable and the investigation is over before it starts. That is what makes a 94-day-old item in a 90-day estate a genuinely different object from a 40-day-old one. The available outcomes have collapsed from three (malicious, benign, benign-true-positive) to one: **unknown, permanently**. ## The disposition you write is the whole test Under time pressure the tempting close is *no evidence of malicious activity found*. It is true in the trivial sense — you found no evidence — and it is deeply misleading, because the reason is that no evidence exists to find, not that you looked and the estate was clean. Anyone reading the queue later, an auditor included, will read it as a verdict. Write instead: **unable to determine — control-plane evidence for this detection expired at day 90; the item was never opened.** Record the date the window closed and which sources were needed. That closure is honest, it is checkable, and, unlike a fabricated benign verdict, it aggregates into a number the organisation can act on: *this many detections became permanently unanswerable last quarter.* ## Events expire; state does not The most valuable move a senior analyst makes here is the pivot from history to the present. The log of *what was done* is gone. The *result* of what was done is generally still sitting in the estate, queryable today, with no retention window at all. For a snapshot shared outward, that means going and checking now: - Does the snapshot still exist, and is its create-volume permission still granted to that external account id? - Is that account id one of yours, a known partner's, or unrecognised? Does the same id appear on any other resource, in any other account, in any of the three providers? - Does the identity that appears in the detection still exist, is it still active, and what can it do today? - Is there a change record, ticket, or infrastructure-as-code commit from that week that explains the sharing? A configuration repository or a build system keeps its own history on its own schedule and may well cover March. A present-state finding is not a verdict about the past, and you should say so plainly: seeing the permission still in place tells you the sharing exists, not who created it or whether it was approved. But it converts a dead item into a live one. If the sharing is unrecognised and unexplained, you are no longer closing an old alert — you are opening an investigation into data that may be readable by a third party right now, and the fact that you cannot reconstruct March does not reduce that. ## Also check what is retained differently Retention is rarely uniform. Organisation-level or security-account trails are often kept far longer than per-account ones. Billing and cost records, configuration-inventory snapshots, backup catalogues, ticketing systems and source repositories all have their own horizons, and in a multi-provider estate they never line up. A senior candidate lists two or three of those rather than declaring the case dead at the first expired index. ## What this changes about how you measure the backlog The operational lesson generalises beyond this one item. A queue's real deadline is not a service-level target somebody wrote down; it is the **shortest retention among the sources a verdict would need**. So the backlog metric that matters is not the raw count of unopened items but two derived numbers: the age of the oldest unopened item measured against that horizon, and how many items are within a short window of crossing it. Those are the ones you can still save this week, and they are the ones a sweep should target. And the number to publish afterwards is the count of items that crossed — detections that will never have a verdict. That is not a backlog statistic, it is a description of what the organisation cannot know. ## What a strong answer sounds like Name the collapse (evidence gone, verdict impossible), refuse the benign close, pivot to current state and differently-retained sources, and finish with the measurement change: track age against the retention horizon and report the items that crossed it, rather than reporting a queue length.