Vulnerability Remediation MTTR: How to Measure It Honestly

Every vulnerability management program eventually gets asked the same question by leadership: how fast are we fixing things? The answer usually arrives as a single number, mean time to remediate (MTTR), and that number is usually wrong in ways nobody in the room can see. Not wrong because someone lied, but wrong because MTTR has no universally agreed clock start, clock stop, or population, and a metric without a fixed definition will drift toward whatever makes the reporting period look best. This article works through the definitional disputes, the four sub-metrics that get collapsed into one, why averages mislead, how the number gets gamed, and what an honest instrumentation and reporting setup looks like.

What MTTR Actually Means in Vulnerability Management

MTTR is a ratio: total remediation time across a set of findings, divided by the count of findings. Every dispute in a vendor call or an audit finding traces back to disagreement over the numerator or the denominator, not the arithmetic.

Clock start. Three candidate start times exist, and they produce materially different numbers:

• Scanner detection time: the timestamp the scan engine first observed the finding. This is the most defensible start because it does not depend on any human noticing.
• Ticket creation time: when the finding was filed into Jira, ServiceNow, or an equivalent tracker. If triage takes five days, this start date already erases those five days from the reported MTTR.
• Disclosure or publication time: for a CVE, the date NVD or the vendor published the advisory. This is the right start for measuring exposure to a known threat, but it is a different question than “how fast does our process work,” because it includes time before you owned an asset or before the scanner had a plugin for it.

Pick scanner detection time as the default for internal process metrics, and keep disclosure-to-remediation as a separate, explicitly labeled metric for board-level “are we exposed to known exploited vulnerabilities” reporting. Mixing the two under one MTTR label is the single most common cause of numbers that cannot be reconciled quarter over quarter.

Clock stop. The equivalent dispute exists at the end: does the clock stop when a patch is deployed, when the ticket is marked resolved, or when a rescan confirms the finding is gone? A patch deployment event and a closed ticket are both proxies for the outcome you actually care about, which is that the vulnerable condition no longer exists. Platforms that automate this phase, such as SITEY, re-test the specific finding instead of trusting the patch command’s exit code, and only stop the clock on a confirmed-closed state through a dedicated retest and closure step. That distinction matters because patch jobs report success even when the underlying package did not update, a service did not restart, or a configuration drift reintroduced the condition on the next build.

Four MTTR Variants You Are Probably Conflating

“MTTR” as a label hides at least four distinct intervals, each answering a different operational question. Reporting one number where four are needed is how a slow triage queue hides behind a fast patching team, or vice versa.

The sum of these four intervals is the end-to-end MTTR that leadership usually wants, but each variant needs its own SLA and its own owner. A security team that only tracks the aggregate cannot tell whether a 21-day average is caused by a two-day triage backlog and a nineteen-day patch wait, or a fourteen-day triage backlog on an understaffed team and a fast patch cycle. Those are different remediation problems requiring different fixes, staffing versus prioritization versus change-management friction, and an aggregate number cannot distinguish them.

Time-to-verified-closed deserves particular attention because it is the variant most commonly skipped. Many programs stop the clock at “ticket closed,” which measures ticket hygiene rather than security posture. If your ticketing system allows a ticket to close without a linked rescan result, you are measuring how fast people close tickets, not how fast vulnerable conditions are eliminated. A finding’s full lifecycle state machine, from detection through verified closure, should make that shortcut structurally impossible rather than relying on ticket hygiene discipline.

Setting SLA Targets per Variant

Reasonable starting SLA targets, to be tuned against your own historical data rather than adopted as universal truth:

• Time-to-triage: 24 hours for critical and high severity, 5 business days for medium and low.
• Time-to-assign: same-day for critical, 48 hours for high, 5 business days for medium and low.
• Time-to-fix: aligned to your patch management change windows, commonly 7 days for critical internet-facing, 30 days for high, 90 days for medium.
• Time-to-verified-closed: rescan within 72 hours of the reported fix date, regardless of severity, because an unverified fix is not a fix.

Why a Single Average Hides Everything

Mean time to remediate is an arithmetic mean, and vulnerability remediation times are heavily right-skewed: most findings close quickly, and a long tail of findings sit open for months because they require a maintenance window, a vendor patch that does not exist yet, or a compensating control decision. A mean pulled up by a tail of 400 day old findings on a legacy system can make a program with genuinely fast remediation for 95% of its backlog look mediocre, while a program that quietly ignores its old findings and only reports on recently opened ones can look artificially fast.

