How do you determine the optimal recovery time objective for your business?

Determinar os RTO, RPO e MTPD ideais come?am com a avalia??o dos processos críticos e das dependências humanas e técnicas do seu negócio através da BIA. Você deve identificar quais servi?os, sistemas e atividades s?o essenciais para a opera??o contínua e quais s?o os impactos de falhas na continuidade. Isso inclui entender as dependências entre os processos e como falhas em um sistema podem afetar outros. Realizar essa análise permite que você priorize os processos que precisam de recupera??o rápida e crie uma base sólida para definir o objetivo de tempo de recupera??o, garantindo que os componentes mais críticos sejam atendidos com urgência durante as crises.

I can second that I find the BIA is the most efficient approach to understanding and establishing RTOs. It's easy to over complicate this process with too many metrics I have found over the years. It is also complicated to simplify an approach if there is a very labour intensive BIA capturing too much detail. Corporate Risk appetite tolerances combined with internal / external SLA's are my preferred foundations.

Determine key business functions, processes, and applications essential for your operations. Categorize these by their importance to the business and their contribution to revenue generation, customer service, and regulatory compliance. Check the impact of downtime on each critical function. Calculate the cost associated with different RTO options, as faster recovery often requires additional investment in tech, redundancy & support. Weigh these costs against the potential losses from longer downtimes. Aim for an RTO that strikes a balance between minimizing downtime impact and keeping costs manageable. Ensure RTO aligns with the RPO for each function. Balancing these ensures a consistent recovery approach. Regularly Review RTO & update.

It all gets back to how you manage your projects. Personally, I prefer the Business Impact Analysis. The only way you can do that is to interview each of the department heads. You DO NOT want to interview your IT department first. On more than one occasion, it has been demonstrated that IT really knows little to nothing about what the different departments actually do on a daily basis. One manager actually argued that the department heads were too stupid to know what was a priority. To him, the most important thing was recovering a database. Actually, the most important thing was recovering Outlook. They could get along or several days, but the need for email superseded everything else. If you don't ask, you'll never know.

In my experience, determining the optimal Recovery Time Objective (RTO) starts with assessing the criticality of business functions. I evaluate which operations are vital to the business and the impact of downtime on revenue, reputation, and compliance. The financial cost of disruption is factored in, as well as the resources required for recovery. Additionally, I engage with stakeholders to align recovery goals with their expectations. By balancing operational needs with resource availability, I set an RTO that ensures minimal disruption while maintaining a feasible recovery effort.

Meanwhile, a non-critical service could tolerate a longer RTO (e.g., 24 hours). Balancing RTO with downtime tolerance ensures cost-effective and efficient recovery strategies.

Let me attempt this with a case. All ATMs of a bank go down. This is an incident for sure, may be not a crisis. The Head of the ATM Operations may be jumping up-and-down, but the CEP of the bank may be cool and calm. I, as the consultant, would like to show a mirror to the Head ATM Operations - 'how much do you make for the bank?' politely, I will reword 'how much do we lose in what time if the ATMs are down?' The answer may be 1-5% of the Bank's revenue. Then, as the CEO, I would like to focus on the remaining 95-99% of the business. My priorities will be HNIs, corporate customers - from whom the Banks makes most of the money. A BIA with realistic RTOs has just been conducted 'by showing the mirror'!

Lets imagine you have bank and running 5 Services - As per BIA you have data which service's are critical. 1. Service A- Loss of service for 5 Mins=1M $ 2.Service B-Loss of Service for 5 Mins=0.75M $ 3.Service C-Loss of Service for 5MIns=0.50 M$ 4.Service D- Loss of Service for 5 Mins=0.40M$ 5. Service E- Loss of Service for 5 Mins=0.30$. Imagine you have lost one of the above service on business day and depend on which service is lost You have revenue data with your CEO and put across this find MTD which Bank can bare revenue loss.

O tempo de inatividade máximo tolerável, ou MTPD, é uma métrica crucial na defini??o do objetivo de tempo de recupera??o do seu negócio. Determinar o MTPD envolve compreender a perda financeira, de reputa??o e de servi?o que sua organiza??o pode suportar antes que se torne crítica. Conversas com líderes de diferentes departamentos sobre as consequências do tempo de inatividade ajudar?o a criar um entendimento mais claro do limite aceitável. Com esse conhecimento, você poderá estabelecer objetivos de recupera??o realistas que n?o apenas protegendo a opera??o, mas também atendem às expectativas dos stakeholders e minimizam riscos potenciais.

Para determinar o tempo de recupera??o e o ponto de recupera??o ideais, RPO, RTO e MTPD, considere seus recursos e capacidades de recupera??o, alinhando-os ao seu apetite de riscos. Utilizar o modelo 80/20 (Princípio de Pareto) pode ajudar a identificar quais 20% dos recursos causam 80% do impacto nas opera??es para assim os priorizar. Avaliar onde você pode obter os melhores resultados com o menor investimento é essencial. Isso significa alocar recursos adequados para os sistemas críticos que realmente impulsionam os resultados. Com um entendimento claro das prioridades e das capacidades de recupera??o, você pode estabelecer RPO, RTO e MTPD que equilibram eficiência e risco, atendendo assim às necessidades do negócio.

To determine the optimal Recovery Time Objective (RTO) for your business, assess the criticality of functions and data. Consider factors like customer impact and revenue loss. Align RTO with realistic recovery resources and capabilities. For example, a financial institution might prioritize faster recovery (e.g., 4 hours) due to transaction sensitivity.

What business processes support the delivery of services? The answer is, all of them. So, you have to understand which areas of the business produce solutions that must be restored in order to continue the mission or purpose of the organization. A business impact analysis can aid in gaining this information when delivered properly with appropriate questions. If the business is providing contracted services, the contractual time requirements must be met. If the business is providing services that enhance people's lives (i.e, convenience/product increases revenue), then the gauge might be the most time a company could afford that to be unavailable. Ultimately, financial impact (revenue) drives the RTO, coupled with legal requirements.

Here are 2 live cases: 1. The shortest RTO for an investment bank came out to be 2 hours after a formal and structured approach to BIA. The CEO said 'I am the boss, I know the business. Nothing in this organisation needs to be recovered in 2 hours'. After much debate, shortest RTO was approved as 6 hours. I recommended to record this as 'the business wanted 2 hours, but the organisation approved 6 hours. This is a known risk and acceptable to us'. 2. A Japanese trading organisation established their BCM capability as 'recovering 25% in 24 hours'. They developed plans and arrangements accordingly. After 6 months, the CEP called me, 'Daman, we can even live with 48 hours recovery'. This is valid, and the RTOs can be revised after reviews.