Mean Time to Remediate: Benchmarks by Industry and Severity

Mean time to remediate is useful only when the clock ends on verified risk reduction. If a closed ticket or successful patch job stops the timer, the metric rewards paperwork and hides failed repairs.

The problem is not that security teams need a lower average. The problem is that one average mixes emergency fixes, unreachable laptops, planned maintenance, accepted risk, false findings, and reopened work. Leaders get a clean number built from dirty states.

Measure the full distribution. Split it by exploit evidence, exposure, business importance, platform, and workflow stage. Then use the metric to remove waiting time and protect the few dangerous items that averages conceal.

What does mean time to remediate measure?

Mean time to remediate measures average elapsed time from a defined start event to verified closure. For vulnerability work, a defensible start is the first qualified observation on an identified asset. A defensible end is a fresh test showing the unsafe condition is gone and required service behavior still works.

Teams also use MTTR for mean time to repair, respond, restore, or resolve. Those are different clocks. Name the metric in dashboards and policy. A responder may contain an incident in 20 minutes while the exploited vulnerability takes 12 days to remediate. Both numbers can be correct.

Link the measure to the automated remediation control loop. Discovery, decision, change, recovery, and verification each create time. Automation should reduce a named stage, not merely make the final command run faster.

How do you calculate mean time to remediate?

For a chosen cohort, subtract qualified detection time from verified closure time for every completed item. Add those durations and divide by the number of completed items.

Suppose six findings close in 2, 5, 7, 14, 30, and 62 days. Total time is 120 days. Divide 120 by six and the mean is 20 days. The median is 10.5 days because the middle values are 7 and 14. One 62 day item nearly doubles the mean compared with the typical case. That is not noise. It is the tail you need to understand.

Report at least the mean, median, ninetieth percentile, oldest open age, sample size, and reopen rate. The mean shows total delay. The median shows a typical completed item. The ninetieth percentile shows the slow tail. Oldest open age catches work that has not entered the completed denominator at all.

When should the MTTR clock start and stop?

Start when current evidence confirms a condition on an identified asset. Starting at scanner import may overstate delay if the source sends duplicates or unsupported version matches. Starting at ticket acceptance understates delay because unowned findings disappear before the clock begins. Keep both timestamps if qualification itself is a bottleneck.

Stop when an independent check observes the desired state and the service test passes. A deployment exit code proves that a task met its own success rule. It does not prove the vulnerable package stopped loading, the exposed listener closed, the identity path lost access, or the setting survived another policy writer.

Do not delete paused time from the main elapsed clock. Maintenance waits and exception periods are part of exposure. Track active work time and wait time as separate fields so operators can distinguish effort from organizational delay.

What are current mean time to remediate benchmarks?

There is no honest universal benchmark. Current sources measure different populations, start events, asset visibility, severity schemes, and closure rules. Compare the method before comparing the number.

Moody's published its cross sector cybersecurity analysis on April 1, 2026, covering 9,500 rated issuers with Bitsight data. It measured time until an externally observed weakness was no longer visible. Half of vulnerabilities outside the KEV catalog were no longer observed after 107 days, compared with 87 days for CISA Known Exploited Vulnerabilities and 59 days for KEVs associated with ransomware.

The 2026 Verizon Data Breach Investigations Report gives another current reference: a median of 43 days for full resolution of a critical vulnerability, almost two weeks longer than the prior report. It also found vulnerability exploitation caused 31 percent of breach entry. A benchmark moving backward while attacker use moves forward is not a target to accept. It is evidence of operating friction.

How should benchmarks change by industry?

Industry changes the constraint, not the physics of exposure. A payment environment has a formal patch requirement. A government cloud service has defined vulnerability windows. A factory may need validation and a physical maintenance period before changing a controller. None gets permission to ignore active exploitation.

The Moody's April 2026 data found slower than average remediation in education and telecommunications. Banking performed well on both unresolved known exploited vulnerability prevalence and repair speed. Information technology software issuers combined high prevalence with one of the shorter sector medians. The report's stronger point is that digital footprint size did not explain all sector variation. Ownership, legacy systems, operating constraints, and patch practice still matter.

For government cloud work, the current FedRAMP Revision 5 RA-5 parameters state 30 days for high risk vulnerabilities, 90 for moderate risk, and 180 for low risk under the traditional process. A CISA KEV due date supersedes those windows. These are compliance ceilings, not proof that waiting 29 days is sensible for an exposed active exploit.

