User Access Reviews: What Auditors Actually Test, and Why Most Reviews Fail Them
A user access review is the periodic check that every account’s access is still needed, decided by someone qualified to judge it, with removals carried out and evidenced. It is the control nearly every framework asks for, and one of the controls most often written up. The reason is not that organizations skip it. They run it every quarter, collect the sign-offs, and still get a finding, because the auditor was testing something the review was never designed to prove.
We compared the free templates published by identity governance vendors and compliance platforms. Almost all of them are a sign-off sheet: user, entitlement, reviewer, decision, date. That records a review. It does not evidence one. What follows is the gap between the two, question by question.
Why do performed access reviews still fail audits?
1. The list was never proven complete
The auditor’s first request is rarely about decisions. It is: how do you know the listing you reviewed was complete and accurate?
The user listing is information produced by the entity. Under PCAOB AS 1105.10 the auditor must test its completeness and accuracy, and PCAOB inspection reports have repeatedly faulted engagement teams for relying on access populations they had not tested. Audit firms responded by pushing the burden back to the company. If you cannot show the query, its parameters, when it ran, who ran it and a record count reconciled to the system, the review can be treated as not performed.
Two things make this worse in practice. Extracts are usually taken from the identity provider rather than the application, so local accounts that bypass single sign-on are missing. And extracts are often passed through a spreadsheet owned by an administrator whose own access is on it.
What closes it: an extract log per system, with a row count taken independently in the system, and the extract delivered to reviewers without passing through anyone whose access it lists. The template’s Population sheet does the reconciliation and flags any variance.
2. Somebody reviewed their own access
Auditors search the decision file for rows where the reviewer and the account holder are the same person. They usually find one: an administrator certifying their own administrative rights, often because the review was delegated to “IT” for the technical systems.
The FFIEC Handbook is explicit that privileged access rights should be reviewed by an independent party. SOC 2 CC6.3, ISO 27001 A.5.3 and NIST AC-5 reach the same place through segregation of duties.
What closes it: route any line where reviewer and holder match to the reviewer’s manager, and show a report with zero self-certified lines. The Review sheet flags matches automatically, ignoring case and spacing.
3. Every line was approved in minutes
A 100 percent approval rate across 400 lines, completed in six minutes, is evidence that nobody reviewed anything. The PCAOB’s Staff Audit Practice Alert No. 11 is where its expectations for review controls come from: a review must operate at a level of precision that would actually catch the problem. Rubber-stamping fails that test regardless of how complete the sign-off looks.
Rubber-stamping is a design failure more than a people failure. Reviewers approve what they cannot interpret. If the screen says APP_FIN_RW_07 with no description, no last-used date and no flag that the person changed role in July, keeping it is the only defensible click.
What closes it: plain-language entitlement descriptions, last-used dates, mover flags and segregation-of-duties conflicts shown at the point of decision, plus per-reviewer revocation rates that someone actually looks at. The Sign-off sheet flags any reviewer with no revocations across fifty or more lines.
4. “Revoke” never reached the system
The review found the problem. The ticket was raised. The ticket was closed. The access is still there at year end.
A closed ticket is not evidence. Auditors want the target system to show the entitlement gone, and increasingly they want to know whether the access was used between the decision and its removal. For a financial system that question matters, because inappropriate access that was exercised can reach the financial statements.
What closes it: for each revocation, a removal date verified by re-extracting from the system, the elapsed time against a stated SLA, and a look-back at activity during the exposure window.
5. Service accounts were not in scope
Most templates are designed around people, so service accounts, API keys and integration credentials are left out. They are also the accounts most likely to hold standing administrative rights, to have no owner, and to carry credentials older than the team that created them.
PCI DSS 7.2.5.1 requires application and system account access to be reviewed at a frequency your targeted risk analysis sets. OSFI B-13 section 3.2.7 expects service accounts to be “securely authenticated, managed and monitored”. HIPAA 164.312(a)(1) applies access control to “software programs” as well as persons.
What closes it: every non-human account in scope with a named human owner and a stated purpose, reviewed by that owner. For why ownership has to come first, see who owns SA-prod-04.
How often are user access reviews required?
This is the most searched question about access reviews, and the one most often answered wrongly. The honest answer is that very few instruments put a number on it.
3 of 15
frameworks in our crosswalk set a review interval. The others leave it to your risk assessment and then hold you to what you wrote.
vaultIAM User Access Review crosswalk, clauses checked at source Sep '26
PCI DSS 4.0.1
- What the instrument says
- User accounts and privileges: at least once every six months (7.2.4). Application and system accounts: per your targeted risk analysis (7.2.5.1).
- What gets tested
- Two completed reviews in any twelve-month assessment period, including vendor accounts, with management acknowledgement.
NYDFS Part 500
- What the instrument says
- All user access privileges: periodically, at a minimum annually (500.7(a)(4)).
- What gets tested
- The review, plus removal of access no longer needed. Class A companies must also monitor privileged access and run a PAM solution (500.7(c)).
SOX / NI 52-109
- What the instrument says
- No interval. ICFR is designed on a control framework, usually COSO 2013.
- What gets tested
- Whatever cadence your control description states, every occurrence, with a tested population.
SOC 2
- What the instrument says
- No interval (CC6.2, CC6.3).
- What gets tested
- Every occurrence you committed to across the report period. A missed quarter is an exception.
HIPAA
- What the instrument says
- No interval. Access establishment and modification is addressable (164.308(a)(4)(ii)(C)).
- What gets tested
- That you reviewed and modified access, or documented why an equivalent alternative is reasonable.
OSFI B-13
- What the instrument says
- "Regular attestation of access" (3.2.7). No interval.
- What gets tested
- A risk-based cadence, applied, with privileged credentials vaulted and service accounts monitored.
FFIEC
- What the instrument says
- On a schedule commensurate with risk (Information Security booklet, II.C.15).
- What gets tested
- Higher-risk access reviewed more often, and privileged access reviewed by an independent party.
| Framework | What the instrument says | What gets tested |
|---|---|---|
| PCI DSS 4.0.1 | User accounts and privileges: at least once every six months (7.2.4). Application and system accounts: per your targeted risk analysis (7.2.5.1). | Two completed reviews in any twelve-month assessment period, including vendor accounts, with management acknowledgement. |
| NYDFS Part 500 | All user access privileges: periodically, at a minimum annually (500.7(a)(4)). | The review, plus removal of access no longer needed. Class A companies must also monitor privileged access and run a PAM solution (500.7(c)). |
| SOX / NI 52-109 | No interval. ICFR is designed on a control framework, usually COSO 2013. | Whatever cadence your control description states, every occurrence, with a tested population. |
| SOC 2 | No interval (CC6.2, CC6.3). | Every occurrence you committed to across the report period. A missed quarter is an exception. |
| HIPAA | No interval. Access establishment and modification is addressable (164.308(a)(4)(ii)(C)). | That you reviewed and modified access, or documented why an equivalent alternative is reasonable. |
| OSFI B-13 | "Regular attestation of access" (3.2.7). No interval. | A risk-based cadence, applied, with privileged credentials vaulted and service accounts monitored. |
| FFIEC | On a schedule commensurate with risk (Information Security booklet, II.C.15). | Higher-risk access reviewed more often, and privileged access reviewed by an independent party. |
The full table, including retention periods for all fifteen, is on the template page and in the workbook.
Two corrections worth making in your own documents. OSFI B-13 does not require quarterly privileged access reviews; some published summaries say it does, and the guideline does not. And SOX does not require you to keep review evidence for seven years. That figure comes from Regulation S-X Rule 2-06, which applies to the auditor’s workpapers. Seven years may be a sensible policy, but it is yours.
What do Canadian regulators require?
Canadian instruments are shorter and less prescriptive, and it is easy to conclude they ask for less. They ask for the same thing in fewer words.
OSFI B-13 section 3.2.7 is one paragraph that covers least privilege, regular attestation of access, MFA for privileged accounts, vaulted privileged credentials, and monitored service accounts. Guideline B-10 carries the same expectations to third parties. NI 52-109 requires non-venture issuers to design ICFR using a control framework (section 3.4), which in practice means COSO and IT general controls tested much as they are under SOX.
The privacy laws reach access reviews through need-to-know. PIPEDA Principle 4.7.3(b) names “limiting access on a need-to-know basis” as a safeguard. Section 20 of Québec’s private sector act, as amended by Law 25, allows staff to access personal information only where it is needed for their duties. An access review is how you show both are true.
How do you run an audit-ready access review?
For a team running its first evidence-grade review on an existing identity platform, this order produces the most defensible result for the least effort. The first two steps are what make every later decision count.
- 1
Scope by risk, and write the cadence down
1–2 daysList systems in scope with the reason each is there: financial reporting, cardholder data, ePHI, nonpublic information. Assign a tier and a cadence, citing any prescribed floor. This is the document every later test is measured against.
- 2
Prove each population before anyone reviews it
½ day per systemExtract from the application, not the IdP. Record the query, parameters, run time and operator. Reconcile the row count to an independent count in the system. Deliver it read-only.
- 3
Give reviewers something to decide with
1 week, first cycle onlyPlain-language entitlement descriptions, last-used dates, mover flags and segregation-of-duties conflicts on each line. Assign a business owner as well as the manager for sensitive entitlements.
- 4
Put service, vendor and emergency accounts in
1–2 weeksEach with a named owner, a purpose and, for vendors, a contract and expiry. Expect it to surface accounts nobody knew existed.
- 5
Close the loop in the system
Ongoing, per cycleA ticket per revocation, removal verified by re-extract, elapsed time against SLA, and a look-back at activity for anything on a financial or regulated-data system.
- 6
Sign off, retain, and look at the numbers
½ day per cycleDated sign-off by each reviewer and the control owner. Keep the cycle as it was. Report revocation rates, exceptions and repeat findings upward.
The first cycle is the expensive one, mostly because steps two and four surface accounts nobody knew about. From the second cycle on, the work is mostly running extracts and chasing reviewers, and the evidence assembles itself as you go.
Where vaultIAM fits
We review identity controls read-only against the platforms you already run, and an access review is usually the first artifact we sample, because it shows how every other lifecycle control is working. If you want someone to walk your last cycle against these questions before your auditor does, that is what the Identity Risk Review is for.
If you would rather do it yourself, the template has everything above, and the IAM Self-Assessment Scorecard scores access certification alongside the nine other identity risk categories.
Common questions
How often are user access reviews required?
Only three of the fifteen frameworks we mapped set a number. PCI DSS 4.0.1 requires user accounts and their privileges to be reviewed at least once every six months (requirement 7.2.4). NYDFS Part 500 requires all user access privileges to be reviewed at a minimum annually (section 500.7(a)(4)). HITRUST sets intervals in its licensed requirement statements. SOX, SOC 2, HIPAA, FFIEC, NIST, ISO 27001, OSFI B-13 and the Canadian privacy laws leave the interval to your risk assessment. Once your procedure names an interval, that is the one you are tested against.
Does SOX require quarterly user access reviews?
No. No SOX rule or PCAOB standard sets a review frequency. Quarterly is common for financially significant systems because it lets an auditor test several occurrences in a year, and because a longer gap leaves inappropriate access in place for longer before it is caught. What the auditor tests is whether the review ran at the frequency your control description states, every time, with evidence.
What is IPE, and why does it matter for access reviews?
IPE is information produced by the entity: any report or extract the company generates and the auditor relies on. For an access review, the user listing is IPE. PCAOB AS 1105.10 requires the auditor to test its accuracy and completeness, and PCAOB inspections have repeatedly found engagement teams that did not. So auditors now ask for the query, its parameters, the run timestamp and a record count reconciled to the system. Without that evidence the review can be treated as not performed, however carefully the decisions were made.
What evidence do auditors want from a user access review?
Five things for each cycle: the complete population with evidence it was complete; the reviewer for each line and why they were qualified; a decision on every line, with reasons for keeping privileged or unusual access; proof that each revocation was carried out in the target system, not just ticketed; and a dated sign-off. They will also sample leavers and new access granted during the period, because a review cannot make up for a broken joiner or leaver process.
Do service accounts need to be included in access reviews?
Yes. PCI DSS 7.2.5.1 requires access by application and system accounts to be reviewed at a frequency set by your targeted risk analysis. OSFI B-13 section 3.2.7 expects system and service accounts to be securely authenticated, managed and monitored. HIPAA section 164.312(a)(1) applies access control to software programs as well as people. Most access review templates cover people only, which is why unowned service accounts with standing privileges are a common finding.
Does OSFI B-13 require quarterly privileged access reviews?
No. Section 3.2.7 of Guideline B-13 expects federally regulated financial institutions to enforce least privilege and conduct "regular attestation of access", manage privileged credentials in a secure vault, and monitor service accounts. It does not set an interval. Quarterly may be the right answer for your privileged population, but it is your risk decision, not a requirement of the guideline.
How long should user access review evidence be kept?
It depends on the regime. HIPAA requires documentation to be kept for six years (section 164.316(b)(2)(i)). NYDFS requires records supporting the annual certification to be kept for five years (section 500.17(b)). SOX sets no retention period for the company's own review evidence; the seven years often quoted is Regulation S-X Rule 2-06, which applies to the auditor's workpapers. Whatever the period, keep each cycle as it was at the time, not overwritten by the next one.
Who should perform a user access review?
Two people, ideally. The manager can confirm the person still needs access for their role; the application or data owner can confirm the entitlement is appropriate. Nobody should review their own access, and the FFIEC Handbook expects privileged access to be reviewed by a party independent of the administrators who hold it.