BIA Alignment? We Don’t Need NO Stinking BIA Alignment!
Industry best practices recommend that the BCM Office align its organizations Business Impact Analysis (BIA) derived Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) with Information Technology Disaster Recovery (DR) capabilities on a regular basis.
  So, here is what are we finding in the industry: Â
- Management does not understand the alignment process and does not recognize its value.
- The business and IT have different RTOs and RPOs matrices so the alignment process can be somewhat difficult to accomplish.
- IT does not provide Recovery Time Actuals (RTAs) or Recovery Point Actuals (RPAs) for the critical systems and applications.
- BIAs are conducted and RTOs / RPOs defined by the business but IT still sets its own timeframes for recovery based on what it can do versus what is needed.
- The business will reset the RTOs and RPOs to what they can achieve versus what the business BIA derived demands are to continue operations.
- They don’t understand that these are objectives and are different than actuals.
- In limited instances, IT can exceed the RTOs and RPOs but does not communicate it to the business.
 They don’t want to be held to it. Â
In a perfect world, you should have an alignment meeting at a regularly planned interval (e.g., annually) to identify successes and gaps in business expectations and IT delivery capabilities. A simple table should be constructed to show alignment and gaps:
| Application | RTO | RTA | RPO | RPA |
| System A | RTO = 12 Hours | RTA = 24 Hours | RPO = 4 Hours | RPA = 12 Hours |
| System B | RTO = 48 Hours | RTA = 24 Hours | RPO = 24 Hours | RPA = 24 Hours |
| System C | RTO = 5 Days | RTA = 5 Days | RPO = 4 Hours | RPA = 12 Hours |
The BIA is conducted for a number of reasons and ensuring alignment across the organization is one of them. So, get out there and get your systems aligned.
Michael Herrera
Michael Herrera is the Chief Executive Officer (CEO) of MHA. In his role, Michael provides global leadership to the entire set of industry practices and horizontal capabilities within MHA. Under his leadership, MHA has become a leading provider of Business Continuity and Disaster Recovery services to organizations on a global level. He is also the founder of BCMMETRICS, a leading cloud based tool designed to assess business continuity compliance and residual risk. Michael is a well-known and sought after speaker on Business Continuity issues at local and national contingency planner chapter meetings and conferences. Prior to founding MHA, he was a Regional VP for Bank of America, where he was responsible for Business Continuity across the southwest region.
With the advent of, and process/data interdependecies dictated by, large ERP applications (SAP, Oracle/PeopleSoft, ….), how can there be different RPOs? Intuitively, the data in the ERP has to be consistent for all applications for it to recover successfully, which means any RPO must be a very short period of time. Thoughts?
Joe,
In tightly coupled ERP systems, I would agree that RPOs could be be same and not different. But in moderately to loosely coupled systems, there will be different RPOs based on what the business needs and can do to replace lost data. We have seen clients attempt to provide one single RPO across all systems/applications; this is not an effective use of IT resources and technology. You may find yourself providing an RPO that is either not enough or too much, you need to know what the business can tolerate.