Independent thinking. Informed defence.

CISO Times

Intelligence for the people behind the defence.

The CISO Decision Brief

If…, then how…

If a restore test misses the recovery time or loses too much data, then what do we do?

5 decision pointsThe pack behind this answer: Backup & Restore Assurance

Add to board memo

The short answer

Recommendation
Record the result as measured. Raise a finding for each missed criterion, and an objective gap where the service's recovery time or recovery point was missed. Fix it, retest, and close the finding only when the retest shows the fix works.
Reasoning
A failed test has done its job: it found the problem on a quiet day. Rerunning until it passes, or changing the criterion, hides the gap. A critical data set that cannot be restored in time, or without too much loss, meets the pack's meaning of a High finding, fixed within 90 days by default, and its risk owner is told so the risk is reassessed. The test measures against the service's objectives and never sets them.
Considerations
  • A tabletop or a drill is not a restore test. Handle what it found under your exercise process and plan a real restore.
  • Where a service cannot be back within its recovery time, its business owner records a workaround and who starts it.
  • Too much data lost may mean the backup interval is longer than the recovery point. Then the fix is to back up more often and retest.
  • The 10 working days for the plan and the 90, 180 or 365 days to fix are the pack's defaults, which your own standard may change.

The decision, step by step

Select any step for the reasoning behind it and where the pack covers it.

  • Start
  • Step
  • Decision
  • Outcome
  • Loop back
StartA restore test missed the time or lost too much dataDecisionDid it restore data from a backup, judged by the criteria?OutcomeDo not count it; plan a real restore testStepRaise a finding for each missed criterionDecisionDid the restore take longer than the recovery time objective?StepRaise an objective gap under P22 and link the finding to itStepShow the restore time beside the cyber recovery timeStepAsk the business owner to record a workaroundDecisionDid the copy lose more data than the recovery point allows?StepCheck the backup interval against the recovery pointStepRaise an objective gap for the data lost, or add it to the open oneDecisionIs a critical data set unrestorable, or outside its time or data loss?StepMeets the High meaning: tell the owner of the risk it bears onStepThe owner sets the severity: Medium or LowStepThe owner agrees a plan, fixes it and asks for a retestDecisionDoes a retest or new evidence show the fix works?OutcomeClose the finding; report the test as a count with its name

Keyboard: Tab to a step, arrow keys move along the flow, Enter pins its explanation, + and − zoom, 0 fits the diagram, Esc closes. The text version below has the same content.

Where a step quotes a number, it is the default in the CISO Times pack. Your own standard may set a different one.

Read as text

