What's a business continuity plan?

A
business continuity plan (BCP) is a
document that outlines how a business will
continue operating during an unplanned
disruption in service.

RTO and RPO: What is the difference

between Recovery Time Objective and
Recovery Point Objective?
When developing Business Continuity Plans (BCPS) or Disaster Recovery Plans (DRPs), two
terms appear quite often: Recovery Time Objective (RTO) and Recovery Point Objective
(RPO). While paramount to the definition of BCPs and DRPs, RTO and RPO aren’t easy
concepts to understand, which can lead to plans that either allocate more resources than
needed, or to plans that won’t achieve the expected outcomes.

RTO definition: The amount of time after a disaster in which business operations need to be
resumed and resources need to be available for use.

RPO definition: The amount of data loss that would be acceptable for an organization as a
consequence of a disaster.

What is the RTO?

The definition of RTO, Recovery Time Objective, is the amount of time after a disaster in
which business operations need to be resumed and resources are again available for use.
The RTO definition can be found in ISO 22300, which defines the vocabulary for ISO 22301.
For example, if the RTO is two hours, then this means you must resume delivery of products
or services, or execution of activities, in two hours – therefore, your business continuity and
disaster recovery plans need to consider the RTO during their development.
What is the RPO?
The definition of RPO, Recovery Point Objective, is the amount of data loss that would be
acceptable for an organization as a consequence of a disaster (e.g., a catastrophic loss of
software or hardware).

The meaning of RPO is also given by ISO 22301: The definition of the Recovery Point
Objective, or RPO, is the amount of data a business can afford to lose in terms of time, or in
terms of amount of information.

As an example, think about a database for recording all transactions in a bank (e.g.,
payments, transfers, scheduling, etc.). Usually, in such a case RPO is zero, because even in
just a few minutes, hundreds of transactions can be made, and this information cannot be
lost and cannot be easily recovered in any other way.

Now think about a source code repository where software developers keep their work. It is
relatively easy to rewrite one day of lost coding for a software developer, but more than that
can be difficult or impossible to recreate. In this case, the RPO would be 24 hours, which
means that the backup needs to be done at least every 24 hours.

The point is, the harder it is to recover or recreate the data, the shorter the RPO needs to be.

RTO vs. RPO: What is the difference?

The main difference between RTO and RPO is in their purposes – being focused on time,
RTO is focused on the downtime of services, applications, and processes, helping define
resources to be allocated to business continuity; while RPO, being focused on the amount
of data, has as its sole purpose to define backup frequency.

Another relevant difference is that, in relation to the moment of the disruptive incident, RTO
looks forward in time (i.e., the amount of time you need to resume operations), while RPO
looks back (i.e., the amount of time or data you are willing to lose).
What are RTO and RPO in disaster recovery and business
continuity?
RTO is used to determine what kind of preparations are necessary for a disaster, in terms of
money, facilities, telecommunications, automated systems, personnel, etc. The shorter the
RTO, the greater the resources required.

RPO is used for determining the frequency of data backup to recover the needed data in
case of a disaster. If your RPO is four hours, then you need to perform backup at least every
four hours; every 24 hours would put you in big danger, but if you did it every hour, it might
cost you too much and not bring additional value to the business.

Both Recovery Time Objective and Recovery Point Objective are related to business
continuity by means of the business impact analysis (BIA), where they are determined, and
the business continuity strategy, where preparations for achieving them are defined.

See these articles to learn more about RTO, RPO, and BIA: Five Tips for Successful
Business Impact Analysis, and Backup policy – How to determine backup frequency.
RTO and RPO – are they related?
Although RTO and RPO are both crucial for business impact analysis and for business
continuity management, they are not directly related, and neither conflict with each other
(one deals with time and the other with an amount of data), so it does not make sense to
talk about RPO vs. RTO.
Should RPO be less than RTO?
Since RTO and RPO are not directly related, RPO does not need to be less than RTO or vice-
versa – you could have an RTO of 24 hours and an RPO of one hour, or an RTO of two hours
and an RPO of 12 hours.
For example, an e-commerce site may need to be online 4 hours after a disruption, so RTO
is four hours. Now, this same e-commerce site has two databases, one for its product
catalog, which is updated once a week, and the second to record sales (thousands per day).
The RPO for the first database can be one week, but for the second, the RPO should be near
zero.

The importance of RTO and RPO in cyber security

Although RTO and RPO were initially introduced regarding disruptive events related to
natural disasters and direct man-made attacks (e.g., vandalism and terrorism), the
increasing dependence of businesses makes RTO and RPO also useful for cybersecurity.
For example, RTO and RPO enable cybersecurity teams to plan responses to cyberattacks,
like DoS and ransomware.

Continuity management is more about preparation and less

about guessing
Business continuity and disaster recovery plans are things that organizations need to have
and hope not to use, and in such cases, they need to find a balance between investing the
minimum amount of resources possible, and having the maximum confidence that the
plans will work.

To achieve this balance, RPO and RTO are paramount. Without determining them properly,
you would just be guessing – and guessing is the best way to ensure recovery disaster,
instead of recovery from a disaster.