Access Review and Audit: How to Run a User Access Certification

User access reviews — also called access certifications — are one of the most universally required security controls. SOC 2 auditors sample them, ISO 27001 demands them, and every security questionnaire asks about them. The principle is simple: periodically confirm that every person who has access to your systems still needs that access, and that their access level matches their current role. In practice, many organizations run access reviews as a compliance checkbox exercise rather than a meaningful security control.

This guide covers how to run access reviews that actually reduce risk — including the provisioning and deprovisioning processes that reviews depend on, privileged access management, and automation that makes the program sustainable.

The Access Review Lifecycle

Access management is a lifecycle, not just a periodic event. Access reviews are the control that catches errors and drift in the processes that should have prevented them in the first place.

Provisioning: Granting access when someone joins the organization or changes roles Ongoing management: Adjusting access as roles evolve Access review: Periodic confirmation that existing access is still appropriate Deprovisioning: Removing access when someone leaves or changes roles

Weak provisioning and deprovisioning processes guarantee that access reviews will always find exceptions. Strengthen the full lifecycle, not just the review step.

Provisioning: Starting with Least Privilege

Every access grant should start from zero and build up only what is needed, not start from full access and remove what is not needed. This is the least privilege principle, and it requires discipline to enforce.

Role-based access control (RBAC): Define job-function roles with corresponding access profiles before assigning access to individuals. When a new engineer joins, they get the "software engineer" role, which grants access to the code repository, CI/CD system, development environment, and the monitoring dashboard — and nothing else by default.

Document your role catalog:

roles:
  software_engineer:
    systems:
      - github: write (assigned repos only)
      - jira: write
      - datadog: read
      - staging_environment: ssh
      - production_environment: no access
    review_frequency: quarterly

  senior_engineer:
    inherits: software_engineer
    additional_access:
      - production_environment: read-only
      - aws_console: read-only (restricted policy)

  engineering_manager:
    inherits: senior_engineer
    additional_access:
      - production_environment: read-write
      - aws_console: power_user (with approval workflow)

Access request process: All access beyond the default role profile should require a formal request with a business justification, approved by the employee's manager. Capture this in a ticket. The ticket becomes your evidence of authorization for auditors.

Temporary access: Some access should be explicitly time-limited. A contractor on a 90-day engagement should have an access expiry date set at provisioning. Use your identity provider's built-in access expiry features or set a calendar reminder to revoke.

Deprovisioning: The Most Critical Control

Studies consistently show that former employees with active accounts are one of the most common sources of insider threat incidents. Timely deprovisioning is not optional.

Day 0 termination checklist:

1. Disable the account in your identity provider (Okta, Azure AD, Google Workspace) — this cascades to SSO-connected applications
2. Revoke all active sessions (force sign-out of all devices)
3. Revoke personal API tokens and OAuth grants
4. Transfer data ownership (files, email, calendar) to manager
5. Disable company-issued device (MDM remote lock or wipe if applicable)
6. Revoke hardware keys (YubiKey, access cards)

For systems not connected to your SSO, maintain a separate inventory and revoke manually. This is often where gaps exist — an old AWS IAM user created before you had SSO, or a legacy database account.

Automate as much of this as possible. An HRIS-to-identity provider integration (e.g., BambooHR to Okta SCIM provisioning) can disable accounts automatically when termination is recorded in the HR system, eliminating the window between an employee's last day and IT processing the offboarding ticket.

Evidence: For every offboarding, generate a ticket that records the date, the systems where access was revoked, and who performed each step. This is your evidence for SOC 2 (CC6.2) and ISO 27001.

Designing the Quarterly Access Review

For systems with highly sensitive data (production databases, identity providers, billing systems, security tooling), quarterly reviews are appropriate. Annual reviews may suffice for lower-risk systems.

Step 1: Generate the Access Report

Pull a report of all users and their current access levels for each system in scope. Most identity providers can export this as a CSV or connect to a GRC platform. For systems not in your identity provider, export from the system directly.

A clean access report includes:

• User identifier (name, email, employee ID)
• Job title and department
• Access level and specific permissions
• Date access was last modified
• Whether the account has been active in the past 90 days (inactivity is a flag)

Step 2: Assign Reviewers

Each access record should be reviewed by the appropriate manager — typically the employee's direct manager or the data owner of the system. Do not have the system admin review their own access list, and do not have users certify their own access.

Step 3: The Review Decision

For each user-access combination, the reviewer makes one of three decisions:

• Certify: The access is appropriate and should remain
• Modify: The access level should be changed (e.g., downgraded from write to read)
• Revoke: The access should be removed

Reviewers should actively make a decision — not approving by default if no action is taken. Require explicit sign-off rather than treating silence as approval.

Step 4: Implement Changes

All Modify and Revoke decisions must be actioned promptly — within 5 business days of the review completion. The person actioning the changes should record the ticket number in the access review log as evidence of follow-through.

Step 5: Document and Archive

Retain the completed review record, including who reviewed each item, when, what decision was made, and what actions were taken. Auditors ask for this evidence. For SOC 2, expect auditors to select a sample of the reviews from your observation period and verify that the actions were completed.

Privileged Access Management (PAM)

Privileged accounts — those with administrative access to operating systems, databases, cloud consoles, or identity providers — warrant additional controls beyond standard access reviews.

Just-in-time (JIT) access: Rather than granting standing privileged access that exists 24/7, JIT access grants elevated permissions on demand for a specific duration (typically 1–4 hours) with automatic expiration. The engineer requests access through a PAM tool (CyberArk, BeyondTrust, HashiCorp Boundary), the request is approved, elevated access is granted, and it expires automatically.

This dramatically reduces the blast radius if a privileged account is compromised — the attacker only has the window of the active session rather than persistent access.

Session recording: For the most sensitive privileged access (production database access, root shell access), record the session so there is an audit trail of every command executed. This is required under PCI DSS and expected by many enterprise customers.

Shared account elimination: Eliminate shared administrative credentials (a single "admin" account used by the whole ops team). Every administrator should have a personal named account, so actions can be attributed to individuals.

Privileged access review frequency: Review privileged access monthly, not quarterly. The access list for production system administrators should be small and reviewed frequently.

Automation: Making Reviews Scale

Manual access reviews become unmanageable as the organization grows. Automation does not eliminate the need for human review decisions, but it drastically reduces the operational burden.

IGA platforms (Identity Governance and Administration): Tools like Saviynt, SailPoint, or Microsoft Identity Governance automate the collection of access data across connected systems, route reviews to the right approvers, track completion, and generate audit reports. They also enforce segregation of duties rules — for example, flagging if the same person both initiates and approves payments.

SCIM provisioning: Many SaaS applications support SCIM (System for Cross-domain Identity Management), which allows your identity provider to automatically provision and deprovision accounts and sync role changes without manual admin action.

Access recertification reminders: If using a GRC platform or even a simple workflow tool, configure automated reminders to reviewers who have not completed their review by the deadline. Escalate to managers for overdue items.

Inactive account detection: Automate a monthly report of accounts that have not authenticated in 90 days. These are candidates for disablement (after confirmation that the account is no longer needed).

Access reviews that take weeks to complete because of manual processes will be completed poorly — reviewers rubber-stamp everything to get through the volume. Automation that makes the process faster makes the decisions better.