Provision Users and Map IdP Groups to Roles Automatically
Access drifts the moment the hand-off goes manual
In a large organization, access is granted in one place and used in another. HR or your directory creates and removes people; the application has to keep up. When that hand-off is manual, deprovisioning slips — a leaver keeps an active account, a mover keeps the rights from their last role, and least privilege quietly erodes.
The gap is hardest to defend at audit. An assessor testing ISO 27001:2022 Annex A 5.18 or SOC 2 CC6.3 asks you to cross-reference recent leavers against active accounts. If your directory and your application have drifted apart, you cannot evidence that access was revoked when it should have been.
A spreadsheet of "who has what" goes stale the day it is exported. The obligation is not to hold a list — it is to show that access matches authorization, continuously.
What you can do with SCIM2 provisioning
- Provision and deprovision users automatically over the SCIM2 protocol as your IdP changes.
- Map each external IdP group to an internal role, so corporate group membership drives application access.
- Sync Azure AD / Entra ID groups directly from your SAML or OAuth assertions into DPMS.
- Soft-delete groups removed during sync with a deleted flag, keeping a reversible record instead of a hard wipe.
- Sync permissions to mapped users when a mapping changes, so a role change propagates without re-keying.
- Track sync state on IAM settings — last sync, accounts synced, groups synced — at a glance.
What it delivers to your program
- Leavers lose access on the next sync, not on the next access review — closing the deprovisioning gap assessors test first.
- Least privilege holds as people move, because role assignment follows IdP group membership instead of manual edits.
- Provisioning scales with headcount, not admin hours — no onboarding ticket per user.
- Access evidence is ready on demand, with mappings persisted as records and sync counts visible to operations.
- One source of truth for access — your IdP — removes the drift you would otherwise reconcile by hand.
Built for compliance
DPMS provisioning helps you evidence the access-control obligations auditors test — mapped to the specific control they cite, never to "ISO certified."
| What DPMS does | Maps to | How |
|---|---|---|
| Provisions and deprovisions identities over a standard protocol | SCIM2 (RFC 7644) | SCIM2 user and group lifecycle, reconciled with the IAM SCIM enable flag |
| Manages identities across their full lifecycle | ISO 27001:2022 Annex A 5.16 | IdP-driven provisioning with sync state surfaced on IAM |
| Grants, modifies, and revokes access rights centrally | ISO 27001:2022 Annex A 5.18 | Group-to-role mappings persisted as records; permission sync on change |
| Restricts access to least privilege by role | ISO 27001:2022 Annex A 5.15 | External-group-to-internal-role mapping |
| Authorizes, modifies, and removes logical access | SOC 2 CC6.2 / CC6.3 | Automated provisioning plus soft-delete on group removal |
Why Priverion
Unlike general-purpose GRC tools that treat identity as someone else's problem, DPMS ties access to the same platform that holds your ROPA, DPIA, risk, and vendor records — the identities provisioned are the identities accountable for the work, with no separate reconciliation. Group-to-role mappings are stored as first-class records with audit-friendly soft deletes, and sync state — last sync, accounts synced, groups synced — surfaces on your IAM settings for operational visibility.
Questions CISOs ask before a demo
Does this work with Azure AD / Entra ID?
Does it replace my identity provider?
What happens when a group is removed during a sync?
How do role changes reach users?
Explore related capabilities
Ready to close the deprovisioning gap?
