​

In a recent report on the market value of S&P 500 companies conducted by PriceWaterhouseCoopers, the nation’s largest firms reported that 78 percent of their assets were classified as “intangible assets.” This percentage is likely to grow as companies increasingly rely on technology—often in the form of mission-critical software—to run their businesses. That means that companies are facing increasing pressure to improve the protection of these intangible assets, particularly intellectual property (IP).

From database software to payroll programs to customer-relationship-management applications, the mission-critical software licensed by a company needs to be viewed as vital intellectual property, and protected as such. One important, but little-known, method of securing mission-critical software is a service known as technology escrow. Security professionals need to know what it is, when it is needed, who the parties are, what it entails, and when to verify and test.

What it is. Technology escrow is like an insurance policy for your intellectual property. These services are required when two or more parties are negotiating a license for technology, such as mission-critical software or other types of proprietary information. If the licensee-company of the technology is concerned that it may not be able to operate its mission-critical software because the developer—the only source of the technology—may no longer be able to provide support in the future, the licensee should request that the technology (typically software source code) be placed into an escrow account.

In this type of arrangement, a technology escrow agent acts as a neutral third party. It sets up the contract, typically signed during license negotiations. The contract spells out the conditions under which the code held in escrow would be released to the licensee-company.

If a predetermined release condition occurs, such as the vendor filing for bankruptcy or discontinuing support of an older product, the licensee-company then contacts the escrow agent to request a release. The agent then notifies the depositor that such a request has been made. If there is no contention, the agent releases the source code to the licensee.

Without an agreement, a licensee may only be able to obtain the source code and maintenance materials of the licensed technology through the court system, which could take years. By then the company will likely have suffered some loss of operations and resources that were tied to that technology, and it may also have had to incur the cost of moving to other software or technology.

I have worked with several companies that have arranged for their mission-critical software to be protected by technology escrow. And I have seen firsthand how this practice has helped companies avoid losses.

Take the case of Trans World Entertainment, which operates nearly 900 specialty music and video retail stores primarily under the FYE brand. Trans World licenses many different kinds of software to help it run its business. One such program was Listening- Viewing Station, or LVS, a software solution that provided a competitive advantage by differentiating Trans World from its competitors.

LVS, launched nationwide in 2002, allows store customers to swipe the bar code on a CD or DVD and hear or see a sampling of the content, enabling customers to “try before they buy” any of thousands of music, movie and game titles. More than 12,000 LVS units were rolled out to 550 stores across the country in 2002, and in 2004, richer content and functionality were added to further enhance this selling tool.

Trans World’s LVS was an instant success. Customers who listened to CDs or viewed movie clips in the stores were more likely to purchase the product after sampling it and were more likely to return to one of its stores because of LVS.

Because the LVS at Trans World’s stores offered something that customers valued and that no other store had, the company’s management identified the software that ran its LVS as mission-critical and knew that it needed to be protected.

Verification services. In addition to escrowing the software source code, Trans World went a step further and used verification services to ensure that the software source code deposited into the escrow account could be recompiled and executed. A thorough verification ensured that, in the event of a deposit release, Trans World would be able to read, re-create, and maintain the LVS software on its own.

Trans World knew this was especially important because it had invested a considerable amount of effort and funds into the LVS and realized that the cost of escrow and verification was insignificant in comparison. (The cost of escrow and verification typically runs just under five percent of the cost of the code being protected.)

Then, in an unforeseen turn of events, the software developer that created the proprietary LVS solution for Trans World went out of business. This could have been a costly event for the company. But because of the escrow deposits and verification of the source code, Trans World had everything needed to re-create, maintain, and continue operating the LVS application, allowing it to continue to provide the popular LVS to customers without interruption.

When it is needed. The first step in protecting IP assets is to know which assets need to be protected. This would apply as well to the use of technology escrow.

As a best practice, many organizations will form a cross-functional internal team to perform a risk assessment and then handle the implementation of technology escrow. The team typically comprises risk management, IT, legal, and business personnel whose task is to identify mission-critical software.

The team will also identify the level of risk with which the company is comfortable. This latter step helps establish objective criteria that determine when protection measures are required for licensed technology.

Generally, commercial off-the-shelf software that resides on a desktop computer (like Microsoft Word or Excel) does not need escrow protection. While this type of software may be critical to the individual user, it is a packaged application that is relatively easy and inexpensive to replace. On the other hand, mission-critical software usually has been customized for a particular organization, and it is usually crucial in helping a company’s employees to deliver its product or service to its customers.

Examples of mission-critical software include any technologies used to interact with customers (including customer-service applications or point-of-sale software), operational, financial, sales, and marketing applications, database software, and customized server operating system or networking and firewall applications. In addition, any products licensed to deliver services to customers, such as portals and Web sites, are usually considered mission-critical programs.

For companies that license software, the following questions can help to determine which software is mission-critical, and therefore in need of technology-escrow protection:

Uniqueness. Is the software unique? Custom software involves complex code that cannot be reproduced quickly. Replacing it could take months.

Dependence. How dependent is the company on the software? Downtime of mission-critical systems could be devastating, particularly in the case where licensed software is embedded within a company’s products.

Investment. How much has the company invested in the software? Technology investments go well beyond licensing. Associated costs such as training, programming, and deployment must also be considered.

Effect. Does this software affect revenue, productivity, customer service levels, public safety, or other applications that affect these issues? New government regulations now require special prudence in maintaining these types of applications.

