User Access Control Checklist
Access Request and Approval
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.
For systems holding regulated data (PII, PHI, cardholder data) or production cloud accounts, the resource owner — typically the data steward or service owner — approves separately from the people-manager. This is the SOC 2 CC6.1 control point.
Identity Verification and Provisioning
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.
Privileged users get a YubiKey or Titan key for break-glass and console access — platform authenticators alone are not sufficient when the laptop itself is the privileged-access endpoint. Register both a primary and backup key; lost-key recovery without a backup is a multi-day support burden.
Role Assignment and Privileges
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.
Privileged accounts (domain admin, root, AWS break-glass) live in HashiCorp Vault, CyberArk, BeyondTrust, or 1Password Secrets — checked out per session, rotated on check-in. Standing local credentials on the user's laptop fail the SOC 2 CC6.6 control.
Monitoring and Audit Trail
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.
Send the access-granted notice with links to the acceptable-use policy, the data classification standard, and the incident-reporting channel. For privileged users, include the privileged-user agreement requiring acknowledgement before first use.
Periodic Review and Recertification
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.
Revocations and privilege reductions get executed within 7 days of the review closing — longer windows are an open finding. Confirm SCIM deprovisioning fired across all connected SaaS, and manually clean up apps that don't auto-deprovision.
Use this template in Manifestly
- Cloud Outage Response
- Vulnerability Intake Checklist
- Network Maintenance Checklist
- Disaster Recovery Checklist
- Server Maintenance Checklist
- Data Backup Verification Checklist
- Software Installation Checklist
- Onboarding a New Software Developer
- Patch Management Checklist
- Server Configuration Checklist
- Software Update Checklist
- Performance Monitoring Checklist
- Incident Response Checklist
- Quarterly Security Review Checklist
- Monthly Server Maintenance Checklist
- Monthly Server Maintenance Checklist
- Desktop Configuration Checklist
Ready to take control of your recurring tasks?
Start Free 14-Day TrialUse Slack? Sign up with one click
