Category: User Provisioning

Provisioning Policy

Also known as: Provisioning and Deprovisioning Policy

Simply put

A provisioning policy is a set of rules that governs how access to systems, applications, or resources is granted, changed, or removed for users and other entities. It defines the conditions under which access is issued and the details that must be supplied when an account or resource is created. In practice, the exact meaning depends on the vendor or platform, since the term is used somewhat differently across products and organizations.

Formal definition

A provisioning policy is an administrative construct within identity governance and administration (IGA) that defines the rules, required attributes, and conditions governing the issuance, modification, and revocation of access to IT resources. Its precise form is vendor- and context-dependent: in SailPoint IdentityIQ, for example, a provisioning policy is defined as a collection of fields configured through a form editor, where each field carries settings that determine what values are supplied during account or resource provisioning. In organizational governance contexts, a provisioning (and deprovisioning) policy instead documents the standards for access issuance, modification, and revocation for affiliated entities. The term also appears in adjacent operational contexts such as Windows 365, where provisioning policies build and configure Cloud PC resources rather than govern identity lifecycle access; readers should confirm scope against the specific platform. As an IGA lifecycle-administration concept, a provisioning policy concerns how access is established and removed and is distinct from runtime access enforcement components such as PDPs, PEPs, and token validation.

Why it matters

Provisioning policies sit at the heart of the access lifecycle: they determine how quickly and correctly a user obtains the access they need and, just as importantly, how reliably that access is removed when it is no longer warranted. When provisioning rules are inconsistent or manually applied, organizations accumulate over-entitled accounts, orphaned accounts from departed staff, and access that drifts away from documented standards. These conditions expand the attack surface and complicate access certifications, because reviewers cannot easily reconcile what access exists against what policy intended.

Because the term is used differently across products and organizations, the stakes depend on context. In an IGA platform such as SailPoint IdentityIQ, a provisioning policy governs the fields and values supplied when accounts and resources are created, directly shaping data quality and consistency at the moment access is issued. In an organizational governance document, such as a university's provisioning and deprovisioning policy, it defines the standards for access issuance, modification, and revocation for affiliated entities, establishing accountability rather than executing technical steps. Confusing these two senses can lead teams to assume enforcement exists where only documentation does, or vice versa.

Provisioning policy also intersects with the timely revocation of access, which is a recurring concern in audits and compliance frameworks. A weak or unenforced deprovisioning process leaves credentials active beyond their legitimate lifespan, which is one of the more common findings in access reviews. Getting provisioning policy right supports both operational efficiency and the segregation-of-duties and least-privilege objectives that governance programs are expected to uphold.

Who it's relevant to

Identity Governance Leads

Governance leads define and maintain provisioning (and deprovisioning) policies as the documented standards for how access is issued, modified, and revoked across affiliated entities. They are responsible for ensuring these standards align with least-privilege and segregation-of-duties objectives and that policy intent is testable during access certifications.

IAM Engineers

Engineers translate provisioning policy into platform configuration, for example, defining the collection of fields and their settings in a tool such as SailPoint IdentityIQ so that correct values are supplied when accounts and resources are created. They must confirm the exact scope of the term in each product, since a provisioning policy in Windows 365 configures Cloud PC resources rather than identity lifecycle access.

Compliance and Audit Officers

Compliance officers rely on provisioning policies to demonstrate that access issuance, modification, and revocation follow documented standards. They are particularly attentive to timely deprovisioning, since access that persists beyond its legitimate need is a frequent audit concern.

System Administrators

Administrators operate provisioning workflows day to day and depend on clear policy to know what details must be supplied at account creation and under what conditions access is granted or removed. Because behavior varies by vendor and configuration, they should validate how a given platform interprets and enforces the policy rather than assuming uniform behavior.

Inside Provisioning Policy

Scope and Target Systems

Defines which downstream applications, directories, and resources the policy governs. In most deployments this includes the connected systems (for example LDAP directories, SaaS applications provisioned via SCIM, or custom connectors) that receive account creation, update, and deactivation actions.

Trigger Conditions and Rules

Specifies the events or attribute conditions that cause provisioning actions to occur, such as a joiner event, a role assignment, or a change to an identity attribute. These rules typically map source-of-truth changes to concrete provisioning operations.

Entitlement and Access Assignment Logic

Determines what access is granted upon provisioning. Depending on configuration this may be driven by an access control model such as RBAC (role-based) or ABAC (attribute-based), and it is an IGA administration concern rather than a runtime enforcement decision made by a PDP/PEP.

Lifecycle Stage Handling

Covers behavior across the identity lifecycle, joiner, mover, and leaver events, including account creation, attribute updates, entitlement changes on role transfer, and deprovisioning or deactivation on departure.

Attribute Mapping and Transformation

Defines how source identity attributes are mapped and transformed into target system attributes, for example populating directory attributes or SCIM resource fields during account creation and update operations.

Segregation of Duties (SoD) and Governance Controls

