The importance of Internal Software Audits
As we are all aware, software audits are something that most organisations dread. Organisations can stay one step ahead of the BSA and FAST by conducting their own internal software audits.
Why should we audit ourselves?
There are a number of key reasons for completing internal software audits. The two main reasons for carrying out an internal audit are to reduce the number of inactive licenses and also to ensure that you are maximising your current license position. You could also add a third factor in there too, as an internal audit can help you reduce your under compliancy should you be in that position for certain applications. Internal software audits are also a cost saving method, as you will remove software from machines that no longer require it, thus reclaiming a license for future use.
Once you have implemented SAM within an organisation, software audits will become a process that can be scaled back. 90% of users do not need administrator rights on their machines, thus restricting their ability to download or install software. This will also reduce the number of trial or evaluation licenses that are installed on your estate. This is another reason why you should complete internal software audits as the majority of SAM tools can’t report what installations are actually trial licenses. By completing an audit you will be able to establish if anyone has downloaded a trial license, and then you can either remove the software from your estate or ask the user to provide business justification and a cost centre/budget for purchasing a license should they need it.
Software Audit Process
Document the process you use for internal software audits and promote the process to the users. It may be the case that you’ve never conducted an internal audit before, so talk to your IT staff and senior management highlighting why you want to create an internal Software Audit process. Conducting an internal software audit usually consists of 5 steps:
- Identify the application you wish to audit
- Use a usage tool to run a report on current usage within the organisation
Step 2:
- Analyse the report, identifying non-usage
- Arrange with the deployment or installation team for the removal of unused applications
- Create a report identifying the application, machine and date of audit
Step 3:
- Analyse the usage report again, highlighting any users that haven’t used the application for 60+ days (and example)
- Liaise with Team Leaders/Business Administrators/ Managers asking if their users still require the software, or if it was only use for a specific action or project
- Add the responses to your audit report, highlighting the justification for keeping the software
- Arrange with the deployment or installation team for the removal of applications no longer required
- Add to the audit report identifying the application, machine and date of audit
Step 4:
- Analyse the usage report again to ensure users are using the correct version/suite of the application (Is a user using a full suite, but only making use of one application that would be cheaper to purchase and maintain?)
- Liaise with Team Leaders/Business Administrators/ Managers asking if their users / they are happy with the changes to their suite/software
- Update audit report
Step 5:
- Run a new install report from SCCM or your SAM tool
- Establish updated compliancy figures
- Rectify any non-compliancy by purchasing new licenses, or recycling licenses recouped through the audit
- Identify the savings made through the audit
- Present the audit report to the Board
- Ask for 10% of all future audit savings! (Good luck with that one!)
I could go into a lot more detail and depth for an internal audit process, but you should get the general idea. The five steps above should give you a good base to work from when conducting an internal software audit and it should also help identify the key stages of the audit.
How often?
If you are after a dynamic SAM estate, then internal auditing should be a continuous process. However, again if resources are stretched then an internal audit of Tier 1 vendors should be carried out at least once a year. Other applications should also be audited once a year, but concentrate on the Tier 1 vendors first if time and resources are limited. Carrying out an internal audit for Microsoft, Adobe or IBM would be of more use to your organisation than regularly auditing WinZip for example.
If you don’t have a ‘locked down’ environment then keeping a record of the machines and users that you have removed a license from will help you in future audits. You are then also able to present these reports to the board, highlighting licenses reclaimed and potential savings made.
Internal software audits are an important and sometimes overlooked process within SAM. With the current audit mentality and vendors looking to reclaim money on any under-licenced software, conducting internal audits are a way for you to stay compliant and be one step ahead of auditors, so should an audit letter land on your desk you will be fully prepared and compliant.
Related articles:
- Tags: Adobe · IBM · internal audit · internal software · Microsoft · SAM · Software Audits
I would emphasize “Identify the savings”. It requires more work (track all the changes and express them as the money), but it helps you promote your work as SAM Manager and also identify ROI for the whole SAM project. And of course, everybody understands SAVINGS. 🙂
I’d start with a rebrand, to something like “Trial True-up”, “Annual Certification” or “Quarterly ELP”. Audit has many negative connotations which is why the word is rarely used in vendor communications.
When it comes to any internal project (which this should be treated as), don’t try to cover everything in one go. Focus on one vendor a quarter, in order of spend or compliance risk, and get that to a high quality.
You’ll most certainly identify savings which will feed into the business case for the next SAM project. This can become a continuous cycle with each project potentially building on the results of the last but they are separate project none the less.
Is it smart to rebrand it Piaras? Internal Audit is a phrase organizations are familiar with a carries a bit of weight. Perhaps you don’t want to rename it and run the risk of it not being taken seriously?
I think it depends on organization. Audit is quite strong word, which can be (dis)advantage. Organizations perform some kind of Internal Audit, so you may just add software audit to this already established practice.