Payment environments have a different rule. The PCI Security Standards Council clarified in May 2025 that PCI DSS Requirement 6.3.3 requires critical security patches within one month of release. Other applicable updates follow timeframes defined by the entity's risk assessment. The same FAQ says organizations can consider their own environment instead of blindly accepting an outside risk rank.

Build an internal benchmark table with separate cohorts for internet exposure, known exploitation, business importance, compensating controls, change constraint, and owner. Compare your trend with external data, but set targets from consequence and verified capacity.

What MTTR targets should you set by severity?

Do not assign time from CVSS alone. Severity describes technical impact under stated conditions. It does not tell you whether the affected component is present, reachable, used, protected, or already exploited. A medium finding on an exposed identity service can outrank a critical library on an isolated test image.

Use a target matrix. Known exploitation on a reachable critical service belongs in an emergency lane measured in hours or a few days. Reachable high impact findings with reliable evidence need a short planned window. Findings with strong compensating controls can use a longer date, but the control needs evidence and an owner. Unverified scanner claims need qualification, not a quiet SLA pause.

Backlog cohorts are better than one ranked list. Our guide to controlling a vulnerability backlog applies the same principle. Compare like with like, then look at transitions between cohorts when exposure or exploit evidence changes.

Which measurement mistakes corrupt MTTR?

• Survivor bias. Only closed findings enter the average, so abandoned old work disappears.
• Duplicate inflation. Repeated scanner imports create several clocks for one condition.
• False closure. Ticket resolution or command success stops time before verification.
• Mixed populations. Endpoints, cloud configuration, code, and appliances share one average.
• Reset clocks. Reopened or rediscovered work starts at zero and makes delay look smaller.
• Hidden pauses. Exception and maintenance waits vanish from elapsed exposure.

Keep a stable finding identity and a history of state changes. When a repair fails verification, reopen the original clock or report both first attempt and final closure. When the unsafe state returns, record recurrence separately so a fast repeated fix does not look like durable control.

How should exceptions appear in MTTR reporting?

An exception should leave the technical clock visible. Record decision time separately, along with the owner, reason, compensating control, approval, and expiration. Otherwise a team can improve MTTR by accepting its hardest work. That is accounting, not risk reduction.

Show exception age beside open finding age. Test the stated control on a schedule. If an exposed service is allowed to remain because a network rule blocks access, verify the rule and the path, not only the change ticket that created it. A failed control should move the finding back into active remediation immediately.

Expiration needs consequence. Route the item to a named decision owner before the date, retain the original discovery timestamp, and show every renewal. Five consecutive exceptions lasting 30 days create 150 days of exposure. Resetting the date each month may satisfy a queue view, but it destroys the metric leaders need.

How do you reduce mean time to remediate?

Break the total into qualification, ownership, planning, approval, waiting, execution, and verification. Fix the largest stage. If work sits unowned for nine days, a faster patch tool will not move the metric. Repair asset and service ownership.

Reuse reviewed plans for frequent conditions. Apply standing policy where consequence is low and proof is strong. Use canaries and failure limits to make change safer at speed. Capture evidence automatically after execution. The patterns in safe remediation scripts help prevent a fast command from becoming a slow incident.

Track arrival rate and verified completion rate too. If 90 qualified findings arrive each week and 75 close with proof, the backlog grows by 15 a week. Cutting MTTR for the easiest 75 will not remove the remaining 15. Capacity, scope reduction, or better prioritization has to change.

Frequently asked questions

What is a good mean time to remediate?

A good value meets your risk and regulatory limits, improves over time, and does not hide dangerous outliers. Compare cohorts and percentiles rather than adopting one generic number.

Should MTTR use calendar days or business days?

Use calendar time for exposure because attackers do not pause on weekends. You may also report working time to diagnose staffing and process effort, but label it separately.

Should accepted risk count as remediation?

No. Acceptance is a decision, not a fix. Stop a separate decision clock when acceptance is approved, but keep the technical condition visible with an owner, expiration, and control evidence.

How often should MTTR be reported?

Review urgent cohorts continuously and operating trends at least monthly. Use a rolling period with sample size so one small month does not create a false victory or panic.

Executive takeaway

Recalculate the last 90 days from qualified evidence to fresh proof. Publish mean, median, ninetieth percentile, oldest open age, reopen rate, and time in each workflow stage for separate risk cohorts. Then remove the longest wait. Do not buy faster execution until the data proves execution is the bottleneck.