net.work

The Way Business Is Moving

net.work published by
Issue Date: September 2005

Software escrow

1 September 2005
Andrew Stekhoven, director, Escrow Europe (South Africa)

The risk of licensing software extends beyond the cost or being locked into a vendor's whims.
Andrew Stekhoven, director, Escrow Europe (South Africa)
Andrew Stekhoven, director, Escrow Europe (South Africa)
Most chief executives will be aware of their obligations under Section 424 of the South African Companies Act, which addresses the requirements for good governance and provides for the introduction of legal steps against senior executives who fail to carry out their company duties correctly.
However, even the most diligent CEO might be overlooking a critical aspect of his or her company's software environment, and as a result inadvertently exposing their businesses to a high level of operational risk.
This often-disregarded risk factor hinges on the fact that many companies' core, mission-critical systems are dependent on software which is licensed from third parties rather than owned in-house, and therefore subject to conditions or events beyond the licensees' control.
The following is a step-by-step process that should assist CEOs understand and minimise the risk:
1. Determine how many mission-critical applications currently running within your organisation are licensed, and therefore contain technology or intellectual property beyond your control. If your organisation only runs 'off the shelf' software applications, you can safely assume that you do not need escrow. On the other hand, if software created by a potentially financially unstable developer impacts your revenue and productivity as well as public safety, etc, you need to consider software escrow.
2. If you do have software escrow agreements in place, make certain that these will ensure business continuity in the event of a release event or condition. This is a vital step because research shows that as many as nine out of every 10 traditional source code deposits held in escrow are useless. The reason for this potentially ruinous failure is that conventional (or passive) escrow deposits are not verified by technical specialists. The software is assumed to be complete and deployable, but usually there is no check on whether or not this is the case.
An infinitely superior option to conventional passive escrow is the more rigorous active escrow. Here the escrow agent subjects the material on deposit to consistent standards of technical verification, at least once a year, and provides a report which warrants that the deposit contains what the supplier has committed to lodge, thereby providing proper reassurance that it is complete, up-to-date and is most likely to be usable.
3. If you do not have escrow agreements in place, ask your developer or software provider if they have escrow. If the answer is 'yes', scrutinise the terms and conditions of the escrow agreement and ensure it specifies exactly what you will need to continue to support the application in the event the vendor ceases to exist, and make sure these specifications are adhered to.
4. If the answer is 'no', insist that the vendor and your company enter into an agreement.
5. Take control of the negotiations. Make sure you have read and understood all provisions written into the escrow agreement. Ensure that the agreement enables you to access the deposit materials when you need them. Scrutinise release conditions and the release process to make sure that there are no loopholes preventing the escrow agent from completing his task.
The objectives of active software escrow are rooted in promoting ICT good governance, and take cognisance of the fact that registered customers can be proactive in complying with current protocols and imperatives such as KingII, COSOII; Sarbanes-Oxley, ISO 17799, ITIL etc.
This is a sound, commonsense approach based on the principle that an ounce of verification is better than a pound of conjecture.


Others who read this also read these articles

Search Site





Subscribe

Previous Issues