How should security teams build a credible manual cost baseline before automating repeatable identity or access work?

Why This Matters for Security Teams

A credible manual cost baseline is what turns “automation would be nice” into a budgetable case. For identity and access work, the real question is not how long a ticket sits open, but how much analyst touch time is consumed by repetitive actions such as account unlocks, access resets, entitlement changes, and non-human identity credential rotation. That distinction matters because elapsed time often hides queue delays, approvals, and waiting on other teams, while touch time reflects actual labour cost.

Security teams also need this baseline to avoid overclaiming automation value. If the starting point is weak, any reduction in cycle time, error rate, or backlog can be misread as savings. A defensible baseline should line up with control intent in NIST SP 800-53 Rev 5 Security and Privacy Controls, where process discipline and measurable control performance support auditability. In practice, many security teams discover their true cost only after recurring access requests, password resets, or service account exceptions have already become too frequent to manage manually.

How It Works in Practice

Begin by defining the work scope tightly. Separate repeatable identity or access tasks from one-off investigations, project work, and exception handling. The most useful categories are the ones that can plausibly be automated later: access approvals with standard patterns, joiner-mover-leaver events, privileged access requests, periodic recertification, and NHI secret rotation. For each category, measure touch time only, then calculate monthly labour cost using fully burdened hourly rates. Trailing 12 month volume averages are usually better than a single busy month because they reduce noise from seasonal hiring, audits, or incident-driven spikes.

A practical baseline usually includes:

• Average analyst minutes per ticket, not portal wait time or queue delay
• Ticket count by use case, ideally split by business unit or application tier
• Fully burdened hourly rate, including salary, benefits, overhead, and support costs
• Rework rate, escalation rate, and exception rate for low-quality requests
• Manual control points that must remain even after automation, such as approvals or logging

That structure helps teams distinguish efficiency gains from simple cost shifting. It also supports control mapping, since routine access work often intersects with identity governance, PAM, and NHI stewardship. For example, a recurring service account change may look like a ticketing issue, but the real exposure is secret handling and privilege sprawl. The OWASP Non-Human Identity Top 10 is useful here because it frames where unmanaged machine identities create operational and security drag. If the baseline ignores those identities, automation ROI is understated and residual risk is mispriced.

Teams should also validate the data source. Service desk exports, IAM workflow logs, and PAM audit trails often tell different stories, so reconciliation is necessary before the baseline is used in a business case. Where ticket metadata is poor, current guidance suggests sampling a statistically modest but representative set of cases and then extrapolating carefully. These controls tend to break down in federated environments with inconsistent ticket classification, because the same work is often recorded under multiple queues and analysts spend more time correcting records than handling requests.

Common Variations and Edge Cases

Tighter measurement often increases analyst overhead, requiring organisations to balance precision against the cost of collecting it. That tradeoff is real, especially when teams are asked to measure every interaction in detail. Best practice is evolving, and there is no universal standard for how granular a manual baseline must be before it is credible. For most cases, enough precision to support a decision is better than perfect precision that never ships.

One common edge case is mixed workflows. A request may start as routine access work, then become a privileged exception or a fraud review. In those situations, split the manual effort by task type rather than forcing a single average across the whole ticket. Another edge case is high-automation environments where the remaining manual work is almost entirely exception handling. There, the baseline should focus on exception volume, not total ticket volume, because the automatable portion has already been removed.

Identity teams should also be careful with NHI and agentic AI operations. Credential issuance, rotation, and revocation for service identities may not resemble human access tickets at all, but they still consume labour and create security exposure. That makes the baseline useful for both budget planning and control hardening. Where secret sprawl, delegated approvals, or shared admin accounts dominate, the baseline can look artificially cheap until a breach, audit finding, or access review forces the true cost into view.

Related resources from NHI Mgmt Group

• How should security teams implement identity visibility before tightening access controls?
• How should security teams build identity maturity without over-automating too early?
• How should security teams replace manual access reviews with automated identity governance?
• What should security teams do before automating identity decisions?