Why do identity governance programmes still leave so much manual toil in place?

Why identity governance still leaves manual toil in place

identity governance programmes are usually built to answer entitlement questions, not to fully automate every operational decision. In practice, the hardest work sits in the exceptions: applications with weak APIs, inconsistent entitlement models, approval chains that depend on business context, and joiner-mover-leaver workflows that do not map cleanly to a single policy. That is why teams often automate the obvious parts and leave the messy edge cases to humans.

Long-tail systems are the main drag. Many were never designed for orchestration, so governance tools can discover access but cannot reliably change it without brittle scripts, ticket handoffs, or compensating controls. Where the access model is opaque, teams also need human review to decide whether a request is legitimate, whether a removal will break a process, or whether a privileged role is actually a shared operational function. The result is that identity governance becomes a control layer with a manual backstop rather than a fully closed loop.

That pattern is common across NHI and human identity environments alike, and the same governance gap shows up when organisations cannot maintain basic lifecycle discipline. NHIMG research on NHI operations notes that 71% of non-human identities are not rotated within recommended time frames, which is a reminder that policy intent and operational execution often diverge when automation is incomplete. In practice, many security teams discover the toil only after repeated exceptions have already become the normal way work gets done.

How the manual work shows up in real operations

Manual toil usually appears in four places: access requests, approvals, reconciliations, and remediation. Requests need manual enrichment because the requester often cannot describe the exact entitlement in system terms. Approvals need people because the decision depends on business purpose, separation-of-duties conflicts, or whether temporary access is justified. Reconciliations need humans because entitlements drift across directories, SaaS apps, and custom systems. Remediation needs humans because revoking access may require coordination with application owners or release windows.

Automation breaks when the identity governance platform can only see part of the truth. A workflow may know that access exists, but not whether it is tied to a service account, a batch job, a delegated admin role, or an application-specific object that has no reliable API. In those environments, the control plane becomes partially informational and partially procedural. Teams then rely on tickets, spreadsheets, and manual attestations to bridge gaps the tooling cannot close.

This is why the question is not simply “why not automate more?” It is “what decision can be standardised without creating business breakage or false confidence?” For some access changes, a deterministic policy is enough. For others, the right control is a tighter human approval path with better evidence, not a weaker automation promise. The practical boundary is where the system can execute safely without needing interpretation. Current guidance suggests using the available control surface rather than forcing one uniform workflow across every application.

• Use automation for repetitive, well-bounded actions such as provisioning, deprovisioning, and periodic recertification where the entitlement model is stable.
• Keep humans in the loop where the access meaning is context-dependent, such as emergency access, shared accounts, or critical production roles.
• Instrument the workflow so every manual exception becomes measurable technical debt, not an invisible normal state.

For broader identity governance patterns, the Ultimate Guide to NHIs is useful because it frames lifecycle, visibility, and revocation as operational controls rather than abstract policy goals. These controls tend to break down when the application estate is fragmented, because the governance platform cannot enforce decisions consistently across systems that expose different levels of automation.

Where teams should draw the automation boundary

Tighter automation often reduces repetitive work, but it also increases the cost of getting the policy wrong, so organisations need to balance throughput against assurance. The boundary should be drawn around decision quality, not around the desire to eliminate tickets. If the system can confidently classify the request and execute safely, automate it. If the system cannot understand the access context or cannot reverse the action cleanly, keep a human decision point.

What to prioritise: Focus first on the workflows that create the most repeated effort with the least decision value, such as standard joiner and leaver actions, simple role assignments, and evidence collection for access reviews.

What practitioners underestimate: Manual toil often persists because it is compensating for bad data, weak ownership, or poor application design, not because teams are reluctant to automate. Until those root conditions change, adding another workflow layer usually just moves the manual work somewhere less visible.

Practitioner takeaway: The goal is not zero human involvement; it is to reserve human judgment for genuinely ambiguous access decisions and remove humans from routine, repeatable ones.

Related resources from NHI Mgmt Group

• Why does outdated access create security risk in identity governance programmes?
• How should security teams modernize identity governance when apps, bots, agents, and service accounts outgrow manual reviews?
• Why does manual identity governance create more risk in fast-changing environments?
• Why is it important to integrate identity and data governance?