Essay: Software audits – notes and guidelines

1. Background

Software audits will come in many different forms and each audit will be different.

There is no standard process for conducting audits, however below are some of the guidelines I use and lessons I have learnt over the past 20 years. Some of these you will skip depending on the size and type of audit.

Most need to be followed but this document is intended to be used as a useful guideline and for avoiding any major pitfalls.

2. Initial Contact

The initial contact will vary but beware of any vendor using the words “SAM assessment, SAM review, license verification, maturity review, software licence review, self-audit “. Sometimes the software vendor will contact you with a “We can help you or we can save you money” – any contact of this type is an AUDIT regardless of the pretty words!

Be careful of “friendly” reviews that assess how well a customer is managing its software. These again are often audits. If the publisher finds unlicensed software, this will turn into an audit. This may be a fishing expedition but how you handle it is critical – so treat all friendly overtures as an audit.

These come in via so many different means, addressed to the CIO, CFO, CEO, the Asset & Licence Manger, a technical contact, the list is endless.
As soon as you’ve received an initial letter or email from the software auditor or vendor:

• Designate an internal single-point-of-contact (SPOC) for the auditor–and no one other than the SPOC should communicate with the auditor at any time during the audit. This ensures that there is no miscommunication.
• Check if they have the right to audit. Usually this is noted in any licence agreements.
• Understand the terms of the audit. Another important step as this will specifically give you details of our rights and obligations. It is important that we understand these terms to ensure our rights are protected and that the right level of information is tailored to any questions.
• Always inform your Legal team. Based on legal advice, either prepare your reply or carry on regardless.
• Put an NDA in place. Whilst there is normally a generic NDA, I would recommend an NDA is tailored to each individual audit. Also consider whether we can send data to a 3rd party, will there be any personal data, off shore etc. Again in my experience, this won’t get sorted overnight and legal will take their time. No information should be disclosed without this in place. (Which is useful as you can use that time to do prep work)

NB: You may undertake an initial kick off meeting but nothing specific can be confirmed until after NDA is in place.

• Perform an initial SWOT analysis of the publisher’s software within our IT estate. Does the audit letter indicate any boundaries (this could play to our advantage if an area is out of scope). Are they auditing one specific Company or that Company and its subsidiaries.
• Identify the relevant stake holders in IT (to include legal). Conduct an internal meeting to build our strategy. A disconnect between these teams leads to a long and tedious audit process that drains time and resources. Experienced IT resources should be provided to work with the IT Asset & Licence team during the data collection phase.
• Inform senior management of an impending audit, including a summary of SWOT
• Consider any major projects or technology\infrastructure improvements that are taking place.
• Who will be undertaking the audit? If 3rd party, is there anything in the contact or licence agreement about whether they can use a 3rd party firm? Consider any conflicts of interest. Do we have a previous experience of their audits – did they badly mess up before. Where will data be stored? Avoid sending data overseas, insist on audit data staying in the UK.

3. Next Response

• Contact the vendor and arrange a kick off meeting.
• Often we cannot buy any licenses of the publisher’s products until the audit is settled and we should also not try to remove software. This needs to be agreed at the kick of meeting. It is often to our advantage not to buy software from the publisher during an audit and can be used as part of negotiation at the end of an audit (if found to be uncompliant). But this can also go against us if say the publisher has a 3 year back maintenance clause.
• An external vendor audit can have a massive impact on your day-to-day job. Check the EULA, ‘disruption to the business’ is often found in EULA’s and it may be worth quoting that to delay an audit. I personally call out existing tasks that might be impacted by taking time out to complete the audit.
• I would also (where we can) offer to supply our own internal compliance reports in return for them not doing a complete disruptive audit. I think this can demonstrate to the publishers that we are compliant and it’s not worth their time\effort and cost to audit us and would not generate any additional income and that doing so would be unreasonable.
• Confirm the scope and products being audited? Limit the scope where you can. Also the scope may not align with the terms of the license agreement and may be over and above what has been agreed to – so this is one of the key areas where familiarity of the license agreement is going to critical.
• Agree what will constitute proof of licence? What constitutes an install of the software under audit?
• A schedule for auditing – accept theirs only if convenient; don’t be afraid to stipulate our own timescales (ensure reasonable however)
• If relevant, confirm that the third party can conduct the audit on behalf of the vendor.
• I would ask to limit the threshold period a 90-day period is good as it provides enough of a sample size to show how we have been operating. This needs to be done and accepted in writing at the kick off meeting and before any data is exchanged.
• Advise that data needs to be anonymized for server names and user names.
• Inform senior management of the precise audit schedule and scope
• Email entire IT department advising we are under audit and that they must not speak to the vendor. All communication must come through the SPOC.

