What REALLY Happens During an Audit (Part 2 of 3)

Audits

What REALLY Happens During an Audit (Part 2 of 3)

This is part two of a three part series. Read the first part here.

This article has been contributed by Kylie Fowler. Regular columnist and Analyst at The ITAM Review.

Data Gathering

On the face of it, an audit is simple. You establish what is deployed on your estate, you establish what you own and then you compare the two to determine whether there is a shortfall.

Software companies don’t care that much about instances where surplus licenses have been purchased because you can’t generally ask for a refund. Shortfalls are what they are concerned about!

Licensing being licensing, getting accurate data for both the deployment and entitlement sides of the equation can be fraught with difficulty.

Reporting Deployment

The highest priority for your auditor will be to obtain a complete set of deployment data as soon as possible because it is the easiest data for a company to manipulate. If a vendor suspects that there has been deliberate fraud or breach of copyright, they are more likely to ask that you use their own tool or engage a 3^rd party to carry out the audit, but if they are auditing you because your company has been identified as being in a high risk category (e.g. you are acquisitive) they are much more likely to allow you to provide your own discovery data as it is much quicker.

For any Software Asset Manager, the cardinal rule in an audit is transparency. Work with the auditor to produce accurate deployment data as quickly as possible.  The brutal reality is that if software has been deployed on machines, you should have a license for it. You should NEVER manipulate deployment data or try and cover up installs. It’s your job to make sure the data supplied is accurate.

Even the best-run SAM programme will need to do some basic checks on the data before they hand it over to the auditor.

In particular, the following checks are recommended:

• Is the data up to date – for instance, does it include deployments from desktops or laptops that have been disposed of but not deleted in the deployment tool? Or virtual machines that have been shut down but not deleted?
• Is the deployment tool interpreting data correctly and identifying licensable applications accurately? Ideally you should sample a set of machines for accuracy before sending the data to the vendor, particularly if the audit is from a niche vendor rather than Microsoft or Adobe. You should do this even if using a vendor supplied tool as these can and do produce anomalous results.
• Is the deployment / configuration data for servers accurate? Have you missed any servers? What about virtual machines?
• Is the data internally consistent? This is particularly important when providing data for virtual machines where you will need to provide information about where the VM is hosted as well as for the VM itself. You may also find that hard drive swap-outs may accidentally duplicate records in some discovery tools if processes are not followed carefully.
• Does the data provide clarity about how you manage CALs and other non-discoverable licenses? If not, what else do you need to provide (e.g. information from Active Directory or HR) to ensure the vendor can calculate deployment accurately – but beware data protection regulations which strictly limit what can be done with data that can identify particular individuals!

Obtaining deployment data for vendors of non-desktop applications, for instance Oracle or IBM, can be particularly challenging. Often the configuration management records are not as accurate or up to date as they could be, and they will often only cover production systems and ignore deployments used for development, testing or evaluation. As a Software Asset Manager it is your responsibility to obtain accurate data, and if you feel some areas of the IT Department are being obstructive, not helpful or not taking the audit seriously you should escalate to internal management immediately. Your company’s reputation for integrity is on the line during an audit and senior management need to recognise this and encourage appropriate behaviour from their staff.

What happens if you just can’t get accurate data? What if records are so poor, staff so obstructive and senior management so disengaged that you just can’t get the data you need and it is full of holes and internal inconsistencies.

Hand over what you can to the auditor and they will identify the holes and internal inconsistencies themselves. They will be very familiar with what the data SHOULD look like and will have their own internal validation processes to confirm the data looks complete. If they are not happy with the quality of the data they will escalate the issues internally, and request a meeting with senior IT management to raise their concerns or in extreme cases take some form of legal action.

Is this necessarily a bad thing?

For the company? Yes.

For you as a Software Asset Manager? Not necessarily – there is nothing better than an audit being escalated or the threat of legal action to make senior management take an audit, and indeed SAM itself, seriously. It may mean you get the support you need to carry out the audit properly and the resources to do SAM better in future.

Reporting Entitlement

On the face of it entitlement should be fairly straight forward – after all, entitlement is generally obtained through the purchase of a license which means there should be plenty of financial records available to provide evidence of purchases. In most countries, companies are required to keep financial records for 5 – 10 years for tax purposes, so the records must be there somewhere. Of course, getting hold of them can be challenging as there is often more than one financial system (particularly for large or acquisitive companies) and when financial systems are upgraded the old data is often mothballed rather than being transferred to the new system. This means it can be a challenge to obtain purchase records, particularly if the staff who knew how to use the old system have left the company.

Sometimes you even need financial records that go back further than the statutory retention period  – for instance to find base licenses for upgrades. Other entitlement may have been obtained through non-financial means – for instance a promotion (‘buy this type of license and we’ll upgrade it for free’) or because the vendor has made a fundamental change to the license type and will cross-grade certain customers for free. Unless you have had good SAM for 10 – 15 years then confirming this sort of entitlement can be a matter of luck as much as anything.

Where a volume licensing agreement is in place vendors will often be able to produce a report showing entitlement. Although helpful, this should NEVER be taken at face value, but should be validated internally to ensure accuracy. In particular, you should check:

• The list of legal / purchasing entities included in the report is accurate
• The volume licensing agreements included in the report are accurate
• There are no obvious gaps – check there is a consistent purchase history for each product that matches what you would expect to see in your business
• Are the support and maintenance records accurate (support can have a dramatic effect on entitlement) and have they been applied to base licenses correctly?
• Have upgrade licenses been identified and applied to base licenses correctly?

Small companies (and some not so small ones!) sometimes have a lot of fully packaged or box product. This is often the case where there have been a lot of acquisitions, or the vendor is not seen as strategic so no volume licensing agreements are in place. In theory the auditor should examine each box to ensure it’s not fraudulent, but in practice they will often accept a list of serial numbers which are then matched against their internal database to determine whether the serial numbers are fraudulent. Vendors often choose to do this because a physical audit of box product is extremely time-consuming and costly, however it does expose you to the risk that their database isn’t accurate and shows the box product as being educational or charitable product when it is nothing of the sort.

If identifying entitlement is particularly challenging, then it can be helpful to work with resellers to identify purchases. However where procurement is decentralised and there are many resellers, this method is not foolproof either, and leads to the problem of de-duplicating the data. In general it is best to use one definitive data source for entitlement data but use other complementary data sources to validate the main source for accuracy. You can then use a secondary data source to fill in the gaps as long as it is clear that you are not duplicating entitlement.

If you have decentralised procurement, or are an acquisitive organisation that has ‘inherited’ licenses as a result of corporate takeovers, obtaining a full picture of entitlement can be particularly challenging. It is extremely difficult for people to estimate whether they have correctly identified all entitlement until it is put into context by being compared with deployments through the reconciliation process. Although it is frustrating for auditors, it is vital that organisations in this position have the chance to revisit entitlement after the reconciliation has taken place.

Part Three: Reconciliation and Settlement will follow shortly.

Can’t find what you’re looking for?