What breaks when security teams measure resolution time using calendar time instead of technician touch time?

The baseline becomes inflated and misleading, because a ticket can sit open for days while staff only work on it for minutes. Calendar time hides the real labour cost and makes manual work look worse or better for the wrong reasons. Touch time is the only measure that captures actual human effort spent handling the request.

Why This Matters for Security Teams

Calendar time and touch time answer different questions, but teams often treat them as if they measure the same operational cost. Calendar time captures queueing, waiting on approvals, and dependencies across teams. Touch time captures the actual analyst effort spent investigating, remediating, documenting, and closing the ticket. When those measures are mixed, reporting can distort staffing decisions, SLA design, and automation priorities.

This matters most in security operations, IAM, and incident workflows where a request may be blocked by third-party validation, change windows, or escalation paths even though a technician spent only a few minutes actively handling it. A calendar-time metric can make a heavily automated process look inefficient simply because it depends on external delay, while a manual process can look acceptable if the work is spread across long elapsed periods. That is why control-minded teams should align metrics to the activity being judged, not just the elapsed wall-clock duration. NIST’s control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it pushes teams to define, monitor, and evidence processes with clear accountability rather than ambiguous timing labels.

In practice, many security teams only notice the distortion after a backlog review has already turned into a staffing argument rather than a workflow analysis.

How It Works in Practice

The practical fix is to separate throughput from labour. Calendar time measures how long a ticket or case remains open from creation to closure. Touch time measures the cumulative minutes or hours that people actively work on it. Those two measures should be reported together, because each exposes a different operational truth.

For example, a phishing investigation may sit in a queue for 18 hours before an analyst reviews it, then take 12 minutes to confirm, contain, and document. Calendar time is useful for service expectations, escalation tracking, and customer experience. Touch time is useful for capacity planning, process redesign, and automation justification. If the team wants to know how much human effort a control consumes, touch time is the better denominator. If the team wants to know how long risk remained unresolved, calendar time is the better risk indicator.

• Use calendar time for SLAs, escalation thresholds, and business-facing reporting.
• Use touch time for workload measurement, analyst productivity, and automation impact.
• Record pause reasons separately, such as waiting for user response, change approval, or external dependency.
• Keep the measurement rule consistent across tickets, incidents, access requests, and exceptions.

This distinction maps well to operational resilience thinking in CISA incident response planning guidance, where elapsed containment time and active response effort are not interchangeable. It also helps in access governance, where a long approval chain can inflate calendar time even when the technical provisioning work is minimal. Teams should be careful not to use calendar time alone as a proxy for labour cost or team efficiency, because that confuses process latency with analyst effort. These controls tend to break down when ticket systems do not capture pause states cleanly because the workflow engine cannot distinguish waiting time from active handling.

Common Variations and Edge Cases

Tighter measurement often increases process overhead, requiring organisations to balance better visibility against the burden of recording every work interval. That tradeoff is real, especially when teams handle mixed work types such as incidents, service requests, vuln remediation, and access approvals. Best practice is evolving, but current guidance suggests that a single metric rarely serves all use cases.

Some environments benefit from hybrid reporting. A SOC may track calendar time for incident containment and touch time for analyst cost per case. A PAM workflow may track calendar time for approval latency and touch time for privileged session review. In highly automated pipelines, touch time can be very small, so manual effort becomes visible only when it is separated from queue time. In heavily regulated environments, elapsed time may still matter more because the business cares about how long a control gap remained open, not just how long staff worked on it.

There are also edge cases where touch time is hard to define. Should waiting for an external vendor reply count as active handling? Should a partially automated workflow include machine execution time? Those questions need policy, not guesswork. Teams should document what counts as touch time, what counts as idle time, and how reassignment or handoffs are recorded. For organisations using NIST AI Risk Management Framework principles in AI-assisted workflows, the same logic applies: measure human intervention separately from system delay so accountability stays clear. MITRE ATT&CK can also help teams understand where time is spent during adversary response, but it does not replace workflow timing discipline.

Guidance breaks down most often in decentralized teams with inconsistent ticket hygiene, because the metric becomes a reporting artifact rather than a reliable operational measure.

Related resources from NHI Mgmt Group

• How should security teams measure identity risk instead of using static tiers?
• What breaks when security teams rely on alerts instead of real-time enforcement for AI data protection?
• What breaks when privilege duration is measured in calendar time instead of task time?
• How should security teams govern AI agents that call APIs instead of using a UI?