Read a recovery-exercise timeline before claiming the target was met

A recovery result needs a defined start, a meaningful completion event and evidence of the data restored. “The restore finished” may answer a technical step without establishing that the business activity could resume.

This original fictional case is for career and portfolio practice. It does not prescribe recovery targets or authorize an exercise on a real system. NIST SP800-34 Revision1 provides contingency-planning concepts, including recovery objectives and exercises. The targets below are invented assumptions, not NIST-required numbers.

The packet

Fictional Cedar's scheduling service becomes unavailable at 09:00. For this exercise, the agreed recovery-time clock begins at loss of service and ends when the authorized business checker confirms usable scheduling. The target is 120 minutes. The acceptable data-loss window is 30 minutes measured back from the 09:00 disruption.

All timestamps use the same date and time zone. For the calculation, assume a separate recovery record confirms a consistent data cutoff at 08:40; the latest entry's timestamp alone would not establish that cutoff. Assume the records describe a controlled technical exercise with the stated scope. No payment system or external integration was included.

Two calculations answer different questions

The defined recovery interval is 09:00 to 11:10: 130 minutes, ten minutes beyond the 120-minute target. Starting the clock at authorization would produce 105 minutes, but that is not the start event agreed in this case. Ending at the tool's completion would produce 110 minutes, but that omits the required usability check.

The latest recovered entry is twenty minutes before the disruption. On the supplied data-cutoff assumption, that is within the thirty-minute acceptable window. A good result on that dimension does not cancel a missed recovery-time target.

Neither calculation establishes that every expected record was restored. The latest timestamp can be recent while earlier records are missing or damaged. Population reconciliation, integrity checks and the defined functional checks would need their own evidence.

Write the bounded conclusion

“For the scheduling functions included in this exercise, the defined recovery interval was 130 minutes against a 120-minute target. The latest recovered entry preceded disruption by twenty minutes against the assumed thirty-minute window. Completeness and integrity require separate reconciliation; external integrations were excluded. The recovery-time target was not met in this exercise.”

This wording preserves a mixed result rather than turning the packet into a single green status. Name the authorized owner for the next decision rather than inventing permission to accept the gap.

Change the evidence type

Now suppose the same times were estimates discussed during a tabletop session; no system was restored. The arithmetic still compares the proposed timeline with the target, but it is not an observed technical recovery result. Label it an estimated scenario and record which assumptions need validation. Discussion attendance and a completed slide deck do not establish the restored data or application behavior.

For your fictional portfolio, retain a timeline, calculation note, evidence references and a revised conclusion. Use the decision-memo example to request the next action. Compare recovery-evidence preparation resources if you want a connected fictional packet rather than this single free exercise.