The two numbers, in plain terms
Two measures describe how an organisation survives losing data or losing a service. They answer different questions, and confusing them is the most common error in a continuity review.
The recovery point objective (RPO) answers: how much recent work could be lost? It is the maximum age of the data you would get back. An RPO of five minutes means that after an incident, at most the last five minutes of changes are at risk.
The recovery time objective (RTO) answers: how long until the service works again? It is the maximum time between an incident being declared and the affected function being available and validated.
An RPO is set by how often data is captured. An RTO is set by how quickly it can be rebuilt. They are improved by different investments, which is why Legiscope publishes them separately for each data class rather than as a single headline figure.
Published objectives
The objectives below apply to the covered production service. They are stated per data class because the mechanisms protecting structured records and stored files are not the same, and a single number would flatter one and misrepresent the other.
The four-hour recovery time applies to restoring one identified database or file store while the rest of the platform keeps running. The twenty-four and forty-eight-hour figures apply to rebuilding the service as a whole.
These figures are held in an approved internal recovery-objective register with a named owner, the analysis behind each number and a review at every material change to the recovery architecture. They are not marketing figures chosen after the fact.
Objectives by data class and scenario
| Data class or scenario | Recovery point objective | Recovery time objective |
|---|---|---|
| Structured customer recordsRegisters, processings, incidents, assessments and related application records | 5 minutes | 4 hours |
| Customer files and uploadsDocuments and evidence stored against an account | Zero for overwrite or deletion | 4 hours |
| Whole service, primary EU regionRebuilding the covered service where it normally runs | As above, per data class | 24 hours |
| Whole service, second EU regionRebuilding after the loss of the primary region | 24 hours | 48 hours |
What produces each number
An objective is only credible if the mechanism behind it is stated. Each number above rests on a specific technical property of the platform, not on an estimate.
- The five-minute record objective comes from continuous point-in-time recovery on the production databases. They can be restored to any second within a trailing 35-day window, and that window trails live data by a few minutes.
- The zero-loss file objective comes from version retention. Every write keeps the prior version, so an overwrite or a deletion is reversible without waiting for a backup cycle: there is no window in which a stored file exists in only one state.
- The twenty-four-hour objective for the geographically separate copy comes from the interval at which covered data is copied out of the primary region.
- The four-hour restore objective covers recovering one identified database or file store while the rest of the platform continues running. It is the ordinary case: a table restored, a set of documents recovered.
- The twenty-four and forty-eight-hour rebuild objectives cover reconstructing the service itself. Infrastructure is defined in controlled source, so a rebuild is a repeatable deployment followed by a data restore rather than an improvised reconstruction.
What these objectives do not promise
The boundaries below are as much a part of the statement as the numbers. A reviewer who assumes more than this is assuming something Legiscope has not said.
- They are objectives, not guarantees. They carry no service credits and no contractual remedy unless a separate written agreement provides one.
- No dated end-to-end restoration exercise measuring these objectives is published. The recovery-point figures follow from the recovery settings in force; the recovery-time figures are approved targets that a measured exercise has not yet confirmed. When one is run, the measured result will be published here.
- They do not promise zero data loss. An RPO above zero is an accepted quantity of loss, stated openly.
- They do not cover data a customer has itself deleted through a supported workflow, or records removed at the end of a retention period. Recovery protects against failure and accident, not against intended deletion.
- They do not extend to third-party services a customer connects, or to exports a customer holds outside the platform.
Where this fits in the security record
These objectives are published as control A32-C-03 in the Legiscope Article 32 record, under Article 32(1)(c) — the ability to restore the availability and access to personal data in a timely manner after an incident. The control map states the evidence boundary for each measure, including the recovery controls that support these objectives.
Article 32(1)(c) does not require a particular recovery time. It requires the ability to restore in a timely manner, and the ability to evidence it. Publishing the objective is what makes the second half assessable.