How do security teams avoid misleading MTTR averages across business units?

They should calculate the metric at the lowest meaningful scope first, then roll it up using total resolved time and total closed findings. That preserves weighting and prevents small teams with a few fast closures from distorting the organisation-wide view. The key is to aggregate the raw data, not the already-averaged numbers.

Why raw MTTR beats business-unit averages

Mean time to resolve only stays meaningful when every observation carries the right weight. If one business unit closes a handful of findings quickly and another closes many more over longer periods, an averaged average can understate the organisation’s true recovery pace. The practical fix is to preserve the underlying counts and durations until the final roll-up, then calculate from the totals.

That approach keeps the metric tied to actual work performed, rather than to the number of teams reporting it. It also avoids a common reporting error, where each business unit gets equal influence regardless of how many findings it resolved or how long those findings remained open. For executive reporting, the organisation-level number should answer, “How long did closure actually take across all closed items?”

How to aggregate without distorting the result

The safest method is to compute at the lowest meaningful scope, such as team, asset group, product line, or control domain, and keep the raw totals available for consolidation. From there, roll up using total resolved time divided by total closed findings, not by averaging team-level MTTR values. That preserves weighting and prevents small samples from overwhelming the result.

This also gives teams a fairer comparison framework. A unit that closes five incidents in two days each should not distort the same dashboard as a unit that closes two hundred items in eight days each. Weighted aggregation makes the metric resistant to sample-size noise, which is especially important when business units differ in maturity, intake volume, or remediation complexity.

When teams need both local and enterprise views, the local metric should stay local and the roll-up should stay roll-up. In practice, that means storing the raw closure time for every item, the closure count for every scope, and the business-unit boundary used for reporting. If the data model only retains pre-averaged values, the organisation loses the ability to recalculate a trustworthy enterprise number later.

What to verify before trusting the dashboard

First, verify that every closed item contributes once, and only once, to the roll-up. Duplicate records, reopened findings, and inconsistent closure timestamps can all skew MTTR just as much as bad averaging can. Second, confirm that the denominator is closed findings, not all findings raised, otherwise the metric starts reflecting intake volume more than resolution performance.

Second, check whether the dashboard mixes scopes with different operating rhythms. A monthly patch queue, a daily vulnerability triage queue, and an incident response queue should not be forced into the same unqualified average unless the reader understands the operational differences. If leadership wants one number, the number should be derived from consistent rules, with a clear definition of what counts as “resolved” and when timing starts and stops.

In many programmes, the real problem is not the metric itself but the reporting layer. Teams often export already-averaged data from separate systems, then combine those averages as if they were raw observations. That is mathematically convenient and operationally misleading. The reporting standard should require source-level timestamps or duration totals, so the final aggregation can be reconstructed and audited.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 provides the primary governance reference for this topic.

Framework	Control / Reference	Relevance
NIST CSF 2.0	GV.OC-01 — Organizational Context	Business-unit MTTR rollups depend on consistent reporting context and scope definitions.
	GV.OV-01 — Oversight of the Cybersecurity Risk Management Strategy	Accurate MTTR aggregation supports leadership oversight of security performance.
	ID.RA-01 — Asset Vulnerabilities are Identified and Recorded	Closure timing for findings is only meaningful when findings are consistently recorded.
Recommendation — Define reporting scope and metric boundaries before comparing MTTR across teams. Use a governed metric definition so executive reporting reflects actual remediation performance. Keep item-level records so closure-time reporting can be recomputed from source data.

Practitioner Guidance

What to prioritise: Preserve item-level closure time and count data in the source system or reporting warehouse. If the raw values are gone, the enterprise MTTR has already become less trustworthy.

Decision rule: If the audience is asking for an organisation-wide view, aggregate durations and counts first, then calculate the metric once. If the audience is comparing teams, keep scoped MTTR side by side with sample size so the comparison is not over-read.

What to verify: Make sure the same business rules define start time, stop time, reopen handling, and closure eligibility across every unit. Inconsistent definitions create false differences that look like performance gaps.

Common mistake: Do not average business-unit averages unless each unit has the same number of closed items and comparable resolution distributions. That shortcut hides the weighting error the question is trying to avoid.

Practitioner takeaway: A good MTTR dashboard reports one mathematically honest enterprise number and preserves local detail for diagnosis, because the point of roll-up is comparability, not convenience.