Chapter 15 — Being Able to Restore Is Not Enough

15.1 Restore Finishing Alone Is Not Enough

In Chapter 14, we saw that a Playbook should keep completion criteria. This chapter considers how you can actually confirm that those completion criteria have been met.

The mere fact that the Backup restoration operation itself succeeded does not, by itself, show that Recovery succeeded. Test and exercise activities related to Recovery need to confirm whether the intended Recovery result was actually achieved.

Being able to Restore ≠ Having achieved Recovery

This chapter organizes this difference.

15.2 Separately Considering "What Came Back"

If you bundle "whether Recovery succeeded" into a single question, it becomes easy to overlook things that need to be confirmed.

So in this book, rather than treating Recovery success as a formal set of stages, we frame it as an organization for separately considering "what came back."

For example, the following questions each confirm something different:

• Has the Backup been created?
• Was the data able to be Restored?
• Does the system operate?
• Does the service function?
• Has Recovery been achieved across multiple systems, or as a business operation?
• Is the resulting state trustworthy (trusted-state validation)?

These each represent a different verification outcome.

This organization is something this book has put together by combining multiple perspectives covered so far; it is not an official hierarchy or a standard six-stage model defined by NIST or CISA.

Also, the list above is arranged for explanatory purposes, and does not mean you must confirm each one in exactly this order before moving on. Even if one perspective has not been confirmed, you can still begin thinking about another, and which one you confirm first can vary depending on the actual situation.

15.3 Data / System / Service / Business Are Not the Same Confirmation

Data having come back, a system operating, a service functioning, and something actually being usable for business are each a different confirmation.

Confirming that a file has come back does not, by itself, confirm that the Service is available.

In the same way, confirming that a system has started does not automatically prove that the service actually functions. And confirming that a service is technically functioning does not automatically prove that it can actually be used for business.

Technical confirmation being complete does not necessarily mean the business side can use it as-is. Conversely, even if the business side's requests appear to be satisfied, that does not mean technical confirmation can be skipped. Each is a matter that needs to be confirmed separately.

15.4 Trusted-State Validation

In addition to the "what came back" perspective covered so far, there is one more, separate perspective.

That is the question of whether the state that came back is itself a trustworthy state.

In Chapter 11, we covered which Recovery Point should be adopted, and how to think about whether its state is trustworthy. This chapter does not go back over that idea in detail.

What we want to confirm here is that trusted-state validation is also a separate confirmation perspective from the data/system/service/business confirmations. Even if you can confirm that a system or service is technically operating, that alone does not confirm that the resulting state is trustworthy.

15.5 Actually Confirming Completion Criteria

As we saw in Chapter 14, it is considered desirable for a Playbook to keep completion criteria.

Completion criteria show what must be true for a piece of Recovery work to be considered complete.

What this chapter wants to consider is how to confirm that those conditions have actually been met. Having "carried out" a piece of work and it having "been completed" are not the same thing. Merely performing some operation does not, by itself, mean the completion criteria have been met.

The concrete procedure or format for confirmation and approval is not covered in this chapter.

15.6 What a Tabletop Can, and Cannot, Confirm

There are also multiple kinds of methods for confirming Recovery, and each confirms a different property. What one method can confirm cannot automatically be extended to a property that a different method is meant to confirm.

The differences and details of Test / Exercise, including tabletop exercises and functional exercises, are covered in the next chapter, Chapter 16.

15.7 The Details of Test / Exercise Go to the Next Chapter

This chapter mainly covered the idea of distinguishing "what was actually confirmed" as a result of Recovery.

Both in actual Recovery and in prior Testing, the need to distinguish what was actually confirmed is a common thread.

On the other hand, this chapter does not cover how to design a tabletop exercise or functional exercise, at what frequency to carry them out, or how to turn the confirmation results into improvements. Those are covered again in a later chapter.

15.8 Summary

This chapter organized the idea that Restore having finished and Recovery having succeeded are not the same thing.

The important points are these:

• The Backup restoration operation succeeding alone does not show that Recovery succeeded (Being able to Restore ≠ Having achieved Recovery).
• "What came back" needs to be considered separately across the different perspectives of data, system, service, and business. Each confirmation does not automatically prove the next one.
• Whether the resulting state is trustworthy (trusted-state validation) is also a separate confirmation perspective.
• Completion criteria only carry meaning once you confirm they have actually been met.
• A successful tabletop exercise does not, by itself, prove technical Recoverability.
• The organization shown here is this book's own teaching perspective, not a standard hierarchy defined by NIST/CISA.

Representative Perspectives to Confirm in This Chapter

Let's organize what we've covered so far into a simple table.

This table is one teaching tool this book uses to organize the perspectives for confirming Recovery; it is not NIST's official verification matrix, nor a universal checklist that must always be satisfied. Also, the order of the rows is for explanatory purposes and does not mean they must be completed one by one in this order. Even if one row has not been confirmed, you can still begin thinking about another.

Questions to Consider After Reading Chapter 15

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

1. Why can a successful Restore alone not be called a successful Recovery?
2. What is the difference between Data Restore and Service Recovery?
3. Why are a service having come back and a business being able to use it not the same thing?
4. Why is the organization of verification outcomes used in this chapter not a standard NIST hierarchy?
5. Why does a successful tabletop exercise not prove technical recoverability?

If there is an item you get stuck on, revisit it to see which confirmation perspective you have not yet distinguished.