Technology escrow can reduce the risks if there are unexpected issues with your technology vendor.
An escrow can reduce the risks if there are unexpected issues with your technology vendor.
The federal government has been using technology escrow to safeguard their commercial off-the-shelf software for decades, but agencies appear hesitant to use this same protection for classified software and other technology.
Technology escrow is a service that mitigates the risk of technology acquisition. With an escrow contract, software source code or other IP from the developer is placed in a secure escrow account held by an escrow agent—a trusted independent third party. If in the future, the developer is no longer able to support the product for reasons specified in the escrow agreement—such as bankruptcy, obsolescence, merger or acquisition—the technology buyer will still have access to the source code, IP, and other “know how” to keep their mission-critical applications and systems up and running.
Any technical data package can be protected with a technology escrow agreement. If escrow will be required, the government entity should make this requirement known in the request for proposal. The DoD ESI Software Buyer’s Guide discusses source code escrow in Section 3.1.13, and the source code escrow is also included in the Software Buyer’s Checklist as part of the key terms to be finalized at the time of placing an order.
How Technology Escrow Works
When commercial off-the-shelf (COTS) technology is placed into escrow, the prime contractor developer is able to retain the IP rights, and the government buyer gains the assurances that the software source code or other technology will be available if needed. The independent, third party escrow agent makes this happen by providing a secure repository and creating an agreement that specifies release terms that detail under what circumstances the technology would be shared with the government buyer.
The escrow agent also facilitates regular updates by the developer and offers verification to ensure everything will be available to recreate and maintain the application if the original developer can no longer support the technology. In essence, it’s a tried-and-true solution for the government’s use of COTS technology, as well as all types of on-premises and SaaS technology for private enterprises.
What about Classified Software?
By definition, classified software or technology involves sensitive information with restricted access, so it is on the opposite end of the spectrum from COTS software. However, because classified software demands more protection and security, this shouldn’t rule out technology escrow. Instead, technology escrow should be considered as an additional safeguard with the right precautions in place. As expected, federal-grade security capabilities are required to support classified escrow, as well as top-notch support and service. Some of the things to look for include:
- A dedicated area for the storage of classified escrow materials.
- This area should be restricted to trained personnel with classified clearance.
- The ability to customize escrow agreement terms and conditions.
- A dedicated escrow adviser as a point-of-contact.
- Proven experience in the storage of classified materials—both physical and digital.
For more information, view these two very informative short videos on Source Code Escrow by the DoD ESI — Part 1 and Part 2. As summarized in the video, “Escrow is an often-overlooked tool to help the government mitigate the risk of licensing commercial software. It should be considered in all situations and secured when the risk warrants its use.” We agree with this assessment and would encourage government agencies to expand their use of escrow to classified software and technology as well.
Reducing risks associated with technology acquisition can save time, money, and frustration if there are unexpected issues with your technology vendor. An escrow agreement is a sound choice to minimize this risk — for both classified and commercial technology solutions.
This article was originally published in Nextgov.