Business continuity planning is a big part of your overall risk management framework – or should be. But if you’ve decided that it’s part of “IT security” and you’ve left it to the IT department, here are the top 5 mistakes you’ve probably made.
1. Continuity is about the whole business
There’s no point having working computers if you don’t have people to use them. Your continuity plan needs to account for losing people – or losing knowledge – as well as losing IT systems or data. When you’re looking for single points of failure, look at the org chart as well as the network diagram.
2. Failures are rarely total
If your continuity plan is labelled “Disaster Recovery Plan” then if it helps at all, it’ll only help in a comprehensive disaster. Most continuity failures are partial: too many people in Accounts go sick at the same time; the ceiling falls in on the Production team; the email goes off-line but everything else is working. Make sure your plan is adaptable to various levels of interruption – if it’s all-or-nothing you’ll probably never use it, but you’ll still suffer plenty of downtime.
3. If you don’t train it, it’s worthless
So you have a shiny continuity plan. You’ve looked at human resources as well as technology. You’ve thought about total and partial loss of access. You’ve table-topped and scenario-modelled it until you’re blue in the face. It’s been signed off by someone important. Excellent! File it in the BCP folder and off to the pub to celebrate a project well done. Cut to: six months later, disaster strikes! Pop quiz: how many people in your organisation know where the plan is? Or even know that there is one? How many of them know what to do without you telling them? What if you’ve left (see point 1)? Once you have a plan, you have to train everyone so they know what to do, and you have to keep training them.
4. If you don’t review it, it becomes dangerous
Continuity plans are snapshots in time; they tell you how to preserve the organisation as it was when the plan was designed. But organisations change – so does the world. Maybe your plan was fantastic 5 years ago when you put it together. But since you don’t train it, you’ve not looked at it since. Come the disaster, it refers to offices that have moved, processes that have changed, products that no longer exist, phone numbers that now connect to the local take-away instead of the standby office-space provider and contracts for resilience provision that have long lapsed or become inadequate. Review the plan. Not just once a year, or once in any arbitrary time period, but as things change. Build BCP review into your change control process. Don’t have a change control process? See me after class.
5. If you don’t test it, it means nothing
The real world doesn’t work the way you’d like it to. Things that make sense around a committee table can look remarkably stupid when you try them in action. It’s like a George Lucas script. The closer you can get to actually executing your plan, the more likely you are to find out if it works. There is risk in doing this. Clearly you try to figure out if it looks stupid round the table first. But in the end you can turn it into a positive. A big part of your BCP is communication, so rope in your staff, suppliers and customers. Tell them you’re running a test – after all, your BCP protects their interests. Tell them how it’s going as you do it – after all, in the real world you’d have to tell them what was going on, even if the ceiling was falling in around your ears. You’ll learn from it and have a better BCP afterwards, and your stakeholders will be reassured that you’re taking the issue seriously.