What breaks when organisations try to model IGA savings as full automation?

The model becomes unrealistic if it assumes every manual step disappears. Many workflows still need human judgment, especially access approvals, unusual entitlement review, policy design, and auditor assessment. A defensible ROI case measures the avoidable administrative work, not the entire process. That produces a more credible forecast and gives leadership a number they can challenge logically.

Why the Savings Model Breaks

IGA savings estimates break when they treat “automation” as a synonym for “no human work.” Identity governance still contains judgment-heavy steps, especially where access requests are unusual, entitlements are ambiguous, policy exceptions exist, or audit evidence must be reviewed by someone accountable for the decision. A credible model separates repetitive administration from the parts of the workflow that still require interpretation, escalation, or sign-off.

The mistake is usually not the automation program itself, but the ROI math around it. Teams often count the full cost of approvals, certifications, and review cycles as if every step disappears once a workflow is digitised. In reality, automation reduces handling time, routing effort, and clerical follow-up, while the highest-risk decisions remain constrained by policy and accountability. The more regulated or exception-heavy the environment, the larger that residual human layer tends to be. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because access control, audit and configuration controls all assume some decisions remain reviewable, not fully hands-off.

In practice, the savings overstatement usually appears first when leadership asks why the “fully automated” process still needs approvers, reviewers and exception handling.

How It Works in Practice

A defensible IGA savings model starts by splitting the workflow into activities that can be automated, activities that can be accelerated, and activities that must remain human-controlled. Provisioning tickets, entitlement lookups, reminders, evidence collection and case routing are often strong automation candidates. Access approvals, policy interpretation, compensating controls, and certification sign-off are not eliminated so much as made faster, better structured, and easier to evidence.

The practical question is not whether automation exists, but how much labour it actually removes. For example, a joiner-mover-leaver workflow may stop an analyst from manually creating accounts, but it does not remove the need to confirm role fit, validate exceptions, or resolve conflicting ownership. Likewise, access recertification tools can present cleaner data, yet reviewers still need to challenge outliers, assess business context, and decide whether an entitlement is justified.

Measure avoided manual handling, not the total process cost.
Separate “straight-through processing” from exception paths.
Keep a line item for policy design, audit support and investigation time.
Assume partial adoption until actual workflow data proves otherwise.

If the model ignores exception rates, policy tuning, and review overhead, it will overstate savings and understate the operating effort needed to keep the control defensible.

Common Variations and Edge Cases

Tighter automation often lowers unit handling cost, but it also increases sensitivity to policy quality, data quality and exception volume, so organisations have to balance efficiency against control reliability. The model changes materially by environment: a low-risk, standardised workforce joiner process can automate heavily, while privileged access, third-party access, and entitlement reviews for critical systems usually retain more human judgement.

There is also a common boundary problem. Teams sometimes classify a workflow as “automated” because the system generates the decision record, even though a person still validates unusual access, rejects edge cases, or performs audit review afterward. That is partial automation, not full automation, and the financial model should reflect that distinction. The same is true for policy design and change management, which are recurring labour costs even when day-to-day ticket handling falls sharply.

NIST Cybersecurity Framework 2.0 is a helpful anchor when leadership wants to separate governance and oversight work from operational execution, because those functions do not disappear just because a workflow is automated.

Risk and Threat Considerations

Overstating IGA automation creates governance risk as much as budgeting risk. If a programme assumes near-total labour removal, leadership may underfund reviewer capacity, exception handling, and audit support, which leaves the organisation exposed when access decisions do not fit the standard rule set. That matters most where privileged access, sensitive systems, or external audits are involved.

Failure mechanism: The model collapses distinct work types into one “manual process” bucket, then assumes the entire bucket goes away. In practice, the remaining work concentrates around the hardest cases, so the organisation ends up with fewer routine tasks but the same, or even higher, need for skilled review at the edge cases. That is where control failures and backlog usually build.

Impact: The result is a misleading ROI case, under-resourced governance, slower exception resolution, and weaker assurance that access decisions are still explainable to auditors and business owners.

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, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	GV — Govern	IGA ROI depends on governance, oversight and accountability costs
	PR.AA — Identity Management, Authentication and Access Control	IGA savings concern access lifecycle work and human review overhead
Recommendation — Account for governance and oversight effort when modelling identity automation savings. Measure automation savings against access lifecycle tasks that still need review.
CIS Controls v8	6 — Access Control Management	IGA automation directly affects account and entitlement administration work
Recommendation — Use access control scope to estimate which identity tasks can actually be automated.
NIST SP 800-53 Rev 5	AC — Access Control	Access approvals and entitlement review remain control-bearing tasks
	AU — Audit and Accountability	Audit evidence and review support remain even when workflows are automated
Recommendation — Preserve manual review for access decisions that require accountability. Budget for audit support and evidence collection as continuing operating work.

Practitioner Guidance

What to prioritise: Build the business case around avoidable effort, not theoretical elimination. Separate request handling, policy maintenance, exception review, audit response and entitlement cleanup into different cost lines so the ROI survives challenge.

What to verify: Check actual workflow logs before claiming savings. If reviewers still touch a large share of cases, or if exception handling consumes most of the analyst time, the process is not fully automated and should not be modelled that way.

Decision rule: If a step requires contextual judgement, treat it as residual operating cost even when the ticket is system-driven. Only remove labour assumptions where the control demonstrably becomes straight-through and low-risk.

Practitioner takeaway: The strongest ROI case is usually the one that admits automation does less than the headline suggests, because that keeps the forecast credible and prevents leadership from budgeting against a fantasy of zero-touch governance.