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.
Getting Started: Planning for Testing Success
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.
Timing and Frequency
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.
Getting Organized: Testing is a Process
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.
These are the key "test planning" questions to be considered....
- What are the goals and objectives of the test?
- How can those goals and objectives be met in the most efficient manner?
- What will be tested and how will the testing activities be most effectively executed?
- Who are the testing stakeholders and what are their respective roles and responsibilities?
- What are the requirements and constraints of the test, considering time and funding?
- How will the test results be used to manage and maintain disaster recovery readiness?
Even under the best of circumstances, management is a challenge. When you learn to fast track, you’ll learn to work smarter, not harder. And that’s the value of every lesson, resource and template available at Fast Track Manage Learning. We teach you how to fast track your way to successful projects, committees and more. Learn More
Planning for Testing Productivity
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).
DRP Test Scope:
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.
Test Success Criteria:
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.
Some final tips....
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:
- Acceptance of all identified goals, objectives, scope and specific tasks involved in the actual test process.
- Acceptance of all assigned stakeholder roles and responsibilities – establishing process "ownership".
- Communication of all test logistics, dates and the potential impact on production systems.
- Analysis and integration of all test results and related "lessons learned".
Source: Unless noted otherwise, all content is created by and for ITtoolkit.com
ITtoolkit.com staff writers have experience working for some of the largest corporations, in various positions including marketing, systems engineering, help desk support, web and application development, and IT management.
ITtoolkit.com is part of Right Track Associates, proprietors and publishers of multiple web sites including ITtoolkit.com, Fast Track Manage, HOA Board List and more. We started ITtoolkit.com in 2001 and have continued to grow our web site portfolio, Toolkit products, and related data services. To learn more, visit us at Right Track Associates.