CyphrQ
Menu

Auditing User Access Reviews: How to Test Recertification Works

A user access review audit tests more than a signed spreadsheet. How to check the user list, spot rubber-stamping and test leavers.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

11 min read

A user access review audit checks that the people who can reach a system are the people who should, and that the review proving it was complete, timely and genuinely done. The signed-off spreadsheet is not the evidence. The evidence is the list behind it, what reviewers did with it, and what happened afterwards.

This post is for auditors, IT managers and business owners who need to answer one question: does our access recertification actually work? It is part of the IT audit series. For the wider picture of general IT controls, start with IT general controls explained.

What is a user access review?

A user access review (also called access recertification) is a recurring check where a manager or system owner confirms that each account's access is still needed. Accounts that are no longer needed are removed. In plain terms, it is the control that catches the leaver who still has a login, and the person who changed teams and kept the old permissions.

NIST SP 800-53 Rev. 5 places this inside account management. Control AC-2, item j, requires you to "review accounts for compliance with account management requirements" at a frequency the organisation defines. The standard does not set the number. That choice is yours, and an auditor will ask you to justify it. NIST SP 800-53 Rev. 5 catalog, AC-2

Why do user access reviews fail when they are done on time?

Many failures are not missed deadlines. They are reviews that ran on schedule over the wrong data, or reviews where nobody looked closely. Three patterns come up repeatedly:

  • An incomplete user list. The review covers only the accounts in the report, so accounts left out of the report are never reviewed.
  • Rubber-stamping. Reviewers approve everything because the list is long, unclear, or nobody checks their answers.
  • No follow-through. Reviewers mark an account for removal, and the removal never happens.

In practice: a regular review that covered 60% of accounts

ISACA describes a client that had "regular reviews performed consistently over years." The review looked like a strong control. However, the report feeding it "captured only 60% of system accounts, creating a massive blind spot." The other 40% were never put in front of a reviewer. ISACA's lesson is that the control focused on the review process rather than on checking that the underlying data was complete. ISACA Now Blog, The Control Matrix Rebooted (2025)

That is why the audit starts with the list, not with the sign-off.

How do you audit a user access review step by step?

Work through these tests in order. Each one produces evidence you can file.

  1. Get the policy. Find the stated review frequency, scope and owner. Check it against the standards you are held to.
  2. Obtain the population yourself. Ask for the account list directly from the system, with the query or report logic, not a copy someone prepared.
  3. Reconcile the list. Compare the review population to an independent source, such as the directory, the application database or HR records.
  4. Read the reviewers' decisions. Look at approvals, rejections and comments, and who made them and when.
  5. Trace removals. For every account marked for removal, confirm it was disabled and when.
  6. Test leavers and movers. Take a sample of people who left or changed roles, and check their access ended on time.
  7. Check privileged and service accounts. Confirm they were in the review and have named owners.
  8. Confirm the evidence is kept. Make sure someone else could re-perform your test later.

The next sections explain what each test is looking for, and the section "Going deeper: for security and IT teams" gives the technical detail.

What do standards say about user access review frequency?

Two frameworks give concrete anchors, and they differ in how prescriptive they are.

Source What it says Practical meaning
NIST SP 800-53 Rev. 5, AC-2 Review accounts at an organisation-defined frequency You set and defend the interval
CIS Controls v8, Safeguard 5.1 Inventory all accounts, including user, administrator and service accounts; check active accounts for authorisation at least quarterly A quarterly floor for the account inventory
CIS Controls v8, Safeguard 5.3 Delete or disable dormant accounts after 45 days of inactivity, where supported A default dormancy threshold
CIS Controls v8, Safeguard 5.5 Inventory service accounts with owner, review date and purpose; review at least quarterly Service accounts need owners and a schedule

The CIS rows come from the CIS Controls Assessment Specification for Control 5. CIS Controls Assessment Specification, Control 5: Account Management

