User access reviews that satisfy every auditor
Access reviews are one of the most frequently failed controls in audits, rarely because nobody did them and usually because nobody can prove they were done properly.
This post covers the 11 frameworks ControlMapping mapped when it was written. Since then, DORA, CPS 234, Cyber Essentials were added on 2026-10-27; their pages and the coverage matrix include them.
Few controls are as universal or as frequently failed as user access reviews. Every framework expects someone to check, periodically, that each person still needs the access they have. Most organisations do the review. Far fewer can show an auditor that it was complete, independent and acted on.
What the frameworks require
| Framework | Access Control | Link |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01PR.AA-05 | Topic definition |
| ISO 27001 | A.5.15A.5.16A.5.18A.8.3 | Crosswalk |
| CIS v8.1 | CIS 5.1CIS 6.1CIS 6.2CIS 6.7CIS 6.8CIS 3.3CIS 5.2CIS 5.3CIS 5.5CIS 5.6CIS 6.6CIS 12.5 | Crosswalk |
| SOC 2 | CC6.1CC6.2CC6.3 | Editorial |
| PCI DSS | 7.2.17.2.27.2.48.2.1 | Crosswalk |
| CMMC | AC.L2-3.1.1AC.L2-3.1.2 | Crosswalk |
| 800-53 | AC-2AC-3 | Crosswalk |
| HIPAA | §164.308(a)(4)§164.312(a)§164.312(a)(2)(i)§164.312(d) | Crosswalk |
| GDPR | Art.25(2)Art.32(1)(b) | Editorial |
| NIS2 | 11.111.211.5 | Crosswalk |
| Essential Eight | — | No mapping in our data |
Full detail and the reason for every link: Access Control across frameworks →
PCI DSS is the only one with a fixed frequency: all user accounts and privileges reviewed at least every six months (7.2.4), and application and system accounts too (7.2.5.1). SOC 2 auditors test that access is authorised, modified and removed appropriately (CC6.2, CC6.3), and look for periodic reviews as evidence. ISO 27001 requires access rights to be reviewed at regular intervals (A.5.18). HIPAA requires information access management and review of activity (§164.308(a)(4)). CMMC expects access limited to authorised users and functions (AC.L2-3.1.1, 3.1.2) and least privilege.
A review that passes
- Complete population. Pull the user list directly from the system (an export, not a spreadsheet someone maintains), including service and shared accounts.
- Right reviewer. The system or data owner, or each user's manager, not the administrator who granted the access.
- Enough context. Show reviewers each user's role and access level, so "approve" is an informed decision.
- A decision per account. Keep, change or remove, with the reviewer's name and date.
- Changes actually made. Raise tickets for removals and keep proof they were completed.
- Evidence kept. The export, the decisions, the tickets and sign-off, stored together.
Frequency
Use PCI DSS's six months as the baseline for all in-scope systems, and review privileged access quarterly. If you hold a SOC 2 Type II, make sure at least one review (ideally two) falls in each observation period.
What auditors find
- Rubber-stamping: every account approved, in minutes, by someone who couldn't know.
- Incomplete populations: the review covered the application but not the database, or human accounts but not service accounts.
- Self-review: administrators approving their own access.
- Removals not completed: the review said remove; the account still exists months later.
- Leavers caught by the review: a sign your offboarding process is failing, which auditors will test separately.
Key takeaways
- Reviews fail audits on evidence, not effort: incomplete populations, self-review and removals never completed.
- Use a system export, the right reviewer, a decision per account and proof of changes.
- Six-monthly reviews (PCI DSS's rule) and quarterly for privileged access satisfy every framework.
- Keep the scope to systems that matter, and automate the mechanics.
Making it sustainable
Automate the export and the reminders, review by system rather than by user, and keep the scope to systems that matter: production, customer data, privileged tools and anything in a framework's scope. A smaller, well-evidenced review beats a sprawling one that's always late.
See the Access Control and Privileged Access topic pages for every requirement with its source, and our post on reusing evidence across SOC 2, ISO 27001 and PCI DSS.
Questions
How often must user access be reviewed?
PCI DSS requires user accounts and access privileges to be reviewed at least every six months (7.2.4). Most other frameworks require periodic review at a frequency you define; quarterly for privileged access and every six months for others is a common baseline.
Who should perform an access review?
The owner of the system or data, or the user's manager, not the administrator who granted the access. Auditors look for independence and an informed reviewer.
Do service accounts need access reviews?
Yes. Auditors increasingly include service, shared and API accounts in the review population; PCI DSS explicitly requires periodic review of application and system accounts (7.2.5.1).
Data as of 2026-10-27: numbers in this post are computed from the current crosswalk and update when it changes. Crosswalk a published crosswalk (NIST, ENISA, CIS, PCI SSC) makes the link · Editorial ControlMapping's judgement where no crosswalk exists; the reason is shown · only shares a CSF 2.0 outcome: worth checking, not a mapping · No mapping in our data nothing mapped in our data; often new work, but check the coverage notes. Not compliance advice.
Related posts
Analysis · 2026-10-27APRA CPS 234 and ISO 27001: what your ISMS covers and what APRA addsAn ISO 27001 ISMS covers nearly every paragraph of APRA's CPS 234, yet APRA adds Board duties, third-party assurance and strict notification deadlines.
Analysis · 2026-10-13MFA requirements compared across 11 security frameworksWhich frameworks require MFA, for whom and how strictly: PCI DSS, CMMC, NIS2, Essential Eight, ISO 27001, SOC 2 and HIPAA compared side by side.
Analysis · 2026-09-29HIPAA Security Rule through the NIST CSF 2.0 lensA NIST CSF 2.0 programme maps to almost every HIPAA Security Rule requirement. What carries over, the two that don't, and what CSF adds beyond HIPAA.