Mean time to remediate (MTTR) measures how long completed remediation work took. Calculate it by adding the elapsed time for the findings closed in a defined reporting period, then dividing by the number of those findings.
The average does not describe the age of findings that are still open. A team can close new vulnerabilities quickly, report an improving MTTR and leave its oldest exposures untouched. Report MTTR beside an open-finding age measure and the number of completed findings so readers can see what the average includes.
Leaders need that context when a monthly dashboard reports that remediation is improving. A lower number can reflect faster execution, a different mix of completed work or the exclusion of difficult findings. The calculation needs enough context to tell those explanations apart.
Define the clock before calculating the average
For vulnerability remediation, a useful default is elapsed time from the first reliable observation of an affected asset to verified remediation of that finding. State the start and end events explicitly. If your organization measures from assignment to closure instead, label that interval and preserve the earlier discovery timestamp.
A documented vendor example illustrates why definitions matter: Cisco Vulnerability Management’s calculation uses the interval between found and closed dates and excludes open findings. This is a description of that calculation, not a universal reporting standard.
For a report covering findings closed during November, the basic calculation is:
MTTR = sum of elapsed remediation times for eligible findings closed in November ÷ number of eligible findings closed in November.
Use consistent units. Elapsed calendar hours and staffed business hours produce different measures. Either can answer a useful question, but comparing them without explaining the difference is misleading. Calendar time reflects how long an exposure remained unresolved under the chosen start definition; business hours describe a working-time interval.
Also define the unit being counted. One CVE affecting 500 assets is not the same denominator as 500 asset-level findings. For operational remediation measurement, an asset-level finding makes partial completion visible. Document that choice rather than allowing an export format to make it implicitly.
A low MTTR can coexist with an old backlog
The following synthetic example is deliberately small. It is a calculation exercise, not customer data or an industry benchmark.
The completed findings took 20 days in total. Dividing by five gives an MTTR of four days. That calculation is correct. It says nothing about the two findings that remain open at 90 and 120 days.
A useful report would show: five findings remediated, four-day MTTR, two findings still open, and a maximum open age of 120 days. It could also show the risk and asset context of those open findings so that age does not become a substitute for prioritization.
Now suppose the team closes the 120-day-old finding in the same reporting cohort at the cutoff. The new mean becomes (20 + 120) ÷ 6, or about 23.3 days. The average gets worse because the team completed old work. The remaining open set becomes younger.
A performance target that rewards only a falling mean can misread this progress. Before explaining an increase as operational deterioration, check which findings were completed.
Pair MTTR with a small, interpretable set of measures
Start with completed-finding count, MTTR, open-finding count and the age of unresolved work. Choose additional breakdowns only when someone can use them to make a decision.
The median helps show the middle of the completed-time distribution. A high percentile can expose a slow tail when the sample is large enough to make that statistic useful. Neither includes open findings automatically. For a small sample, displaying the actual durations may be clearer than presenting a precise-looking percentile.
Age bands help make unresolved work visible. Select bands that align with your organization’s operating decisions and show the number of findings in each. Do not imply that a recommended band is an industry-mandated deadline.
Segment the report by a stable, documented attribute when the aggregate hides important differences. For example, endpoint application findings and production-server findings may follow different execution processes. Comparing the segments can reveal where further investigation is useful, without assuming that every longer interval reflects poor performance.
Keep deadlines and elapsed-time measurement separate. A service-level agreement states the required response period. MTTR summarizes completed work. For the policy side, see vulnerability remediation SLAs.
Use closure evidence that matches the metric’s name
A metric called time to remediate needs a defined remediation outcome. NIST’s enterprise patch-management guidance includes verification as part of patching. A deployment assignment or an accepted ticket should therefore not silently substitute for verified patch completion in a remediation-time calculation.
Use the following as a reporting policy for ambiguous outcomes. It is a recommended measurement convention, not a claim that every platform uses these labels.
This separation allows a team to recognize useful mitigation without claiming that the vulnerable condition has been removed. It also prevents changes in inventory or ticket administration from being mistaken for faster technical execution.
Handle reopened findings without erasing history
Two different situations can produce a reopened record. The earlier closure may have been wrong, or the affected condition may have returned after a genuine fix.
If later evidence shows the original closure was unsupported, preserve the original observation timestamp and explain the correction. Restarting the clock would make the unresolved exposure appear younger.
If a verified fix was followed by a new affected state, retain the earlier completed episode and link the recurrence as a new episode. Record enough evidence to distinguish recurrence from a correction. This convention makes repeated problems visible without rewriting previously valid work.
Choose and document the policy before comparing teams. Otherwise, one team’s corrected closure and another team’s new record can produce different MTTR figures for substantially similar events.
Make the monthly comparison reproducible
Save the reporting cutoff, scope and calculation rules with each result. A later export can differ because findings were closed, asset records changed or severity classifications were updated after the original report.
A minimal calculation record should contain a stable finding identifier, asset identifier, first observation time, verified closure time, disposition and reporting cutoff. If you publish results by severity, state whether that severity is captured at discovery, closure or report time.
Check the weighted average when combining groups. A team with ten completed findings should not receive the same weight as a team with 1,000 merely because each produces one departmental mean. Sum the underlying durations and divide by the total number of included findings.
Use the review meeting to identify which part of the measured interval the team can shorten safely. Separate waiting for assignment, an available fix, an approved execution window and verification where reliable timestamps exist. This turns a dashboard discussion into a decision about remediation work.
For the wider measurement context, remediation-effectiveness metrics explains the shift from counting findings to evaluating outcomes. The calculation here adds a reproducible way to interpret one of those measures.
Frequently asked questions
How do you calculate mean time to remediate?
Add the elapsed remediation times for eligible findings closed within the reporting period, then divide by their count. State the start event, verified end event, units and exclusions so another person can reproduce the result.
Does MTTR include vulnerabilities that are still open?
A closed-finding MTTR calculation excludes open vulnerabilities. Show their ages separately. Adding their current ages to completed durations would create a different measure and should not be presented as the same MTTR.
Why can MTTR rise when a team is improving?
Completing long-standing findings adds long durations to the mean. In the synthetic example, closing a 120-day-old finding raises MTTR from four to about 23.3 days while reducing the old open backlog.
What is a good MTTR target?
Set targets for a defined population and risk context, then compare results using consistent rules. A universal target can hide differences in exposure, remediation options and operational constraints. Track old open findings alongside the target.
Is time to mitigate the same as time to remediate?
They should be distinguished when mitigation leaves the underlying vulnerable condition in place. Record how quickly verified protection was established and continue tracking permanent remediation where it remains necessary.
Check your next MTTR report
Recalculate one reporting period from the underlying finding records. Put the completed count beside the mean and add the age of the oldest open findings. Use those results to identify a specific delay the team can remove without weakening the evidence required for closure.
.webp)
%20Signals%20a%20New%20Era%20of%20Supply%20Chain%20Risk.webp)
