There are a number of formal processes that you can follow for IT contingency planning. In this video, you’ll learn about some well-documented contingency strategies from the United States National Institute of Standards and Technology.
<< Previous Video: Disaster Recovery Planning and TestingNext: Succession Planning >>
There are some guidelines available for IT contingency planning. This is in this publication, Special Publication 800-34. And it’s called “The Contingency Planning Guide for Federal Information Systems.” It’s something put out by the National Institute of Standards and Technology that is part of the US Department of Commerce. And this has instructions, recommendations, considerations for your IT departments to be able to do contingency planning.
So if you’re looking for a guideline, you’re looking for something that can help you understand what you should be putting together, grab this document. Google this document and be able to understand what do I need to think about for a relocation and additional systems and how I can do things manually. Maybe we’re not going to use our computers and our networks. Maybe we’re going to write everything on
Paper. Remember paper? We used to use. We would have pencils are the things that we would use with those.
This document includes three different types of systems that you should consider when you’re planning for IT contingency. Talks about client server systems. Those are the traditional systems that we have in our data centers. What about our phones? We talk to people with voice, and our telecommunications systems are an important part of that.
There’s also mainframes to keep in mind. And very, very large organizations, you have these monster systems, these mainframe computers. And they become a completely different challenge when it comes to maintaining the IT contingency planning for this, and so this document is going to give you ideas and guidelines you can use to maintain the availability of all three of these different platform types.
This document also provides a guideline of seven steps you should keep in mind when creating or planning for a contingency. The first step is to create a planning policy statement. Come up with what you’re planning to do and how your systems will be made contingent, and this will be a formal policy that everybody gets to participate in.
Then you need to look at the business in the overall organization and find out what is the business impact for some of these problems that might occur, and we probably want to prioritize the mission critical systems that we have in our organization. Then we can look at ways that perhaps we can prevent some of these problems from occurring in the first place. That way we can maybe take a big section of disasters or problems that might occur and be able to mitigate those, be able to make sure that maybe they’ll never happen in our organization.
Maybe we’re buying redundant systems. Maybe were creating a different way of backing up our existing systems. And we need to think about contingency strategies, then. If a problem does occur, how can we recover as quickly as possible? And that, of course, means that we’re going to create a contingency plan around these things. If a system is to fail and we’re going to get up and running quickly, we need to have the exact process and procedures to restore that particular system.
And then we’re going to talk about how do we train? How do we plan? What do we do to make sure that these things that we’ve created are actually going to work when we need them? So there will be testing, testing, and even more testing after that.
And, of course, this is a living document. This is something we’ll be improving on. We’ll be changing as our IT systems change, this particular plan will need to change. So this will be something that is always going to be a work in progress.