Recovery Time and Recovery Point Thinking

Recovery time thinking asks how quickly a service, or a step within it, needs to return before harm becomes intolerable. Recovery point thinking asks how much recent data a service can afford to lose, and therefore how recent a usable recovery copy must be. The two ideas work together, and both should be driven by the service tolerance, not by what technology happens to offer. Under DORA in the EU, which applies from 17 January 2025, and under the separate UK regime in FCA PS21/3 and PRA PS6/21, firms should label the regime they are working under, because tolerance language and supervisory expectations differ between regimes. This guide discusses both ideas qualitatively, without inventing numeric targets for any service, because a target only has meaning for a named service in its own context.

Time and data loss are often confused, but they answer different questions. A service can return quickly yet serve stale or incomplete data, leaving customers with wrong balances or missing transactions. Conversely, a service can restore a very recent data copy yet take so long to return that customers have already suffered the harm tolerance was meant to prevent. Planners therefore need both lenses. They should ask, for each service step, what a delay does to customers, and separately what missing or uncertain data does to customers. Only then can they judge whether a recovery design is balanced, or whether it optimises one dimension while quietly neglecting the other.

Consider an illustrative insurance claims service. A customer reporting a loss may need acknowledgement, guidance and a route to urgent support, even if full claims processing cannot yet resume. The recovery time question for that early step is about contact and triage, not about restoring the entire claims system at once. The recovery point question is different: if recent claim notes, photographs or correspondence are lost, the firm may have to ask customers to resubmit material at a distressing time, or may make decisions on an incomplete record. Thinking through both dimensions helps the firm sequence recovery so that humane, useful steps return earliest, while data-sensitive steps wait until their records can be trusted.

Trade-offs are unavoidable. Faster recovery and more recent data copies usually require more investment, more complexity, more testing, and more operational discipline. A firm cannot simply demand the fastest and most complete recovery for every service step, because resources, supplier capabilities and technical constraints are finite. Impact analysis helps here: steps where delay or data loss causes rapid or serious harm justify stronger recovery arrangements, while steps where customers can wait safely or where data can be reconstructed justify lighter arrangements. Those judgements should be explicit, owned and revisited, so that they reflect service priorities rather than the preferences of individual teams or suppliers.

A common mistake is to record recovery objectives in a plan and then never test whether they are achievable. A test should check not only whether systems can be restored, but whether they can be restored in service order, with data that passes integrity checks, and with the people and suppliers needed for the work. If a test shows that recovery takes longer than assumed, or that the usable data copy is older than assumed, the plan should change, or the tolerance discussion should be reopened with honest reasoning. Pretending that an objective is met because it is written down is worse than admitting a gap, because it leaves service owners, reviewers and customers with false confidence.

Recovery thinking should also cover partial and degraded service. A service need not return in full to be useful, and insisting on full restoration before any customer step returns can prolong harm. At the same time, a partial service that creates misleading records or promises customers something that cannot be fulfilled can cause fresh harm. Planners should therefore describe, for each service, which steps can return in degraded form, what customers will be told about the limitation, and how work done during degraded operation will later be reconciled. That description turns recovery time and recovery point thinking from abstract objectives into a practical sequence that responders can follow and customers can understand.