---
title: "How to run a user access review"
canonical: https://harmony.io/insights/user-access-review
---

# How to run a user access review

_Ran Ribenzaft · 2026-10-18_

_Data verified October 2026 · Reviewed by Ran Ribenzaft, Co-Founder & CTO._

**Categories:** SSO / Identity, SaaS Application

A user access review checks that everyone's access to your applications is still appropriate. Seven steps from scoping to evidence, how often SOC 2, ISO 27001, PCI DSS, HIPAA and CIS expect it, and how to stop it taking a quarter.

A user access review (also called an access certification or SaaS access audit) is a periodic check that every person's access to your systems is still appropriate for their job. To run one: choose the applications in scope, export who has access to each, send each person's access to the right reviewer (usually their manager, or the application owner), have reviewers keep or revoke each entitlement by a deadline, remove what was revoked, and keep the decisions and the removals as evidence. Review privileged and sensitive applications at least quarterly and everything else at least twice a year; PCI DSS requires a review at least once every six months, and CIS Controls asks for active accounts to be validated at least quarterly.

## Why access reviews matter

Access accumulates. People change teams and keep their old permissions, contractors finish and stay in groups, admin rights granted for a project are never taken back, and apps outside single sign-on keep accounts nobody remembers. Each one is a way in for an attacker and a finding for an auditor. A review is the control that catches what provisioning and offboarding missed.

## What the frameworks ask for

| Framework | Requirement | Frequency |
| --- | --- | --- |
| SOC 2 (Trust Services Criteria) | CC6.2 and CC6.3: authorize, modify and remove access based on roles and least privilege, and remove credentials that are no longer valid | Not fixed; auditors expect a defined, followed cadence |
| ISO/IEC 27001:2022 | Annex A 5.18 Access rights: provision, review, modify and remove access in line with your access control policy | Not fixed; set in your policy |
| PCI DSS v4.0 | Requirement 7.2.4: review all user accounts and access privileges, including third-party accounts, address inappropriate access, and have management acknowledge the result | At least once every six months |
| HIPAA Security Rule | 164.308(a)(4): policies to establish, document, review and modify a user's right of access | Not fixed |
| NIST SP 800-53 | AC-2(j) review accounts; AC-6(7) review user privileges and remove those no longer needed | Organization-defined |
| CIS Controls v8 | Safeguard 5.1: validate that all active accounts are authorized; 5.3: disable dormant accounts after 45 days of inactivity | At least quarterly |

Where a framework leaves the frequency to you, the auditor checks that you chose one, wrote it down and kept to it.

## How to run a user access review in 7 steps

### 1. Define the scope

List the applications that hold sensitive data or support critical processes: the identity provider and its admin roles, cloud infrastructure, code repositories, finance and HR systems, CRM, and anything in scope for your audit. Start narrow and widen each cycle. Decide whether you are reviewing user accounts, privileged roles, or both; privileged access deserves a tighter cadence.

### 2. Export the access data

For each application, pull every account and its role or group. Use the identity provider for SSO-connected apps (Okta, Entra ID, Google Workspace) and export directly from each app for the rest. Include service accounts and third-party accounts, which PCI DSS calls out explicitly. Join each account to the HRIS record so you can see department, manager, employment status and title.

### 3. Clean the obvious first

Before anyone reviews anything, remove what needs no judgement: accounts belonging to people who have left, accounts with no sign-in in 45 days or more, and duplicates. Reviewers who see a short, accurate list make better decisions than reviewers handed a raw export.

### 4. Assign reviewers

Two models work: managers review their direct reports' access across applications, or application owners review everyone with access to their app. Managers know the person; owners know the permissions. Many teams use managers for standard access and owners for admin roles. Nobody should review their own access.

### 5. Collect decisions by a deadline

Send each reviewer their list with a clear choice per entitlement: keep or revoke. Give a deadline, send reminders, and escalate non-responses. Ask for a reason when someone keeps admin access. Avoid "approve all" without looking; a review where every line is approved in seconds is a finding waiting to happen.

### 6. Remove what was revoked

The review is not done when the decisions are in. Revocations need to be carried out, in the identity provider for SSO apps and in each application for the rest, and confirmed. Track each removal as a task with an owner.

### 7. Keep the evidence

Store the scope, the access snapshot, each reviewer's decisions with timestamps, the removals and their confirmation, and management's sign-off. That package is what SOC 2, ISO 27001 and PCI DSS auditors ask for.

## How often to review access

| Access type | Suggested cadence | Why |
| --- | --- | --- |
| Privileged and admin roles | Quarterly | Highest impact if misused; CIS asks for quarterly account validation |
| Sensitive and in-scope applications | Quarterly to semi-annually | PCI DSS sets six months as the minimum for in-scope systems |
| All other applications | Semi-annually or annually | Lower risk; driven by your policy |
| Triggered reviews | On role change and departure | Catches access when it changes, not months later |

