Mean Time to Remediate: Measuring What Clients Fix Between Pentests

Mean time to remediate, or MTTR, is the average time between a client being told about a vulnerability and that vulnerability being fixed. For a testing firm with returning clients it turns a series of separate reports into evidence that a client’s exposure is shrinking, or is not, which is exactly what a CISO needs to show a board. It only works once three things are settled: what counts as the same issue from one engagement to the next, when the clock starts and stops, and what is reported beside the average so that it cannot flatter.

Why a single report cannot answer it

A report is a snapshot of one engagement. It says what was found in a scope over a few days, and nothing about whether last year’s findings were fixed, how long that took, or whether the same weaknesses keep coming back. Clients who test every year end up with a folder of PDFs and no way to read across them, and the questions their leadership asks are all across them: are we getting better, are we fixing things in time, what keeps recurring.

The firm holds every finding of every engagement, with its status and dates. That is the raw material for a register that answers those questions, provided the findings can be lined up.

One issue, many engagements

The first decision is identity. Last year’s “SMB signing not required” and this year’s finding of the same name are one issue for the client, reported twice. Findings should be grouped across engagements by the issue they describe: the same entry in the firm’s library, or the same normalised title. Getting this right matters for the same reasons as deduplicating scanner findings within one report: count an issue twice and every figure that follows is wrong.

Grouping also exposes recurrence. An issue fixed after the first engagement and reported again by the second is not new; it came back. That is worth its own flag, because it usually means a fix was applied to the hosts tested rather than to the build or process that produced them.

When the clock starts and stops

The clock should start when the client was told, which is normally the day the report went out, or the day a finding was released early for an urgent fix. Starting it on the day the tester found the issue charges the client for the firm’s own reporting time.

It stops when the finding is marked remediated, ideally confirmed by a retest; running a retest properly covers what that confirmation should say. Two cases need care. A finding whose risk the client accepted is closed but not fixed, so it belongs in the register and out of the remediation average; when a client accepts the risk instead of fixing it covers recording that decision. And findings fixed before anyone recorded the date need a fallback, such as the retest’s completion, rather than the date the record was last touched.

Targets by severity

An average means more against a target. Agree a remediation target for each severity with the client, and treat any open issue past its target, counted from the day it was reported, as overdue. The client’s own vulnerability management policy is the best source of targets; where there is none, a firm needs defaults to start from. Pental starts from 14 days for critical, 30 for high, 90 for medium and 180 for low, and expects a client’s policy to replace them.

The figures that keep MTTR honest

MTTR on its own has a blind spot: it only counts what was fixed. A client that fixes the easy medium findings in a week and leaves every critical open looks excellent on the average. So report it with the figures that cover what it cannot see:

Figure	What it shows
Open issues, by severity	What the client is exposed to today, and the change since the end of the last quarter
Overdue	Open issues past the target for their severity, the figure most likely to need action
Mean time to remediate	Days from report to fix over the last twelve months, overall and for critical and high separately
Fixed within target	The share of fixes that met their target, which an average can hide

Quarter by quarter

Trends are what a board reads. Three views cover most of what is asked: open issues at the end of each quarter, stacked by severity, which shows whether exposure is shrinking; issues found and fixed each quarter, which shows whether fixing keeps pace with testing; and the time fixes took each quarter, which shows whether the process is getting faster. Count an issue as found in the quarter it became open, whether for the first time or again after a fix, so that recurrence shows up as found rather than disappearing.

A language the board already uses

Security leaders report against frameworks. Mapping open issues to MITRE ATT&CK tactics and techniques shows which stages of an attack the client’s weaknesses would help with, initial access or credential access for example, and mapping each issue’s CWE to the OWASP Top 10 gives application issues a category everyone recognises. Neither replaces the findings, but both make the register readable to people who will never open a report. And with an asset inventory behind it, each issue can name the team that owns it, which turns a list of overdue items into a list of conversations.

For what the client should do with a report in the meantime, see what happens after a penetration test.