Incorporates governance constraints such as SoD checks and approval requirements that can gate provisioning actions. These are IGA controls applied at assignment time and are distinct from runtime access enforcement.

Exception and Approval Workflows

Describes when human approval or exception handling is required before a provisioning action completes, typically for sensitive entitlements or out-of-policy requests.

Common questions

Answers to the questions practitioners most commonly ask about Provisioning Policy.

Is a provisioning policy the same as a runtime access control policy enforced by a PDP?

No. A provisioning policy is an identity governance and administration (IGA) construct that governs how accounts and entitlements are created, updated, and removed across target systems during the identity lifecycle. It operates ahead of and separately from runtime enforcement. A PDP (policy decision point) evaluates access requests in real time at the moment a principal attempts an action; the provisioning policy instead determines what entitlements a principal is granted in the first place. Conflating the two blurs lifecycle management with real-time enforcement. In most deployments the entitlements a provisioning policy assigns become inputs that runtime enforcement later evaluates, but the policy itself does not make per-request access decisions.

Does a provisioning policy decide who a user is or authenticate them?

No. A provisioning policy addresses neither authentication (verifying who a principal is) nor per-request authorization. It concerns the administrative act of granting, modifying, or revoking accounts and entitlements based on attributes, roles, or other governance criteria. Authentication happens at access time through separate mechanisms and credentials. A provisioning policy may rely on identity attributes as inputs to decide what to provision, but establishing or verifying identity at login is out of scope for the policy itself.

How does a provisioning policy typically relate to access models like RBAC or ABAC?

A provisioning policy is often expressed using the access model an organization has adopted for governance. In an RBAC-oriented deployment, the policy may map roles to sets of entitlements and assign accounts based on role membership. In an ABAC-oriented deployment, it may drive provisioning decisions from attributes such as department, location, or job code. Some organizations combine models. The policy defines the criteria and resulting grants; it does not make one model inherently superior, and the appropriate choice depends on the environment and governance requirements.

What role does SCIM play in enforcing a provisioning policy?

SCIM is a standard commonly used to carry out the provisioning actions a policy specifies, propagating account creation, updates, and deprovisioning to target systems that support it. The provisioning policy decides what should be provisioned and to whom; SCIM is one mechanism, depending on configuration, for how those changes are communicated to downstream applications. Systems without SCIM support are typically integrated through connectors, APIs, or other methods, so SCIM is not required for a provisioning policy to function.

How should a provisioning policy handle deprovisioning and joiner-mover-leaver events?

A provisioning policy typically defines behavior across the full identity lifecycle, including how entitlements are added when a user joins, adjusted when they change roles, and removed when they leave. Depending on configuration, mover events may require revoking prior entitlements to avoid accumulation, and leaver events should trigger timely deprovisioning. Precise handling of these transitions is central to reducing orphaned accounts and excess access, though the exact timing and automation depend on the deployment and connected systems.

How does a provisioning policy interact with segregation of duties and access reviews?

A provisioning policy is one of several IGA controls and typically works alongside segregation-of-duties (SoD) checks and periodic access certification. In many deployments, provisioning decisions are evaluated against SoD constraints to prevent granting conflicting entitlements, and grants made by the policy are later subject to access reviews to confirm they remain appropriate. The policy governs initial and ongoing assignment; certification and SoD provide detective and preventive oversight, and how tightly they integrate varies by vendor and configuration.

Common misconceptions

A provisioning policy enforces access decisions at runtime.

Provisioning policy is an identity governance and administration (IGA) concern that governs account creation, updates, and deprovisioning. It is separate from runtime access enforcement performed by components such as a PDP, PEP, or PIP and from token validation. Granting an account or entitlement is not the same as authorizing a specific request in real time.

SCIM and provisioning policy are the same thing.

SCIM is a protocol commonly used to carry provisioning operations to target systems, while a provisioning policy is the set of rules that decides when and how those operations occur. In most deployments SCIM is one possible transport or connector, not a substitute for the policy logic itself.

Deprovisioning is automatic and immediate once a provisioning policy exists.

Deprovisioning behavior depends on trigger conditions, connector capabilities, and configuration. Depending on the deployment, leaver actions may be delayed, may require approval, or may only disable rather than delete accounts, so timeliness should not be assumed.

Best practices

Keep provisioning (an IGA administration function) explicitly separate from runtime enforcement, and document which access decisions are made at assignment time versus enforced later by a PDP/PEP.

Define clear trigger conditions for joiner, mover, and leaver events so that account creation, entitlement changes on role transfer, and deprovisioning are handled consistently across target systems.

Integrate segregation of duties checks and approval workflows into the policy so that sensitive entitlement assignments are gated before provisioning completes.

Map the chosen access model (for example RBAC or ABAC, depending on your environment) explicitly to entitlement assignment logic rather than mixing models implicitly.

Validate attribute mappings and transformations against each target system's schema (for example directory attributes or SCIM resource fields) to avoid inconsistent or failed provisioning.

Pair provisioning policy with periodic access reviews and certification so that assignments granted over time remain aligned with current need.