If you handle card payments, PCI DSS v4.0 has its own requirement for periodic review of user accounts and access privileges. It is not quoted here because the full standard text was not read for this post. Check requirement 7.2.4 in the current PCI DSS document before you rely on a figure.

How do you test that the user list is complete?

Completeness means every account that should be in scope is in the review. It is a common point of failure, and one of the easiest to test.

Ask a simple question: does the number of accounts in the review match the number of accounts in the system? If you cannot answer that, the review has no proven population.

A practical approach:

  • Get the review population and the system's own export on the same day.
  • Count both. Investigate every difference.
  • Look for filters in the report logic that silently drop accounts, such as excluded system IDs, disabled accounts that can be re-enabled, or accounts with no manager recorded.
  • Repeat for each system in scope, not just the largest.

Differences are findings only if you cannot explain them. A timing gap of a few hours is explainable. A missing set of accounts is not.

What does a rubber-stamped user access review look like?

A rubber-stamped review looks perfect on paper. Every account is approved, nothing is removed, and it was completed on the due date.

Signals worth checking:

  • Every reviewer approved 100% of accounts, review after review.
  • Reviews were completed in minutes for lists that should take hours.
  • Approvals were made by someone who cannot know the person's job, such as a delegate who never worked with them.
  • No access was ever removed, across several cycles.

None of these proves the control failed, but together they tell you where to look. Pick a sample of approved accounts and ask the reviewer why that access is needed. If the answer is "I assumed it was fine", the review did not work.

How do you test leavers in a user access review audit?

Leaver testing is the sharpest check on whether recertification works. A review exists partly to catch access that should already be gone.

NIST AC-2(3) requires organisations to disable accounts within a defined time when they meet certain conditions. NIST SP 800-53 Rev. 5 catalog, AC-2(3)

To test it:

  1. Get a list of leavers from HR for the audit period.
  2. Match each leaver to every system in scope.
  3. Compare the HR leaving date to the date the account was disabled.
  4. Check whether any leaver account was used after the leaving date.
  5. Ask why any account stayed active, and who accepted that.

If a leaver's account is still active at the next review, ask whether the reviewer saw it and approved it anyway, or never saw it at all. The first is a judgement problem. The second goes back to the completeness test.

Going deeper: for security and IT teams

This section assumes you already run or audit access reviews and want the technical checks.

Standards to map to. NIST SP 800-53 Rev. 5 AC-2 covers account management, and AC-2(7) covers privileged user accounts. AC-2(7) lists four items: establish and administer privileged accounts according to defined requirements, monitor privileged role or attribute assignments, monitor changes to roles or attributes, and revoke access when privileged role or attribute assignments are no longer appropriate. NIST SP 800-53 Rev. 5 catalog CIS Controls v8 Safeguards 5.1, 5.3, 5.4 and 5.5 give concrete intervals and an inventory requirement. CIS Controls Assessment Specification, Control 5

Completeness and accuracy of the user listing. Treat the user listing as information produced by the entity (IPE) and test it before you rely on the review. Completeness asks whether all accounts are present. Accuracy asks whether the attributes shown, such as role, manager, department and last logon, match the source. They need separate tests. ISACA's example shows what goes wrong when only the review step is tested: the report captured 60% of accounts and nobody noticed for years. ISACA Now Blog, The Control Matrix Rebooted

Re-perform the extraction yourself:

  • Capture the query, filters and run date. Re-run it and compare record counts.
  • Reconcile directory objects, application local accounts and database users separately. Local application accounts often sit outside the directory.
  • Compare against HR to find active accounts with no matching employee and vice versa.
  • Check for service, shared and emergency accounts that the report excludes by naming convention.

Rubber-stamp detection. Pull review decision logs and calculate approval rates per reviewer, time between the review being issued and each decision, and the number of decisions made in a single session. A reviewer approving hundreds of rows within a few minutes did not examine them. Then sample approved accounts and ask reviewers to explain the business need. Also confirm the reviewer is the right person: the account owner's manager or the system owner, not the user themselves.

