Home > Risk > Auditing Identity and Access Management

Auditing Identity and Access Management

The IIA has published several useful Global Technology Guides (GTAGs), available to members on their website under Standards and Guidance. They are considered recommended rather than mandatory guidance.

However, their recent GTAG, Auditing Identity and Access Management, second edition, 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 “there is no such thing as an IT risk, there is only business risk” (Jay Taylor). There are other major issues, but rather than get into the detail of what was wrong or omitted, I will share some alternative guidance.


  1. Don’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.
  2. Where’s the risk? It is important to understand how an access management issue could affect the business. The GTAG falls into the NIST trap 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 card reader at the office.
  3. Any 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.
  4. Which 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.
  5. Focus on the business controls (or ITGC key controls) that rely on limiting either individual access or a combination of access. For example, 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).
  6. Understand 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?
  7. Are 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.
  8. Are 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?
  9. How 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 and/or system. For example, the AP 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 (e.g., through transfer or termination)?
  10. 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 any generic standard or list of information assets.


I welcome your thoughts.

  1. July 22, 2021 at 10:50 PM

    You are right that more can be said. It starts with the question if the auditor has enough knowledge to be able to perform the audit. Acces control in Linux is different from Windows and SAP different from Oracle Business Suite. I have seen enough examples in the past of (financial) auditors using checklists from their audit manuals and having no clue what they where actually doing and what they should be looking for.
    Second, you may think that autorisations are restricted and devisions of dutie in place on the business side, but did you also pay attention to priviliged accounts, both in front (SAPALL) and in the back of the IT-organisation (Windows administrator, Linux Root) who could do anything when they want and even drop teh logfiles of their evil actions …
    Third, it starts with access: 2FA/MFA to deal with risks form cyber security (hacking, ransomware).
    And there may be more.

  2. July 25, 2021 at 10:00 PM

    Emphasizing the need to tie the audits to the highest risk areas of operations is critical to providing a functional audit plan. If the company does not store a lot of sensitive data, auditing access controls might be a lower priority. As with any element of the audit plan, it should be discussed with risk owners and senior leadership in order to properly tailor the plan to cover the highest risks.

    The only thing I could potentially disagree about is whether or not the risk owners properly understand the emerging risks around system access vulnerabilities and ransomware. Without strong audit leadership advocating for emerging risks, the business might not be properly calibrating strategies to meet risks they don’t completely understand.

    Excellent post, as always! Thanks for making such consistently engaging posts.

  1. July 22, 2021 at 3:33 PM
  2. July 24, 2021 at 1:27 AM

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: