User Access Control Checklist

Create the request in the PSA or ITSM tool (Jira Service Management, Freshservice, ConnectWise Manage, ServiceNow). Pick the access category — this drives later branching for hardware keys, PAM enrollment, and contractor expiration. Free-form email requests are not acceptable; the ticket is the audit-trail anchor.

Document the specific systems requested (AWS account, Salesforce role, GitHub org, production database) and the business reason. Vague requests like "give me admin" get rejected — auditors flag missing justification during SOC 2 review.

Manager approval is required even when the requester is the manager — use a peer-manager or director in that case. Approval lives on the ticket, not in email or Slack.

Confirm the requester exists in Workday, BambooHR, or Rippling with an active employment status and the requested start date. Tickets opened before the HR record exists are a common phishing vector — never provision off a manager's word alone.

Create the user in Okta, Entra ID, JumpCloud, or Google Workspace. SCIM-connected SaaS apps will populate downstream — apps without SCIM need manual provisioning at the role-assignment step.

Use FIDO2 / passkey or platform authenticator (Touch ID, Windows Hello). SMS and email codes do not meet the bar — SMS falls to SIM swap; email falls to credential phishing. Document the enrolled factor in the IdP.

Map the role to the documented RBAC group — never grant ad-hoc app access bypassing the IdP group. Direct app assignments break SCIM deprovisioning and create orphan accounts at offboarding.

Apply AWS IAM roles, GitHub team membership, Salesforce profile, database grants. Default to least-privilege — read-only unless write was explicitly justified. Production write access goes through a separate just-in-time elevation, not standing privilege.

Confirm the user does not hold conflicting roles — examples: developer + production deploy approver, AP clerk + payment approver, identity admin + their own access reviewer. SoD violations are a recurring SOC 2 finding.

Contractor accounts get a hard expiration matching the SOW end date — set it in the IdP, not on a calendar reminder. Re-enable requires a fresh access request; quiet auto-renewals are how third parties end up with multi-year standing access.

Confirm IdP sign-in logs and target-system audit logs land in the SIEM (Splunk, Datadog, Sumo Logic, Elastic). Default cloud retention of 30-90 days is below SOC 2 / PCI minimums — verify the cold-tier 13-month retention path is wired up.

Add the new account to alerting for production database access, IAM role assumptions, and admin-console activity outside business hours. Tune alert thresholds; a noisy alert that nobody reads is worse than no alert.

Capture screenshots or exports showing the approval chain, the assigned IdP group, and the SoD check result. Vanta, Drata, and Secureframe can pull most of this automatically — but the human-approval evidence still needs to be attached to the ticket.

Quarterly cadence is the SOC 2 baseline; PCI environments and privileged accounts run monthly. Use the GRC platform's campaign feature (Vanta, Drata, AuditBoard) — manual spreadsheet reviews routinely miss accounts and produce findings.

Resource owners certify each user's continued need. Auto-approve clicks without inspection are the most common audit finding — require a justification field for any privileged-access certification.

Record per-user outcomes: confirmed, modified (privileges reduced), or revoked. Reviewer notes capture the rationale for any retained-but-unusual access — auditors will sample these.