Mean Time to Remediate (MTTR) is one of the few vulnerability management numbers that reaches a board deck, which is exactly why it gets manipulated, sometimes without anyone intending to. A team can cut its reported MTTR in half without closing a single real risk faster, just by changing where the clock starts, which findings count, or how reopened tickets are handled. Before you put this metric in front of a CISO or an auditor, you need a definition precise enough that two different analysts, pulling from the same ticket queue, arrive at the same number.
Defining the Clock: Detection, Triage, or Assignment as the Start Point
MTTR is only as meaningful as its start and end events, and teams routinely disagree on both without realizing it. There are three common start points, and each tells a different story about where your program is actually slow.
- Detection timestamp: the moment a scanner or agent first observes the finding. This is the most honest start point because it captures the full exposure window, including the time a finding sits unvalidated in a queue.
- Triage or validation timestamp: the moment a human or an automated validator confirms the finding is a true positive and assigns severity. Starting here hides any backlog in your validation step, which is often where the real delay lives.
- Assignment timestamp: the moment a ticket is opened and routed to an owner. Starting here can make MTTR look excellent while a finding actually sat unvalidated for three weeks before anyone touched it.
The defensible choice is detection to verified closure, because it is the only definition an attacker’s timeline would agree with. If your program insists on measuring from assignment, report the detection-to-assignment interval as a separate number rather than dropping it. A finding that takes two days to remediate once assigned but twenty days to reach a human is not a two-day problem.
The same discipline applies to the end point. “Remediated” should mean a control change has been deployed and independently re-tested as closed, not that a patch ticket was marked done. Automated patching pipelines that report success codes without confirming the underlying condition is gone will systematically understate MTTR, because a failed patch that silently reopens later gets counted as fixed the first time.
Mean vs Median vs 90th Percentile: Why the Statistic Changes the Story
Once the clock is defined, the choice of statistic matters almost as much. Remediation time distributions are heavily right-skewed: most findings close quickly, a small number drag on for months waiting on a maintenance window, a vendor patch, or a business owner’s sign-off. That shape makes the arithmetic mean unstable.
| Statistic | What it tells you | Where it misleads |
|---|---|---|
| Mean | Overall average burden across the queue | Dominated by a handful of long-lived outliers; one 400 day finding can swing the whole number |
| Median | Typical experience for a normal finding | Can look great while a long tail of critical findings quietly ages past SLA |
| 90th percentile | How bad your worst-case handling is | Sensitive to sample size; noisy on small monthly cohorts |
Report at least two of these together. Median plus P90 is the combination most practitioners land on: median shows whether the day-to-day process works, and P90 shows whether your tail risk, the findings most likely to be exploited before they close, is under control. A mean reported alone is the easiest of the three to game, since closing a batch of trivial low-severity items pulls it down without changing anything about how long critical findings actually take.
One more wrinkle: findings still open at report time are censored data. If you exclude open tickets from the calculation, you are only measuring findings that happened to close during the window, which biases the number toward the fast ones. A common fix is to include open findings using their age so far as a lower bound, or to report an explicit “backlog age” distribution alongside MTTR so the still-open population cannot hide.
Segmenting MTTR by Severity, Asset Class, and Owning Team
A single blended MTTR across your whole environment is close to useless for decision-making. It averages away the differences that actually drive risk. Break it out along three axes before you trust it for anything beyond a headline slide.
By severity
Critical and high severity findings, especially on internet-facing assets, should be tracked and targeted separately from medium and low. Blending them lets a wave of easy low-severity closures mask a critical finding that has been open for two quarters.
By asset class
Remediation on a stateless container image redeployed through CI is a different operational problem than remediation on a legacy on-prem database that requires a change advisory board and a maintenance window. Segmenting by asset class (cloud workload, on-prem server, network device, endpoint, SaaS configuration) keeps the target realistic for each and stops infrastructure-wide averages from punishing teams that own harder-to-patch systems.
By owning team
MTTR is often used, implicitly or explicitly, to evaluate teams. If ownership routing is inconsistent, a team can look slow simply because it inherits ambiguous or cross-cutting findings that sit unassigned longer. Segment by the team that owns the fix, not the team that owns the asset inventory record, and track how long assignment itself takes as a separate figure.
How MTTR Gets Gamed
None of the following require bad faith. They are the natural result of optimizing a number instead of the outcome it is supposed to represent, and every one of them is detectable if you know what to look for in the underlying ticket data.
- Bulk false-positive closures. Closing a batch of low-confidence or duplicate findings as “not applicable” removes them from the denominator without remediating anything. Watch for closure-reason distributions that shift suddenly toward “false positive” or “risk accepted” right before a reporting period ends, especially if the shift is concentrated in one scanner or one asset group.
- Reopen churn. A finding closed and reopened three times gets recorded as three short remediation cycles instead of one long one if your tooling resets the clock on reopen. Track time-to-first-close and time-to-final-close separately, and flag any finding reopened more than once as a process failure worth its own review, independent of the MTTR number.
- Stale tickets parked outside the count. Findings moved to a “deferred,” “exception,” or “backlog” status often get excluded from active MTTR calculations entirely. If exception requests are not time-bound and periodically re-reviewed, this becomes a permanent escape hatch. Cap exception duration (30 or 90 days is a common default) and force re-justification, or count the exception period toward the clock. This is easiest to enforce when every status change is recorded in a single vulnerability lifecycle record rather than split across a scanner export and a separate ticketing system.
- Re-testing that trusts the tool instead of verifying the fix. A patch job that reports exit code 0 is not evidence the vulnerability is gone; a config error, a rollback, or a partial deployment can leave the underlying condition intact while the ticket closes on schedule. Platforms that automate this phase, such as SITEY, run a dedicated retest and closure step that re-checks the specific finding against the original evidence rather than trusting the patch command’s reported success, which is what keeps a “closed” timestamp from becoming a second false positive on top of the first.
A useful audit habit: periodically re-run last quarter’s validation logic against last quarter’s closed tickets. If the false-positive rate or reopen rate on that historical set is meaningfully different from what was reported at the time, the metric was probably being managed rather than the risk.
Realistic Ranges and Setting Your Own Target From a Baseline
Resist importing an industry benchmark as your target before you have measured your own baseline. Asset complexity, change management maturity, and patch availability vary enough between organizations that an external number is a weak anchor. Instead, run detection-to-verified-closure across at least one full quarter, segmented by severity, and use that distribution as your starting point.
A structure many programs converge on, as a starting point to adjust rather than a fixed rule, ties SLA tiers to exploitability and exposure rather than CVSS base score alone:
| Tier | Example criteria | Illustrative target window |
|---|---|---|
| Tier 1 | Critical, internet-facing, known exploited (KEV-listed) | Days, not weeks |
| Tier 2 | High severity, exploitable but not internet-facing or not known exploited | Within one sprint or patch cycle |
| Tier 3 | Medium severity, internal, defense in depth | Within one to two maintenance windows |
| Tier 4 | Low severity, compensating controls present | Batched with routine patching, tracked but not urgently escalated |
Tools that compute this baseline automatically from raw detection and closure timestamps, such as SITEY, remove the temptation to cherry-pick which quarter counts as “normal” before setting the target. Once you have a baseline P50 and P90 per tier, set the target as an improvement increment (for example, a 20 percent reduction in Tier 1 P90 over two quarters) rather than an absolute number pulled from a report. Improvement-from-baseline targets are harder to game because they force the conversation back to your own historical data instead of a benchmark nobody can verify against your environment.
Presenting MTTR Trends Alongside Volume So the Number Stays Honest
MTTR read in isolation invites exactly the gaming described above, because a falling MTTR and a growing backlog can coexist. A team can hit an aggressive MTTR target while the count of open findings quietly climbs, because the fastest, easiest findings get closed first and the hard ones accumulate untouched. Pair every MTTR chart with at least three companion figures.
- Open finding volume over time, segmented by the same severity tiers used for MTTR, so a shrinking average duration next to a growing backlog is visible on the same page.
- SLA compliance rate, the percentage of findings closed within their tier’s target window, which captures tail behavior that a median or even a P90 can smooth over.
- Aging backlog distribution, showing how many currently open findings have already exceeded their SLA, so leadership sees the accumulating liability rather than only the historical average.
When these figures are generated automatically from the same underlying finding lifecycle data, rather than exported and recombined by hand each month, the numbers stay consistent with each other by construction. A reporting layer built directly on the retest and closure records, rather than on a manually reconciled spreadsheet, makes it harder to quietly redefine “closed” for one chart while leaving the backlog chart on the old definition. Whatever tooling you use, the test is simple: could someone pull the raw ticket export and reproduce your reported MTTR using only the definition you published. If the answer is no, the number is not ready for a board slide yet.
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.