The IT Disaster Recovery Plan (DRP) provides a roadmap for response and recovery in the event of a technology "disaster", as defined by a sustained interruption or failure in systems use, access or functionality. Documented, actionable DRP's are essential - but how can you be sure your plan will work when it's time to activate? The answer is simple -"test, test, and test again". Read on to learn more.
When it comes to managing IT in business, a defined, actionable and approved Disaster Recovery Plan is a must - to protect technology assets, related data, and to ensure business continuity should disruptive events occur. While we all know we need a DRP, we also hope that we never have to actually use one. Therein lies the rub. Can you comfortably rely on a DRP if it remains largely untested by actual circumstance? Probably not. Proper, proactive testing is the only answer to this dilemma.
Until the disaster happens, disaster plans are largely theoretical ... "what will happen if...?". It's not wise to wait until a disaster is at hand to learn whether your plan is going to work or not. For that reason, it is important to hold regular, realistic tests for your disaster recovery plan. Also Read: Fundamentals of IT Disaster Recovery Planning
Disaster recovery testing is the formal, planned process to test and verify whether an adopted DRP will work if and when it is actually needed. An executable "test plan" is the primary deliverable of the testing process, along with the execution of the actual tests, and analysis of related results.
Disaster recovery plans will quickly lose value and meaning if they are not tested on a regular basis. We know that you have to test, but how often? It all depends on your individual needs and circumstances, but on the whole, testing should occur with sufficient frequency to maintain an appropriate comfort level with the relevance and applicability of the DRP.
Timing issues will play a large role in determining test purpose and structure. DRP tests should be conducted on a regularly scheduled basis, depending upon the size and scope of the disaster recovery program. More complex plans will require more frequent testing, perhaps on a quarterly basis. DRP tests should also be scheduled whenever major technology changes are implemented, including physical upgrades, new installations, and related re-configurations. The key is to ensure that disaster recovery testing is a fully integrated component of your IT service portfolio so that all needs and expectations can be carefully considered.
To achieve desired results, DRP testing should be approached in an organized manner, following standardized management practices so that all issues can be addressed. As an executable process, DRP testing must have an established purpose, with an orderly execution of pre-defined steps, carried out by DRP "stakeholders" with appropriately assigned roles and responsibilities. In addition, DRP testing will also be heavily influenced by constraints, considering available time, resources, and funding.
There can be no doubt that effective disaster recovery planning takes considerable time and effort. And while DRP related activities are essential to business survival, they do little to bolster daily workplace productivity. As such, any planning activities should be well thought out, precise and relevant. Along these lines, specific testing plans, intended to verify and validate recovery strategies, should be clearly designed with specific goals and purpose in mind. In order to maximize the investment made in DRP testing, three (3) elements must be consistently addressed:assumptions, scope and success criteria.
Every test plan should be built on a foundation of defined “assumptions”, which sets the stage for meaningful results. Any effective statement of test assumptions should accomplish the following:
1. To define the and related response mechanisms to be tested.
2. To provide the justifications for the scenarios and conditions to be tested.
3. To identify test prerequisites (i.e. pre-test circumstances and/or conditions that must be met).
4. To define test expectations (i.e. the results and benefits to be realized from the testing process).
To establish and maintain relevancy, test scope must be clearly defined and communicated. Test scope sets the parameters for the work to be completed, identifying the exact systems and/or specific functions to be tested. Test scope should be as precise as possible so that all parties are fully aware of the elements being tested. Since it may not be possible to test every plan component or scenario, exclusions and limitations should be established before the testing process begins.
How will you know if your test is a success? On one level, success can be simply defined as “the recovery plan works, and all related systems and services functioned as expected”. In reality, actual test success is not always that simple. Test success is obviously achieved once the DRP is proven valid and viable. On the other hand, success can also be achieved even if the DRP fails to pass the test. In this respect, testing efforts can be proven successful simply because DRP weaknesses were exposed through a simulated event, rather than an actual disaster. Ultimately though, success is born out of expectations, and expectations have to be defined. When “success” expectations are openly stated, false impressions, blame and confusion can be avoided, and common expectations can be established. Along these lines, success must be considered from all the angles:
In addition, pre-defined success criteria will facilitate the lessons learned review process, to be conducted at the conclusion of all testing activities. Using the established success criteria, "test" results can be evaluated to quantify DRP performance, test effectiveness, and to identify appropriate corrective actions.
To realize all of the intended benefits, DRP testing activities must be consistently implemented and enforced according to the following (4) standardized goals and objectives:
About Us- ITtoolkit.com has been around since 2001. What will you find here? We have articles (covering a wide range of topics relating to our IT service strategy and project fast tracking methodologies). We have templates and whitepapers to download. We have our series of IT management infographics. And, we have our "Toolkit productivity packages", combining "education and execution" - with time-saving concepts, steps and templates packaged in digital downloads. Our current Toolkit offerings include the Fast Track Project Toolkit and IT Service Strategy Toolkit.
If you are, then you need the IT Service Strategy Toolkit from ITtoolkit.com! The Toolkit teaches you how to "add value" to IT projects and services -- using our time-saving "service strategy process". It's ready for instant download, filled with 400+ pages of steps, guidelines, practices and templates. Find Out More
Strategic fast tracking is a streamlined project management process, used to level the playing field when "project problems" get in the way of on-time success. Our informative "fast tracking" article series explains more:
Sign up for the ITtoolkit.com newsletter and be the first to know about our latest blog articles, templates, white papers, infographics, and special offers.
We won't overload your inbox and we don't share or sell subscriber information. Just enter your email address below.