self-audit

Before A Software License Audit, Self-Audit

By Kim Addington, COO, NPI

The disruption of the last 18 months has done little to slow down the pace of software license audits. As customers embark on bold transformation initiatives, vendors are finding ripe territory to uncover noncompliance issues in legacy software estates. That cloud project with Microsoft, Oracle, or SAP can quickly turn into an opportunity for these vendors (and others) to sniff out compliance shortfalls.

The likelihood your business will undergo at least one major IT vendor audit in the near future is high.  If you’ve received an official audit request from your vendor – or suspect you’ll receive one soon – it’s imperative you conduct an internal self-audit before vendors initiate their process.

At a minimum, the self-audit should involve the following activities:

  • Establish a formal license position. First, develop an accurate record of deployments. Then compare that to license entitlements to identify gaps. Be sure to include a vendor-specific licensing expert This requires a PhD in product use rights for each vendor as they are ground zero for non-compliance. Product use rights are complex, confusing (often intentionally) and are subject to change at any time.
  • Review and clarification of audit rights. Audit rights specify how much time a company has to respond to a formal audit request, which vendor resources are authorized to audit, what tools will be used, what data has to be provided (and how soon) and how arbitration will be handled. By fully understanding audit rights prior to an official audit, companies can model their self-audit using the same rules of engagement that the vendor will use.
  • In the event of non-compliance, development of a remediation plan defining how compliance will be achieved. If material noncompliance is discovered during a self-audit, companies need to develop a remediation plan that takes into account their current and future software needs. Remediation can take many forms – tuning virtualization strategy, changing servers to avoid certain size “taxes,” making simple changes to eliminate unnecessary access, changing usage for certain constituencies, adopting different license types that are a better match for actual usage or, if no other alternative is practical, purchase additional licenses. Even if the outcome of a self-audit is the requirement to purchase licenses, companies that follow this best practice have the ability to work through the funding challenges on their own cadence.

Top Culprits For Noncompliance

For the most part, noncompliance is unintentional, and very few enterprises knowingly engage in noncompliant license use. The seven most common reasons for falling out of compliance are:

  • You bought software for one reason, now you use it for another. Certain license types, such as limited use licenses, can only be used in non-production environments like development, testing or failover. Companies often purchase these licenses over full use licenses to obtain a pricing discount. Then, months or years later they discover their limited use licenses are being used for production use purposes such as internal data processing operations.
  • No one told you the product use rights changed. Product use rights can change at any time, and the rate of change is growing among larger IT vendors. For example, during recent contract negotiations and audits, SAP and Oracle are asking some clients to purchase additional licenses for third-party application access. A business with 100 Salesforce.com licenses that needs to access information from SAP may now be required to buy 100 additional licenses. It’s only been in the last few years that the vendors have begun to interpret “indirect access” this way and attempted to enforce it with clients.
  • Your definition is different from the vendor’s. Licensing programs and definitions have changed dramatically over the last several years. What constitutes a qualified user or device (Microsoft)? What about a concurrent user or a floating user (IBM)? What’s the difference between an application-specific full use license or an embedded software license (Oracle)? Any misinterpretation can unwittingly throw a customer out of compliance.

CLICK HERE TO KEEP READING….