MTTR (Mean Time to Remediate)

Mean Time to Remediate: a metric measuring how long, on average, an organization takes to fix an exposure from when it is identified. A central indicator of an exposure program's maturity.

What it counts

MTTR is the mean time between a problem entering the queue and leaving it fixed. In security it usually measures vulnerabilities: from ticket open to ticket closed.

The metric is useful because it describes execution capacity. A team closing in five days what another closes in forty has a better process, and that shows.

When its clock starts

Here is the limitation almost nobody states.

The MTTR clock starts when the problem is known. Everything before that falls outside the count: the time the asset sat exposed with nobody aware, the time between the flaw being published and the scanner running, the time between the scan and someone opening the ticket.

An organization can post a three-day MTTR and carry a seven-week real exposure, if the finding took six weeks to surface. The indicator looks good and the risk stays where it was. This is why it works better beside the exposure window, which counts from when the problem came into existence.

Why the average misleads

MTTR is a mean, and a mean over a skewed distribution hides exactly what matters.

A queue with ninety items closed in a day and ten dragging for ninety days returns an MTTR of ten days. The number looks reasonable, and the ten forgotten items are precisely the ones nobody could resolve, usually legacy systems with no clear owner.

Tracking the 90th percentile alongside the mean shows the tail. If P90 comes in far above MTTR, the problem is not speed: it is a stuck subset the average dissolves.

How it gets gamed without bad intent

Three moves improve MTTR without improving security.

Closing tickets as accepted risk. The queue moves, the asset stays the same.

Raising the severity threshold that generates a ticket. Fewer items enter, the ones that do are the easiest to justify, and the average drops.

Reopening as a new ticket. The clock resets and the old item shows as resolved.

None of these is usually deliberate. They appear when the metric becomes a target, which is why MTTR alone makes a poor contractual indicator.

Where it fits

MTTR measures the mobilization phase of an exposure management program. It says nothing about the quality of discovery or about the queue being in the right order.

An excellent MTTR over a queue sorted by theoretical severity means the company is fixing the wrong thing quickly. That is why it only makes sense read alongside the exploitability validation rate and the window.

Veja isso na sua superfície

Análise preliminar gratuita