High-Level Data-Collection Strategies for Software Audits
In our experience, many companies facing software-licensing audits initiated by vendors like Microsoft, Oracle or IBM seem to be under the impression that auditors have a nearly unfettered right to information. This is not the case. However, too many audit targets discover too late that what may have seemed like good-faith cooperation in the interest of currying favor or “being nice” ends up leading to material, unbudgeted exposure from increased licensing costs and/or audit penalties.
While most software vendors would be loath to admit it, few license agreements actually convey carte blanche when it comes to data-collection and disclosure obligations related to audits. Below are some critical points to keep in mind when engaging with software auditors (regardless of whether those auditors are a vendor’s “in house” team members or a hired firm, like KPMG, Deloitte, E&Y or PwC):
1. Tools – Most software audits require at least some kind of hardware- and software-discovery requirement, and that task usually is accomplished via a software asset management (SAM) or other data-collection tool. Auditors typically prefer the use of their own, proprietary tools or processes, and many will identify those tools on their lists of data-collection action items, sometimes without identifying any alternatives.
The problem with those tools is that they often are optimized to generate outputs that can be easily digested by other tools used by the auditors. Those outputs may not be easy for the audited company to review, making it difficult to vet them and to predict how the auditors may interpret them. Those outputs also may contain information that is irrelevant to a company’s licensing obligations and, therefore, that is outside the scope of the audit.
However, while there are exceptions, it is relatively rare for software license agreements to obligate licensees to use particular tools or processes to gather information during audits. In most cases, license agreements instead require only reasonable cooperation and/or timely delivery of information relevant to a company’s license position. A company therefore needs to carefully review all applicable license agreements at the outset of an audit in order to set expectations for exactly what it is contractually required in connection with that review. If auditors insist on the use of a tool that is not required by those agreements, then one approach would be for the audited company to insist that the auditors accept any and all risk of liability or loss associated with the use of that tool in the company’s environment (which the auditors likely would refuse to do). Alternatively, the company could consider simply refusing to run the auditors’ tool, provided that a suitable substitute can be identified and proposed.
Remember that a key strategic requirement in all audits control over the flow of information. If the use of an auditor-preferred tool would compromise that requirement, then we typically advise our clients to pursue alternatives.
2. Timing – From the outset of most reviews, auditors will seek to get audited companies to “consent” to arbitrary timelines for reaching various milestones in the audit process. These timelines typically are formulated unilaterally between the auditors and the software publishers that hired them, and they are designed to provide predictability for the publisher. The timelines typically have little, if any, relationship to the realities figuring out how to allocate resources to auditors’ often voluminous requests for information.
Fortunately, auditors’ timelines also typically have little, if any, relationship to contractual obligations in license agreements. Again, most such agreements require only reasonable and/or timely cooperation, and they do not impose any set period of time to provide information responsive to auditors’ requests. Furthermore, most such agreements also incorporate assurances that audits will not interfere unreasonably with audit companies’ business operations.
We typically recommend that our clients resist the urge to agree to any audit timelines, especially at the outset of a review. In the vast majority of audits, it simply is not possible for most companies to hit the timing targets in audit project plans, and many publishers will not hesitate to reference those kinds of incremental failures during negotiations to resolve audit findings. Our preferred approach is to acknowledge proposed timelines, but to be explicit about not making any promises to adhere to them. Where auditors or publishers persist in seeking to apply those kinds of expectations, it is better to promise only diligent effort and regular updates, always subject to the priority of a company’s critical business operations. In our experience, most auditors will (perhaps begrudgingly) accept those kinds of assurances.
3. Volume of Requests – Finally, at the outsets of most engagements, auditors will describe an audit process that appears to be fairly well organized and segmented, with the goal of defining various, discrete steps to be followed in advance of closing out a review. However, in practice, that kind of structure can break down when applied to the sometimes messy and disorganized realities of software asset management, especially within organization that may not have implemented mature, internal SAM processes in advance of a review. Consequently, one set of requests from the auditors can yield one after another set of follow-up or supplemental requests, like a never-ending series of (very expensive) Russian nesting dolls.
While some such requests may be legitimate and reasonable, depending on the fulsomeness of an audited company’s prior disclosures, in many cases these kinds of serial follow-ups may comprise little more than fishing expeditions. Audited companies always need to remain mindful of any “unreasonable burden” language appearing in their license agreements (as noted above), and to be prepared to reference it when it appears that the auditors are dragging their feet toward a conclusion. At a certain point, it may make sense to simply refuse to provide more information and to insist that the auditors proceed with preparation of a draft audit report. If the auditors agree, then any true information gaps can be revealed and discussed as the company works to vet the draft report. If the auditors do not agree, then the audited company can address its concerns to the publisher and, at a bare minimum, set expectations that further inefficiencies could have a negative impact on the company’s relationship with the publisher.
We regularly work with our clients to address these kinds of concerns in the context of software audits, and we encourage all companies to be mindful of them in responding to audit-related information requests.