## Common mistakes

- **Reviewing a spreadsheet nobody can verify.** If reviewers cannot see what a role grants, they approve it.
- **Forgetting apps outside SSO.** Local accounts in SaaS tools are where leftover access hides.
- **Collecting decisions but not acting on them.** Auditors test that revocations happened.
- **Running it once a year, manually.** A review that takes a quarter to finish is out of date when it ends.

## Automating access reviews

The parts that take time, exporting access, chasing reviewers, collating answers and building the evidence, are the parts that automate well. Harmony's [Software Compliance Report](https://harmony.io/agents/software-compliance-report) runs application access reviews on a recurring schedule: it scopes the employees in review using filters such as classification, status and location, pulls their current application access, asks each manager in Slack, Teams or email to keep or reject their direct reports' access, sends reminders against a deadline, and creates a ticket with a CSV report of every decision for IT and compliance. Revocations then run through Harmony's governed workflows, such as [group membership management](https://harmony.io/agents/group-membership-management) and [GitHub access management](https://harmony.io/agents/github-access-management), and [Inactive Employees](https://harmony.io/agents/inactive-employees) flags dormant accounts between reviews.

Access review is the check; the controls around it are [governed access requests](https://harmony.io/insights/automate-access-requests), [revoking access when people leave](https://harmony.io/insights/revoke-access-when-employee-leaves) and [finding shadow IT apps](https://harmony.io/insights/find-shadow-it-apps) that never went through either. For audit trails across the service desk, see [SOC 2 and HIPAA-compliant ITSM](https://harmony.io/insights/soc2-hipaa-compliant-itsm).

This guide is written and maintained by Harmony. Framework details come from the sources listed below and were last checked in October 2026. It is not audit or legal advice; confirm requirements with your auditor.

## Frequently asked questions

### What is a user access review?

A periodic check, usually by managers or application owners, that each person's access to systems and applications is still appropriate for their role, followed by removal of anything that is not and a record of the decisions.

### How often should user access reviews be done?

Quarterly for privileged and sensitive access and at least twice a year for the rest is common practice. PCI DSS requires at least every six months, CIS Controls asks for quarterly account validation, and SOC 2 and ISO 27001 expect the cadence defined in your own policy.

### Does SOC 2 require user access reviews?

SOC 2 does not prescribe a frequency, but criteria CC6.2 and CC6.3 cover authorizing, modifying and removing access based on roles and least privilege, and auditors typically test for periodic access reviews as evidence.

### Who should review user access?

The person's manager for standard access, and the application owner for administrative or sensitive roles. Nobody should review their own access.

### What evidence do auditors want from an access review?

The scope, a snapshot of access at the time, each reviewer's decision with a timestamp, proof that revoked access was removed, and management sign-off.

### Can user access reviews be automated?

Yes. Harmony's Software Compliance Report agent collects application access, asks managers to attest in Slack, Teams or email, chases non-responders and produces an audit-ready report attached to a ticket.

## Sources

1. [Microsoft Entra ID and PCI DSS Requirement 7 (Microsoft Learn), accessed October 18, 2026](https://learn.microsoft.com/en-ca/entra/standards/pci-requirement-7)
2. [ISO/IEC 27001 Control 5.18: Access rights (Evolveum), accessed October 18, 2026](https://docs.evolveum.com/midpoint/compliance/iso27001/5.18/)
3. [SOC 2 CC6.2 (Cloudaware), accessed October 18, 2026](https://ce.prod.cloudaware.com/frameworks/soc-2/cc6/02)
4. [SOC 2 CC6.3 (Cloudaware), accessed October 18, 2026](https://ce.prod.cloudaware.com/frameworks/soc-2/cc6/03/)
5. [NIST SP 800-53 Rev. 5.1 controls (NIST), accessed October 18, 2026](https://csrc.nist.gov/CSRC/media/Projects/risk-management/800-53%20Downloads/800-53r5/SP_800-53_v5_1_XML.xml)
6. [45 CFR 164.308 Administrative safeguards (eCFR), accessed October 18, 2026](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.308)
7. [CIS Control 5: Account Management (Center for Internet Security), accessed October 18, 2026](https://cas.docs.cisecurity.org/en/latest/source/Controls5/)
8. [ISO 27001 Control 5.18 (UpGuard), accessed October 18, 2026](https://www.upguard.com/compliance/iso-27001/5-18)

_Microsoft Entra ID is a trademark of Microsoft Corporation. Okta is a trademark of Okta, Inc. Google Workspace is a trademark of Google LLC. PCI DSS is a trademark of PCI Security Standards Council, LLC. SOC 2 is a trademark of the American Institute of Certified Public Accountants. Harmony is not affiliated with these companies._