Too many companies think they have disaster recovery measures in place, when in reality no one really knows whether they will work or how to implement them.

The problem is that no one person is given the responsibility for disaster recovery, and therefore there is often no follow through.

Testing policies requires simulating a complete system failure, something that most people balk at in case they cannot actually recover.

It is a sad fact of business life that disaster recovery is something that is only thought about after some catastrophic event, such as terrorist attacks or the floods that blight parts of the UK on a yearly basis.

"Post 11 September there was huge investment, but we are now right back to where we were two years ago," warned Bill Pepper, head of security risk management at Computer Sciences Corporation.

"Initially, and quite rightly, there was a gut reaction from many organisations to take a serious look at their disaster recovery plans, but investment has now levelled off as these plans have reached a more acceptable level."

A survey by backup software vendor Veritas showed that more than 97 per cent of respondents admitted that they could not survive a system outage for more than a few hours. Some 72 per cent had a plan, but hadn't even tested it.

This failure to maintain effective plans could place the careers of company board members in jeopardy.

"There is a process in place at board level via the Turnbull Report [which sets out a Code of Conduct and Ethics on Corporate Governance] which ensures that the board has a legal responsibility to assess the risk to the company," explained Jeanette O'Neil, head of business continuity at LogicaCMG.

"This is binding and, in turn, gives the driver at board level the opportunity to burrow down to ensure that proper risk analysis and business impact analysis are conducted."

If the board fails to provide a comprehensive understanding of the risks in relation to the potential losses, and fails to approve a plan for business continuity, it is in breach of its legal obligations.

A company that doesn't update, practise and adapt its disaster recovery plan from one year to the next risks breaking the law by losing data.

Unfortunately, risk assessment is rarely carried out in many companies, and few boards understand what disaster recovery and business continuity really means.

How to build a disaster recovery process
The starting point for any disaster recovery strategy is a corporate policy, which needs to specify what constitutes a 'critical system'.

It might be something as mundane as an active directory server, or as complex as a distributed database. It could be outside the building, such as the power supply or leased lines, or inside, such as an ageing tape drive used for the daily backup of the accounts system.

Whatever it is, you need to identify it and decide what action to take to prevent it causing a catastrophic failure. In essence, this is simply a case of risk management.

If you don't possess your own risk management team you should consider employing an external company to do it for you.

Once these policies have been agreed they need to be turned into actions. For IT systems, this is often more complex than it would appear.

For example, it might be decided that all key data should be backed up nightly. For this to happen there needs to be other policies in place to ensure that all key data is stored in a central location where it can be accessed.

This means, if necessary, denying access to local hard disks when users want to store data.

Once policies have been defined, along with the processes needed to implement them, the systems must be reviewed. The first step towards disaster recovery for many companies is their backup processes.

There are many ways to implement a backup process, but typically they involve a series of cycles: incremental backups on a daily basis followed by full backups once a week, month, quarter and year.

Some advocate just backing up changes to data in the daily cycle, while other backups should include data, system and applications.

Whatever you choose, it should be capable of ensuring that the maximum amount of data lost at any given point is no more than that created in a single day.

With current operating systems and enterprise software supporting snapshot backups, lost time can be reduced to a few hours or even minutes. Snapshot mechanisms have evolved to resolve the problem of an open file preventing a backup from completing.

There is also a need to ensure a continuance of equipment and the ability to read media over time. An example of an organisation being caught out by this was the BBC's Doomsday Project. Originally collated in 1986, the Doomsday Project data was stored on Laserdisc.

Today, engineers are faced with the daunting task of trying to extract the data onto a platform that can be read by modern PCs, as both the Laserdisc technology used, and the BBC Micro computers on which the data was formatted, are no longer produced.

If you cannot read the backup media because the only hardware capable of doing so was lost when your building burned down and can't be replaced, your disaster policy is a complete waste of time.

Ask yourself when you last restored more than a single file. Could you take any of your backups and completely restore a system with total confidence? For most people the answer is no. It's never been necessary, so it's never been tried.

If you cannot do a complete system restore you cannot validate your backups. What is equally important is how long it will take to restore your systems.