“Escrowing software is a lot like creating a prenuptial agreement before you get married. You hope you never need it, but if worse comes to worst, you want to be prepared. Escrowing software protects your company in the event that your relationship with your vendor takes a sour turn.” – Software Escrow for Dummies
This post will cover some of the steps you can take in advance to make sure nothing is missing from your escrow account. It is the last in a three-part blog series. In part one, I introduced a process to evaluate your existing escrow agreement to see if it is still needed (Step 1) and if your release conditions should be updated (Step 2). In part two, I introduced the importance of reviewing the escrow account to ensure it is being managed properly, in terms of both the designated contact (Step 3) and deposit activity (Step 4). Here, we’ll talk about escrow verification and completing the escrow deposit questionnaire.
Step 5: Be Proactive with Verification
Escrow verification services are used to validate the completeness, accuracy, and functionality of the vendor’s deposits of software source code or other technology with a neutral third party, such as Iron Mountain. This critical audit of the technology and the deposit materials help to ensure that you can read, re-create, and maintain the developer’s technology if necessary.
As a beneficiary of the agreement, if you don’t verify your vendor’s escrow deposit, there is no way of knowing if the intellectual property deposited will be complete and functional when you need it – such as if the vendor disappears, or stops supporting your software – and then, it’s too late. Most of the issues that we find with intellectual property submitted into escrow include data that are incomplete, unusable, encrypted and/or unreadable. That’s why Iron Mountain recommends creating a schedule for verifying your escrow deposit on an annual basis or during major releases of system features and functionality. There are four levels of escrow verification that can complement your software escrow arrangement, and will help verify all the pieces of your escrow deposit will work together when needed.
Beneficiary Responsibilities: There are two critical areas of an escrow agreement that are constantly overlooked in a Standard Three-Party Agreement related to deposits and verification:
- Section 3(b): “It shall be solely the Beneficiary’s responsibility to monitor whether a deposit or deposit update has been accepted by Iron Mountain”
- Section 5(a): “…Upon request by Iron Mountain and in support of Beneficiary’s request for verification services, Depositor shall promptly complete and return an escrow deposit questionnaire and reasonably cooperate with Iron Mountain by providing reasonable access to its technical personnel whenever reasonably necessary”
In my last post, we reviewed the benefits of the Escrow Management Center. Another added benefit of this online portal is deposit tracking/notification. This feature allows users to set reminders for deposits that they are expecting from their vendor. It’s critical to set these reminders at the desired frequency to avoid missing scheduled updates to the system and to ensure all the development activities run parallel to your escrow account. If your vendor is non-compliant with updating the agreed upon escrow account, Iron Mountain recommends that you contact your attorney immediately in order to rectify the situation. Although Iron Mountain is the global leader when it comes to information management and protection, we do not have the authority to enforce any escrow responsibilities onto either party.
Step 6: Avoid an Incomplete Deposit by Asking the Right Questions
One of my strongest recommendations for every escrow arrangement will always be for the software developer to update your escrow deposit questionnaire on an annual basis. By completing the deposit questionnaire, you can help ensure that nothing is overlooked in the deposit process.
The questionnaire covers three main areas of source code deposits, and these are some of the questions that are asked:
- General Description: What is the general function of the software and what media will the source code be delivered in, along with the total uncompressed size of the deposit in megabytes?
- Requirements for the assembly of the deposit: Describe the nature of the source code in the deposit (interpreted code, compiled source or a mixture). How many build processes are there and how many unique build environments are required?
- Requirements for the execution of the software protected by the deposit: What are the system hardware requirements to successfully execute the software (memory, disk space, etc.) and what is the minimum number of machines required to completely set up the software sufficiently to support testing?
Technology is constantly changing, so the answers to this questionnaire will change over time. The vendor should get into the habit of updating this information and submitting the completed questionnaire into escrow for safe keeping. Since the information on this document really isn’t that intrusive, the developer should feel comfortable sharing/reviewing this information with their customer, the software licensee, on a regular basis. This process will help to ensure that both parties are aware of the “moving parts.” It helps guide the relationship in the direction it was originally intended – to mitigate risk if the unforeseen happens.
I hope this blog series will help you determine your need for source code escrow, accountability for the escrow agreement, and how to determine if anything is missing from your escrow deposit.