Independent thinking. Informed defence.

CISO Times

Intelligence for the people behind the defence.

The CISO Decision Brief

When do we…

When do we test recovery, and how much testing is enough?

6 decision pointsThe pack behind this answer: Cyber Resilience & Recovery

Add to board memo

The short answer

Recommendation
Test the recovery of every critical service at least every 12 months and after any significant change, and a never-tested service within 6 months of agreeing its objectives, by the pack's defaults. Only a test that restores systems and data and times them against the objectives counts.
Reasoning
An untested recovery time is an estimate. Only a recovery timed against the objective shows whether the service can come back in time. A tabletop exercise tests decisions and restores nothing, so it never counts as a recovery test. Testing is enough when every critical service was restored within its recovery time in a test in the last 12 months. Every objective a test misses becomes a gap with an owner, so it is fixed before the next test finds it again.
Considerations
  • Where a supplier runs the systems, the test is the supplier's own recovery test, with its results shared and checked against the objectives.
  • Check the recovery time and the recovery point separately. A service can come back in time and still lose more data than its objective allows.
  • A restore onto trusted systems does not measure the cyber recovery time. A cyber recovery test rebuilds the foundations in an isolated environment first, then the service's systems.
  • Where a law or supervisor applies to you, check what it asks. For financial entities under DORA's full framework, plans are tested at least yearly and after substantive change.

The decision, step by step

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

  • Start
  • Step
  • Decision
  • Outcome