Leaver testing. Match HR termination dates to disable timestamps in the directory and each application. Check last-logon and sign-in logs for activity after termination. Test movers as well as leavers: someone who changed teams should lose the previous role's access, which a review of "does this person need this account" will not catch unless reviewers see the entitlements, not just the account name. CIS Safeguard 5.3 sets a 45-day dormancy default; compare last-activity data against it. CIS Controls Assessment Specification, Control 5

In practice: a dormant account behind a council ransomware attack. The UK Information Commissioner's Office reprimanded the London Borough of Hackney on 17 July 2024 over a 2020 cyber attack. Attackers gained access to and encrypted 440,000 files, affecting at least 280,000 residents and other people, staff included. The ICO says the council "failed to change an insecure password on a dormant account" that was still connected to its servers, and the attackers exploited it. The ICO considered a fine but issued a reprimand under its public sector approach. For an auditor, the lesson is that dormant accounts belong in the review population. A user listing that shows only recently active accounts hides exactly the ones this case turned on.

In practice: contractors who left but stayed in the system. The Treasury Inspector General for Tax Administration's audit 2024-100-063, Former Contractor Employees Retained Access to IRS Facilities, Systems, and Equipment, was issued on 18 September 2024. Its two recommendations show where the control broke. One asks for an "ongoing periodic review of contractor employees' status in HRConnect". The other asks for an "ongoing periodic quality review" of separation actions. The report's figures sit in a PDF that was not read for this post, so none are quoted. The pattern is still useful: contractor leavers often sit outside the HR feed that drives your leaver test, so source their end dates from contract records too.

Privileged and service accounts. Confirm privileged accounts are in scope and reviewed at the entitlement level. CIS Safeguard 5.4 asks that administrator privileges sit on dedicated administrator accounts, not on a user's everyday account. For service accounts, Safeguard 5.5 expects an inventory recording department owner, review date and purpose, with reviews at least quarterly. Test that each service account has a named owner who can explain it, and that the owner responded.

Closing the loop. For every "remove" decision, find the ticket or change record and the disable timestamp. Measure the gap between decision and action. A review that finds problems nobody fixes is a documented risk, not a control.

Evidence retention. Keep the population extract with its query and date, the reconciliation, reviewer decisions with timestamps, the removal evidence, and the exception log. Store the evidence so a second person can re-perform your test. How long you keep it depends on your own retention policy and any regulator or auditor requirement. Neither NIST AC-2 nor the CIS safeguards set a retention period.

Questions to ask. Who owns the report logic? When was it last changed? Which systems are outside the review, and who accepted that? How are accounts outside the directory found?

What should you do next about your user access review?

Run this short check on your next review:

  • Count the accounts in the system and in the review. Do they match?
  • Pick five leavers. Were their accounts disabled on time?
  • Find the reviewer with the fastest approvals. Ask them about three accounts.
  • Pick three removal decisions. Were they carried out?
  • Find the service accounts. Does each have an owner?

One failed check is a finding. Several failed checks suggest the review is a ritual, and the fix starts with the population, not the reviewers.

Key takeaways

  • A user access review audit tests the user list, the reviewers' decisions and the follow-up, not just the sign-off.
  • Test completeness first: reconcile the review population to the system's own export.
  • ISACA describes a review that ran for years over a report capturing only 60% of accounts.
  • The ICO reprimanded Hackney council after attackers used a dormant account with an insecure password; 440,000 files were encrypted.
  • CIS Controls v8 gives a quarterly floor for account inventory and a 45-day dormancy default.
  • NIST AC-2 sets no review interval. You choose one and defend it.
  • Leaver, mover, privileged and service account tests show whether the review works in practice.
  • Keep evidence that lets a second person re-perform your test.

Sources