Backup and Disaster Recovery
CareLedgerPro
Version 1.0 — Last updated: 6 August 2026
This statement sets out how service-user financial records are backed up, how quickly they can be recovered, and what happens in each failure scenario. It supports the availability and resilience requirement of UK GDPR Article 32(1)(b)–(c) and the business-continuity expectations of the DSPT and CQC well-led domain.
1. What is backed up
- The full PostgreSQL database: service-user records, transactions, balances, signatures, spending plans, communications, and all audit logs.
- Object storage: receipt images and communication attachments.
- Authentication data: user accounts, roles and two-factor enrolment.
- Application source, database schema and every migration, held in version control.
Backups are encrypted at rest and held in the same UK/EU region as the production database.
2. Backup regime
The managed database platform takes daily full backups and maintains continuous write-ahead logging that enables point-in-time recovery to any moment within the retention window. Backups are retained on a rolling basis by the platform; older financial records remain available in the live database for the full seven-year retention period, so backup retention is a recovery mechanism rather than the archive of record.
Backups are managed by the infrastructure provider and are not writable from the application, which limits the blast radius of an application-level compromise.
3. Recovery objectives
Targets below are CareLedgerPro's operational objectives. They are not contractual service levels and are not independently certified.
- Recovery Point Objective (RPO): under 5 minutes for database content within the point-in-time recovery window; up to 24 hours for a full region rebuild.
- Recovery Time Objective (RTO): 1 hour for an application rollback, 4–8 hours for a database restore, up to 72 hours for a full region rebuild.
4. Scenarios and response
| Scenario | Response | Objective |
|---|---|---|
| Accidental bulk deletion or a bad data change by an administrator | Point-in-time recovery to a timestamp immediately before the change, or targeted restore of affected rows from a recovery copy. Audit logs identify the change and the actor. | RPO under 5 minutes; RTO within 4 hours |
| Database corruption or failure of the managed database instance | Restore the most recent backup and replay write-ahead logs to the failure point on new infrastructure provided by the managed platform. | RPO under 5 minutes; RTO within 8 hours |
| Application or deployment failure | Roll back to the previously published build. Application code and the database schema are held in version control and applied through migrations, so a rebuild does not depend on any single machine. | RTO within 1 hour |
| Loss of a hosting region | Provision a new project in an alternative UK/EU region from migrations, restore the latest database backup, and re-point DNS and storage. | RPO under 24 hours; RTO within 72 hours |
| Ransomware or malicious destruction of production data | Restore from an isolated backup copy that is not writable from the application, rotate all credentials and API keys, force re-authentication, and raise a breach record with the 72-hour ICO clock. | RPO under 24 hours; RTO within 72 hours |
| Loss of a receipt or attachment file in object storage | Restore from storage backups. Transaction records remain intact regardless, and a missing receipt is surfaced by the missing-receipt report. | RTO within 24 hours |
5. Restore testing
Restores are exercised at least annually against a non-production copy, and after any change to the backup configuration. A test is recorded as successful when the restored database passes schema verification, row-count comparison on core tables, and a sign-in plus transaction-read check. Outcomes are logged in the testing schedule.
A restore that fails its verification checks is treated as an availability incident and handled under the incident response plan.
6. Controller responsibilities
Providers remain responsible for their own continuity arrangements: keeping a periodic export of transaction reports where their internal policy requires an offline copy, maintaining a paper or offline fallback for recording cash movements during an outage, and reconciling any offline entries once service is restored. Data loss caused by a Controller deleting their own records is recoverable only within the point-in-time recovery window, so deletion requests should be confirmed carefully.
Contact
To request a restore, report suspected data loss, or ask for evidence of the last restore test, contact support@careledgerpro.co.uk.
Not independently certified. Not legal advice. CareLedgerPro provides controls designed to help Controllers meet their obligations under UK GDPR, safeguarding standards, and CQC evidence expectations. Final responsibility for compliance, DPIA completion, DSPT submission, DSAR handling, and record retention rests with the provider.