Key Components of Software Audit Response Policies

Software audits are significant legal and financial risks for all companies. With more and more software publishers utilizing intrusive audits and other information-gathering exercises as the basis for licensing transactions and – more troublingly – as sources of revenue through compliance-enforcement actions, more of our clients are implementing detailed policies to define whether and how to respond to such matters. Here are some of the key topics that all such policies should address:

• Who? (Software Audit Response Teams) – One of the key benefits of a software-audit response policy is a clear specification of which team members will be responsible for responding to inquiries from software publishers (and their representatives). Confusion as to staffing on audit responses is among the greatest challenges and sources of risk that businesses face in all audit matters. Many publishers are expert at gathering information from multiple sources within an organization, and companies that are unprepared for this often see certain team members’ statements and actions used against those companies’ interests by publishers’ compliance teams. Controlling the flow of information therefore is key, and the first step to accomplishing that goal is clearly an unambiguously designating a core team for receiving, evaluating, and responding to all inquiries that could entail any level of risk to the company. Those teams typically consist of members from companies’ legal, IT and procurement organizations.
• Why? (Applicable Contractual Obligations) – Far too many companies make the mistake of simply responding to information requests from software publishers, without responding team members giving sufficient, substantive thought to whether those publishers have any right to that information and to whether that information may entail risk. It is important to keep in mind that such risk can arise both from compromised leverage during commercial negotiations as well as (more significantly) from usage of software products outside the scope of applicable licenses. Therefore, one of the first steps that all software-audit response teams must take is a careful evaluation of the information requests against any software-audit or other compliance-verification terms in those license agreements. Where such requests exceed the scope of the publishers’ rights, companies need to determine whether there is any strategic benefit in providing the information, or whether it makes more sense to politely decline the invitation to share that information.
• What (and Where)? (Audit Scope) – Never undertake any third-party audit (pertaining to software licensing or, really, any other subject) without a clear understanding at the outset of the scope of the review. Software auditors in particular are notorious for expanding the scope of their reviews, and the absence of an agreement as to scope can result in significant, incremental risk to audited companies. The scope of a software audit encompasses several different factors, including: (a) what legal entities are to be audited (this can be an especially crucial question when a company’s legal affiliates use software under that company’s licenses), (b) what geographic regions are to be audited, and (c) what software products are to be audited. The software audit response team must ensure that all of those factors align with a publisher’s audit rights, and they also need to conduct a preliminary, internal review to determine whether any of those factors may have a significant impact on the overall risk associated with a matter.
• When? (Audit Pacing) – Closely related to the need to control the scope of an audit is the need to control the pace of the audit. Third-party auditors typically are under instructions to move audits forward at a pace that charitably could be characterized as “brisk” and that, for many companies, is simply unreasonable. Auditors need to hear early and often that an audited company is not in the business of predicting the future, and that while the software audit response team will work diligently and in good faith to provide information within the scope of a company’s obligation to do so, it cannot commit to meet any arbitrary deadlines for data collection. In addition, no information at all should proceed until an audited company has confirmed that such information is subject to appropriate confidentiality and non-disclosure obligations. In some cases, applicable license agreements may contain language that publishers would identify as protecting audit data. However, third-party audit-services firms like Deloitte and KPMG are not parties to those agreements, and most such firms are willing to negotiate independent non-disclosure agreements at the outsets of their audit engagements. The negotiation and execution of such agreements should be considered a prerequisite to moving forward with the auditors’ proposed timelines.
• How? (Data Collection) – Finally, software audit policies need to address the subject of how audit information is to be collected. In most audit matters, the auditors will have a set of scripts, queries or other data-collection requests that they prefer. However, in many such instances, the outputs from those tools may not be easy for audited companies to read and interpret before sharing them with the auditors. In others, it can be unclear as to how those tools operate and whether they may entail any data-security or system performance risks. Therefore, software audit response teams should be prepared to push for the utilization of their own, preferred data-collection strategies in lieu of those proposed by the auditors. In some cases, applicable license agreements may identify specific reports or other information to be provided during an audit (outputs from IBM’s License Metric Tool are a prevalent example). However, such language is relatively uncommon, and provided that a company’s preferred data-collection strategy will result in all of the information required to validate compliance, most auditors are willing to be flexible with regard to how information is to be gathered.

Thorough audit-response policies also often address other “Hows” that occur at the end of an audit, specifically how audit findings are vetted and how any licensing shortfalls are to be resolved.

Companies that lack strong, internal policies for responding to software audits and related information requests should assume that they are at a competitive disadvantage, relative to their peers in their industries. Companies that are better equipped to respond to such inquiries are better equipped to mitigate and sometimes avoid the significant risks that software license-compliance obligations can produce, thereby freeing resources for core business priorities. Companies without such plans therefore are well advised to engage with licensing consultants and knowledgeable legal counsel to formulate and implement such plans.