Key considerations when implementing periodic User Access Reviews

This article is a part of Risk Update 3. 

---

An effectively designed user access review (UAR) process mitigates the risk of inappropriate access to an organisation’s data, which in turn reduces the risk of either erroneous data entries being made, or confidential data being leaked.

Introduction

User access reviews are a key review area from internal risk management teams and external auditors, and often a recurring source of findings. In this article, we look at some key considerations for user access reviews, which should be considered when implementing a user access review across a business unit, application or organisation.

Tooling

Identity access management tools are becoming increasingly popular for large and complex organisations. These tools help automate the ‘hire to retire’ process including periodic UARs. By automating some or most of the process, the risk of human error is reduced, which is a common area of control breakdown. It is important to consider the cost and the complexity of the IT environment and user base before implementing such a tool.

Policy and Procedure

Policy and procedural documentation are integral for a well-functioning UAR process. A well-defined policy clearly identifies the requirements for the user access review such as frequency, timeliness and accountability of control owner(s). A control owner leaving an organisation is a common reason for the UAR process breaking down. However, a well-documented policy and procedure ensures that in the event of changes to control owners, the UAR process is not impacted.

Frequency

The frequency of the review is dependent on a range of factors, which includes size of user base, turnover within the organisation and number of third-party users with access. The user access review should be performed more than annually for critical applications. A more frequent review should be performed for privileged users as the risk of inappropriate activity is higher due to the elevated access.

A targeted UAR for an individual user could also be performed by their line manager upon a position or team change. This helps determine what access should be retained in the new position or team.

Scope of review

The user groups to be included in the review should be noted in the policy or procedural documentation. Key considerations include whether access is more than read-only (i.e. – write access) and whether it includes contractors and/or suppliers.

The scope should also consider whether users with access to the supporting infrastructure to the application should be included. This is dependent on what activities a user with access to the database and/or  operating system can perform. Privileged access to the database should be included in scope if it allows users to make direct data changes. Similarly, if privileged access at operating system level allows users to change critical application functionality and/or create new users, then it should also be included in the UAR.

Completeness of user listings

This is a key area of breakdown for user access reviews. Organisations should retain sufficient evidence to validate that the user listings used as part of the UAR are complete. This includes retaining screenshots of the parameters applied to generate the listing. Where possible, screenshots showing row count should also be retained to validate  that the raw user listing was not modified after generation.

Where user listings are generated automatically, the respective teams should perform procedures to validate that the underlying script or query is generating a complete and accurate user list. The script or query used to generate the listing should be retained. This is to validate that the script or query has not been modified since initial testing performed, to validate that it generates a complete and accurate user listing.

Precision of review

Role descriptions: In some instances, the   role name does not provide a clear description of what it allows a user to do. The review sheet should include a description of what a role allows a user to do so the reviewer can evaluate whether the role is required by the user as part of their day to day activities.

Segregation of permissions: The review should also be performed to determine that permissions assigned to roles or entitlements do not create a segregation of duties violation. For example – a segregation of duties violation would occur if a role allows a user to both create and approve purchase orders.

Assigning the reviewer: It is important to assign responsibility for the UAR to someone who has good knowledge of users’ day to day functions. This can be either a user’s line manager, product manager, application owner or someone else. An option should also exist for the reviewer to delegate the review to someone else where they do not have sufficient knowledge.

Evidence of review: The review documentation should provide sufficient evidence that all users and their corresponding roles have been reviewed. This can be done by commenting next to each line item for the user or ‘tick marking’. A signature at bottom of review sheet may not be enough in some instances to satisfy the requirement of Audit and Assurance that each role has been reviewed. Where possible, the reviewees should have a predefined list of options to choose from (i.e. retain, remove or modify).

Follow up actions

The user access review process is only valuable if follow-up actions are executed. Hence, it is important that any modifications and deletions identified are actioned in a timely manner. Accountability should be clearly defined for the team responsible for ensuring that follow-up actions have been actioned.

A high number of follow ups is an indicator that preventative controls (provisioning, modifications and terminations) are potentially not operating effectively. The respective teams should work with internal risk practitioners to investigate.

Evidence that deletions and modifications have been actioned should be retained. This is ideally evident through automation within an Identity and Access Management tool.

This can be also be done through creation of tickets through a ticketing system (e.g. in ServiceNow) including screenshots showing access has been modified or deleted. Alternatively, a new user listing should be generated again and retained to validate that follow-up actions were effectively actioned.

Self-review

There should be procedures in place to ensure that there are no instances where a user reviews their own access. This is a segregation of duties violation.

Timeliness

The review process from initiation to closure should be monitored. Timeliness is an important aspect since a user’s access may change from the date of user list generation to when it is reviewed. Ideally, the review should be completed within 30 to 60 days from initiation depending on the user base and complexity of review.

Accountability should be assigned to a team (e.g. an internal governance function) to manage the overall process and ensure that responses are received from reviewees in a timely manner. Another consideration is escalating the review to the 2-up manager, if a response is not provided by the respondent. If a response is not provided by the 2-up manager, the user’s access should be revoked.

Retrospective reviews

A retrospective review should be performed for users marked to have their access removed or modified. The retrospective review should identify whether any inappropriate transactions were made by users during the period they were inappropriate.

Checking application logs can be a complicated process as it requires identifying the date the user was deemed inappropriate from and reviewing the changes made within the application by the user. This may not be possible depending on application functionality and whether event monitoring exists.

This can be done by checking the last login dates for terminated users. For modifications, this can be done by checking application logs (if feasible) to check that transactions made by the user were appropriate.

Closing Thoughts

The User Access Review is a key control as part of the general access management controls within an organisation. Organisations should consider and implement the key considerations identified in this article. The level of documentation for user access reviews should be retained at a sufficient level to permit a risk practitioner or external auditor to re-perform the steps and reach the same conclusion.