4. Preparing for the Audit

• It is common practice for the auditor to give us a report of its purchasing history from the publisher. Always verify the auditor’s purchase report list. This is very often wrong and negatively impacts any audit outcome
• Collate all proofs of entitlement and verify against auditors purchase report list
• Schedule the installation and running of any scripts – making sure they only run on devices specified in the scope of the audit.
• Schedule any on-site audit (if required) If onsite audit, always chaperone your auditor or vendor.
• Schedule any weekly conference calls. If team conference calls, ensure that team are aware of the rules of engagement and don’t say anything that can be misconstrued. It is better to get Wincanton IT team in a conference room for conference calls (so you can get their attention if you need them to stop talking)

5. Conducting the Audit

• Don’t over share information – only provide what is necessary. There is no obligation to give a software vendor audit more information than they need. For example, only provide data where a product is installed or run. There is no obligation to give them any more than that. Be prepared for a battle and a couple of rounds of them demanding it. Ask them where in the contract this requirement exists. Often, in my experience, they will give in as they can’t answer this. But also be aware that the more you battle at this stage, the harder the entire audit may be. This is why it’s key to go through all of this at kick off stage.
• In the event of an audit, the way to manage this situation is to only give LMS the data relevant to where Oracle is/has actually installed or run. There is no obligation to give them any more than that, but you will go through at least half a dozen rounds of

1. Oracle saying they want all your VMware data and you are contractually obligated to provide it,
2. Customer asking where in the contract this obligation exists
3. Go to 1

In our experience eventually Oracle give in because they can’t actually answer point 2.

• Understand the role of the platform (dev/ test/ production etc.) in our IT estate.
• Always check any scripted reports for errors and always verify data before handing over to an auditor. For secure networks and\or sensitive data areas, you can refuse to run scripts.

THERE ARE ALWAYS ISSUE WITH THE DATA

These are the most common data issues that I’ve come across:

• Over-counting to include double counting of software installations,
• False positives & ghost installs
• Incomplete product names (e.g. missing editions)
• Wrong product name/edition (can make a massive difference on entitlement)
• Incorrectly counting cores and processors
• Trial software that is baked into a licenced install of a product suite

And for all the reasons above, never trust the auditor’s ELP report.

• Prepare a summary report for senior management and set expectations of potential liability. DO NOT DISCLOSE TO OTHER STAFF MEMBERS ONLY SENIOR\EXEC MANAGEMENT.

Potential liability is often way higher than actual liability and you will go through several reiterations of verification and negotiation before you reach a final version of the exposure. I have seen exposures of several million reduced to nothing after the negotiation\verification phase. Remember at this stage, this is just an indication of what the vendor thinks you have exposure for.

It is not helpful to have staff speculating over potential losses or worrying at this stage and can be detrimental to the Company.

6. Negotiation & Validation Preparation

The audit team will have an aim, to document that we are not compliant and that we need to spend a lot of money to become compliant. They often have targets like sales targets to reach, so it is to their advantage if you are uncompliant.

It is the software licence manager’s job to PROVE that the Company is compliant. Software auditors usually work under the concept of Guilty until proven innocent.

