IS Audit Basics: Auditing Software Licenses

Those of you who have read my bio are aware that in addition to writing for the ISACA Journal, I am also a topic leader for the Audit and Assurance community on ISACA’s Engage Online forum.¹ A recurring request on the forum is for a software licensing audit/assurance program. This strikes me as something that would be suitable for collaboration and the development of an open-source audit/assurance program.^{2, 3} However, for various reasons, mostly around a suitable platform, this has not yet managed to get off the ground. Perhaps I have been too ambitious.

I, therefore, propose a simpler approach. I will run through my thoughts on software licensing and ask you, the reader, to add your thoughts in the comments section. In this way we can produce a collaborative audit/assurance program. As in previous columns,⁴ I will use the ISACA white paper Information Systems Auditing: Tools and Techniques, Creating Audit Programs.⁵

Determine Audit Subject

The first thing to establish is the audit subject. What does a software license mean in your enterprise? If there are distinct types of software licenses (figures 1, 2) in use, it may make sense to record these as separate audit universe items. This is because there may not be the same need to audit “free” software (figure 1) as opposed to purchased software (figure 2). In addition, where types are the same, the inputs to calculate the license costs will be the same.

The key is to use the guidance to consider the software licenses in use at your enterprise and to determine the audit subject(s). You need to answer the key question: What are you auditing?

Define Audit Objective

Once what is to be audited has been determined, the objective of the audit needs to be established. Why is it being audited? From an auditor’s perspective, it is advisable to adopt a risk-based view and define the objectives accordingly. Likely risk factors include:

• Financial (i.e., penalties, fines)
• Reputational
• Opportunity costs

Audit objectives should also correspond to goals as defined by the enterprise (figure 3).

Unusually, for an audit, it is also worth considering what is not an objective. It is not, in my opinion, an objective of a software licensing audit for IT audit to scan the network or otherwise confirm the number of software installations. This, most definitely, should be performed and is a key input to the audit; however, it should be a separate management exercise subject to an independent, separate audit of software or IT asset management.

Attempting to identify all instances of installed software, especially in an environment where there is no predefined scanning, inventory or discovery tool, will result in drowning the audit in a sea of false positives. If it is determined that this is the case, the audit should be stopped and this should be made the key finding.

Set Audit Scope

When the objectives of the audit have been defined, the scoping process should identify the actual software licenses that need to be audited. In other words, what are the limits to the audit? Examples of scope limitation could include:

• Licenses that are calculated in a similar manner (as previously mentioned)
• The top-five vendors based upon annual licensing cost
• Areas where there is a high likelihood of noncompliance (e.g., after a merger or acquisition)
• Vendors who have recently changed or adjusted their licensing model

Perform Preaudit Planning

Now that the risk factors have been identified (figure 3), they should be evaluated to determine their significance. Conducting a risk assessment is critical in setting the final scope of a risk-based audit.⁶ The more significant the risk, the greater the need for assurance.

The assurances considerations for software licensing can be grouped by borrowing the functions from the US National Institute for Standards and Technology (NIST) Cybersecurity Framework (CSF):⁷

• Identify—Is there a central register detailing the software license entitlements? Does the enterprise record and know the costs of the licenses?
• Protect—Does a policy exist for software licensing? Are all licenses centrally authorized? Is all other software strictly forbidden?
• Detect—Is there a need for continuous and periodic monitoring?
• Respond—Are the results of the periodic monitoring reported to senior management?
• Recover—Are corrective actions in place?

Finally, the auditee should be interviewed to inquire about activities or areas of concern that should be included in the scope of the engagement. Once the subject, objective and scope are defined, the audit team can identify the resources that will be needed to perform the audit work.⁸

Determine Audit Procedures and Steps for Data Gathering

At this stage of the audit process, the audit team should have enough information to identify and select the audit approach or strategy and start developing the audit program.⁹ There is now enough information to decide what documents are expected for review, what licenses apply, the criteria and whom is going to be interviewed. However, the testing steps need to be defined.

In previous columns, at this stage, I have introduced an ISACA audit/assurance program and documented how the assurance considerations map to audit testing steps. However, ISACA currently has no specific audit/assurance program for software licensing (although the COBIT-related Build, Acquire, Implement [BAI] BAI09 Manage Assets Audit/Assurance Program¹⁰ does provide some coverage and is worth consulting). I, therefore, propose to map the assurance considerations directly to high-level control tests (figure 4). I am asking that readers collaborate by adding any missing control tests or observations in the comments section.

Conclusion

The fact that I author this column does not, by any means, mean that I have a monopoly on audit experience. I am certain that I have missed something that others have come across, besides which the editor is hawkish on the space allocated to me. I am, therefore, asking all readers to collaborate by adding their thoughts to the comments section. I hope that this is the first of many such partnerships and that this will become the de facto audit/program for software licenses. Alone we can do so little; together we can do so much.¹¹

Endnotes

¹ ISACA Engage, Audit and Assurance, https://engage.isaca.org/communities/community-home/digestviewer?communitykey=b4f0c214-8b78-4359-8bd0-8f0e7382b68a&tab=digestviewer
² Cooke, I.; “Audit Programs,” ISACA Journal, vol. 4, 2017, https://www.isaca.org/resources/isaca-journal/issues
³ Cooke, I.; “Innovation in the IT Audit Process,” ISACA Journal, vol. 2, 2018, https://www.isaca.org/resources/isaca-journal/issues
⁴ Op cit Cooke, “Audit Programs”
⁵ ISACA, Information Systems Auditing: Tools and Techniques, Creating Audit Programs, USA, 2016
⁶ ISACA, Audit Plan Activities: Step-By-Step, USA, 2016
⁷ National Institute for Standards and Technology, Framework for Improving Critical Infrastructure Cybersecurity, USA, 2018, https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf
⁸ Op cit Audit Plan Activities: Step-By-Step
⁹ Ibid.
¹⁰ ISACA, BAI09 Manage Assets Audit/Assurance Program, USA, 201
¹¹ Quote Investigator, Helen Keller, https://quoteinvestigator.com/2014/04/21/together/