Backup Copy for Jacque Rupert

What is it, where did it come from and why is it important to your organization?

By Jacque Rupert.

The concept of Maximum Tolerable Period of Disruption (MTPOD) suddenly appeared with the introduction of British Standard 25999-2, published at the end of 2007. Eighteen months later, it remains a highly misunderstood concept. However, when applied appropriately, MTPOD will improve management’s understanding of your program and add clarity to your recovery priorities.

Background

BS 25999-2, Section 4 states that the goal of a business impact analysis (BIA) is to “determine the impact of any disruption of the activities that support the organization’s key products and services.” A key aspect of determining the impact of a disruption is identifying what BS 25999 calls the “Maximum Tolerable Period of Disruption,” or MTPOD. BS 25999 defines MTPOD as the “duration after which an organization’s viability will be irrevocably threatened if product and service delivery cannot be resumed.” Put simply, MTPOD is the maximum amount of time that the organization’s key products or services can be unavailable or undeliverable before its stakeholders realize unacceptable consequences.

Start with executive expectations

The full application of this concept means rethinking how a BIA is approached. While many of us start a BIA by gathering data from individual departments, MTPOD forces us to first look at products and services. Business continuity professionals should engage their executive managers in a discussion regarding their thoughts on downtime tolerance, taking into account:

• Customer expectations
• Regulatory requirements
• Reputational issues
• Financial and operational impairment
• Strategic consequences.

Based on management input, business continuity professionals can propose preliminary Maximum Tolerable Periods of Disruption for key products or services within the scope of the business continuity program.

Map products and services to critical activities Once MTPOD is established for key products and services, the traditional BIA data gathering process can be used to map departments and processes to each product or service. From there, the BIA can either validate or refute these preliminary MTPOD conclusions. Of equal importance, the BIA will identify the department, function and process details needed to achieve the MTPOD.

Perhaps most importantly, the business continuity professional must understand the amount of time required to perform the process or activity in order to deliver the product or service to its key stakeholders (internal or external). This is often referred to as cycle time. For example, in a manufacturing company, cycle time would be how long it takes to procure necessary stock, manufacture the product, and deliver it to the customer.

Recovery time objectives for critical activities With an understanding of MTPOD and cycle time, the business continuity professional can identify what is commonly accepted as the core output of the BIA – the recovery time objective, or RTO. RTO is the point in time following a disruption when operations must resume (at a minimum level) in order to meet downtime tolerances. The following graphic illustrates this relationship.

MTPOD

In conclusion

To recap, a BIA starts with a strategic executive management-level discussion concerning MTPOD, as it relates to key products and services. The BIA continues with:

• 1. Mapping departments, functions and processes to key products and services
• 2. Organizational data gathering to confirm or refute preliminary MTPOD conclusions, as well as collect department, function and process details (including cycle time)
• 3. Identifying recovery time objectives based on MTPOD and cycle time
• 4. Presenting BIA findings to executive management for comment and eventual acceptance

The business continuity planning process continues with the identification of response and recovery strategy options that meet recovery objectives.

Although our profession does not need another acronym, MTPOD is an important concept that will add context and validity to recovery objectives by involving management input up front and focusing on the ultimate goal – recovery of key products services. Based on this understanding, management can ensure the proper plans are in place so the customers’ maximum tolerance is not exceeded and continual customer satisfaction is achieved.

Author: Jacque Rupert is with Avalution Consulting. http://www.avalution.com/

Make a comment

BSI Commitee response to this article

Reader comment

Jacque Rupert has done a great job in explaining the concept of MTPoD- an extension of RTO. However there are couple of observations I would like to pass along:

1.Traditionally BIA not only covers the RTO (Recovery Time Objective) for each activity/business process/product and services of an organization, but it also covers the RPO (Recovery Point Objective) as well. The reason why we have these two done separately is to identify both the transaction sensitivity and time sensitivity of the organization and its relationship to the impact. Just MTPoD in my opinion does not give management enough information to make rationalized decisions. MTPod & RTO in my opinion only facilitates decision when an organization is just time sensitive. However as we know most organizations are sensitive to both and some may be more transaction sensitive than time sensitive (as an example Security transaction, banking transactions). As Malcolm Cornish explains in the Corrigendum to this article, this exercise of defining MTPod as an extension to doing both RTO and RPO have to be defined at each activity, process and product/service level and is the right approach.

2. This leads to my second point. Not every organization will be able to define MTPoD top down at an organizational level (working with the management) as suggested by Jacque Rupert. Though it sounds really appealing from a conceptual standpoint, practically it is not possible. Most of the time when we approach senior management with such a definition they are clueless as to what that real number needs to be for RTO, RPO or MTPoD. What I propose we do instead is do this bottom up. We go and work with individual business partners and explore what the RTO and RPO along with MTPoD for each business process/ product & service offered by the organization. During this exercise we will also learn which part of the organization is time sensitive and which are transaction sensitive. With that information on hand, we derive what is the MTPoD, RTO and RPO for the entire organization.

Shankar Swaroop Director - Business Continuity & Disaster Recovery Navy Service Exchange Command Department of the US Navy (DOD)