• You need to pour over our license Terms and Conditions to counter any potential claims by the auditor. SAM isn’t just about counting licences but also ensuring we are using the software as per the publisher’s terms.
• You will often find that auditors say one thing but our license terms will say another thing and the publisher’s legal team will say something else. I have successfully argued against initial findings using the publishers license terms.
• Always check the data and verify that their findings are correct.
• Ensure that platform usage is factored into audit findings
• Ask the auditor to validate the licence metric and interpretation of any shortfalls

7. Final Meeting & Negotiation

• Go into the final negotiation understanding what you are prepared to fight and what is not worth the time effort. What are legal prepared to do?
  An example, one vendor audit advised we had an exposure of £35k, this was negotiated \ challenged down to £3k. Whilst we felt that the final £3k was still not an “out of compliance” situation would have taken too much time, effort and cost to prove otherwise. We therefore settled by agreeing to buy new software from them (and not plug the gap) which was software we wanted\needed anyway.
• This stage is always up for negotiation; make a strong case and argue it.
• Come to an agreement on any fees due (if any) using all the data at your disposal.
• Each negotiation is different. Sometimes you can use the money towards updated software, some will demand you plug the compliance gap with licences. Some will ask you to rectify the estate and pay the licence fee\penalty. Some will ask for 3 years back maintenance, others may ask for 3.5 x licence prices or may ask you to pay list price. (Again check your license agreement to see what they can charge).
• You might be able to schedule an agreed payment plan. We are still their customer, so negotiate on terms here as well.
• Offer feedback on the how the audit was conducted and how the audit experience was for you – remember, you’re the customer.

8. Post Audit

In the event of an exposure, perform an RCA and distribute to senior management\Exec. Use this to improve SAM throughout the company.

Review audit and update this document as appropriate!

9. Additional Hints and Tips – somethings are worth repeating!

• Don’t bury your head in the sand – software auditors will make life awkward if you don’t respond in a timely manner and this can work against us.
• You need a strong will and nerves of steel!
• Don’t let the audit go beyond the agreed scope.
• You need to fully understand what information is being provided back to the publisher.
• Be friendly but be always be firm! All audits will start off nice and friendly, again in my experience it’s when the final ELP is produced that it turns really aggressive. So always be careful of what you say (even when they are being your friends) and don’t be afraid to stand your ground.
• Where possible, negotiate the right to not have an audit following renewal for X period of time. I have done this at settlement negotiation and have done at renewal or when purchasing large volumes of licences.
• Licensing isn’t just about counting numbers of licences and is only half of the equation. Licensing use-rights, terms and conditions are often the reason why Companies fall out of compliance.
• If there is a large exposure, I would highly recommend seeking assistance from a 3rd party with reputed license expertise. Software Asset Managers usually don’t specialize in one particular software vendor whereas a licence partner will have specific individuals that can provide advice.
• I have found that auditors will gloss over how much work is involved and will quote a short period that the audit will take, in my experience these rarely take a few weeks and I have seen Oracle audits take up to 2 years.
• Audit are all about winning and losing.

IMPORTANT NOTE

If you are imminently due to start any transformation projects, major infrastructure changes, etc. etc. that will change your IT environment then I would highly recommend that the audit is either delayed or all data is returned before the project is started.

If we can, we can offer our own data as evidence that we are compliant and ask if they will use this as a self- audit and delay the audit for a year or two.
In my experience, a large transformational project will actually attract auditors. This is a good time for them to audit as this when Companies go from compliance to non-compliance or when Companies go from non-compliance to compliance.

It is exceedingly difficult to back track on data after the estate has changed and get auditors to accept that they took a “snapshot” at a bad time. They won’t see it as a short period (sometimes just 1 day) where you were uncompliant but as a reason you need to buy more licences.

For example; server A is being decommissioned and Server B is replacing it but the auditors saw both during their snapshot – so both need to be licenced. Legally that is correct but realistically would you want to pay for a perpetual licence for 1 day only.

During one audit, the datacenter was flooded and this resulted in 100s of servers that were “switched off” and no longer active being switched back on inadvertently. (Also another reason why all data should be checked before being returned).

2018-9-19-1537356416