What is the maximum tolerable downtime for these critical business functions and processes?

MTPD: what business continuity professionals think about it and how they calculate it

There was a good reaction to the survey, with 167 responses being received in the fortnight period that it was open for.

The majority of respondents (87 percent) believe that they understand the MTPD concept . 10 percent aren’t sure whether they understand it and 3 percent do not understand what MTPD is.

How useful is the MTPD concept?
Overall 56.5 percent of respondents think that MTPD is a useful concept. 21.5 percent say that it is not useful and 22 percent are unsure.

When broken down by organizational size,  there are some interesting and significant differences. Small organizations (1-99 staff) are the most positive, with 79 percent of respondents from these organizations stating that MTPD is a useful concept. 55 percent of large organizations (500+ staff)  agree that this is the case. However, only 33 percent of medium sized organizations (100-499 staff) think that it is useful. 50 percent of the latter said it was not useful and 17 percent were unsure.

Respondents were asked to explain their view on the usefulness of the MTPD concept. These are reproduced below. Apart from spell checking they are reproduced verbatim:

Responses from those who said that the MTPD is NOT a useful concept

• As a manufacturing company we know to the last minute and penny when our critical processes are at risk of failure.
• Because it is difficult to identify and may alter in response to alternate actions taken. In reality it is the acceptable risk identified by Directors that practitioners work to.
• I believe that the business line must continue to define only its RTO= BRTO. According to the BRTO, crisis management and the IT must be organized in the respect of this BRTO. That means for example that, to respect the 4 hours BRTO  it is necessary to define a latest deadline for decision making/crisis management. The crisis must be managed in one hour to be able to leave the IT with 3 hours at least in order to prepare the BCP site and to allow the activity to continue in the 4 hours respect defined by the business via the BIA. The DRP will follow the same rule, the application derives the BRTO from the process, the crisis will have to be managed within one hour to leave  the IT 3 hours at least in order to prepare the site of DR and start again the application in the respect of the RTO. It would be necessary to continue to ask the Business to define only the RTO, and to derive information RTO IT with a rule at legal Entity level so that: Time of decision by the committee of crisis + RTO IT of each necessary application <= RTO process of the business line. To require to each business line a MTPD  more than one BRTO for each process will result in the answer from the Business : MTPD and RTO for us are equal and represent the maximum deadline  acceptable.
• I don't believe it adds anything new to the BIA process. I have always calculated this but from the other angle - within what period must a business/function be able to resume (essentially the RTO), rather than how long can it be out for? Personally I think it just adds another unnecessary and confusing acronym rather than any additional value
• I work in the financial industry. This concept is almost impossible to calculate. We need to take market movement, client perceptions and damage to brand and reputation into account, which are all soft issues.
• In practise, the RTO for the initial Phase 1 of the recovery process serves as the MTPD. BCPs therefore don't refer to it as it just further confuses users with this jargon. Recording RTO (containing the RPO) are sufficient for users to get the job done!
• It has created great confusion.  The most common issue is whether it refers to the period until the business needs to start processing at any level or is it the period until the business has to be operating at full capacity?  The confusion is worsened by the fact that the RTO for some IT services is less than the MTPD and for some it is more.  For example, our FX settlement system needs to be up before the MTPD so we can catch up with the trades that have happened in the period between failure and recovery but our FX trading system does not have to recover until after the MTPD as we can manually enter trades for a short while.  As professionals, we should be going out of our way to remove barriers to success and understanding.  MTPD does precisely the opposite.  It is a nonsense that should be banished.
• It is a waste of time as major organisations will not allow activities to fail. The concept was dreamt up by some theoretical academic with little practical experience in managing real disasters and incidents. MTPD is unclear in the standard and we should be looking at a measure of impact at which time the business needs to take extraordinary actions.
• It is an unnecessary, redundant concept created to 'differentiate' BS 25999.
• It is at the base level a re-hash of RTO and RPO concepts.  However it's added "complexity" only increases verbiage and decreases clarity.
• It is confusing and not used before BS25999; its exact meaning and application is unclear
• It is confusing to the core critical business that must resume operations following an event that impacts normal operations.  RTO is best used for operations and RPO for IT/DR
• It is very difficult to get Business areas to understands the concept of MTPD
• It tended to confuse the non practitioner when trying to get decisions made by stakeholders
• It's just an precursor to RTO
• MTPD does not fulfil the requirement of analysing and understanding the true end point of an organisation. There are single points of failure in any organisation and single business strands that, if not there will cause the business to collapse. It does not take a genius to work this out or present it to a management board. It is arrogant for any business continuity person to try and present some theoretical point in time to a management board and tell them that "the end of the world is nigh". I don't want some snotty business continuity analyst telling me when my business is likely to fail. I understand my business and I know my cashflow situation throughout the day and I also know the critical business processes associated with the delivery of my business.
• MTPD is a confused expression that seems to have been invented by a committee of academics with time on their hands to demonstrate how clever they are.  The correction was then given a Latin name, again to show the cleverness of the people involved in making the change. MTPD does not influence our thinking or our method of delivering business continuity. It ought to be dropped as a term and a more realistic expression used to determine the point at which an organisation can no longer function effectively.
• MTPD is often very difficult to quantify (so figures are often just guesses (twice RTO, RTO +3 days etc.). RTO is a much easier concept to quantify
• Prefer to address individual business and infrastructure RTO/RPO as component parts along disruption timeline. The recovery strategies need to address each component to produce the end-to-end result. This is not possible with MTPD concept.
• Recovery Time Objective when agreed by management is the most important goal.  RTO will always be the same or less than MTPD.  MTPD is just another acronym that causes client confusion.
• RTO well know and the results are the same - depends on wording in BIA
• Still use RTO and MAO this is mainly because of business acceptance and understanding and generally perceived little value in changing the terminology just for the sake of it.  Why change if there is no demonstrable 'value add'.
• The concept of RTO is more useful as it is the target for making decisions regarding restoration priority and resources needed to meet that goal. MTPD I believe is too vague.
• The increasing introduction of obscure business continuity jargon to support an academic model of ideal business continuity does nothing to improve our profession's credibility within our businesses.  In our business, BCM will always be overhead and a distraction to our business partners.  Sticking with simple, accepted terminology and focusing on practical means of establishing how time sensitive a business function is and what the business needs to do to improve its resilience is the only way to establish credibility and be viewed as valued and trusted partner to the business.
• The MTPD makes reference to the full restore of the service, which is irrelevant for BCM. It is the minimal service level that should be equal to the MTPD, not the "full service level"
• The nature of disruptions is that their consequences are unknown.  If your organisation is disrupted for longer than the MTPD - for whatever reason - then what? Do you go bust?  Are your continuity plans rubbish? Restoration of business after a significant interruption should not be against the clock. Continuity plans should cater for your organisation being out of action - not just recovery.
• Too complicated a concept to get over /explain to the uninitiated. Assumes a level of understanding that most people outside of BCM don't have!
• Too confusing for use in a large enterprise, where no single activity failure would render the organisation unviable.  It is just one more committee created acronym that makes it more difficult to sell the BCM concept to senior management.   
• Too much for people to handle.  Suggest describing it as a useful addendum for advanced practitioner companies that have done the basics, and not as an entry-level best-practice requirement.  Especially companies in the Asia Pacific that are so new to BCM.
• We already use RTO and RPO, no reason to change.
• What am I going to do with the information that MTPoD gives me?  The Standard gives me no steer on its usefulness.

Responses from those who said that the MTPD IS a useful concept

• Allows the Business Areas to have a discussion with the IT areas, and to seek clarity on whether business process can be restored to meet business requirements....otherwise a "discussion" is needed to either revisit the MTPD or find some more funding to improve the Recovery Time Objective (RTO) by the IT departments.
• as a public service we find that MTPD is a more useful tool than loss based calculations
• As a way of determining how long an organisation can be "out of action" or running as a reduced service, this is as good a measure as any.
• But only in the context of identifying RTOs (for non BC experts).  I don't believe it is required as part of BS25999 as RTO supersedes it.
• Despite being a bad acronym, it is a concept understood by management and aligns to products and services, as opposed to RTO (which aligns to organizational entities, processes and resources). 
• Gives an imperative in addition to the RTO
• I deployed a DR methodology for the Local Government sector in Victoria (79 Councils). Councils do not "die" or  go out of business. MAO is a good concept for the maximum time of return of an IT application before the loss of the app causes "grief". The RTO is always inside the MAO. MTPD is used to determine the maximum time that can elapse once the app is returned and all data entry (from manual workarounds) has been caught up.
• I feel it extends RTO to the period of incremental or total recovery, since critical work will happen though disruption is there. While RTO is the period where disruption has occurred and recovery is yet to start.
• I like it but it will take a little education to get mgt to look at overall concept instead of specific technical requirements.
• I previously used MAO, but MTPD is more intuitive by its title alone. One downside MTPD does not roll off the tongue like MAO does.
• If used correctly it can help during the business impact analysis for establishing expectations (as RTO alone is too limited a concept).
• In some instances not all task/applications are needed in a process so MTPD sifts out the key requirements and help to identify the recovery activity critical path.   RTO is the desired MTPD is the absolute must have.  Sometimes the RTO and MTPD are the same and that's okay but asking the MTPD question in the BIA phase often induces scrutiny of individual tasks/processes at more granular level detail.
• It allows me to clearly articulate a number of concepts with respect to the link to the business requirements and the lead time to restoration for IT DR, and the sourcing of all other dependencies.  It also leads the discussions when looking at underpinning any spend and workarounds required.
• It assists in determining the timescale in which if the function or process is not recovered it will have an extremely detrimental effect on the viability of the organisation. This helps with setting the recovery time objectives so that they are well within that critical period.
• It brings into play many more factors than just RTO.  It may help customers to understand how difficult it is for a BC or DR program to answer just to them.
• It explains how long a business/process can survive before failure to recover would compromise its ability to continue to operate effectively.
• It fits closely with the BIA process and within IT, helps determine the RTO and RPO by ensuring recovery capabilities do not exceed the MTPD.
• It focuses the business on exactly how long they can survive without some form of recovery.
• It forms a true recognition of the level of service a customer requires and also focus to endure that control established in important area in order of priority
• It helps de organization to define the minimum time needed to respond in a disruption situation.
• It helps explain to management what the absolute acceptable outage is.
• it helps prioritize processes or technology during recovery
• It helps to define clearly how long a business activity can survive before mitigation and recovery plans are implemented
• It helps to focus the minds of the services to what is REALLY important and gets people from different units talking. 
• It helps to get senior management to concentrate on business continuity & its' importance to keeping the organisation viable
• It is a good way to prioritise recovery of business areas related to financial risk and risk related to reputation as both these parameters can be related to the duration that the business area/s is down
• It is a useful concept if the activity that is being protected is a manufacturing process or is that critical to income generation that a lack of that service will result in bankruptcy. When it comes to the public sector and the delivery of services I do not think the concept is relevant, because however long a service may be interrupted for, it will eventually be restored. BUT, recovery time objective (RTO) and recovery point objective (RPO) are more relevant in governing when a minimum level service can be recovered.
• It is another tool in helping the business manager understand how to think about interruptions.
• It is helpful to make the organisation think through the impact on management, customers, media and when the 'stuff' hits the fan
• It is useful  as well as the company  will be able to estimate what is the most extreme time framework in which is required to operate in a reasonable way.
• It is useful because it is to be used during BIA to categorise services into what may be critical or not. It is to be used to determine impact of disruptions to organisations.
• It is useful in a couple of ways. Initially it allows you to consider maximum down time, which is a sobering thought. It is also useful to assist with categorizing the Critical Activities.
• It is useful because it allows businesses to fully understand if there is any gap between their recovery time objective and their MTPD.
• It is very useful concept. It gives a reference point that is  in conversations with leaders of business activities and top management.
• It is a useful concept if it replaces the MTO and enables a further acronym to be defined - BRTO which is the 'business recovery time objective' that embraces the objective that the business must aim for during the recovery process. The difference between BRTO and MTPD enables an absolute limit to be set (MTPD) whereas the BRTO may be governed by the time the incident occurs.  
• It provides more context for business folks than MAO ever did.
• It provides the baseline for capturing RTOs in outsourced IT service agreements.
• It reduces the need for specific scenario planning, because it focuses on managing the financial impact to the business, rather than on the cause.
• It serves to differentiate between business timescales and ICscales (RTO, RPO etc)
• It's important at a very basic level to understand the business need against the IT RTO capability.  If the RTO for a critical app for the business activity, then there is a gap that needs to be addressed.
• It’s not a calculation done by consultants. It’s a calculation done by Business Units and Divisions to ascertain their threshold level of total business disruption, this then determines overall Recovery/Continuity requirements....This is not rocket science!!! MTO is the same thing, not sure why we are reinventing the wheel
• It’s useful as it goes beyond RTOs, RPOs, RTNOs.
• Measures the whole end user experience not just IT recover y
• MTPD allows for a distinction between "RTO" and "MTPD". Having only the term "RTO" assumes a utopian world where a business need is met in every case by the RTO. MTPD allows for BC professionals to clearly demonstrate the difference between or overlap of MTPD and RTO.
• MTPD gives your business a time frame or goal in which they have to meet to reduce the disruption to the business. This time frame whether it be hours, days etc is understood by all within the business. Although your goal is to get the business back up and running as soon as possible so you could just use the RTO
• MTPD is a far more useful concept than the old interpretation of RTO as it measures the tolerance to disruption from the time of the disruptive event - overcoming the inclination to disregard the recognition, reflection and decision-making delays.
• MTPD is poorly defined in BS25999 but it is a useful concept.  It helps top management define its risk appetite.  In short, how bad can it get before there is an unacceptable chance of irreparable or lasting damage to the organisation that would be very difficult to come back from?
• MTPD is very useful in defining the pain thresholds for the services, products, and supporting processes and components. It actually serve as a border line that should not be crossed.
• MTPD provides the maximum criticality point for each process or asset / resource.
• Not only does it focus the business on the need to prioritise critical activities, it helps inform our contracts with IT suppliers of the required response times, in case of IT failure.
• Once clearly understood MTPD can assist in clearly defining your services.
• Once you've determined the MTPD, you can then focus on avoiding the outage trigger and developing a BCP to cover these critical business areas.
• Our approach was to take BIA data and translate to MTPD with the same metrics used in previous Impact Analysis, the focus on our vendors and supply chain was the latest focus and it was determined by several factors including results of audits of BCM capabilities of critical suppliers.
• RTO, RPO,NTO (network)  are mainly objectives related to I.T. and a corporation DRP. They account for MCAs. MTPD : Finally, MTPD allows a corporation as a whole to set a maximum allowable and tolerable continuity of operations downtime.
• Strategy creation. If you know the business you are in you can make decision - supported by shareholders - about MTPD. It is a good tool in case of incident modifying changing the existing strategy. It keeps you awaken - making decisions on time.
• The business needs to understand how long it can tolerate disruption to individual critical business processes, however, it is often the component steps that they cannot tolerate loss of, rarely likely to lose the whole process
• The concept helps people think about the relative importance of activities. It can be difficult to apply because people don't always have the same context (business unit vs company-wide view) or give different weights to different aspects (financial loss vs reputation impacts vs customer impacts, etc.).
• The concept is useful because it helps the organisation to understand the impact of the disruption, and the period of sufferance. This in turn will help focus the mind on what survival procedures need to be planned / implemented and at what point these should be activated...
• The concept of maximum tolerable period of disruption is understandable by the customer than time to disaster as many customers have a problem identifying when a problem actually becomes a disaster:
• The MTPD is an indication of the criticality and the value of the process to the organization. The MTPD sets the priority for risk assessments which in turn assess the threats, vulnerabilities and probabilities for partial or total disruption scenarios.
• This concept directs an organisation towards a baseline on which threats and vulnerabilities may be assessed. In other words the question if an event occurs and causes disruption, how long can that disruption be tolerated ? Is easier to ask, for those who do not have BC at the top of their day job priorities, than more direct questions about threats etc. Some staff also view BC as the answer to every crisis and MTPD concepts allow this philosophy to be tackled so that people see disruption in a much healthier way of pressure, escalation and crisis before BC plans are enacted.
• To me it is the same as defining RTO - the time when you have to have a business function or an application recovered in order to avoid unacceptable impact to the business.
• Very useful as it made everyone aware of all the critical points in our operations and continuous risk assessments are carried out on these critical points
• we adopt the BS 25999's definition
• While the theory is sound, the defining and application of the theory needs to be further developed.  The greatest issue with MTPD is that it is not explained very well and in some cases it is defined in a too narrow field of operation (i.e. the point at which the business ceases to be viable) and this definition does not sit well across many public sector or service organisations.
• within the fire and rescue service we need to ensure that all our HQ departments and stations are able to maintain core business no matter what the disruption
• Without knowing the 'point of no return' you cannot intelligently set a recovery time objective.  Without it you may overspend hugely on recovery - or you might be bust before your recovery kicks in
• Yes as it is used to managed stakeholder's expectation as well as a target for which your response should be in place to minimize impact of disruption to vital processes or activities of the organization
• Yes in theory, harder to quantify in practice.
• Yes, it gets over the idea that it may not just be the event which causes the disruption, but the follow on repercussions. Also that you may be able to recover but at a reduced capacity.
• Yes, it highlights the difference between RTO and MTPD: RTO must be (quite a bit) shorter that MTPD. RTO is an objective, MTPD is a kind of point of no return for a process or company.
• Your RTO must NOT be anywhere near your MTPoD

Responses from those who are UNSURE whether the MTPD is a useful concept

• A useful concept but very difficult to get useful data.  Most "estimates" I have seen are really guesses from BC staff - not really a "customer" viewpoint
• Although I understand the concept writing the BCPs is done by individual departments etc and regardless of how much training they have they still seem to get it mixed up with RTO. Unfortunately some of this is down to workload as BC yet another task amongst many for the contacts
• Depending on the size and structure of the organisation, along with the type of organisation it is. It is much more applicable to manufacturing organisations as opposed to services or government companies
• How is it different from Max. Tol Outage (MTO)?
• I clear Definition of MTPD is necessary to prove the concept
• I do not know how to calculate and depending on that
• I feel that it is fairly useful as a marker for your contingency planning, but difficult to verify.  It seems like a finger in the air at times.
• I have not used the MTPD concept so it is hard to say if it is useful.
• I use RTO and RPO analyses. I did not really analyse the MTPD already
• In many cases it cannot be a finite period in time as this could differ from month to month, week to week, day to day or even hour to hour.
• In theory this concept can be a useful tool but to many people within the org mis-use or mis-understand the concept
• It has added a level of complexity that did not exist before. Measuring MTPD for a particular business process can be extremely difficult as differing parts of the same process have a different MTPD.
• It is still confusing subject though we implemented it in our organization as per 'our' understanding of this subject. I have seen that many discussion start on this topic and left unclosed as everyone has different opinion. In brief it is an extension of 'RTO' where the actual recovery time is included plus some cushion is kept as provision for complete recovery of services be at DR site or production if it could be possibly brought  up back.
• It's difficult to ensure that all the MTPDs are on a consistent basis, particularly where finance is not involved.
• It's just another method of describing a concept
• MTPD is either not totally understood or used in the region
• Our organisation identifies how long critical functions can remain undelivered and within that we break it down into what resources are needed at what time to maintain critical functions ie Child Protection is a critical function and service needs to be restored within 4 hours although officers would not need their office building to deliver the service as they could work from home/other offices etc.  So knowing this helps us organise our response to any disruption
• People seem to be defining this differently - I don’t think the definition in BS25999 is clear enough.  Is the MTPD the time to resume the function to any operating level or back to the normal levels pre the incident?
• Personally I don't think MTPD as a concept is particularly helpful, especially given the confusion over its meaning in BS25999. Most of my clients manage perfectly adequately with RTO and don't get too hung up on MTPD.
• Prefer MAO (Maximum Acceptable Outage). Simpler concept, easier to say!
• Properly used, RTO and sliding recovery periods to BAU should be adequate to reflect
• RTO may be enough! Most times, MTPDs may be agreed with the management board and not calculated or evaluated by business...
• The label/term is not readily used within our organization but the concept is and the concept is effective.
• To the business, MTPD could provide a clearer definition than MAO etc. BC practitioners, however, are overcomplicating and overengineering the definition and its current linkage to a standards based methodology causes many to shy away. Consequently, until the dust settles, clarity is understood, agreed and in general practice, it is my opinion we continue to use MAO, which the business currently understands reasonably, and keep the business away from the still turbulent and muddy discussion around "what is this thing called MTPD?".
• Traditionally RTO and MTPD have gone hand in hand. However, we could do with just one... But it’s not like you can do away with both of them, for an effective strategy you need to have at least one of them....
• Trying to co-ordinate ( and manage) BC arrangements across a large organisation with a changing group of business representatives it is easier to introduce RTO and get to the RTO by considering MTPD
• Useful concept YES.  Useful practical applications - NOT ALWAYS. Technology drives individual areas to state that the MTPD is restricted to a sensible recovery time (eg 24hrs) however the knock on effects of this 24 hours are not always considered and therefore a view is taken in isolation.

Are organizations using MTPD and how are they calculating / estimating it?
Exactly 50 percent of respondents’ organizations are using MTPDs within the business continuity planning process and 48 percent are not. (Two percent don’t know.) Again there are differences according to organizational size, with 79 percent of small organizations, 48 percent of large organizations and 42 percent of medium-sized organizations using MTPDs.

How organizations calculate or estimate MTPDs:
Respondents were asked to briefly describe how MTPDs were calculated or estimated if this was done by their organizations. The results were as follows, again verbatim apart from being spell-checked:

• *) Regulatory requirements *) Assessing impacts *) Dependencies
• Based on BIA results 2) BIA is structured on quantitative value assessment of impacts, 3) Hi-management then set the MTPD based on operational impacts and not to exceed downtime. We calculate MTPD based on the results of an organisation BIA decisional Matrix defining quantitative values
• A number of ways, briefly: 1. how much (in financial terms) will the organisation stand to lose from the point of failure. 2. how much (in financial terms) will the organisation stand not to gain, from the point of failure.
• after the BIA, combining Businesses RTOs and ICTs RTOs
• all our BCM plans have MTPoD timelines in them for various events/emergencies to enable departments and sections to maintain business as usual where possible and to highlight main areas for concern
• As a manufacturing company who sell to affiliates, we know the MTPD timescales that we must meet in order to minimise irreparable damage to our brands.
• As per previous feedback box... the RTOs used in template form serve as the MTPD (although not explicitly named as such). There’s the minimum service delivery (Phase 1 = RTO) that gets bulked-up over time to eventually have services "back to normal".
• Ask the senior executives
• Average transaction volumes/values are calculated and a risk based approach applied to potential losses arising from different disruption periods (eg 1,3,5,7 days).
• based on customer requirements and realistic capability with existing resources/resilience
• Due to the MTPD we are now aware how long supplier takes to provide us with parts or how long our client can wait and it has helped us in determining what stock to keep on site, etc and alternative ways to operate in case of emergency
• Estimate based upon business knowledge...then reviewed depending upon any other business interdependencies
• Estimates by business professionals
• How long the business can operate without haemorrhaging
• I deploy solutions for clients so this question is irrelevant
• I have used this as practitioner and as consultant both. But at the organisational level/ BU level (rather than at process/ activity level) and with a great flexibility.
• I use it in meaning now described by corrigendum to BS 25999 (which is similar to meaning used earlier by various organizations - e.g. DRII).
• I use something similar when conducting BIAs but it's not quite the same as the BS25999 definition of MTPD.  I look at the point at which the disruption to an activity would cause intolerable or unacceptable impacts, which informs the RTO.
• I’m planning to - but have recently started at new organisation so no plans in place as yet.  At my old organisation, we included MTPD and just gave the definition of the standard i.e. how long could you cope without the function before viability would be threatened.  Obviously it had to be greater than RTO.
• In Banking there is a complexity of MTPDs. This allows for recovery resource/facility and exercise optimization regarding high availability and deferred RTOs.
• In the two organisation in which I have used this concept (both public sector, one of which is certified to BS25999) the calculation is based not against organisational viability but about the achievement of outputs to the customer/client and outcomes against the business plans.  Because of the significant political drivers and imperatives in public sector organisations this has more value than looking at organisational viability.
• Is used in the Risk description within the BIA.
• It is a mixture of actual experience from when the critical activity has not been available and how bad things we getting without it.  Othertimes it is just a mixture of experience of the importance of the activity, the speed of impact that denial of the activity would have and the speed of response by third parties. 
• It is an estimate based on past disruption experience, current market conditions, reputation etc.
• It is calculated using Service level agreements, contracted service provision to customers, Key performance indicators etc
• More art than science, assessment of when company would have question marks over the ability to continue.
• MTPD calculated as the maximum period of time an identified key business process can remain unavailable, considering both recovery point & time objectives and work arounds (if applicable), before the financial and or operational impacts reach unacceptable levels.
• MTPD cannot be calculated with any precision and is in any event modified by BC/DR, i.e. putting some BC in place increases MTPD.  I'd typically regard this as the point on the BIA at which impact = very high or catastrophic.  This differs from RTO, which is less than MTPD and a choice based on affordability and impact tolerance.
• MTPD helps identify critical recovery requirements when there are conflicting demands with limited recovery resource
• MTPD in our business is maximum downtime for products and services. 
• MTPD is calculated as the time period by the end of which the organization will has extremely serious consequences if normal working has not resumed.
• MTPD is that time after which an organisation must begin to deliver a service that has been disrupted. It will cover the time to move to alternative location+compliance with SLAs+Equipment set-up time+Recovery Time Objective.
• MTPoDs come from the BIA interviews with our managers. A brief discussion is needed to explain to them the concept.
• Only to satisfy the requirement for BS25999, and even then it was a simple statement for inclusion in the impact assessment.
• Qualitative and quantitative ($), as agreed upon by management and the executive.
• Some departments do and I am currently carrying out an organisation-wide survey to determine how each department calculates their MTPDs.
• Subjective.  Unit managers make calculations on what would happen if their business is disrupted, and no recovery efforts whatsoever are made.
• The company's definition is non-standard and does not make any sense to many of specialist BCM practitioners in the organisation. 
• The MTPD is always equal to or more than the BRTO
• The time factor makes it serious - and brings in the business view into the planning. Time is money :-)
• This is assessed on the basis of experience and guessing - which is why I would question the validity of using it - as it can serve as yet 1 more aspect to confuse.
• This is established from questions directed to the customer and their needs as to what we can do for you, the customer, rather than what we can do, period. 
• Through information gathering with staff
• to ensure we focus our efforts in the appropriate areas to mitigate the risk in a prioritised fashion
• Used to determine the overall business process recovery options and is maintained as a global benchmark in looking at the over al continuity provision for each process or subcomponent.
• Using a qualified and quantified impact matrix the time to organisational atrophy can be assessed for all business units against a common matrix/scale.
• Using agreed criteria which we have incorporated in our BIA to assess how fast the risk affects critical activities
• We are not a revenue-generating company so our MTPDs are based more on relationship management impacts, which is very subjective, and regulatory requirements, which are partially influenced by our ability to manage through backlogs created by a disruption.
• We built response plans based on early warning indicators, for example if our suppliers in China is facing a facility outage that will be sending parts to our manufacturing plants a subsection of the plan is activated and our procurement and risk management team begin to contact pre-identified suppliers that can fill the gap.
• we calculate by empirical/clinical judgements of maximum time for which defined patient cohorts can be left before there is an increased risk to health/welfare
• We calculate it based on an estimated period which the process manager understands as really impactant to our organization, if his process is disrupted. It’s pretty much subjective, but this estimate is just a parameter that will be refined. We deal with this period as a starting point to define the RTO.
• We calculate the maximum tolerable time as a form of risk tolerance and compare this to our estimated outage time to work out priority areas for further continuity planning and/or testing
• We calculate the stock-cover for the top SKUs manufactured and calculate the time to 'fill the pipe' with replacement stock and then work back to the point where, if we don't start production, we would face an 'off the shelf/stock-out' situation.
• We estimate the point at which "pain" will be experienced - then evaluate the effect of any short-term / interim contingency to mitigate the impacts pending full recovery.
• We first collect the MTPoD for each business activity, look at the business activity's interdependencies, complete the BIAs for all areas, then prioritized order of recovery and criticality.  Then MTPoDs need to be analyzed to determine the ability to meet the activities' recovery needs.
• We had no choice.  It's a requirement for certification.  The period of time the key product or service can continue for at a BC-level, before it leads to the demise of the business.  NB.  I have since changed my mind and now I calculate MTPoD as equating to BAU.
• We have just ventured into BCM. Currently we have just used estimates provided by process owners based on their SME and proficiency as being the process owner
• We stick to MAO as noted in 2.
• We take the financial impact and extrapolate the projected losses over time to include additional cost of working plus reputational damage. In interviews with senior management we agree the point at which the business would suffer the most and cannot continue any further.
• We use Maximum Acceptable Outage - and are still having trouble with business understanding that this is for the process, and the RTO is for the system /application supporting the process
• We use RTOs  based on SLAs
• We use RTOs and MTPDs. We start with a scanning process - MTPDs of less than 7 calendars days (MUST DOs); 7-30 days (SHOULD DOs) and 30+ days (COULD DOs or things that need to be re-established before BAU is restored). We then revisit the MUST DOs with a risk rating and confirm or reduce < 7 days to no downtime or an agreed MTPD at a timeframe in between. I have used this approach with 3 clients. It seems to work well and is well accepted.
• We use them or prioritise the business processes which require the earliest attention in the event of a business continuity incident
• What is the maximum time the activity can be left until the company will suffer to such an extent that it can no longer continue.
• What we do is by each process, we define resumption of service at different levels based on business needs and IT resources availability, to a level where 100% service is resumed either at our DR site or production site if it is brought back to normal. That 100% level service is MTPoD for our activities.
• Would call it a guesstimate, not a calculation.
• Yes - But not always... We use RTO and build the MTPD into this calculation
• Yes but we don't call it MTPD. We call it the Recovery Time Objective that is based on the findings of a BIA.
• Yes-ish.  Some parts of the business are easier, e.g. those with cyclical operations, others it is almost impossible and reverts to 5x the RTO!

•Date: 9th Sept 2010 • Region: World •Type: Article •Topic: BC statistics
Rate this article or make a comment - click here

How do you calculate maximum tolerable downtime?

What is meant by maximum tolerable downtime?

What is the acceptable level of downtime?

What is downtime tolerance?