How should organisations restart a stalled IAM and IGA program without adding more manual work?

Why This Matters for Security Teams

Stalled IAM and IGA programs usually fail for the same reason: they become review factories instead of control systems. When provisioning still depends on tickets, spreadsheets, or one-off approvals, the team spends more time moving records than reducing risk. For identity governance to restart cleanly, the program has to remove friction from the highest-volume lifecycle events first, then let automation absorb the repetitive work that humans should not be doing by hand.

This is especially important because manual identity operations do not scale with the volume and churn of modern environments. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, and 96% store secrets outside secrets managers in vulnerable locations including code and config files. That combination means identity sprawl and access drift tend to grow while the governance backlog grows faster. NIST’s control guidance also makes clear that access enforcement and account management need repeatable controls, not ad hoc handling. See NIST SP 800-53 Rev 5 Security and Privacy Controls for the control families that translate this into operational expectations.

In practice, many security teams only discover how fragile their identity program is after an audit exception, a delayed onboarding wave, or a leaver still holding access weeks after departure.

How It Works in Practice

The restart should begin with lifecycle automation for joiners, movers, and leavers, because those events are high-volume, easy to measure, and directly tied to risk reduction. Start by identifying the authoritative systems for employee status, department, manager, and role data, then map those sources to the accounts, groups, and entitlements that actually change when people move. The point is not to automate every workflow at once. The point is to automate the most repetitive one.

A workable sequence usually looks like this:

• Define a narrow first scope, such as one business unit, one directory, or one critical SaaS platform.
• Connect authoritative HR or workforce data to provisioning logic so changes flow from source of truth to target system.
• Replace spreadsheet approvals with policy-driven rules for standard access packages and role changes.
• Automate deprovisioning for leavers and trigger revocation checks for high-risk access immediately.
• Measure cycle time, orphaned access, and exception volume before expanding scope.

Automation works best when governance is simplified at the same time. If every request still needs custom review, the program just moves the manual work into a different queue. Current guidance suggests using least privilege, role-based baselines, and exception handling for unusual access, while reserving human review for edge cases and sensitive roles. NHIMG’s research on secrets hygiene also shows why this matters operationally: the organisation cannot govern access effectively if secrets are already scattered across code, messaging tools, and unmanaged stores. For deeper context, see Azure Key Vault privilege escalation exposure and TruffleNet BEC Attack — Stolen AWS Credentials.

This approach breaks down when the organisation has no authoritative source of truth for roles or when downstream systems cannot accept automated deprovisioning events because access is embedded in custom workflows.

Common Variations and Edge Cases

Tighter lifecycle automation often increases upfront coordination, requiring organisations to balance speed against data quality and change management. That tradeoff is real, especially in hybrid environments where HR, IT, and application owners all define identity attributes differently. Best practice is evolving here, but there is no universal standard for how much identity data must be normalised before automation can safely begin.

Some organisations restart by focusing on offboarding first because it delivers the clearest risk reduction. Others start with standard joiner packages because onboarding pain is easier to prove to leadership. Both approaches can work, but the safest path is usually the one that removes the most manual churn without widening access. If access models are already inconsistent, do not try to rebuild the entire governance catalog before shipping one automated workflow. That often stalls the program again.

There are also environments where full automation is not appropriate yet. Regulated entitlements, break-glass access, and highly sensitive admin roles may still need explicit review until confidence in the source data and control logic improves. The objective is not zero human oversight. The objective is to reserve human effort for exceptions while removing repetitive identity handling from the operating model. That is the difference between a restart and another failed redesign.

Related resources from NHI Mgmt Group

• How should organisations modernise IGA without creating more manual work?
• How should security teams extend IAM and IGA coverage to disconnected apps without creating more manual work?
• How should organisations improve privileged access administration without adding more manual work?
• How should organisations frame an IAM roadmap so executives see business value, not just technical work?