Some Thoughts on Auditing Identity and Access Management

GUEST BLOG POST
The Institute of Internal Auditors regularly publishes useful Global Technology Audit Guides (GTAGs), available to members on their website under Standards and Guidance. They are considered recommended rather than mandatory guidance for internal auditors.

As part of that effort, the IIA recently published a second edition of its guide, Auditing Identity and Access Management. While the guides are generally helpful and typically offer good information, I can’t say that about this latest GTAG. The IIA guide on auditing identity and access management should not be recommended. I recommend setting it aside. In fact, I recommend that the IIA delete it.

The primary problem is that the GTAG does not recognize that, as risk management expert Jay Taylor once said: “There is no such thing as an IT risk, there is only business risk.” There are other major issues with the guidance, but rather than get into the detail of what is wrong with it or omitted, I will share some alternative guidance of my own, included in the following ten points:

1Don’t audit access management (or anything else) just because the “authorities” say you should. The IIA mandates a risk-based approach and that requires judgment. Audit what matters to the success of your organization.

2Where’s the risk? It is important to understand how an access management issue could affect the business. The GTAG falls into the NIST trap (National Institute of Standards and Technology) of talking about information assets when we should be talking about the potential impact on the business. In fact, access management is not only about limiting who can access information systems and data; it also may limit access to inventory, facilities, people, and equipment! Just think about your identity card reader at the office.

3Any audit of access management should be identified through the singular internal audit planning process, based on which areas represent higher enterprise risk where we can add value. There should not be a separate IT audit risk planning process. Instead, there must be a clear understanding of where access management falls against other sources of business risk—and that will help with the detailed scoping of any audit.

4Which access needs to be limited and why? Not all access issues represent a risk of any significance to the business. All audits should focus on what matters to the business. The whole array of controls should be considered in assessing the risk, including business process controls. For example, there may be both card readers, guards, and daily inventory counts around valuable raw materials.

5Focus on the business controls or key IT general controls (ITGC) that rely on limiting either individual access or a combination of access. You might, for example, consider a control that says only certain people can approve a journal entry or an invoice for payment. Then there is the need to limit who can both set up a new vendor and approve payments to them. Can you see where the GTAG mentions a combination of access, apart from in the glossary? It does not! We need to understand where controls within business processes specify either restricted access (relying on a limited number of people having access) or a division of duties (representing a fraud risk).

6Understand how access is controlled, limiting access to individuals authorized in the system. What systems are involved? Are they purchased or maintained in-house? How do they function, including how access limits are set up, enforced, and periodically reviewed?

7Are the controls over access adequately designed and operating consistently? This may require understanding and then assessing related IT general controls. It should include testing that the access limits are properly enforced and exceptions investigated.

8Are the controls that monitor access rights adequately designed and operating consistently? For example, if a monthly or quarterly report is provided to business managers to review and confirm, what assurance is there that the report is complete and accurate, that it is properly reviewed, and actions taken as needed?

9How is access granted? How does the provisioning system work and is it reliable? Consider the need for the access request to be approved, not only by the user’s manager, but also by the owner of the related risk or system. For example, the accounts payable manager should approve all access to several functions within the AP system. When a SOX key control is involved, additional approvals may be needed. Is there assurance that access is changed on a timely basis when the individual’s needs change (through transfer or termination, for example)?

As new systems and processes are introduced or changes made to existing ones, are there adequate controls to ensure access management is appropriately addressed? I have seen situations where a new code was used to distinguish types of credit notes in an SAP system, but the reports used to monitor who had the ability to approve credit notes was not changed.

I am sure there is more to be said, but the key point is that any audit should be based in design and execution on the level of business risk, and not only on any generic standard or list of information assets. I welcome your thoughts in the comment section below. 

Norman Marks is an internal audit and risk management expert and author of the blog, “Norman Marks on Governance, Risk Management, and Audit.” He is also the author of several books, including World Class Risk Management, Risk Management in Plain English: A Guide for Executives, and Auditing that Matters.

NOTE: This article was republished with permission from “Norman Marks on Governance, Risk Management, and Audit.”