Testing user access: provisioning, terminations and periodic access reviews

How to test new user provisioning, timely removal of access and periodic user access reviews, including completeness of the user listing and precision of the reviewer.

5 min read · CORAA Team
Lesson 4 of 14 · 0 of 14 complete
In this lesson you will
  • Design tests of access provisioning and removal using HR and system populations
  • Test a periodic user access review for completeness, precision and follow-up
  • Identify common access review failures and their audit consequence
  • Document access testing so a reviewer can reperform it

The three access controls you usually test

AS 2110.B4 lists unauthorized access to data among the risks from IT, including the recording of unauthorized or nonexistent transactions. Three controls address it at the user level:

  1. Provisioning. New access is approved by an appropriate person before it is granted.
  2. De-provisioning. Access is removed timely when a user leaves or changes role.
  3. Periodic review. A knowledgeable owner reviews who has access and what they can do, and changes are made.

Privileged access is covered in lesson 5.

Testing provisioning

Population: all users created in the in-scope application during the period, taken from the system (creation date field or audit log), not from the help desk ticket list. The ticket list shows what was requested; the system shows what happened.

For each sample item, inspect the access request and check that:

  • an appropriate approver (usually the user's manager or the data owner) approved before the access was granted;
  • the access granted matches the access requested;
  • the role is consistent with the user's job.

A common exception: the approval is dated after access was granted. That is a design or operating failure, not a timing nuance.

Testing de-provisioning

Population: terminations from the HR system for the period. Match each terminated employee to the application's user list and access logs.

For each sample item, check the date access was disabled against the termination date and the entity's policy (for example, the next business day). Then check activity: did the account log in or post anything after termination? An account that stayed active but was never used is a deficiency with lower risk than one that was used.

Also test transfers. Role changes are where access accumulates silently.

Testing the periodic user access review

This is the control most often tested and most often found weak. Test four attributes.

Completeness of the listing. The reviewer reviewed a system-generated user list. You need evidence that the list was complete and accurate: how it was generated, when, and whether it agrees to the system at that date. This is an IPE question (lesson 8).

Precision. The review covered roles and permissions, not just names. A reviewer who confirms "these 140 people still work here" has not reviewed whether they should be able to approve payments.

Reviewer competence and independence. The reviewer knows what access each role needs and does not review their own access.

Follow-up. Changes the reviewer requested were made. Pick each requested removal and check the system.

Sample sizes

Sample sizes for ITGC tests come from firm methodology and depend on how often the control operates and the risk it addresses. For provisioning and de-provisioning, the sample is drawn from the system population of new users and terminations. Document the table you used and how you applied it.

Typical failures and what they mean

Failure Consequence
Review used an unvalidated list Review cannot be relied on until the list is tested
Reviewer approved everything without removals for years Ask whether the review is precise enough; inspect a few users
Terminated user still active and used Investigate activity; assess effect on transactions posted
Approvals after the fact Operating deficiency in provisioning

When a control fails, consider whether another control compensates (for example, a detective review of all journal entries above a threshold) and test that control rather than assuming.

Documentation

Keep the population source, the extraction date and method, the sample, and the evidence for each attribute. The user access review checklist gives a workpaper layout.

Worked example

Quarterly access review at Pine Ridge Credit Services

Pine Ridge Credit Services has 210 users in its loan servicing application. The operations manager performs a quarterly access review. The team tests the June 30 and December 31 reviews.

June review: the manager received a user list generated by IT on July 3. The team obtains the query used and reruns it against the July 3 system backup; the counts agree (210 users). The list includes user names, roles and the permission "approve payoff waiver." The manager flagged three users for removal. The team checks the system and finds all three removed by July 12.

December review: the list given to the manager showed names and departments only, no roles. The manager signed "all appropriate." The team concludes the December review lacked precision: the manager could not have evaluated whether anyone held the waiver permission inappropriately.

The team then runs its own listing of users with the waiver permission at December 31: nine users, of which two had transferred to collections in October and should not hold it. Neither approved a waiver after the transfer, based on the application log.

Conclusion: an operating deficiency in the December review (insufficient precision) and a de-provisioning gap for the two transferred users, with no misstatement found. The team communicates it, assesses severity in lesson 14 terms, and does not rely on the December review for the second half.

Self-check

Answer each question before you open the answer.

  1. Why draw the provisioning population from the system rather than from approved tickets?

    Show answer

    Tickets show only access that went through the process. The system shows every account created, including any granted without a request, which is the risk you are testing.

  2. A reviewer confirms that every user on the list is a current employee. Is that an effective user access review?

    Show answer

    Not on its own. The review has to assess whether each user’s roles and permissions are appropriate for the job. Confirming employment does not address excessive or conflicting access.

  3. What extra evidence do you need when the review is performed on a system-generated listing?

    Show answer

    Evidence that the listing was complete and accurate as of the review date (how it was generated and that it agrees to the system), because the review is only as good as the list.

  4. A terminated employee’s account stayed active for 30 days but was never used. How does that compare with an account that was used?

    Show answer

    Both are deficiencies in de-provisioning, but an unused account carries lower risk of misstatement. A used account requires you to examine what was done and its effect on the financial statements.

Sources

Back to the syllabus

Standards are paraphrased from the primary sources listed above; read the source before relying on a requirement. This lesson is training material, not professional advice. Report an error

For US CPA firms

Join the CORAA waitlist

CORAA AI drafts audit working papers from your client’s QuickBooks books and does the first pass: lead schedules, tie-out, memos, draft notes and letters. CORAA Network reviewers clear every finding. Your firm reviews and signs.

  • First audit free, so you can judge the quality on a real file
  • Flat fee by entity size; messy books included
  • We work only with CPA firms, never their clients
See how it works →

* required