StartPlan when to test a service's recoveryDecisionIs it one of your critical services?OutcomeFollow the Restore Testing Methodology for other restoresDecisionHas its business owner agreed its recovery objectives?OutcomeAgree its objectives first; test within 6 monthsDecisionHas its recovery ever been tested?DecisionTested in the last 12 months, with no significant change since?OutcomeNot due yet: book the next test before 12 months passStepChoose a test that shows the time a real recovery would takeDecisionWill it restore data and time it against the objectives?OutcomeThat is an exercise; plan a real recovery test as wellStepRun it and record the time achieved and the data lostDecisionWere both the recovery time and the recovery point met?OutcomeWrite lessons into the plan; book the next testOutcomeRecord each miss as a gap; fix, retest and tell the risk owner

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. 15 steps.

  1. Start

    Plan when to test a service's recovery

    An untested recovery time is an estimate. Only a recovery timed against the objective shows whether the service can come back in time. The pack sets when each critical service is tested, what counts as a test, and what follows a missed objective.

    In the pack

  2. Decision

    Is it one of your critical services?

    A critical service is one whose disruption beyond its maximum tolerable downtime would cause Severe harm on your risk register's impact scale. It is a business service, such as online ordering, not a system. The recovery tests in this flow are for those services; if you are unsure whether a service is critical, treat it as critical.

    In the pack

  3. Outcome

    Follow the Restore Testing Methodology for other restores

    The pack tests the recovery of critical services, which includes restoring their data. How often other restores are checked, and how they are judged, follows the Backup & Restore Assurance pack's Restore Testing Methodology. Follow it, and check that the copies are checked for integrity before anything is restored.

    In the pack

    See also

  4. Decision

    Has its business owner agreed its recovery objectives?

    A test measures the time achieved and the data lost against the recovery time objective (RTO) and recovery point objective (RPO). Without objectives the business owner has agreed, there is nothing to measure against. Objectives set by IT alone are not agreed.

    In the pack

  5. Outcome

    Agree its objectives first; test within 6 months

    Ask the business owner to agree the service's maximum tolerable downtime, recovery time and recovery point from an impact analysis. A service never tested is then tested within 6 months of its objectives being agreed, by the pack's default. Book that test as soon as they are agreed.

    In the pack

    See also

  6. Decision

    Has its recovery ever been tested?

    A service never tested is tested within 6 months of its objectives being agreed. Its status until then is Not proven: the objectives may be right, but nobody has shown they can be met. In the pack's example, two services never tested have their first tests booked within 6 months of the objectives being agreed on 25 Sep 2026.

    In the pack

  7. Decision

    Tested in the last 12 months, with no significant change since?

    The recovery of every critical service is tested at least every 12 months, and again after a significant change to it, such as a new platform, host or supplier. A test older than that, or taken before such a change, no longer shows what recovery takes today. If you cannot tell, take the cautious branch. For financial entities under the full framework, DORA asks for tests of the plans at least yearly and after substantive change, including cyberattack and switchover scenarios.

    In the pack

    See also

  8. Outcome

    Not due yet: book the next test before 12 months pass

    Put the next test in the year's plan before its due date. Keep it away from any period when the business cannot risk a test; the pack's example keeps tests off its peak season. If the last test missed an objective, that miss should already be an open gap with a change agreed; check it is. A real recovery that missed an objective counts the same way.

    In the pack

  9. Step

    Choose a test that shows the time a real recovery would take

    Pick a test that recovers the service or its systems and measures the time. The pack's example uses a full restore, a system restore, a supplier's failover with its results shared, and a cyber recovery. A cyber recovery test rebuilds the foundations in an isolated environment first, then the service's systems. It measures the cyber recovery time, which a restore onto trusted systems does not.

    In the pack

    See also

  10. Decision

    Will it restore data and time it against the objectives?

    A recovery test recovers the service or its systems, restores its data, and records the time achieved and the data lost. A tabletop exercise tests people and decisions and restores nothing, and the pack treats a drill as an exercise too. Neither counts as a recovery test. A trial of a workaround does not count either.

    In the pack

  11. Outcome

    That is an exercise; plan a real recovery test as well

    Run the exercise for what it tests: decisions and roles. Do not record it as the service's recovery test. Plan a test that restores systems and data and measures the time, so the service does not appear tested when nothing has been recovered.

    In the pack

    See also

  12. Step

    Run it and record the time achieved and the data lost

    Count the time from the start of the recovery to the point the service would be ready for users, and the data lost back to the recovery point used. Write both against the RTO and RPO. The resilience coordinator answers for the test; the technical recovery lead runs it; the business owner is consulted.

    In the pack

  13. Decision

    Were both the recovery time and the recovery point met?

    Check each separately. In the pack's example, the warehouse system came back in 5 hours against an 8-hour RTO, but lost 24 hours of data against a 4-hour RPO: one objective met, one missed. If the test stopped before the service was ready, the time is not known: take the cautious branch.

    In the pack

  14. Outcome

    Write lessons into the plan; book the next test

    Review the recovery plan after the test and write in what it showed. Book the next test within 12 months. Testing is enough when every critical service has been restored within its RTO in a test in the last 12 months, reported as a count with every service that falls short named. Work out the cyber recovery time too and compare it with the RTO; the pack's example then measures it in a cyber recovery test.

    In the pack

    See also

  15. Outcome

    Record each miss as a gap; fix, retest and tell the risk owner

    Every objective a test missed is an objective gap. By the pack's default its owner agrees the change that closes it within 10 working days, with a due date. The service's risk owner is told and the risk is reassessed. The business owner reviews the objectives and the plan is updated. The gap closes when its checks pass, which for a missed time means a retest, or when the business owner re-agrees the objective on a new analysis.

    In the pack

    See also

Practical checklist

  1. Confirm the service is critical and its business owner has agreed its recovery time and recovery point.
  2. Book a never-tested service's first test within 6 months of its objectives being agreed.
  3. Schedule each critical service's next test within 12 months of its last, and again after a significant change to it.
  4. Choose a test that recovers the service or its systems and restores its data. Run tabletops and drills as exercises alongside.
  5. Record the time achieved and the data lost against the recovery time and recovery point objectives.
  6. Record each missed objective as a gap with an owner, a closing change and a due date, and tell the service's risk owner.
  7. Write the lessons into the recovery plan and book the next test.

Evidence to have ready

  • The test schedule, with each critical service's last test date and next due date.
  • For each test: what was recovered, the time achieved and the data lost against the objectives, and who ran it.
  • A supplier's shared test results, checked against the service's objectives.
  • Each objective gap a test opened, with its owner, closing change, due date and retest.
  • The recovery plan as updated after each test. The pack's default keeps test records for 3 years, or longer where law or a contract asks.

Assumptions

  • You have a list of critical services, each with a business owner who has agreed its recovery time and recovery point objectives.
  • Someone coordinates the test schedule, and your IT team or providers can recover systems somewhere that does not disturb production.
  • You use your own policy's intervals. The 12 and 6 months here are the pack's defaults; where a law or supervisor applies to you, check what it asks.

Not covered here