What are the key factors to consider when setting your recovery time objective (RTO)?

A BIA is needed. It helps ID impacts to your business. Everyone's job is important! If you are excluding janitorial... think again. Keep things simple in identifying Risks and associating them to the BIA. After the BIA is complete the question should be asked to the ELT is: What is your number one issue or what keeps you up at night. Associate that with your BIA and now you have a beginning. RTOs are important and each critical function should weighed against need not want. Such as, Computer Co X protects assets against hacking. It gets hacked! What is Co X doing to resolve issue and how long will it take to be up. 4 hrs-30 days? What just happened to RPO/RTO? Does this solve your issue? What back up do you have? Business able to recover?

Initial RTO that is set through BIA, is independent of strategies and capabilities! I also draw attention to my 'Cause and Affetc' theory. There are 100s of causes that can bring interruption in my services to you, but the affect will only fall in 1to6 categories i.e. people, building, IT, utilities, supplies, information etc. As a smartBC Manager, you should focus on affects (because these are only 6 or so) more than the causes (because these are too many). So, do not think of what can go wrong, just assume that your service has gone down then what is the impact. Do not think of strategies, capabilities, availability of the solutions, affordability etc. All this comes later.

Too often, BIAs account for what the Business thinks OR what IT thinks. In reality, the BIA should inform both Business and IT of each others viewpoint and then be set based on tolerance for downtime vs cost to treat every application like its the most important one in the portfolio.

It's important for business lines to have access to a risk matrix that is specific to the triggers which help them define their Recovery Time Objective (RTO). When we accomplish a Business Impact Analyst (BIA) we need to run a gap analysis and conduct additional interviews when we find noticeable differences that should be explained.

Setting a Recovery Time Objective (RTO) hinges on a meticulous business impact analysis. Understand the critical functions and prioritize based on financial, operational, and reputational impacts. Assess your recovery strategies and capabilities—consider redundancy, data backups, and alternative facilities. For example, if e-commerce is vital, a shorter RTO is crucial, necessitating robust backup systems. Aligning RTO with business priorities ensures a resilient and responsive continuity plan.

I've learned by doing BIA's at multiple organizations that the process owners always have a higher view of their process than what it actually might be. Having good questions help to ensure standard answers, but I found that instead of asking the process owner all the BIA questions instead I go to the Enterprise Owner of (i.e. Finance, Brand/Image, Legal, etc.) I give them the process, the definition, and scope - then have them answer the impact questions.

When deciding on recovery time objectives, think about how quickly you need things up and running after a hiccup. Consider which parts of your business are most important and how long you can afford to be without them. Also, factor in how much it would hurt your bottom line or upset customers if things stayed down for too long. Balance that with what your technology and resources can handle. And don't forget to keep checking and adjusting your objectives as your business evolves.

Key components of a BIA include: 1. Determine which processes and activities are essential for the organization's survival and success. 2. Evaluate the financial and non-financial consequences of disruptions to these critical functions. 3. Calculate the direct and indirect costs associated with the loss of critical functions over time. Determining recovery time objectives (RTOs): Establish the maximum acceptable time for restoring each critical function after a disruption. 4. Defining minimum acceptable service levels: Identify the bare minimum operational capacity required to maintain essential business functions. 5. Mapping dependencies: Understand the interconnections between various business processes, systems, and resources.

Setting RTO should take into consideration length of time for various things, such as: 1) how long does it take to get to your alternate site, whether that be a home office or alternate recovery site, 2) how long does it take to get communing communications out, 3) what are the recovery time frames for your applications. RTO setting should be a holistic approach AMF not just based on how fast do I need the process because if that is the case you will never meet your targets.

Do we spend time evaluating alternate capabilities or work arounds that can/will mitigate an outage, thereby making it less critical in our recovery efforts? Recovery strategy (again) should be informed by both the Business and IT to get the best scenario for recovery of the entire organization.

It is easy to say we have a strategy. It is hard to demonstrate it. I used to work at a bank that was required to have an alternate work and data center site. Leadership "assumed" we were "good" because we had an alternate site. Once we started testing the various components of the site we learned that we were not ready. It took many tests to get ready.

When it comes to setting recovery strategies and capabilities, think of it like having backup plans for your backup plans. You want to have different strategies in place for different types of disruptions, whether it's a power outage, a cyberattack, or a natural disaster. Look at what resources you have available – like backup data centers, cloud services, or alternate suppliers – and how you can use them to keep things running smoothly during a crisis. It's also crucial to prioritize which parts of your business to focus on first for recovery and to make sure your staff know what to do when the unexpected happens. And just like with RTOs, keep reviewing and updating your strategies as your business evolves and new risks emerge.

