Preparing for a BIA – Understanding RTO and RPO

In my time as a security and compliance auditor and virtual CISO, I have reviewed countless business continuity plans (BCPs) resulting from regulatory and industry requirements to which clients must adhere. For the most part, the business continuity plans I have reviewed were written and owned by IT, security, or compliance departments without buy-in, visibility, and support from the company as a whole. Business units need IT resources to do their jobs, and IT is responsible for managing them, so why should other departments be involved in a business continuity plan?

In one of my previous jobs, I supported the IT contract at a military facility. We had regularly tested backup and recovery plans for all the critical systems and redundant onsite server rooms, generators, and communication links. What could go wrong? The building’s HVAC system was dependent on a boiler that was installed during the Ford administration and those server rooms need a lot of humidity-controlled, cold air to keep running. One quiet evening, that boiler had a catastrophic failure, destroying a critical environmental control room and flooding the area with heavy-metal contaminated water. Soon after the cooling stopped working, the thermal shutdown limit of each of the servers was reached and the long road to restoring operations began.

The cost of contingency operations and emergency repairs was more expensive than proactively addressing the problem, but the organizational leadership (who lacked an IT background) did not understand the risk and impact that the boiler posed to the mission. How does a business ensure they understand the risks and impacts each business unit and asset has to the overall organization? A complete picture can be obtained by performing a business impact analysis (BIA) as part of a business continuity planning program, and including all relevant departments in the process, not just IT. A BIA looks at every business process to understand:

• What business function the process is accomplishing?
• What technologies and inputs the process is dependent on?
• What is the impact to the business if the process can’t be done?
• How long can the process not be done before the business is affected?
• How much data or work the process can afford to lose before the business is affected?
• Are there alternate ways for the process to be done if the primary method is offline?

RTO vs RPO

Gathering this information for all an organization’s processes will help to determine the recovery time objectives (RTOs) and recovery point objectives (RPOs). ISO 22300 defines these terms as the following:

Recovery Time Objective (RTO)

The period of time following an incident within which a product or service or an activity is resumed, or resources are recovered

• For products, services and activities, the recovery time objective is less than the time it would take for the adverse impacts that would arise as a result of not providing a product/service or performing an activity to become unacceptable

Recovery Point Objective (RPO)

The point to which information used by an activity is restored to enable the activity to operate on resumption

• Can also be referred to as “maximum data loss”

To give an example, think of your external-facing company website that you utilize to get found by prospects, offer answers to client questions, and manage your online presence. If an event occurred that took your website down, the recovery time objective would be close to zero as you would need your website to be back online almost immediately. However, if this website’s content is mostly static and only updated monthly, your recovery point objective would be higher (longer period of time allowable) as the data does not need to be backed up as often due to how infrequently it is modified. These objectives are both measured in time. They are not just important for your internal stakeholders; they will also play a crucial role in meeting the service level agreement (SLA) you may have in place with your customers.

Performing a quality, organization-wide business impact analysis prior to developing or updating a business continuity plan is crucial to ensuring the business continuity plan reflects the critical resources of an organization by addressing the critical processes with their technology and process dependencies. If a process can only be down for 4 hours (RTO) but the server it relies on requires 24 hours to restore, or the business can only tolerate 1 hour of data being lost (RPO), but the vendor that stores the data only does daily backups, then the business continuity plan isn’t meeting the needs of the business. Understanding objectively what the priorities are for restoration, how backup and recovery objectives are being met, and what critical process owners will do if the primary process fails using information from a business impact analysis is the key to an effective business continuity plan.

Let Compass IT Compliance Help You With Your Business Continuity Plan

Leveraging a security vendor (such as Compass IT Compliance) to assist in developing, testing, and updating your business continuity plan and conducting a business impact analysis can take the weight off your team’s shoulders and provide expert team to take care of everything. Contact us today to learn more and discuss your organization’s unique challenges!