What’s in Your Software Escrow Deposit?

When you “escrow” a software solution, your software vendor deposits their software source code and other important information such as build instructions and third party tools, into a secure escrow account with a trusted, neutral third-party such as NCC Group. You’re providing protection against a potential risk that could impact your ability to support your end users. These types of risks are typically bankruptcy, breach in the agreement, or failure to provide support, but they could include any other predetermined scenario.

When a software escrow agreement is set up, these risks are called as “release conditions” – if any of the named conditions are met, the software source code and supporting materials can be released from escrow to the beneficiary, the party that licensed the software.

Software Escrow Deposit Contents

In no particular order, here is a list of NCC Group’s suggested materials to be deposited in a Software Escrow Deposit Account. ^*

• Roadmap of Deposit Material(s): High-level set of instructions regarding where the components are within the escrow account to save time during a release
• General description of items deposited: Functionality of the software, type of media the source code will be delivered on, the size of each deposit (Physical and Logical) and information on utilities or third-party applications such as an operating system or third party backup software
• Encryption information and/or required passwords: Any information that allows access the Deposit Material and it’s a good idea to include the program’s version numbers too
• Information required to produce a plain-text version of the Source Code: Include any information that’s required to extract the data; such as hardware, OS, source code control, recording densities, archive utilities, and/or network systems
• Contact information for key programmers: In addition to work contact information, we recommend asking for any relevant information that will help the beneficiary track down the programmer after a release.
• Source code: Material is based on the programming language. Common document file types are .java, .c, .cpp
• Component dependencies: In order to compile or link modules, software components are often required.  Include a list that identifies all known dependencies between components
• Build environment setup and configuration: Detailed instructions on configuration settings for all compilers and third-party components along with details on the build process to determine if the source code is loaded to a specific location
• Build control files: These files vary depending on the operating system and tools used, but typically include scripts that control the build process
• Build instructions: These are the detailed instructions that explain how to compile the source code and build executable code
• Design documentation: This information should cover the source code architecture, overall design of the source code and interactions among modules; so, a reasonably skilled programmer can recreate the software
• APIs/Program interface documentation: This requires specifications for any application programming interfaces that are exposed by the application(s), as well as any documentation used during the design, code, test, or maintenance phase of the software life cycle.
• Test diagnostics: It’s important to include regression tests and automated scripts, if available.

Lastly, an item that is overlooked more time than not, is information regarding any application necessary to compile and build executable code, objects, dynamic libraries, and so on.  It’s critical to note any required services packs, patches, or updates, including compilers, linkers, third party libraries, assemblers, pre-processors, and post-processors.  If all of this information isn’t readily available then at least provide the names of all the required applications, version numbers, vendor names and contact information, you do have available.  In a nutshell: Something will always be better than nothing.

At NCC Group, we also highly recommend escrow verification services to ensure that all these deposit components work together seamlessly so that you can effectively read, recreate, and maintain your developer’s technology in-house or transition smoothly to another vendor if an escrow release is necessary.

Software Escrow Deposit Update Schedule

I’m sure if this is your first escrow project then this “laundry list” of items may make your head spin. Have no fear; just take it one step at a time.  First, include all of the applicable items from today that will remain the same in the next release (file, tools, supporting documents).  Then provide a deposit update to the escrow account on a predetermined frequency (e.g. monthly, semi-annually, annually period) changes to the application along with details in regard to the current status of the software, previous status of the software and expect status of the next upcoming escrow deposit.

This process might sound tedious at first, but it will save you a tremendous amount of time down the road, when new people start to manage the escrow relationships.  Newcomers to the escrow relationship typically ask questions, such as “What’s in the account?”, “When was our last deposit?” and “How do we know everything is in there?” When you carefully think through and document your escrow deposit, you’ll have all the answers.