An often overlooked aspect is the importance of psychological preparedness and resilience training for employees. Disasters and major disruptions can be highly stressful, and the ability of staff to function effectively under pressure is crucial to successful recovery. Organizations should consider implementing stress management programs and conducting regular simulations to help employees build mental fortitude and decision-making skills in crisis situations. Another critical component is the development of a comprehensive communication strategy that extends beyond internal stakeholders. This should include plans for managing public relations, addressing customer concerns, and maintaining investor confidence during and after a crisis.

In my experience, risk tolerance is often determined after data points are collected on strategies and we can quantify the actual gap of a strategy. Improving enterprise strategies often come with price tags that make accepting a risk sometimes more palatable!

Setting risk appetite and tolerance is like defining how much risk you're comfortable with and how much uncertainty you can handle. Consider your business goals, regulations, and potential impacts of risks. Align your risk appetite with your strategy. Set clear boundaries for acceptable risk levels, known as risk tolerance. Regularly reassess and adjust to stay resilient.

Identify relevant laws, industry standards, and regulations that apply to your business. Understand what's required to stay compliant, whether it's data protection laws, safety regulations, or financial reporting requirements. Integrate compliance into your business processes and continuity planning. Regularly review and update your practices to ensure ongoing compliance as regulations evolve. Failure to comply can lead to legal issues, fines, and damage to your reputation. So, it's essential to stay informed and proactive in meeting regulatory obligations.

When setting your Recovery Time Objective (RTO), consider the expectations of key stakeholders. Engage in dialogue to understand their tolerance for disruption and prioritise RTOs accordingly. Communicate your RTOs, set clear expectations, and regularly review and adjust them to align with changing stakeholder needs. This demonstrates your commitment to business continuity and strengthens stakeholder relationships.

In my experience, integrating stakeholder expectations into the RTO is strategic. For instance, during an ISO22301 implementation at a Delivery Center, facing a critical event, a meticulous Risk Impact Assessment gauged potential ramifications on stakeholders. Recognizing their pivotal role, we initiated a dialogue, aligning RTO with their risk tolerances. This approach established a transparent channel, empowering us to tailor our RTO based on stakeholders' unique risk profiles and needs. The synergy between Risk Assessment, & stakeholder engagement ensured timely recovery and strengthened relationships. This highlighted the interdependence of managing expectations, BIA, RA, and setting RTOs to navigate the dynamic landscape.

Consider stakeholder expectations and needs by listening to their concerns, involving them in planning, and communicating openly. Understand how disruptions impact them and prioritize accordingly. Building trust and collaboration with stakeholders ensures alignment and support during crises.

RT Objective vs RT Capability; RTC in hours <=RTO in hours ✅ RTC in hours > RTO in hours ⛳️ Red flag would remit RCA and a relook at all parameters inluding investment, even that of resetting RTO value if deemed appropriate. However, should it still remain a red flag at the end of it, it needs to be Risk Accepted with full implications documented and ratified at the appropriate executive level with strong management awareness.

None, RTO is obsolete, Calculations need to be in 4 or 5 9s or Impact Tolerance levels. RPO is also obsolete. Critical Data should always be 0 loss

Agee, impact tolerance considers the overall consequences of an incident on business operations, customer experience, and reputation. This approach provides a more holistic understanding of resilience by emphasizing the organization's ability to absorb and manage disruptions rather than just minimizing downtime or data loss.

To Paul's point, RTO for critical systems is largely obsolete. Businesses should be working towards resiliency, not recovery. The question then becomes what level of service degradation can an organization withstand and for how long.

RTO and RPO are not obsolete - you need to categorize the entire portfolio of Applications (what are other less critical apps then identified as from a recovery perspective?) 4 or 5 9s related to SLAs - not recovery - SLAs have penalties associated with them, RTO and RPO are based on an expectation that recovery can be completed within a specific time frame, also covered by force majuere contract clauses...(no contractual penalties due to a disaster event).

The most important is to understand, admit, and use that 'shorter the RTO - costlier is the solution', hence the ideal solution is where RTO is as long as possible. Keeping emotions out, raking practicable approach - the fact is that even if the whole organisation is down, it wont be out of business for 1,2,3 or many days! This is true about any organisation!

Whilst I agree with a couple of the points above, impact tolerance is at service level and needs to be supported by RTOs that enable recovery within it.

I'm curious that there is no direct mention of operational work arounds in relation to RTOs. For small to mid-size businesses that cannot afford high availability solutions, well defined work around procedures prove invaluable in my experience.

Once you (the business) have established your RTO, there is a possibility that you may not get it - because of approved strategies, capabilities, availability of solutions, and affordability etc. So, what you get may be worse than what you asked (i.e. a longer RTO), in rare cases it may be better than what you needed (i.e. a shorter RTO). Both cases need to be recorded as exceptions. The first one as a known risk and signed off by the appropriate authority.

Business continuity of priority of applications which is not always immediately known by the customer. Standards for RTO is speed of receiving DR network avenues to deliver return. Most cases require examination by both Business teams as well as development to determine business priority of applications.