Chapter 4 — Starting from BIA

4.1 What to Think About Before Technical Design

So far, we have seen that Backup existing and being able to Recover when needed are separate matters.

So then, what should you prioritize being able to Recover in the first place?

There is an order to this: before choosing a technical method, first understand what matters from a business perspective, look at the impact of a disruption, and from there consider the need for Recovery.

Chapter 3 looked at Backup methods and Restore dependency. But before choosing a method, you need to think about which business functions or data need to be protected as a priority.

This chapter deals with the thinking that serves as that starting point. This is presented less as a fixed procedure that applies to every situation, and more as a flow of thinking to keep in mind before beginning a design.

4.2 What BIA Looks At

BIA (Business Impact Analysis) is an effort to analyze what impact arises when a business operation or function is disrupted.

In the technical guidance on contingency planning for information systems published by NIST (the National Institute of Standards and Technology) — the Contingency Planning Guide for Federal Information Systems — BIA is also treated as something that provides the basic information for thinking about the analysis of business operations and functions, the impact of disruption, the need for recovery, and recovery priority.

Let's clarify a point that is easy to misunderstand here. BIA is not the following:

• the work of creating a list of Backup targets itself
• work limited to taking inventory of IT assets
• risk assessment itself (evaluating threats or risks themselves)
• the work of uniquely determining a Recovery architecture

What BIA provides is material used in subsequent planning. BIA itself does not determine the technical design or the concrete procedures.

4.3 Looking at Business Functions and Disruption Impact

In BIA, you first identify the business operations and functions an organization performs, and consider what impact arises when each one stops.

For example, differences such as the following can be considered:

• a business function where the impact is small if the stoppage is relatively short
• a business function whose stoppage cascades into impact on other business functions
• a business function whose stoppage directly affects external customers or business partners
• a business function related to law, contracts, or safety

These are only examples meant to help understand differences in business impact. This is not a fixed classification under which every business function must necessarily fall into one of these four.

What matters is holding onto the perspective that "even business functions that look similar do not necessarily have the same impact when they stop." This perspective leads into 4.4.

4.4 Not Everything Can Be Treated at the Same Priority

As we have seen, the impact of a disruption differs by business function.

What follows from this is that it is not necessarily the case that every system or piece of data needs to be Recovered under the same conditions and at the same priority.

This is exactly the problem the people in charge faced in the opening scenario. Even when Backups were technically in place, if it had not been sorted out which ones should be recovered first, judgment and prioritization at recovery time become difficult.

There is a point to note here. The idea of "recovering, as a priority, whatever has the greatest business impact" and the question of "in what technical order things can actually be recovered" are not necessarily the same. For example, even if some business function is extremely important, if the foundational mechanism supporting it has not been recovered first, that business function itself may not be recoverable.

The relationship between business priority and technical recovery order is covered again, in more detail, in a later chapter. This chapter covers only the foundation: that the content and urgency of the Recovery needed can vary depending on business impact.

4.5 Considering the Resources Needed for Recovery

Once BIA has made clear which business functions matter and what impact a disruption would have, the next thing to consider is what is actually needed to Recover that business function.

What to hold onto here is that what is needed for Recovery is not just Backup data.

For example, the following can be involved:

• the people who actually carry out the recovery work
• the procedures for recovery
• the systems or technology used for recovery
• resources outside the organization, such as external services or business partners
• the facilities or equipment needed to carry out the recovery work

These are only examples, and are not a fixed list of resources that necessarily applies in exactly this form to every organization or every system.

What matters is that Recovery planning needs to identify what organizational resources are required and consider their priority. Having Backup data alone does not mean the whole of the recovery work will succeed.

Summary So Far

Let's organize what we've covered on BIA into a simple table.

This table, too, is only a guide for organizing ideas, not a numerically scored measure of importance or a formula that mechanically determines priority.

4.6 What BIA Tells You, and What It Doesn't

Summarizing what we've covered, BIA gives you basic information for thinking about business functions, the impact of disruption, the need for recovery, and priority.

At the same time, it needs to be made clear what is not decided by BIA alone. BIA alone does not decide the following:

• concretely which Backup product to use
• which of Full / Incremental / Differential to choose
• the concrete Recovery architecture (technical configuration)
• the actual technical recovery order
• every concrete target value for things like RTO and RPO

The information BIA gives you is material and a foundation for these subsequent decisions; it does not, by itself, uniquely determine the answer. The concrete time targets and the acceptable range of data loss are covered in the next chapter, Chapter 5.

4.7 Connecting to Backup / Recovery Design

The flow of thinking covered in this chapter can be summarized simply as follows.

Teaching Diagram (a simplified conceptual diagram; it does not show BIA alone
uniquely determining Recovery design)

Business / Mission Function
          ↓
   Disruption Impact
          ↓
Basis for Recovery Requirement (material for the need and priority of recovery)
          ↓
Input to Backup / Recovery design

What this diagram shows is that the flow from business function, to disruption impact, to the need for recovery ultimately becomes an input for thinking about Backup or Recovery design.

What we want to emphasize here is that this flow does not automatically or uniquely determine the content of Backup/Recovery design from business impact. The information obtained from BIA is material and a foundation for judgment. Actual design also needs to take into account the technical perspectives covered in later chapters.

An actual Recovery plan needs to consider not only Backup data, but also people, procedures, technology, external resources, and dependencies. Recovery plans themselves are covered again in a later chapter.

4.8 Summary

This chapter organized the need to confirm business impact and recovery requirements before getting into technical Backup design.

The important points are these:

• BIA provides basic information for thinking about business functions, the impact of disruption, the need for recovery, and priority.
• BIA is not, itself, the creation of a list of Backup targets, an inventory of IT assets, or risk assessment.
• It is not necessarily the case that every system or piece of data needs to be Recovered under the same conditions and at the same priority.
• What is needed for Recovery is not just Backup data — people, procedures, technology, and external resources are also involved.
• BIA alone does not determine the concrete product selection, Backup method, Recovery architecture, technical recovery order, or the concrete values of RTO/RPO.

In the next chapter, Chapter 5, we look concretely at how to think about RTO (Recovery Time Objective) and RPO (Recovery Point Objective).

Questions to Consider After Reading Chapter 4

Thinking about the systems or business operations you are responsible for, can you answer the following questions?

• Can you explain why BIA should be considered before selecting a Backup product?
• Can you explain how looking at the impact of business disruption relates to Recovery design?
• Can you explain why it is not necessarily the case that every system should be treated at the same priority?
• Can you explain why what is needed for Recovery is not just Backup data?
• Can you explain what BIA alone cannot decide?

You do not need to be able to answer all of them.

Rather, if there is a point where you get stuck, that is exactly the point this chapter is meant to help you check.