Mean Time to What?

Every metric names a moment. Mean time to detect names the moment a signal exists. Mean time to respond names the moment someone acts on it. In vulnerability management we lean on mean time to resolve, which names the moment the finding is gone. These are good words, and they have served the industry well.

The trouble is not the words. It is what sits between the moments, and who does the work there. Detect-to-resolve reads as one clock, but in practice it runs through three or four teams. A scanner finds the issue. An analyst confirms it. An engineer somewhere else fixes it, on a schedule that belongs to their product, not to security. When all of that collapses into a single number, the number blends everyone’s work and tells you nothing about which part was slow. “Resolve” quietly absorbs everyone.

Naming what we are trying to measure makes all the difference in achieving the outcomes we are looking for.

The flow

Signal  ──[1]──▶  Triage  ──[2]──▶  Fix proposed  ──[3]──▶  Fixed

Three metrics between the different phases let a security team measure progress.

Metric 1 — mean time to accept. From the signal to a human deciding the signal is real and ours. Accept does not mean fix. It means we have confirmed a true positive, assigned a severity, and put it in a queue with a named owner. This is triage’s clock, and it belongs entirely to security. Many programs never measure it, which is how “time to detect” grows a long tail of findings that were detected weeks ago and simply never looked at.

There is a second reason to measure this stage on its own. Until a signal is accepted, it is not yet counted against the organization; it is a candidate, not a finding. That is what triage is for, and it is a reasonable line to draw. What the team responsible for this metric owes the organization is that every signal is assessed, and either accepted or rejected, at an acceptable pace. Otherwise the candidate queue becomes the place where real findings sit uncounted.

Metric 2 — mean time to propose a fix. From accepted to a concrete proposal: a pull request, a configuration change, a compensating control, or a written recommendation specific enough that the receiving team does not have to re-investigate. This is the stage where security either does the work or hands it off, and the quality of the handoff shows up later in metric 3. This clock is security’s too, or at least shared, and it is the one with the most room to improve. Proposing the actual fix, where you are able, instead of filing a ticket that says “please fix,” is the single biggest lever I have found here.

Metric 3 — mean time to resolve. From proposal to fixed. This clock belongs to the team that owns the system. Security can influence it, escalate on it, and report it, but security does not run it.

When fixed is two things

For simple cases, a fix is a fix. For complex ones, “fixed” hides an important distinction, and it helps to split the last stage in two.

Signal ──[1]──▶ Triage ──[2]──▶ Fix proposed ──[3]──▶ Contained ──[4]──▶ Fixed

Metric 3 becomes mean time to contain. The exposure is closed even though the root cause is still there: a firewall rule, a feature flag, a revoked credential, a temporary block at the edge. Metric 4 is mean time to resolve. The real change lands and the compensating control comes off.

The reason to split them is that containment is what reduces risk, and the fix is what removes the debt. A ninety-day fix with a two-hour containment is a different story than a ninety-day fix with no containment at all, and a single “time to resolve” cannot tell those two stories apart. It also shows the reader where the effort is going. Containment is often something security can do or directly enable. The fix usually is not.

Whose clock is it?

Metrics 3 and 4 are, in most organizations, measurements of teams outside security, and this is where the choice of words does the most damage. Reporting them as security metrics, and grading the security team on them, measures the wrong people. It also creates the wrong incentive. A team judged on a clock it does not control will start working the number instead of the problem: downgrading severities, closing findings on technicalities, or arguing about scope instead of fixing things.

So I would hold security accountable for metrics 1 and 2, and report metrics 3 and 4 with the owning team attached. The distinction is attribution rather than blame: the number sits next to the team that can change it, which is also the team that needs to see it in order to prioritize the work.

Security should still watch metrics 3 and 4 closely, because a long resolve time often points back at us. Was the proposal clear enough to act on? Was the severity credible, or did we cry wolf? Did we route it to the right owner the first time? Did we hand them a change, or an investigation? When metric 3 is slow, the first question is not “why is that team slow.” It is “what did we hand them.” Those are security process improvements, and the downstream clocks are how you find them.

Ask which R

Respond, resolve, remediate, accept, contain: each word names a different moment, and each moment has a different owner. The next time someone reports MTTR, it is fair to ask which R they mean, and whose clock was running.

Splitting the clock is not a way to make security look better. It gives each team a number it can act on, and gives leadership a view of where in the flow the time is going, instead of one blended number that hides the handoffs.