Business Impact Analysis and the RTO
Though the title of this submission may not sound like a bedtime story you may read to your children, there is a moral to this story. In my last submission, I explained how important it is to complete a Business Impact Analysis (BIA) for the organization. I listed a number of reasons why this is important, but the most important reason gets it's own blog submission, this one!
So what is an RTO you may ask? According to DRII and DRJ glossary, the RTO is...
RECOVERY TIME OBJECTIVE (RTO): The period of time within which systems, applications, or functions must be recovered after an outage (e.g. one business day). RTO’s are often used as the basis for the development of recovery strategies, and as a determinant as to whether or not to implement the recovery strategies during a disaster situation.
The RTO is a powerful number that should NOT be randomly chosen. By completing the BIA, you should be able to determine what critical functions your area is responsible for. Through the analysis, you should be able to determine within a reasonable timeframe how long a critical function could be down without negatively impacting your customers.
Most units want to skip this part. Just like the prioritization the critical services, they want to pick a number for the RTOtime frameprioritizing that they think would make their management happy. By choosing RTO's instead of really understanding the critical function, we create false criteria in which recovery plans are built on. Recovery plans have no hope of working because everyone knows they cannot possible hit the targeted RTO stated in the plan. In knowing this, the recovery teams do not take the recovery plans seriously. Like "The Boy Who Cried Wolf", how will you know when your recovery plan is telling the truth or just making it up?
How can this all be prevented? Taking the BIA seriously and understanding what it is to be used for. The BIA is more than a silly survey that slows you down in the planning process. Like "The Tortoise and the Hare", slow and steady DOES win the race. In this case, the race is to create a recovery plan that is actually usable and practical.
Here are some critical decision that use the RTO
- The strategies you need to implement
- The cost of implementing those strategies
- When should you declare a disaster or wait out the event
Don't let your Recovery Time Objectives (RTO) be a "Wolf in Sheep's Clothing". Complete the BIA and analyze the results for a better understanding of the services you provide. The moral of this story is: will your plans be built out of straw, sticks or bricks and can they withstand the huffing and puffing of an outage?
0 TrackBacks
Listed below are links to blogs that reference this entry: Business Impact Analysis and the RTO.
TrackBack URL for this entry: https://blogs.psu.edu/mt4/mt-tb.cgi/3584
Based on the BIA, the RTO is always the worst case timeframe for recovery. The problem you run headlong into the is cost of implementing the RTO. But, the cost is also a DR person's friend! With the cost of the recovery strategy in hand, a DR person can get a reality based solution from upper management instead of a knee jerk or politically charged answer from the business owner.
I found your blog is so interesting and helpful... Now I am working on the Business Continuity project. As you said, but BIA and RTO is a very important part for BC, but you don't mention RPO (recovery point objective). Do you think RPO is less important than RTO?
You bring up a good discussion about RPO's. They are as important as the RTO and probably should have their own blog topic (maybe that will be the next one!).
Currently, we are not focusing on the RPO as much as we should. Most of our business units feel that DR and BCP are only technology related and the IT departments are tasked with completing plans. As the business units get more involved in the planning process, they are identifying their business needs with just a Recovery Time Objective. I feel that as our program matures and the business units continue to be more involved, we will be able to focus on both the RTO and RPO.