Viability. How committed to the software are the developers of the technology? The long-term viability of small companies is often risky, while large companies commonly discontinue products and stop supporting them to force migration to their next generation of products.

The parties. Three parties are typically involved in an escrow relationship: the company licensing the technology (the licensee); the company that developed the technology (the developer); and the escrow agent. Attorneys generally represent the licensee and the developer to help craft the most favorable terms.

Companies must understand that these contracts are not standardized. Each company is in a position to establish terms and conditions that best meet its needs (see the “Terms and conditions” section for more on this).

Licensees. For the licensee, an escrow account provides access to the developer’s source code and other maintenance materials contained in the escrow deposit account. The licensee is the beneficiary of the deposit materials in the escrow account. The IT group, the contracts management group, and the compliance or legal department are all typically involved in setting up the agreement.

Developers. Developers are, of course, the parties who create the technology to be put into escrow. But developers can also use technology escrow as a way to ease customer concerns about future technical support and to establish credibility as a trustworthy, reliable vendor with the customer’s best interests in mind.

As such, it is typical for sales, marketing, and business development or C-level management to offer escrow as part of the effort to drive revenue. Technology escrow also creates an audit trail for the developer, which protects and validates its intellectual property.

The case of Computrition, Inc., illustrates how a software developer can use technology escrow as a benefit for its customers. Computrition provides fully integrated software systems for food-service and clinical nutrition management. Customers include colleges and universities, military groups, commissaries, hospitals, and long-term care facilities.

Computrition started seeing technology escrow appearing as a requirement in requests for proposals (RFPs) from large organizations and government agencies. The management team wanted to be proactive for this initiative as it began to realize the importance of offering technology escrow up front. It developed a packaged program to meet future customer requests and has found that customers appreciate this attention to their concerns.

Escrow agent. The final party involved in technology escrow is the escrow agent. A number of companies, including the author’s, offer this service. As a neutral third party, the escrow agent will set up the contract, safeguard the assets, and manage the account. The escrow agent dates and time-stamps all material deposited into escrow, creating an audit trail of development for the technology. This documentation can be used in court as irrefutable proof of a developer’s ownership of the intellectual property, if it is ever contested.

The escrow agent also administers the terms and conditions of the agreement by reporting to both parties any activity relative to the deposit account, and the agent coordinates any desired actions on the part of the parties, including a request for source code release. (For more on escrow agents, see the box “Choosing an Escrow Vendor' on page 68.) And, as explained ahead, the escrow agent also can verify and test the items in escrow.

Terms and conditions. Management needs to specify in the terms and conditions exactly what it needs to continue to support the application in case a vendor ceases to exist. This language will affect how well the escrow serves its purpose should a condition of release arise.

The importance of doing it right cannot be overstated. Rule number on is that the company needs to make sure that its own best interests will be addressed.

A properly crafted escrow arrangement will:

• Allow timely access to the source code and maintenance materials when specific release conditions have been met

• Enable quick re-creation of the application development environment

• Provide leverage after the license has been signed

• Provide an option to control the future software upgrade timetable

• Address legal considerations

• Enable corporations to avoid litigation and the courts

• Minimize the risk of loss with the right language written into the formal agreement

Verify and test. The value of the escrow arrangement is dependent on the quality of the escrow-deposit materials. A thorough verification of the materials provides the licensees assurance that, in the event of a deposit release, they would be able to more quickly and effectively read, re-create, and maintain the licensor’s technology in-house.

Just as lenders examine collateral when they sign a loan, the best practice in technology escrow is to verify and test the deposited materials. This should happen soon after an escrow agreement is executed to ensure that all of the components necessary to rebuild the executable program are part of the deposit and are in working order. Since software vendors are most familiar with the escrow materials at the time they prepare the deposit, the verification process tends to move more quickly if conducted shortly after the escrow agent has taken the materials into possession.

Verification is done through a three-step process. In the first step, the escrow agent validates the ability to read the media in deposit, performs some analyses of the media (such as virus scans), and reports on its findings. Next, the agent actually compiles the deposited code to re-create the software vendor’s product. Finally, the product is tested to ensure that it is fully functional.

The verification process has uncovered and corrected significant deficiencies in some cases. For example, one national retailer learned that the license keys placed in escrow to allow it to expand the number of cash registers used in its stores were actually incapable of activating additional machines; in another case, it was discovered during verification that there were no build instructions present, and it cost an additional $80,000 to have these instructions developed.

Problems are not always found in verification. Such was the case with the New Jersey Transit Authority, which recently licensed new technology to upgrade its fare- and data-collecting system. It then relied on the technology manufacturers to set up the escrow account.

The transit authority depends on the newly licensed technology to collect information and generate reports on fare revenue, passenger destinations, bus activity, route usage, and other data. This technology also has been integrated with the transit authority’s garage and fare-register computer systems. Almost every one of the authority’s departments will eventually rely on the software, including transportation planning, maintenance, and claims.

Because the system was so critical, says Robert Fitzgerald, technical specialist for the Transit Authority, a thorough verification on the source code placed in escrow was needed. Fortunately, verification went smoothly for the transit authority, and it now knows that if it needs to rebuild the application at some point, all of the components needed to do so are available in the escrow account and have been tested as executable.

Security professionals know that some software is as critical to the company’s mission as any product. Identifying which software falls into that critical category and properly protecting it in escrow is a vital part of any business continuity plan.

Jeffrey Johnson is the senior vice president and general manager of the intellectual property management business unit of Iron Mountain, a global service provider of intellectual property management services specializing in technology escrow and domain-name records management.