Fall World 2014

Conference & Exhibit

Attend The #1 BC/DR Event!

Summer Journal

Volume 27, Issue 3

Full Contents Now Available!

DRJ Blogs

A short description about your blog

Mar 13
2014

Using the Results of Your BIA to Develop Disaster Recovery Requirements

Posted by: Courtney Bowers in DRJ Blogs

Courtney Bowers

By Michael Bratton, Avalution Consulting
Originally posted on Avalution Consulting’s Business Continuity Blog

So you’ve just completed your business impact analysis (BIA) – identifying recovery time objectives for a variety of processes and functions throughout your organization and captured the names of applications and systems that business owners state they just can’t live without. In addition, the IT department heard you were conducting a BIA and mentioned on a few different occasions that they were excited to see what the final results would be to help with their planning. You’ve taken all the applications and their reported recovery time and recovery point objectives and crammed them into a very lengthy spreadsheet, and then the inevitable happens… you realize that everything you have collected is a huge mess.

But, don’t worry, this is a common issue! This perspective will explore the process of taking that seemingly disorganized pile of data and organizing it into something that can be utilized by IT disaster recovery planners to help meet continuity goals. So, let’s get started!

Step One: Double check your data and ensure that the RTOs for systems and applications are similar to the RTOs for the business activities they support.
Business continuity planners work closely with operational area leaders to help define when operations need to be up and running. Recovery times can vary greatly and so can the recovery times associated with the applications that support these activities. A first step in verifying application data after you have consolidated it into a spreadsheet is to examine the recovery time objectives (RTOs) and recovery point objectives (RPOs) associated with a given activity and compare them to when the supporting systems need to be online. In most cases, these recovery time objectives should be very similar. For example, it doesn’t make sense to have an activity or process that needs to resume within 10 days, but have a supporting system that needs to be up within 24 hours. There are a few exceptions to this rule, but in general the RTOs should be aligned. A common exception is a system that is shared between multiple processes and activities; in this case, the lowest requested RTO should be reflected.

Step Two: Make sure the requested recovery point objectives actually make sense.
The process of defining recovery point objectives is a commonly misunderstood concept. Even when explained in terms of data loss tolerance, it is very common for non-IT or non-BC personnel to completely miss the concept. For this step, you will need to review the RPO information from the BIA and compare it to the purpose of the application and the requested RTO. Lower requested RTOs and RPOs (more time-sensitive) typically complement each other. Once again, if there is an application with a requested RTO of 10 days, it probably doesn’t make sense to have an RPO defined in minutes. This doesn’t mean that there will always be a 1:1 relationship between RTO and RPO. In fact, your organization may have policies that all data is backed up daily (e.g., RPO: 24 hours). In other cases, there may be regulatory requirements or service line agreements (SLAs) that define data loss tolerance. While there may be exceptions, look for outliers and understand why they exist.

Step Three: Determine how you’re going to organize the data into logical groupings or tiers.
After following steps one and two, you should now have a fairly accurate dataset that can provide a starting point for ITDR planning, but it is likely still jumbled without an overarching means of organization. There is no quick fix for organizing the data, but you should consider ways to logically group different applications. In most cases, this will likely be sorting and organizing by applications’ requested RTOs. Some organizations use other methods of scoring to determine an application’s criticality in addition to the RTO. In these cases, whatever criteria is used needs to be both simple and based on criteria the business continuity planner can both easily understand and readily explain. Assigning arbitrary criticality rankings does not meet these requirements. You will need a solid story of why it’s important so management can understand the logic.

In organizations with more mature IT departments or organizations that employ IT service management (ITSM) programs, there may already be published standards of service for various applications. If this is the case, try to setup a meeting with IT service managers to learn about the organization’s IT structure. Many organizations have a tiered system or a “gold, silver, bronze” model that can be directly applied to your results. Use ITSM systems as a guide, but keep in mind that applications are often pre-selected for service levels because service managers see them as important, not because there is adequate research (such as the BIA) driving the decision making.

For organizations that have less mature IT departments, try to take a step back from the data and identify where there are logical breaks. Do you see applications divided fairly evenly between 24, 48, or 72 hours? Are there lots of applications with RTOs at the 1 week or 2 week+ levels? Try to envision how you might organize all the applications into three or four groups. Consult with IT representatives to get additional input as needed.

While this will likely not be the final determination of a tiered structure (at least not without IT’s input), feel free to start placing applications into tiers and see how the distribution falls until you see a structure with applications either fairly evenly distributed among different tiers or results resembling a bell curve.

Step Four: Step back from your results, get input, and consider costs.
Once you have a solid draft, seek input from other stakeholders (e.g., program managers and information technology subject matter experts). Keep in mind that while the business impact analysis is identifying organizational requirements, there may be a substantial amount of investment required to build out IT systems to the point where they can actually meet the business’ requested RTOs. Try to look at your results the way your Chief Information Officer would. If you see numerous applications with very aggressive recovery time objectives (e.g. RTOs less than 48 hours), understand that there may be substantial investments required. As a business continuity practitioner, your role is to convey what the business is requesting in an organized manner and present management with options. BUT, in the end, it’s ultimately up to management to decide whether it is worth investing capital to achieve the requested results. The organization’s risk appetite will help to determine the appropriate approaches and strategies.

Step Five: Hand off your results to the decision makers and ITDR planners.
Once you have taken the results from the BIA, extracted application and system requirements, ensured the results are generally free of inaccuracies and inconsistencies, and logically grouped the information, you should be left with a product that can be handed off to help generate IT strategy. What you have just produced serves as both a report and recommendation; however, remember that there may be some technical limitations to the document you have just produced. For example, when ITDR planners look through the results and see aggressive RTOs associated with specific hardware platforms that are not easily replicated at a DR site, some of the requested application RTOs may not be feasible. Be sure that both business continuity and IT disaster recovery planners continue to collaborate closely. When solutions cannot meet expectations of process owners, practitioners will need to be able to explain why and what actual performance might look like.

There will always be an element of subjectivity in developing business continuity and IT disaster recovery strategies. As the business continuity practitioner, your role is to explain the process behind any recommendations and understand the impact to operations to provide stakeholders with a clear view of business requirements and potential strategies. As IT dependencies continue to become more and more prevalent in the workplace, the ability to bridge the gap between business continuity, IT disaster recovery, and management is a very important skill. By collaborating with both business owners (for the BIA) and the IT department (for ITDR strategy development), you are helping to improve the organization’s overall capability to continue operations regardless of the disruptions it may face.

Please contact us if you would like to discuss specific strategies or approaches to align your business continuity program with information technology disaster recovery initiatives, as we have helped numerous organizations identify the most cost-effective and modern recovery strategies that meet the business’ most aggressive recovery objectives. We look forward to connecting with you!

_______________________

Michael Bratton
Avalution Consulting: Business Continuity Consulting

Our consulting team regularly publishes perspectives (shorter, independent articles) that touch on the trends currently affecting our profession and the strategic issues facing our clients. This is one of our most recent posts, but the full catalog of our perspectives – over 100 published since 2005 – can be accessed via our blog.