From the key products and services offered to their customers to critical back-office functions like accounting and regulatory reporting, financial institutions rely on licensed software to perform many of their most important functions. But what happens when a vendor seeks to conduct an audit of the financial institution’s use of the software it licenses to the financial institution? We canvass best practices for responding to audits to prevent business disruption, avoid conflict and strengthen vendor relationships.
Companies typically license the right to use software, rather than create their own. As a result, most companies have entered into hundreds, if not thousands, of software license agreements with the vendors that own the software. These agreements dictate the terms of the license, including how many individuals can use the software, any specific restrictions on how it is to be used, the length of the license term, and other rights. Often, these agreements will give vendors the right to conduct an “audit” or a “compliance review” of the licensee’s software use. Through an audit, the vendor looks to determine whether the institution is using the software in accordance with the agreement.
Receiving an audit notice does not necessarily mean trouble. Vendors perform audits for many reasons, including performing routine compliance checks. But vendors may also use audit rights when they suspect the customer is in breach of the terms of the license (for example, using more copies of the software than licensed), to recoup license fees it believes it is owed or to create leverage over the customer. This is particularly common when renewals are coming up in the short term.
Financial institutions should be ready to respond to an audit before even receiving the notice. This starts with an internal tracking system of what its rights are under each license, and regular monitoring to ensure compliance. This prevents the institution from exceeding its rights under the license.
After receiving the audit notice, institutions should take two steps—scrutinize the request and investigate the facts:
Legal should review the original license agreement and see whether it permits the audit that is being sought. Because the audit request cannot exceed the scope of the vendor’s audit rights, the agreement may provide a basis to resist or refuse certain aspects of the audit. For example, some audit rights are time-limited, contract-limited, software-limited, or have limits on geography (e.g., is the vendor coming on site?) and how the audit is to be conducted (e.g., is the vendor touching your systems?)
After scrutinizing the request, institutions should work with the vendor to clarify and confirm the information that the vendor is seeking. These discussions may provide an opportunity to limit parts of the audit or to agree on other terms (such as confidentiality and timing).
Once the scope of the audit is clear, the next step is to gather a team to investigate the software use before the audit is conducted. Institutions should work with their legal advisors to best protect privilege over this internal investigation. The audit creates the spectre of litigation, but clients should not assume that the pre-audit period will be covered by litigation privilege.
Audits raise complicated legal and technical questions that must be analyzed through multiple lenses. For example, potential overuse may depend on how an individual user is defined and counted under the license agreement. This may turn on both the interpretation of the license agreement and the specific facts of the use, such as the location of the user and whether the use was in a production environment. Answering these difficult questions requires careful analysis, legal input, and fact finding. The investigation team should also consider whether the institution has other license agreements with the same vendor that may be relied on to support usage.
After the investigation team has addressed any legal questions and collected, examined, and verified the data, it must decide whether there has been a breach of the software license. The institution’s response to the audit will depend on this conclusion.
If the team determines that there has been no overage or misuse, they should prepare a response setting out its findings and the basis for this determination. The institution may then decide to share this report with the vendor and offer to address any questions that the software vendor may have in an effort to avoid the time and effort of both parties to complete the audit.
But if the investigation team concludes that there has been an overage, the institution must consider how to work towards a resolution with the software vendor. Audits can be delayed but ultimately not avoided if the contract provides for them. The institution and its (internal or external) legal team will need to work on a strategy to ultimately resolve the issue. Vendors often take a hard line because they believe they have leverage and perceive overages to be a threat to their business. But that leverage only works in the short term. In the long term, the institution can decide between different vendors. This leaves it with more options—and more negotiating leverage—than might be immediately apparent when the results of the audit come in.
To discuss these issues, please contact the author(s).
This publication is a general discussion of certain legal and related developments and should not be relied upon as legal advice. If you require legal advice, we would be pleased to discuss the issues in this publication with you, in the context of your particular circumstances.
For permission to republish this or any other publication, contact Janelle Weed.
© 2025 by Torys LLP.
All rights reserved.