In law courts around the world, the golden rule is “innocent until proven guilty”. For many aspects of IT systems, a similar concept applies too. For example, you can see that you have enough data storage capacity, by comparing with the gigabytes or terabytes you’ve used with the space still available on your storage network. You can show a system is capable of handling a certain workload or reaching a given performance level by running that workload and measuring the results. You can even prove business continuity. If your systems are still running, you have business continuity! However, when it comes to other areas, notably disaster recovery, “guilty until proven innocent” may be a safer way to proceed.
The big challenge in showing your disaster recovery plans are adequate is that it takes a real disaster to provide definitive proof. However, a real disaster is the last thing you want to provoke, even if you spend considerable time, effort, and money in thinking and planning for it. IT departments are not the only ones faced with this awkward situation. For example, national emergency response plans to combat influenza outbreaks and other pandemics must also deal with hypothetical cases and projections, until the “real thing” happens.
The way forward is to use experience, vision, and simulation of disaster situations. Response times and vaccine supply speeds for pandemic response plans, and failover and rapidity of data backup restores for the IT disaster recovery. Regular tests, plan reviews, and exercises with as much realism as possible are the only way to stay prepared and ready to handle a system crash, security attack or denial of access to a site. You can and should build up high levels of probability that you’ll cope, but you’ll never really know if your DR works until the time comes when you really need it.