When speaking of technology and information governance, we often are told that “if it ain’t broke, don’t fix it” – or in other words, don’t go looking for trouble where there isn’t any. But when it comes to disaster recovery and, especially, continuity of operations, I vehemently disagree.
These two disciplines exist specifically to ensure you are ready to respond when things DO break – and the best way to prepare for that is to break them on purpose, and then figure out how to most quickly put them back together.
To be clear, I’m not advocating that you unplug your servers or trigger your fire suppression system to see what happens. But simulating these events is a “must,” and regular drills in this regard have to be part of your risk readiness if you want to achieve “continuity of information,” and keep your business moving when real trouble strikes.
Disaster Recovery and Continuity of Operations:
The Same, but Different
Disaster recovery and continuity of operations both center on quickly getting your systems back online after something bad takes place – after all, even a few minutes off the grid can be costly in terms of transactions not completed or customer service not provided. However, they differ in scope and intention, generally as follows:
- Disaster recovery describes the wheels you put into motion in the aftermath of a physical calamity of some sort, e.g., a hurricane, flood, earthquake, or fire.
- Continuity of operations is the button you press in the midst of a business interruption, which can be caused by a natural disaster but is more often thought to be the result of a protracted power outage, server crash, Internet backbone failure, etc.
Prime responsibility for these traditionally has been vested in the good folks in IT, who of course are the overseers of your technology infrastructure. However, they should be of at least equal concern to those of us charged with the care and feeding of business-critical information.
Call it “Continuity of Information”
You see, there isn’t a single application today that doesn’t rely on the capture, retrieval, and/or massaging of information in some way, shape, or form. Take that information away, even temporarily, and the application fails – as do the business processes and desired outcomes that depend on it.
So if you get wind of some initiative regarding disaster recovery/continuity of operations at your place – or worse, you find out that there isn’t one – do what you can do to get involved, and start breaking as many things as you can. For the very best time to go looking for trouble is when there isn’t any. Any later is too late.