What should IAM teams do if access approvals and provisioning live in different systems?

Why split approval and provisioning becomes a governance problem

When approvals and provisioning sit in different systems, the main risk is not technical integration friction. It is that the organisation can no longer reliably show a single, auditable chain from request to approval to entitlement change. That weakens accountability, complicates reviews, and creates room for mismatched decisions or shadow exceptions.

The practical question is whether the approval system and the provisioning system still behave like one control. If they do not share the same request identifier, approver context, and final outcome record, teams lose the ability to answer a basic audit question: who approved this access, on what basis, and did the granted access match that decision?

This is why the issue is usually a governance design problem before it is an interface problem. A clean integration can still fail if the two systems produce different records, different timestamps, or different interpretations of the approved scope. IAM and IGA Basics is useful here because the control objective is not just request handling, but entitlement governance across the full lifecycle.

What has to stay linked across systems

The minimum control expectation is one decision record, one approval trail, and one provisioning outcome. That means the approval evidence should travel with the request, not sit in a separate workflow island that must be reconciled later by manual detective work.

In practice, the provisioning step should inherit the approved scope rather than reinterpreting it. If the approver granted a role, group, or application entitlement, the downstream system needs to create exactly that outcome or surface a controlled exception. The Joiner-Mover-Leaver (JML) Guide is relevant because lifecycle-driven access changes depend on clean handoff between decision and execution.

For mixed environments, the best pattern is usually to bind both systems to a common workflow key and a common entitlement vocabulary. That lets teams trace the original request, the approving authority, the resource being granted, and the actual account or token change. IAM and IGA Basics also covers provisioning and access review patterns that become harder when records are split across tools.

Where machine or application access is involved, the same principle applies to non-human accounts, keys, or service credentials. Separate systems are acceptable only if they still preserve an unbroken record of who authorised the access and what operational change was made. Ultimate Guide to NHIs, Lifecycle Processes for Managing NHIs is directly relevant because lifecycle control is where approval, provisioning, rotation, and revocation should remain aligned.

How IAM teams should design the operating model

IAM teams should treat the approval system as the system of record for the decision and the provisioning system as the system of record for execution, but neither should be allowed to stand alone. The operating model must define which system owns the authoritative request, how status moves between them, and which fields are mandatory for reconciliation.

What to verify: Confirm that every approved request can be matched to one downstream provisioning event, and that every provisioning event can be traced back to one approved request. If the matching relies on screenshots, email, or informal follow-up, the control is too weak for audit or incident review.

What to prioritise: Start with high-risk entitlements, privileged access, and non-human credentials. If the split workflow affects admin access, service accounts, or secrets with long lifetimes, any inconsistency has a larger blast radius than a routine business application request.

Common mistake: Teams often focus on API integration and ignore identity reconciliation. That leaves duplicate approvals, partial provisioning, or orphaned entitlements that look successful in one system and incomplete in the other. Top 10 NHI Issues is a useful reference when that gap affects service accounts, tokens, or other non-human access paths.

Practitioner takeaway: If the systems cannot produce one end-to-end evidence trail, the workflow should be treated as a control gap until the approval, execution, and audit records are provably reconciled.

Related resources from NHI Mgmt Group

• How should teams handle access requests when ServiceNow and provisioning live in different systems?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• How should security teams govern API keys used for generative AI access?