- 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:
- Provisioning. New access is approved by an appropriate person before it is granted.
- De-provisioning. Access is removed timely when a user leaves or changes role.
- 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.
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.
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.
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.
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.
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.
Use it on the file
- GuideUser Access Provisioning and Quarterly Access Reviews: ITGC Testing Steps
- TemplateITGC and User Access Review Checklist (Financial Statement Audit)
- TemplateSOX User Access Review Test Worksheet
Sources
- PCAOB, Auditing Standards compilation including AS 1105, AS 2110, AS 2201, AS 2601 and AS 2605
- AICPA, Statements on Auditing Standards currently effective (AU-C sections, including AU-C 315 as amended by SAS No. 145)
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