The same flow written out: each step, its reasoning and where the pack covers it. 17 steps.

  1. Start

    A restore test missed the time or lost too much data

    A failed test has done its job: it found the problem on a quiet day. It is not a failed backup. Record the result exactly as measured. Do not rerun the test until it passes and do not change a criterion to fit the result.

    In the pack

  2. Decision

    Did it restore data from a backup, judged by the criteria?

    A restore test restores data from a backup and checks it against the six criteria. A tabletop, a drill or any other exercise is not a restore test. Data a provider holds with no copy of yours is tested through the provider's own recovery test, which is a different route. If you do not know which it was, answer no.

    In the pack

  3. Outcome

    Do not count it; plan a real restore test

    An exercise may teach something, but it shows nothing about whether a backup restores. Handle what it found under your exercise process, and plan a restore test of the data set so there is a measured result to judge.

    In the pack

    See also

  4. Step

    Raise a finding for each missed criterion

    Name each criterion not met, such as TC-03 for the time or TC-04 for the data lost. Each becomes a finding with an owner, a severity and a due date, in the findings tracker. Take times from system logs, not from memory. A test with a missed criterion has not passed, however many others held.

    In the pack

  5. Decision

    Did the restore take longer than the recovery time objective?

    Compare the time from the decision to restore to the data owner's confirmation with the service's recovery time objective from P22. The test measures against the objective and never sets it. Answer no if the test was not timed: an untimed test claims nothing about recovery time.

    In the pack

  6. Step

    Raise an objective gap under P22 and link the finding to it

    A test that shows an objective cannot be met is an objective gap. Its owner agrees the change that closes it within 10 working days by the pack's default, with a due date, and the service's risk owner is told so the risk is reassessed. The finding keeps the date the gap sets.

    In the pack

  7. Step

    Show the restore time beside the cyber recovery time

    A restore in normal conditions shows the restore time. It does not show the time after a destructive attack, when the foundations must be rebuilt first. Report both beside the objective. A rebuild test measures the foundations and replaces the estimate in the recovery objectives.

    In the pack

  8. Step

    Ask the business owner to record a workaround

    Where a service cannot be back within its recovery time, its business owner records a workaround that keeps the harm below Severe until the service returns, and who starts it. That is the business owner's decision under the recovery policy, not the backup team's.

    In the pack

    See also

  9. Decision

    Did the copy lose more data than the recovery point allows?

    Compare the data lost, between the copy used and the failure point, with the service's recovery point objective. Answer no if the test was not timed. A copy older than the objective allows may mean the backup interval is longer than the objective.

    In the pack

  10. Step

    Check the backup interval against the recovery point

    The backup interval of every data set a service needs must be no longer than its recovery point. If the interval is longer, the fix is to back up more often, then retest the recovery point. If it is not longer, find why the copy used was older than the interval suggests.

    In the pack

  11. Step

    Raise an objective gap for the data lost, or add it to the open one

    Data lost beyond the recovery point is an objective gap too, with its own owner and change. If a gap was already raised for the time, add the loss to it rather than keeping two. The owner agrees the change within 10 working days by the pack's default.

    In the pack

  12. Decision

    Is a critical data set unrestorable, or outside its time or data loss?

    A High finding means a critical data set cannot be restored, or not within its recovery time or recovery point, or has no copy an attacker with administrator credentials could not reach. If you are unsure whether the data set is critical, answer yes.

    In the pack

  13. Step

    Meets the High meaning: tell the owner of the risk it bears on

    The pack's meaning of High fits this finding, and by its default a High finding is fixed within 90 days. Its risk owner is told so the risk is reassessed. A High finding that is also an objective gap keeps the date the gap sets.

    In the pack

  14. Step

    The owner sets the severity: Medium or Low

    A Medium finding is a weakness that other protection backs up, fixed within 180 days by the pack's default. A Low finding is an improvement tracked to the next review, within 365 days. The owner of the finding chooses between them for a missed criterion.

    In the pack

  15. Step

    The owner agrees a plan, fixes it and asks for a retest

    The owner agrees a plan within 10 working days by the pack's default, and the backup owner is accountable for the fix. The owner saying it is done does not close the finding. It moves to Fixed, awaiting retest.

    In the pack

  16. Decision

    Does a retest or new evidence show the fix works?

    A finding closes only when a retest or new evidence shows that the fix works. For a missed time or data loss, a new restore test measured against the same objective is the clearest evidence. If the retest has not been held, the answer is no.

    In the pack

  17. Outcome

    Close the finding; report the test as a count with its name

    Report the test result as a count that names the gaps, for example 3 of 5 tests passed every criterion and the other 2 are named. Never a score or a share. Keep the test record with its evidence for at least 3 years by the pack's default, or longer where law or a contract asks.

    In the pack

Practical checklist

  1. Confirm the test restored data from a backup and was judged against the criteria.
  2. Raise a finding for each missed criterion, with an owner, a severity and a due date.
  3. Raise an objective gap for a missed recovery time, and show the restore time beside the cyber recovery time.
  4. Ask the business owner to record a workaround where the service cannot be back in time.
  5. Check the backup interval against the recovery point, and add any excess data lost to the objective gap.
  6. Set the severity, and tell the risk owner of a High finding so the risk is reassessed.
  7. Have the owner agree a plan within 10 working days, fix the cause and ask for a retest.
  8. Close the finding only when a retest shows the fix works, and report the test as a count with its name.

Evidence to have ready

  • The test record, with times from system logs and each missed criterion named.
  • Each finding with its owner, severity, due date and link to any objective gap.
  • The objective gap, the change agreed to close it and when the risk owner was told.
  • The retest record that shows the fix works.
  • The test record kept for at least 3 years by the pack's default, or longer where law or a contract asks.

Assumptions

  • The test restored data from a backup and was timed. A tabletop or a drill is not a restore test, and a provider's own recovery test counts only for data it holds with no copy of yours.
  • The service's recovery time and recovery point objectives already exist. The test measures against them and never sets them.
  • The days shown are the pack's defaults: 10 working days for the plan and 90, 180 or 365 days to fix a High, Medium or Low finding. Your own standard may set others.

Not covered here