Identifying Your Business Continuity Priorities

Business continuity is sometimes referred to as operational continuity, or specifically the areas where an organization identifies the critical and essential functions of the business. This is a realm that goes beyond technology systems to include all essential aspects of your organization – the personnel, processes, physical workspaces, equipment, and technology that you need to maintain baseline operations.

As an IT leader, you’ll have personnel to consider in your business continuity plans, with additional considerations for any data center space you operate, perhaps some critical heavy equipment, and desktop and mobile hardware. But your primary role within business continuity is likely to be disaster recovery focused, simply because you must keep crucial applications and data available to those stakeholders and operational sites deemed essential. Your DR plan should focus on recovering key essential technical functions while also considering the supporting tools, applications, data collaboration, and potential workforce displacement.

But how exactly do you identify which systems are critical – and in need of faster time to recovery – and which can rely on more simple backup methods? Here are four key questions to ask yourself as you prioritize within your continuity plan.

What Technology is Directly Supporting Revenue?

A disaster recovery environment can be expensive, but not everything has to be up and running again within an hour window. Is every IT service actually mission critical? Is your copier mission critical as opposed to, say, payroll?

Prioritizing recovery is important. What are you trying to protect? What makes prudent sense on the cost perspective? Sit down with team leadership, department heads, and any other key stakeholders to map out true SLAs needed for your critical workloads. The goal is to right-size your DR solution to minimize costs but maintain your revenue streams.

The challenge then becomes one of managing expectations and priorities. When Lunavi starts looking at disaster recovery from a planning perspective or exercise, we first become acclimated with your organization’s key essential functions. What we’re looking for is alignment.

• What are the critical parts of the business and how do they generate revenue?
• What are the technology tools and applications that support those revenue generators?
• What compliance and security measures might be required in a secondary environment?
• Will you be leveraging a third party or hyperscale cloud provider?
• What technology solutions might be needed to protect, maintain, or replace these critical tools and applications in a relatively steady-state?

This exercise will be different for every industry and every organization. A business continuity planning team assembled from your executives, department leadership, and IT subject matter experts can help identify exactly which technology services support revenue-centric operations.

Where Does Your Workforce Come into Play?

One of the organizations I’ve had the pleasure of dealing with is in the mortgage service business. They have around 600 agents processing loan applications and if there is a disruption in technology, all of a sudden 600 people are unable to execute their jobs. A strong recovery plan will have identified the possible suite of technologies that could be used to reconnect these workers, such as remote desktops, VPN connectivity, cloud-based storage repositories, SaaS collaboration tools, and so forth.

Of course, that is the obvious side of downtime or an outage: your workforce simply can’t do their work. But beyond your staff being unable to perform their usual duties, workforce displacement can also affect your DR execution itself. You might have all the technology in place with a detailed recovery and failover plan ready to go, but without key technical staff available, that plan could fail spectacularly. So every business continuity prioritization must also list responsibilities and secondary players who can step up in the chain of command and communicate to make sure that critical systems are restored in a timely manner.

That means an essential component of identifying recovery priority is also those processes and communications used to carry out systems recovery. Automated notifications, updated contact trees, lists of relevant third-party contacts, and “hotline” updates for employees who are not involved in IT are all components of your DR plan that will be informed by your prioritization process.
 

Why Do RPO and RTO Matter?

RTO (Recovery Time Objective) and RPO (Recovery Point Objective) are essentially acronyms that deal various aspects of backups and DR. The two, although they both are inclusive, have slight differences. However, one commonality is that the closer you get to zero on an RTO and RPO the more expensive your DR solution gets.

When we talk about RTO, the T indicates the organization is racing against time, which is of the essence. RTO is how long before your failover is up and running. You start looking at the cost of downtime, so from a time perspective, you’re asking “How much revenue does this downtime cost me? How quickly do my various prioritized systems need to be back online?” This can be minutes, it can be hours, or it can be days or even weeks, depending on the importance of the technology being restored.

You might have an RTO of four hours, so you want to have all of our mission critical functions up and operational within that time. That’s an established time frame, so then we align tools and processes to accommodate that.

RPO, on the other hand, refers to the recovery point, or how far back in time you want to recover your data. When you start looking at RPO, you might be focusing on what kind of data loss you can sustain. That could be anything from a credit card transaction, a data handoff, or some sort of integrated transactions that apply to data.

It involves aligning the cost of downtime and basing that against a time clock. For RPO that’s the minimum tolerance your organization has for specific workloads such as transactional data.
 

Where Can You Afford a Little Less, for a Little While?

Remember that your recovery environment will be functioning on a temporary basis. Prioritizing within your continuity planning is therefore largely a discussion of value.

At Lunavi, we look at it from a recovery surface level or RSL, which helps align with key essential functions. That may be an application or a specific department, for example. To save some costs, your failover environment is not necessarily apples to apples. The RSL helps define things such as compute resource reduction or lower bandwidth. You may not require 100% performance from a recovery environment and can therefore scale down compared to your production VM provisioning or bandwidth allotments.

You can design your recovery infrastructure and replication to have critical apps running on higher performance infrastructure with a minimal period of downtime and less data loss. Lower end apps can simply be restored from backups. They may not even need to be included in DR but rather longer-term storage and snapshots.

You truly have to look at continuity from a department to department standpoint. Continuity can’t be a decision that IT makes in a vacuum. Functional and cost-effective recovery truly has to be designed by thinking about how you function today, what you can live without, and what you can’t live without.

To learn more about continuity and disaster recovery solutions, read more about our DR as a Service solutions, or contact us today to discuss continuity planning for your critical business technology.