Ask who "owns" user provisioning at most organizations, and you'll get one answer: IT. That answer is wrong in a way that causes real problems, because provisioning actually passes through six distinct stages, several different owners, and most provisioning failures happen exactly at the handoff between them.
Provisioning looks like a single event from the outside: someone needs access, and eventually they have it. Documented properly, it's a process flow with distinct stages, each with a different owner, a different input, and a different failure mode. Treating the whole thing as "an IT task" obscures where accountability actually sits at each stage, and that ambiguity is exactly where requests stall, get approved without proper review, or get provisioned incorrectly.
This is a reference for mapping that flow explicitly, stage by stage, with ownership assigned at each one.
Stage 1: Initiation
What happens: a need for access is identified, either by an HR event (a new hire, a role change) or by an individual request (someone needs a specific tool for a project).
Who owns it: HR for lifecycle-triggered initiation; the requesting employee or their manager for ad hoc requests.
Common failure: ad hoc requests submitted informally, through a direct message or a hallway conversation, rather than through a defined intake channel. Informal initiation is invisible to any downstream process, which means it either gets forgotten or gets handled entirely outside the governed flow.
Stage 2: Validation
What happens: the request is checked against defined policy: does this role, in this context, typically warrant this access? Is the requester who they claim to be, in the role they claim to hold?
Who owns it: typically an automated policy check, with escalation to a manager or IT for anything that doesn't cleanly validate against existing policy.
Common failure: skipping validation for "obviously fine" requests, which is how policy drift starts. A request that seems reasonable in isolation, evaluated without reference to the actual documented policy, is exactly how access creeps wider than intended over time.
Stage 3: Approval
What happens: a designated approver reviews and signs off, with the approval chain scaled to the sensitivity of the request, a single manager approval for routine access, multiple approvers for sensitive systems or elevated privileges.
Who owns it: the manager, app owner, or security team member designated by policy for that specific type of request, not a generic "IT approves everything" default.
Common failure: a single, overloaded approver bottlenecking every request regardless of type, or approval depth that doesn't scale with risk, meaning sensitive access gets the same one-click approval as a routine tool.
Stage 4: Provisioning
What happens: the actual technical execution, the account gets created or the entitlement gets granted, through whatever connector or manual process is available for that specific application.
Who owns it: IT or an automated provisioning system, executing what was approved, at the specificity (app-level or entitlement-level) the approval actually specified.
Common failure: execution that doesn't match approval, most often because the available provisioning method only supports a broader grant than what was actually approved, silently over-delivering access relative to the decision that was made.
Stage 5: Verification
What happens: confirmation that the access actually works and matches what was approved, closing the loop rather than assuming the provisioning step succeeded.
Who owns it: ideally a brief check by the requester or their manager, confirming the access is functional and correct, not just that a workflow reported success.
Common failure: this stage is skipped almost universally. Most provisioning processes end at execution, with no verification step at all, which means the first time anyone actually confirms access is correct is when the requester notices something's wrong, or doesn't notice at all if the error is that they received more access than intended.
Stage 6: Review
What happens: at a later point, independent of the original request, the access is periodically reassessed: is it still needed, does it still match the person's current role, has anything about the original grant become inappropriate.
Who owns it: a designated reviewer, often the app owner or a security/compliance function, operating on a scheduled cadence rather than triggered by the original request.
Common failure: review that happens rarely or not at all, meaning Stage 4's grant becomes permanent by default, regardless of whether it's still appropriate months or years later. This is the stage most often missing entirely from a documented process, even at organizations with reasonably mature request-and-approval flows.
Why Mapping This Matters More Than It Seems
Ownership ambiguity is where failures live. When every stage is informally attributed to "IT," accountability for any specific failure, a stalled approval, a mismatched grant, a review that never happened, has nowhere to land. Explicit stage ownership means a specific person or function is answerable for a specific kind of failure, which is what actually drives fixes rather than diffuse frustration.
Stages 5 and 6 are the ones organizations most often skip entirely. Most provisioning process documentation, when it exists at all, stops at Stage 4. Verification and review are treated as optional add-ons rather than integral stages, which is precisely backwards: they're the stages that catch errors from every stage before them.
The flow is the same one that has to run in reverse for offboarding. Every stage described here has a mirror image at deprovisioning: initiation (a departure event), validation (confirming what needs to be revoked), execution, and verification that revocation actually happened. Organizations that map and govern the provisioning flow well are usually the same ones whose offboarding process holds up, because it's built on the same stage-by-stage discipline.
How Zluri Supports the Full Flow
Zluri is an identity security platform for autonomous enterprises, built as four products on one platform: Identity Visibility & Intelligence (IVIP), Identity Governance & Administration (IGA) with its four modules (Access Management, Access Requests, Access Reviews, and SoD), Identity Security Posture Management (ISPM), and SaaS Management (SMP).
Each stage of this flow maps to a specific part of the platform rather than depending on informal ownership. Initiation runs through the Access Requests module's defined intake, replacing informal, invisible requests with a governed channel. Validation checks requests against IGA's policy engine automatically. Approval routes through defined chains scaled to request sensitivity. Provisioning executes through IVIP-backed connectors at the specificity the approval called for. Verification and review, the two most commonly skipped stages, are where the platform adds the most structural value: ISPM continuously monitors granted access for drift or mismatch from what was approved, and the Access Reviews module runs Stage 6 on a defined schedule automatically, rather than depending on someone remembering to initiate a periodic check.
Six Stages, Not One Task
Treating provisioning as a single, IT-owned task is why it fails in the specific, predictable ways it does: informal requests that never enter a governed process, validation skipped for "obvious" cases, approval bottlenecks, execution that quietly over-delivers, and verification and review that almost never happen at all. Mapping the actual flow, with a named owner at each stage, is what turns a vague responsibility into six specific, answerable ones.
Frequently Asked Questions
What are the stages of a user provisioning process flow?
Six: initiation (the access need is identified), validation (checked against policy), approval (a designated approver signs off, scaled to risk), provisioning (technical execution), verification (confirming the grant matches what was approved), and review (periodic reassessment of whether the access is still appropriate).
Who should own each stage of user provisioning?
Initiation belongs to HR (for lifecycle events) or the requester and their manager (for ad hoc requests). Validation is typically automated against policy, with escalation for edge cases. Approval belongs to whoever policy designates for that request type, manager, app owner, or security, scaled to sensitivity. Provisioning belongs to IT or automation. Verification belongs to the requester or manager. Review belongs to a designated reviewer operating on a schedule.
Which stage of the provisioning process is most often skipped?
Verification and review. Most documented provisioning processes end at the execution stage, assuming a successful workflow trigger means the grant is correct and will remain appropriate indefinitely. Neither assumption reliably holds, which is why these two stages, though most often missing, tend to matter most for catching errors and preventing long-term access drift.
Why does treating provisioning as "an IT task" cause problems?
Because it obscures where accountability sits at each of the six actual stages. When something goes wrong, a stalled approval, a mismatched grant, a review that never happened, there's no specific owner to hold responsible if every stage is generically attributed to IT, which makes the underlying process weakness hard to identify and fix.
How does the provisioning process flow relate to offboarding?
They mirror each other. Offboarding runs the same stage structure in reverse: an initiation event (departure), validation of what needs to be revoked, execution, and verification that revocation actually happened. Organizations with a well-mapped, stage-owned provisioning process tend to have correspondingly reliable offboarding, since both depend on the same underlying discipline.
.svg)
