Until recently, the full extent of any disaster recovery process in traditional software deployments was to ensure adequate backups from tape through to replication, and to require the supplier to place the source code for the software in escrow.

Of course, a source code deposit is only as good as the quality, extent and “freshness” of the code provided. While a good escrow agent can verify the contents of a deposit to a degree, that is not the same as taking the source code and compiling it into a working application.

That the source code is viable does not mean that the customer can use it. Most customers will not have the resources, time or money to take over the development of a sophisticated application. If the supplier goes into liquidation, there is little prospect of recovering damages either.

If one accepts this argument then the business should not look to the “protection” afforded by an escrow clause. Rather, it should be basing its continuity plan on the likelihood that a migration to another supplier/application may be the only practical solution.

In the software-as-a-service (SaaS) scenario, the customer does not have to worry about maintaining various systems. All it needs is a good internet link and a browser.
There are many reasons why the SaaS approach is eminently suitable, but it brings with it particular continuity issues. All your eggs are in one basket. You have no software to run the application yourself and you do not have access to the data either. You are entirely dependent on the supplier providing the services and ensuring that there is continuity.

Buyers typically get what they pay for, and that applies to the quality of the service and the redundancy provided by a particular supplier. Replication between datacentres will not prevent data loss due to human error, but timed snapshots and rollbacks might mitigate the loss. The first step in any contingency planning is to evaluate the backup/recovery procedures implemented b y the supplier. It is your call as to whether or not you take the supplier’s word for it; you may want to seek independent verification.

None of that helps of course if the supplier goes into liquidation and stops trading. Again, a pragmatic view has to be taken. If you do have access to the data, perhaps because you have ensured that copies of the data are provided regularly, will you be able to do anything with it?

Continuity planning has certainly got a lot more complicated, but given that many businesses do not survive more than six months after a major data loss, it should be a priority at board level.