Most sourcing managers have never heard of software or source code escrow; so, the idea of managing an escrow relationship may be a bit intimidating. This post will walk you through issues that may arise if you gain responsibility for an escrow agreement but are unsure of what you need to do.

Let’s pretend you just inherited the responsibility for managing an escrow agreement that was established years before you joined the organization. One of your responsibilities is managing the relationship with a vendor that provides a mission-critical application. You understand the application’s use and the development cycle for future releases/updates. You have a great relationship with the vendor’s executive team and whenever there’s a problem, the vendor is very responsive. However, one day you receive a phone call from your escrow provider, and they inform you that your escrow account has not received a deposit in over twelve months. What does that even mean? Is there a problem? Do you need to contact the vendor? If so, what does the vendor have to do?

Have no fear, you came to the right place…

The first step is to review the escrow contract. Each party on the agreement has a list of responsibilities — the depositor (also known as the software developer or vendor), the beneficiary (your organization, the user of the software), and the escrow provider (such as Iron Mountain). The depositor is responsible for providing all proprietary technology and any other materials covered under the business agreement.

Depositor’s responsibilities typically include:

  1. Submit all proprietary technology and any materials covered under the business agreement (“deposit material”) within 30 days of the execution of the escrow contract.
  2. Provide all of the information on the updates to the software into the escrow account during the term of the business relationship.
  3. A minimum of one complete copy of the software application must be in the escrow account at all times.
  4. Depositor must include an accurate and complete description of all deposit material submitted into the escrow account.

Technology is constantly changing, which is why Iron Mountain recommends a regular deposit schedule even if there isn’t a new version of the software. Most applications require ongoing bug fixes and maintenance in order to keep the application functional. “Minor” changes add up to a major change to the source code, and if you’re not receiving at least two escrow deposits each year, I suggest you create a schedule immediately, so the depositor is held accountable.

Beneficiary’s responsibilities typically include:

  1. The beneficiary will act on communication from the third-party provider and will keep contact information up-to-date and current for their designated contact.
  2. The beneficiary understands that beyond the visual inspection of the deposit materials by the escrow agent, there is no confirmation that the escrow deposit is in fact what the depositor reps and warrants unless escrow verification services are elected.

At the end of the day, it’s solely the beneficiary’s responsibility to monitor whether a deposit or deposit update has been received by the escrow provider. Iron Mountain provides an online Escrow Management Center portal for setting reminders and alerts for escrow deposits. The condition of the escrow account depends on the management of the escrow process. As a neutral third party, it is difficult for the escrow agent to know what version of the software is running on-premises or in the cloud. The interaction with the escrow agent, its communications, and alerts, are critical to making sure the escrow account is up-to-date and current.

Escrow Agent’s responsibilities typically include:

  1. Not accepting escrow deposits in sealed packages that cannot be inspected and confirmed.
  2. Requiring a deposit description form from the depositor to accompany all escrow deposits.
  3. Providing notice to the parties that all deposit materials that are submitted into the escrow account and accepted.
  4. The escrow provider is responsible for following and administering the release of deposit material per the agreed upon conditions by both parties.
  5. The escrow provider will hold and protect deposit material in physical or electronic vaults that are either owned or under the control of the escrow provide unless otherwise agreed to by the parties.
  6. Upon receipt of written instructions by both depositor and beneficiary, the escrow provider will permit the replacement or removal of previously submitted deposit material.

The only party that can determine whether or not everything is in the escrow account is ultimately the beneficiary. The escrow provider can provide information on the condition of the account; i.e.: the number of deposits and date/time of each deposit. Unfortunately, if a depositor submits corrupted information or encrypted data, the escrow provider would have no way of knowing that, unless the beneficiary requests the escrow provider to test the materials. (See: “Why Would You Verify your Software Escrow Deposit?”.)

A simple rule of thumb for monitoring the escrow material is every time the vendor releases a new version of the source code, a deposit should be made into the escrow account (immediately). After a deposit is made, the next deposit should come no more than six months later and it should include all of the activity/changes that have been made by the developer. In my next blog, I’ll provide a checklist, for an easy way to review your escrow account to ensure all of the essentials are included before it’s too late!