Your quarterly dwell figure is the median over cases closed that quarter — what does that number miss?

## The population, not the statistic The defect in 'median dwell over cases closed this quarter' is not the median. It is which cases are in the bag. ### Censoring by closure date Investigation length correlates with dwell. A phished-mailbox case with two days of activity closes in a week; an intrusion that ran for seven months across a server fleet takes a quarter to reconstruct and closes long after the quarter in which it was detected. So a population defined by *closure* date systematically over-represents short, simple cases. The bias is not noise — it points in one direction, and it flatters you every time. Worse, it is self-correcting in the wrong way: the long case eventually lands in some later quarter and makes *that* quarter look bad for reasons that have nothing to do with that quarter's performance. The fix is to cohort by **detection date** and accept that a cohort matures — the quarter's figure is provisional while cases in it remain open, and is republished as they close. That is uncomfortable for a slide deck and correct for a metric. ### Cases still open have no dwell yet A case detected on the last day of the quarter and still under investigation contributes nothing. If you have three such cases and they are your three worst, the published number is a description of the cases you finished, not of the quarter. ### The denominator is intrusions you detected Dwell can only be computed where detection happened. Whatever fraction of intrusions you never detected is absent from the population entirely, and it is precisely the fraction with unbounded dwell. This does not make the metric useless — it makes it a metric *about your detected set*, and it must be labelled that way, because a board hearing 'our median dwell is nine days' will hear 'intruders survive nine days here', which is not what the number says. ### Sample size Most SOCs close single or low double digits of genuine intrusions per quarter. A median over eleven cases moves visibly when one case changes, so quarter-over-quarter movement is mostly noise. Publish **n** next to the figure. If n is small, publish the cases as a distribution — a list of spans — rather than a central value pretending to be a trend. ### Mix One median over commodity credential-theft cases and a multi-month intrusion in the same bag describes neither. Segment by intrusion class, and the segments will move for different reasons and be actionable in different ways. ## Revision: the aggregate can get worse by getting honest Dwell is reconstructed from evidence, not read off a counter, which makes it revisable in a way most operational metrics are not. A closed case is reopened — a colder log tier is searched, an archived build manifest turns up, a second host is found to have had the same malicious package weeks earlier — and the anchor for the start date moves backward. The case's dwell goes from 42 days to 96. The median you published last quarter is now wrong, and it is wrong in the direction that makes you look worse. The correct handling is the boring one: restate. Publish metrics with an **as-of** date, keep the per-case records that let you recompute, and issue the corrected figure with a one-line note saying which case moved and why. Do not push the extra days into the current quarter — that assigns the past's dwell to the present and corrupts both. Do not quietly drop the case either. A SOC that restates a number upward and explains why is demonstrating exactly the property the metric is supposed to evidence; one that freezes published numbers is telling you its metrics are presentation rather than measurement. ## What a defensible quarterly figure looks like - cohorted by detection date, marked provisional while cases remain open - n stated, and the distribution shown when n is small - segmented by intrusion class rather than one median over everything - each case's start date carrying a source and an evidenced-or-estimated flag - an as-of date, and a restatement policy that has actually been used at least once The interviewer is checking whether you treat a SOC metric as a statistic with a defined population, or as a number that appears on a dashboard.