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

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.

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.

Related resources from NHI Mgmt Group

• How should security teams make NHI best practices usable across the business?
• How should security teams govern AI use cases across multiple business units?
• How should security teams evaluate contract management software for visibility and compliance across business units?
• How should security teams benchmark application security risk across multiple tools and business units?