Manual work persists when the data foundation is unreliable enough that automation cannot be trusted to close the loop. If identity records disagree across systems, teams fall back to spreadsheets, email and contractor-driven chase work because those are the only ways to reconcile exceptions. The process survives because the records do not.
Why manual IAM work survives platform rollouts
Manual IAM survives when automation is asked to make decisions against inconsistent identity data. Platform features can accelerate provisioning and policy enforcement, but they cannot reliably close exceptions if source systems disagree on ownership, status, entitlement history, or record freshness. In that state, teams keep spreadsheets, inbox queues and human chase work because those are the only tools that can reconcile bad inputs.
The persistence is often less about platform weakness than about control-plane trust. If the organisation cannot tell whether an identity is current, duplicated, orphaned or incorrectly scoped, then every automated workflow risks amplifying the error instead of fixing it. Manual handling becomes a compensating control for data quality, not a preference for old process.
Even well-funded IAM programmes can end up splitting work into “happy path” automation and exception-heavy human review. That split is common when joiner, mover and leaver data arrives late, is incomplete, or is maintained differently across HR, ITSM, directory and SaaS systems. The result is a platform that performs the easy cases while people absorb the edge cases that actually determine risk.
Where the operating model breaks down
Manual processes persist longest where identity lifecycle governance is fragmented. Discovery, ownership assignment, access review and deprovisioning all depend on a shared record of who or what an account represents, which system is authoritative, and which entitlements are expected. Without that shared record, automation can issue actions, but it cannot reliably confirm that the action is correct.
That creates a practical ceiling on straight-through processing. If the IAM team lacks confidence in lifecycle signals, then approvals, recertification and offboarding remain partly human because someone still has to judge exceptions, resolve duplicates and decide whether a record mismatch is benign or a real access issue. The platform may reduce volume, but it does not eliminate judgement where the data model is unstable.
This is why lifecycle discipline matters as much as tooling. A platform investment without ownership, classification and reconciliation rules simply moves the bottleneck downstream. For a deeper lifecycle view, the NHI Lifecycle Management Guide and Lifecycle Processes for Managing NHIs show how provisioning, rotation and offboarding only work when the records behind them are trustworthy.
Manual work also tends to survive where organisations treat identity as a ticket queue instead of a governed data set. That usually shows up as repeated rework, ad hoc exception handling and inconsistent entitlement cleanup, especially when teams cannot agree on what the authoritative source is for a given identity type. In those environments, the platform becomes a faster interface to the same unresolved operational debt.
What has to change before automation can close the loop
The real prerequisite is not another workflow feature, but cleaner identity data and clearer control ownership. Teams need a defensible source of truth for identity attributes, a reconciliation process for conflicts, and lifecycle rules that define when an account should exist, what it should be able to do, and when it should be removed. Without those basics, every “automation improvement” simply inherits the same ambiguity.
Practically, this means measuring exception rates, stale records and manual touches per lifecycle event before promising further automation. If the platform still needs humans to verify core attributes on most high-impact actions, the organisation has not yet reached a state where automation is safe to trust end to end. In that case, the right priority is data remediation and ownership, not more orchestration.
For practitioners comparing platform capability with operating reality, the strongest guidance is to align the IAM toolchain with lifecycle governance rather than expecting tooling alone to create it. The Identity Security Programme Guide and IAM and Identity Provider Buyer’s Guide are useful reminders that capability selection should follow operating model clarity, not replace it.
Risk and Threat Considerations
Manual fallback work is not just inefficient, it is often the only safeguard against incorrect automated access changes when identity records are inconsistent. The risk is that organisations can mistake “more automation” for “more control” while stale, duplicate or misowned records continue to drive bad decisions across provisioning and deprovisioning.
Failure mechanism: Conflicting identity data, weak ownership, or delayed lifecycle updates force teams to bypass automation and handle exceptions manually, leaving the same bad records in circulation.
Impact: Access persists longer than intended, removal is delayed, and exception handling becomes the normal path, increasing operational load and the chance of entitlement drift or missed offboarding.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-1 — Inventory and Control of Enterprise Assets | Identity work slows when inventories and ownership records are inconsistent. |
| Recommendation — Maintain authoritative inventory and ownership records before automating identity workflows. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Manual IAM persists where account lifecycle decisions need governance and exception handling. |
| IA-5 — Authenticator Management | Identity operations depend on managed credentials and trusted lifecycle handling. | |
| Recommendation — Define account lifecycle rules and review exceptions before expanding automation. Track credential lifecycle events and remove stale authenticators promptly. | ||
| ISO/IEC 27001:2022 | A.5.9 — Inventory of information and other associated assets | Identity governance needs reliable asset and record inventories to reduce manual reconciliation. |
| Recommendation — Keep identity-related records inventoried and reconciled to reduce exception work. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud identity platforms still rely on lifecycle governance and accurate identity records. |
| Recommendation — Align IAM controls to authoritative lifecycle data and exception handling. | ||
Practitioner Guidance
What to prioritise: Fix the identity records that create the highest manual load first, especially mismatched ownership, duplicate identities, and stale lifecycle status. Those are usually the points where automation fails repeatedly and where human intervention hides the deepest operational debt.
What to verify: Before increasing automation scope, verify that one authoritative source exists for identity attributes, that exceptions are measurable, and that offboarding and access review decisions are traceable back to a clear lifecycle rule. If those cannot be shown, the process is not ready to be fully automated.
Decision rule: If an automated IAM action depends on a record that is routinely corrected by hand, treat the record problem as the control issue. Automating over bad data only speeds up inconsistency.
Practitioner takeaway: Manual IAM persists when the organisation is still using people to reconcile trust in the data, so the highest-value investment is usually governance and record quality, not another workflow layer.
Related resources from NHI Mgmt Group
- Why do healthcare identity breaches persist even when IAM investment is a priority?
- Why do non-human identities create compliance risk even when policies exist?
- What is the difference between human IAM controls and NHI governance?
- What does the 144:1 NHI-to-human ratio mean for IAM governance programmes?