Report at minimum:

• Median, which is resistant to the tail and represents the typical finding’s experience.
• P90, which tells leadership what the worst-case-but-not-extreme finding looks like, and is usually a better predictor of audit findings than the mean.
• Severity-segmented views, because a blended MTTR across critical and low severity findings answers no question anyone actually has. A critical finding open for 45 days is a different conversation than a low finding open for 45 days, and averaging them together erases both signals.

A useful sanity check: if your median and your mean differ by more than roughly 2x, you have a long tail problem worth investigating on its own, separate from whatever the headline number says.

The Gaming Problem

Any metric tied to a target gets gamed, consciously or not, and MTTR is gamed through a small set of recurring patterns:

• Bulk closing near reporting deadlines. A spike of closures in the three days before a monthly report, followed by a spike of new findings from the next scan, is a visible signature in the raw ticket timeline even if the aggregate MTTR looks stable.
• Reclassifying severity downward. Moving a finding from high to medium extends its SLA window and can retroactively make a breach look like compliance. Track severity change events as their own audit trail, not just the final severity.
• Marking risk-accepted instead of remediating. A risk acceptance is a legitimate outcome, but if the risk-accepted rate climbs alongside a falling MTTR, the two numbers are telling you the same story from different angles: findings are leaving the “open” bucket without the underlying condition changing.
• Reopening suppression. If a rescan finds the same condition again after a ticket closed, does your system open a new ticket with a new clock, or reopen the old one and keep the original age? The former resets the age counter and hides recurrence; the latter is the honest choice.

The defense against all four patterns is the same: track the finding’s lifecycle as an immutable event log, not as a single mutable status field, and audit the distribution of closure reasons and severity changes on a cadence independent of the MTTR report itself.

Instrumenting MTTR Across Scanners, Ticketing, and CMDB

In practice, the data needed for one honest MTTR number is split across three or more systems that were not built to talk to each other: the scanner holds detection and rescan timestamps, the ticketing system holds assignment and closure timestamps, and the CMDB holds the asset ownership needed to route the finding correctly in the first place. Three integration problems recur:

• Deduplication across scan cycles. If the same underlying vulnerability is reported by two scanners with different finding IDs, or by the same scanner across two scans with a new ID each time, your finding count inflates and your MTTR calculation silently double-counts. Deduplication needs to key on host identity plus CVE or plugin ID plus port or service, not on the scanner’s own finding ID.
• Asset identity drift. A CMDB that identifies assets by hostname and a scanner that identifies them by IP address will disagree the moment DHCP reassigns an address, breaking the join between “who owns this” and “what needs fixing.” Use a stable asset identifier (agent UUID, cloud instance ID) as the join key wherever your inventory supports it.
• Clock skew and time zone normalization. Store every timestamp in UTC at the point of ingestion. A scanner reporting local time and a ticketing system reporting UTC will produce MTTR calculations off by hours, which matters when your triage SLA is 24 hours.

This is the layer where automation earns its keep: manually reconciling scanner output, ticket status, and CMDB ownership across a few thousand findings a month is not a sustainable weekly task. Systems that ingest results from multiple scanner integrations and normalize them against a shared asset inventory before deduplication, such as SITEY, remove the most error-prone step by construction, rather than relying on an analyst to catch mismatched identifiers.

Reporting MTTR With a Denominator

An MTTR number reported without its denominator is not a metric, it is a headline. “Our MTTR for critical findings this quarter was 6 days” means something very different if it is based on 4 findings versus 400. Always report, alongside the MTTR figure itself:

• The count of findings included in the calculation, and the count excluded (risk-accepted, false-positive-dismissed, still open past the reporting window) with reasons.
• The open backlog age distribution, not just the closed-finding MTTR, because a shrinking MTTR alongside a growing open backlog means new findings are being fixed fast while old ones are never touched.
• The time period’s scan coverage: if asset discovery only covered 70% of the environment this cycle, the MTTR is only honest about the 70% you looked at.

A reporting view built this way, MTTR variant, median and p90, severity segmentation, denominator, and backlog trend together, is harder to present as a single win-or-lose number, and that is precisely why it is harder to game. Boards and auditors increasingly ask for exactly this level of decomposition once they have seen one MTTR figure fail to predict an actual incident.

About SITEY

SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.