One of the biggest mistakes companies make when evaluating risks to their business continuity is to neglect to consider and acknowledge how dependent their annual revenues are on technology platforms over which they have no control.

For corporate entities, this is often measured in millions of Rands, and yet this clear and present danger is often ignored or grossly underestimated, according to Escrow Europe Managing Director, Andrew Stekhoven.

For nearly two decades, during which time his company received an Institute of Risk Management of South Africa (IRMSA) award for its role in assisting South African businesses manage their mission critical business risks, Stekhoven has pointed out that most commercial and governmental institutions are often entirely dependent on software over which they have limited or no control.

Software, he stresses, which in the case of a natural or man-made disaster, could become ‘orphanware’ in less time than it takes to log on to Google.

‘Orphanware’ is software that is no longer supported by the company that developed it, and can come into being for a number of reasons, ranging from the obvious, for instance, bankruptcy on the part of the supplier, to the more subtle - what happens if a competitor acquires the supplier with the sole purpose of killing a competitive product.

One of South Africa’s most high-profile cases in the mid-2000s involved Prestasi, which lost its entire customer database in a highly-publicised dispute with its then-IT outsource provider, Dexdata. Prestasi was reduced to managing its business without access to its own customer database. A court order eventually compelled Dexdata to return the data, but the returned tapes were unreadable.

One way to mitigate operational risks associated with dependency on software is to purchase a Source Code License, a situation actively discouraged by the developers because it gives the purchaser direct access to the ‘secret code’ in which the application is written.

An alternative with far more appeal is for both parties to enter into an active escrow agreement as a simple method of guaranteeing access to maintainable information systems by the software end-user should certain predefined commitments such as warranty, support and maintenance are not honoured by the software supplier irrespective of its stability or commercial stability.

“An active escrow arrangement entails verifying the deposit material to ensure that the source code is present and accurately and completely reflects the software in operation at the end user’s site,” says Stekhoven.

“Passive escrow, which does not ensure the source code is verified to confirm that what was deposited was in fact the complete set of source code, associated technical documentation etc, offers no proper reassurance that the source code material is present or that it will be of any use in the event of a release.

“In fact, the exposure as ‘foilware’ of the Lorenzo patient record system at the heart of Britain's £10 billion ($25 billion) National Health Service IT upgrade highlighted the importance of active – as opposed to passive – software escrow.”

Foilware is a term used for software that is delivered late, not at all or doesn’t do the task for which it was commissioned. The Lorenzo system was initially scheduled for release in March 2004 but, in 2010, delays with its delivery were bringing the NHS close to collapse.

These delays caused David More, an independent consultant and e-health blogger in Australia (aushealthit.blogspot.com) to point out that New South Wales Health should not rely on its escrow arrangements with iSoft to protect the rollout of patient administration systems.

iSoft Australia was supplying the same product for various state health projects, including Victoria's $323 million HealthSmart. More said there was no point holding obsolete software code in escrow. All that does is provide a false sense of security that something can be done when iSoft fails.

“That’s vital point right there,” says Stekhoven, “and another is that a properly considered active software escrow agreement will protect the business from other challenges should it call for the release of the source code from escrow.”

Here Stekhoven was referring to a recent court case in the USA. A company called National Quality Assurance (NQA) used software developed by Jadian Enterprises to support its registration and certification services.

As part of the agreement between the two, they entered into an escrow agreement which required the escrow agent release the source code to NQA in the event of a failure to perform by Jadian Enterprises ‘for the sole purpose of continuing the benefits afforded’ by the licensing agreement.

Jadian Enterprises was bought out by another company, but failed to provide the same level of service as the original Jadian Enterprises had, prompting NQA to halt paying subscription fees and to request release of the source code from the escrow agent. The agent did so, and NQA hired another provider to develop and maintain the source code.

Jadian and its owner, Epazz, Inc., sued NQA for breach of contract and trade secret misappropriation. The district court granted summary judgment in favour of NQA, finding no misappropriation of a trade secret and that NQA had not acquired the source code by improper means.

“This case is a good reminder for both customers and developers alike to clearly define the bounds of the use and/or transfer of source code and trade secret material. Customers having doubts or concern as to a software vendor’s ability to perform should strongly consider escrow agreements, especially where the software is central or key to the customer’s operations or it has fears of the vendor going bankrupt,” adds Stekhoven.

“A sound, common sense approach to mitigating disaster, active software escrow provides cost effective relief and security for a business. In today’s technology dependent business world, active escrow agreements between an end-user organisation and the supplier of the technology it utilises are a necessity, not a nice to have.”

Should you have any doubt about your need for active software escrow, answer these three questions:

• Is the technical or IT know-how I use every day critical to my business processes and functions?
• Is this know-how not easily replaceable by an alternative or is the conversion to an alternative too costly or too lengthy?
• What if the company that developed and now maintains one of my business-critical software applications becomes insolvent, or is taken over by a competitor and changes business direction?

Frank answers could prompt you to rethink your existing unworkable escrow agreements, substantially lower your risk profiles and strengthen your good corporate governance.