User Role Management Checklist

Record who requested the role, which business process it supports, and the named role owner who will sign off on access. A role without a named human owner becomes orphaned within a quarter and shows up in the next access review as a finding.

List every system, share, and SaaS entitlement the role requires. Start from zero and add only what the job function demands — copying an existing similar role is the most common source of permission bloat.

Tier 0 covers domain admins, identity infrastructure, and backup systems. Tier 1 covers server admins and application admins. Tier 2 covers helpdesk and end-user roles. Privileged tiers require PAM enrollment and a separate admin account.

Cross-reference the proposed permissions against your SoD matrix. Common conflicts: AP entry plus payment release, code commit plus prod deploy, user provisioning plus access review approval. SOX and SOC 2 auditors flag these every year.

If the conflict cannot be eliminated, document the compensating control — typically a quarterly transaction review by an independent reviewer or alert-driven exception monitoring — and obtain risk-owner sign-off before proceeding.

Route the role definition to each data owner whose data the permissions touch. Approval comes from the business owner of the data, not from IT — IT operates the system but does not authorize access to the data.

Use the naming convention from your IAM standard — e.g., SG-APP-Salesforce-Admin — so the group's purpose is obvious in audit logs. Set the group as assigned, not dynamic, unless you have a vetted membership rule.

For SCIM-enabled apps (Okta, Entra), assign the group to the application and map the app role. For SAML-only apps, push the group claim and configure the app to consume it. Manual per-app provisioning becomes the source of orphaned access within 12 months.

Apply the appropriate CA policy: MFA required, compliant device required, and for privileged tiers, sign-in from a Privileged Access Workstation only. Verify legacy authentication is blocked — basic-auth bypass of MFA is the single most common identity compromise vector.

Record the group name, owner, tier classification, app entitlements, conditional access scope, and approval ticket. Future access reviews and offboarding workflows will pull from this documentation — if it isn't there, the role gets missed.

Confirm the user's department, manager, and employment status in Workday or BambooHR match the request. Manager approval should come from the user's current manager of record, not whoever filed the ticket.

Add the user via the IdP admin console, not by editing on-prem AD directly when the group is cloud-managed. Note the assignment expiration date if this is a time-bound grant — JIT access without an expiration becomes permanent.

For privileged tiers, the user logs into target systems through the PAM session broker — never with cached domain admin credentials on a daily-driver laptop. Issue the separate admin account, vault the password, and confirm session recording is active.

Send the role description, list of granted permissions, and a link to the acceptable use policy. For privileged roles, require explicit acknowledgment before the access activates — silent grants leave you with no record the user understood what they accepted.

Have the user sign in to one or two representative apps and confirm the entitlements work as expected. Token caching means group changes can take up to an hour to propagate; if access doesn't appear, sign the user out of all sessions in the IdP and retry.

Open the RFC in ServiceNow or your PSA before touching the group. Include the diff (permissions added / removed), the reason, the rollback plan, and the affected user count. Untracked group edits are the leading source of audit findings in ITGC reviews.

Count the users currently in the group, the apps it gates, and any nested-group memberships that will inherit the change. A 'small' edit to Domain Users or a top-level synced group can cascade across hundreds of resources.

Schedule the change for the next CAB. Bring the RFC, the rollback plan, and the named approver from the data owner. Do not push high-impact role changes during a freeze window or right before month-end close.

Apply the change in the IdP and let SCIM propagate to downstream apps. Verify the change in two representative target systems before closing the RFC. Notify affected users of any reduction in access before the change window — reduced access discovered Monday morning generates a flood of tickets.

Generate the entitlement report from the IdP and route per-role attestation packets to each named role owner. SOC 2 CC6.3 and SOX ITGC both expect documented quarterly reviews with reviewer sign-off — the report alone is not enough.

Flag roles with zero members, roles whose owner has left the company, and roles last modified more than 12 months ago against drift in the underlying app. These are the candidates for retirement.

For any role being retired, map current members to the appropriate surviving role and confirm the new role's entitlements cover the user's job function. Get the manager's confirmation before swapping membership.

Disable the group first, leave it in the disabled state for at least 30 days to catch any service or scheduled job that still depends on it, then delete. Document the deletion ticket and update IT Glue. Hard-deleting a group with hidden dependencies breaks production at the worst possible time.

Capture the signed attestation from each role owner and store it with the quarter's audit evidence. Auditors will ask for the signed reviewer attestation, not just the report — missing signatures are a common SOC 2 finding.