Reference table
Recovery objectives
Sets out the recovery time and recovery point objectives Pensieve targets for each service, with the measure behind each figure.
A recovery objective sets two things: the recovery point, how much recent work a restore may lose, and the recovery time, how long until the platform is back. Both are committed per deployment and recorded on the order form and in the service level agreement, not fixed on this page. This page sets out what is backed up, the retention clocks that are kept apart, and who commits and who restores for each deployment model.
What is backed up
Each layer is protected in the way that fits it. The database keeps a rolling recovery point, object storage keeps its own versions, and configuration is rebuilt rather than restored.
| Layer | How it is protected |
|---|---|
| Database | Automated backups with point-in-time recovery. The recovery window and the backup frequency are set per deployment and recorded in the deployment record. |
| Object storage | Versioned, with a soft-delete window. An accidental or malicious deletion of a document or image is recoverable within that window without going to a backup at all. |
| Configuration and infrastructure | Defined in code and held in version control. An environment is rebuilt from code rather than restored from an image. |
Backups the application cannot reach
Backups stay in the deployment's own data region and inherit the encryption of their source, under the same key hierarchy. They are held in storage the application's own service identity cannot delete, so a compromise of the application does not reach the backups. Deleting backup data needs a separate administrative identity, and it is logged.
Three retention clocks
Three clocks are routinely conflated. They are kept separate here, because each answers a different question and each is set in a different place.
| Clock | What it governs | Where it is set |
|---|---|---|
| Backup retention | How far back a restore can reach. | The window set per deployment. |
| Record retention | How long a record is kept live in the system. | Per record class, with statutory floors. |
| Log retention | How long audit and system logs are kept. | Not less than 365 days. |
Deletion is not instant in backups
Deleting a record from the live system does not instantly delete it from backups. Backup deletion follows the backup rotation. A claim of instant deletion from backups means either that there are no backups or that the claim is not true.
Who commits, and who restores
Pensieve commits recovery objectives only where it controls the infrastructure. The committed recovery time and recovery point for a deployment are the values recorded on its order form and in the service level agreement. The split of who commits and who runs the restore follows the deployment model.
| Deployment model | Recovery objectives | Restore run by | Backup media held by |
|---|---|---|---|
| DM-1 Dedicated | Committed. | Pensieve | Pensieve |
| DM-2 Shared | Committed on the same basis. | Pensieve | Pensieve |
| DM-3 Customer cloud | Committed, subject to the hospital's project staying available, funded and within quota, and its keys staying accessible. | Pensieve, inside the hospital's project | The hospital |
| DM-4 On-premise | No Pensieve commitment. Restore time depends on the hospital's hardware, media and staff. | The hospital, with Pensieve support | The hospital |
The same split is set out from the other direction in shared responsibility. A commitment that offered the same recovery time for on-premise hardware Pensieve has never seen as for its own cloud would not be an honest one.
A restore verifies before it opens
A restore does not end when the data is back. Before access is restored, the recovered system is checked for integrity: row counts, referential checks, and the most recent encounter, medication administration and transaction against the chosen recovery point. Sessions from before the event are invalid and are not carried across. This check runs even under pressure, because a restore that is fast and wrong is worse than one that is slow and right.
Does Pensieve publish a recovery time in hours?
No. The committed recovery time and recovery point for a deployment are recorded on its order form and in the service level agreement, because they depend on the deployment model and the region. This page describes the mechanism that meets them.
Where do backups live?
In the deployment's own data region. They are not copied to another region or another country. Keeping backups in region is a deliberate choice, and it means a total loss of the region is the worst case rather than one a copy elsewhere would soften.
What happens while a restore is in progress?
The hospital's own downtime procedure governs care while the platform is unavailable. That procedure, and what degrades and what holds, is set out in what happens when the link drops.
Read how long each record class is kept live in retention.