Part 1 looked at the basics you need before starting the DR planning process. Part 2 looked at the process of starting the DR plan and talking with the different parts of your organisation to build a picture. Today I’ll look at the next stage: getting an actual plan document in place.
Remember that this is a general outline of an approach to DR planning. Every business and organisation has its own structure and provision; the ideas and suggestions made in this series should be amended to fit your own business needs and IT provision.
At this stage (ideally) you should have
- A good, secure backup regime
- Up to date documentation which is stored securely
- Support from top level management for the DR planning process
- Documents describing expectations of an ideal minimum level of service for the different sections of the organisation
At this stage no promises have been made to anyone about service levels. You can’t make a commitment until you have gone through the planning process and seen what you can do in reality.
The ideal minimum service level documents should help you draw up a wish list for a basic level of service. Some will be practical and realistic, others will be neither. If you have pages and pages of notes from this exercise try and distil them into something more manageable. This body of work is your bedrock. From this you will be able to work with an IT services company to develop a DR plan.
There are some very good reasons why you should work with an IT services company to develop your DR plan. Here are three:
- Knowledge and specialism
Unless you’re a specialist DR practitioner you won’t have up to date knowledge of solutions and the right people to contact at technology and communications companies. They will already have a list of companies they trust to provide replacement equipment, premises, et cetera. They will also have tried and tested means of putting DR plans into action. By doing the work discussed here, you have prepared a great base for them to work from.
The service company can look at your wish list document and tell you what parts of it are feasible and what parts are not a lot more quickly than you, me or your company’s directors. They can deal with the technology and communications companies while you’re getting on with the other parts of your job. After all, a techie’s work is never done. The IT services company can dedicate time to your DR plan without interruptions.
A lot of service & support folk I’ve met and worked with tend to have one particular moan in common: too many people ignore the advice they are given and then expect the S&S folk to clean up the mess. For some reason the same advice an in house staff member would give seems to carry a lot more weight when it is given by someone external to the organisation. Consultantitis: If a techie says something it might be relevant. If a consultant says it then it must be Gospel.
So with your bedrock document go out and get quotes from IT services companies to see what they can offer you. Your bedrock document makes your requirements clear so you should get detailed quotes back with a clear process that will be followed to arrive at your DR plan.
A word of warning: Most companies probably won’t have computer kit which is difficult to cover as part of a DR contract. But such kit does exist. In your tender or enquiry document you should list all of your essential IT infrastructure equipment so that potential providers will know what they are working with.
Even though you have your bedrock there are still things to discuss. Should you keep some spare ready-configured kit (cold servers) in storage for DR plan activation? This is a good idea for smaller companies with say, up to five small servers and up to 25 or 30 desktop computers. When the DR plan gets activated, get the cold servers in place and you’re near basic operational status. I’ve been there, done that and I do think it well worth considering. Keep a few switches and a bunch of network cables in storage as well.
Whether or not you go down the route of cold servers creation of DR specific packs is a good idea. These should contain backup copies of server and operating system CDs and DVDs, essential driver and application CDs as well as electronic versions of network, server and computer config documents. They should be issued only upon the activation of the DR plan, which should be activated only by senior management. I’ll talk more about that in part 4.
One word of warning: If you decide to keep kit stored for a DR scenario, make sure it stays in storage. It will not look good if the DR plan gets activated and the cold server is missing because the Marketing Director (for example) wanted a new computer. The rule should be that DR kit is purely for DR and nothing else.
You can go down to the minutest detail of risk mitigation for your DR plan if you have the time, money and desire. But you should be aware of potential risks to your provision which can be identified and lessened. One example is a multi tenant office premises I know where the incoming phone and fibreoptic cables for the whole building enter via an unlocked cupboard in the disabled toilet. Unrestricted access to anyone and everyone. The locks on the cabinet are left open, the door to the cabinet hangs open so everything is on show.
Just think about it for a few seconds.
Unrestricted access to anyone and everyone. The locks on the cabinet are left open, the door to the cabinet hangs open so everything is on show. That is a huge risk which could and should be resolved very quickly.
Someone feeling malicious – it could be anyone at all – could go in there and cut off the entire building’s comms provision in a matter of seconds. Never mind an employee with a grudge. Water, a lighter and a can of hairspray or a good pair of scissors could be used to cut off the building. Several companies.
One question which comes to mind is “Do they all know where their comms provision comes into the building?” Let’s take that a step further: Do you know where your comms provision enters your premises? Is it as wide open as the one mentioned here?
So there is plenty to discuss. You’ve got your bedrock there so that’s a solid base on which to build your DR plan. That process will involve discussions between the IT services company, you as the IT department, occasionally the top level management (who should be kept up to date via regular reports or project meetings anyway) and occasionally representatives of the other departments in the company. This process may take a couple of weeks, it may take a couple of months. This process should produce a proposed DR plan.
The proposed plan may not meet everyone’s expectations. Remember, the objective of the DR plan is to provide a basic operational status as quickly as possible in the event of an incident. That is your priority. Once that is in place the remainder of the provision can be added once the extent of the incident and a way forward from it has been identified. Bells and whistles aren’t necessary here. Getting the basics right is.
The next (and last) part deals with testing your DR plan and the activation process.