What GDPR Article 32(1)(c) requires for restoring personal data
Article 32(1)(c) asks controllers and processors to have the ability to restore the availability of and access to personal data in a timely manner after a physical or technical incident. If you have been asked to show restore capability for personal data, the test is not whether backups exist but whether you can bring the specific personal data back, within a time you have defined and can justify, and show that you have done it. The EDPB treats accidental or unauthorised loss of access to, or destruction of, personal data as an availability breach under *Guidelines 9/2022*, so a ransomware event or a failed storage volume can be notifiable even when no one has read the data. The guidelines also note that whether the controller still holds a copy of data destroyed at a processor may affect whether notification is needed, which makes the processor's backup position part of your risk picture.
Three things usually make this hard. First, backups often cover whole platforms but not the personal data sets that matter most, or they cover data nobody can map back to a processing purpose. Second, restore objectives are often unwritten, so nobody can say how quickly a customer record or HR file must return. Third, backups keep personal data after the controller has deleted it elsewhere, which the EDPB's 2025 coordinated action on erasure flagged as a difficulty for controllers. Backup design therefore affects both restoration and erasure. Confirm with your legal and records team which datasets must be restorable, the retention rules that apply to each copy, and how an erased record is removed from or excluded in future restores.
Start by writing down restore objectives per dataset, then run a restore test against a non-production target and record what came back and how long it took. Tools such as *Bareos* can restore files from the current backup or from a point before a given date and time, and *restic* can read pack files back with restic check --read-data to confirm the stored data is unmodified. Use monitoring, for example *Prometheus* metrics alerted through *Grafana Alerting*, to show that backup jobs are running and that failures are seen. Keep the test results, the decisions behind the objectives and the erasure handling as evidence. A third party can check that evidence, but only the organization owns the restore capability it describes.
Which systems and backups fall under the restore obligation
Article 32(1)(c) applies to every place personal data sits and every party that can make it unavailable. The cards below separate the production stores, backup copies, outsourced holdings, logs and restore responsibilities that a restore plan must cover before it can be tested.
Production databases and file stores
Start with the systems that hold personal data in active use: customer and employee databases, document stores, shared drives and object buckets. For each one, record the data categories, the owner and the business processes that stop when it is unavailable. Article 32(1)(c) asks whether the controller can restore access to this data in a timely manner after a physical or technical incident, so each store needs a stated recovery point and recovery time that someone has agreed to. Confirm that no personal data sits in an untracked export, spreadsheet or test copy outside the inventory.
Backup repositories and archives
Backups are in scope even though they are rarely used day to day. List every backup target, including disk repositories, tape, off-site copies and immutable archives, and note which production systems feed each one. Check whether the backup catalog itself can be restored, because a backup that cannot be located or indexed cannot be used. Backup design also affects erasure, since the EDPB's 2025 coordinated action on the right to erasure found controllers struggling to delete personal data held in backups. Document how restored data will be re-checked against erasure and restriction decisions.
SaaS-hosted data held for customers
If your organization is a processor, the restore obligation still reaches the personal data you hold for controllers. Confirm in the processing agreement who is responsible for backups of customer data in each SaaS or hosted service, the restore targets promised, and how a controller can request a restore. Ask sub-processors whether they keep their own backup copies, where those copies are stored and who can access them. The EDPB's breach guidelines note that whether a copy of lost data exists at the processor can change whether the controller must notify, so the copy's existence must be known and documented.
Logs containing personal data
Application, access and audit logs often contain IP addresses, user identifiers and request content that qualify as personal data. Decide which log sources must be restorable, for example those needed to investigate a security incident or demonstrate accountability, and which can be discarded under a retention schedule. Logs that support breach assessment are only useful if they survive the incident that disabled the systems producing them. Check that the monitoring stack, such as Prometheus metrics or Grafana alert history, is included in the restore design where it stores or displays personal data.
Restore operators and third parties
Map who performs and approves a restore: internal backup operators, the cloud provider's support staff, managed service providers and any outsourced backup vendor. For each party, record the access they hold to backup data, the approval step before a restore runs and the contact path during an incident. An outside party that can read restored personal data is a processor or sub-processor, so the contract and transfer terms must cover that access. Confirm that restore credentials are held under separate access control and that someone internal can restore without depending on a single vendor.
Recovery authority and decision records
Decide who may declare an availability incident, start a restore and decide whether the event is a notifiable personal data breach. EDPB Guidelines 01/2021 include ransomware cases where proper backups changed the notification outcome, so the decision depends on evidence about what was lost and what could be recovered. Record the restore scope, the time each step completed and the data subjects and categories affected. Confirm that these records are kept with the incident file so a supervisory authority can see how the decision was reached.
How the restore objective shapes the whole program
Article 32(1)(c) does not set a number for how quickly personal data must come back. It asks the controller to restore availability of and access to personal data in a timely manner after a physical or technical incident. The controller therefore has to decide what "timely" means for each dataset, based on the risk to the individuals concerned, and then show that its systems can meet that decision. The starting point is a recovery point objective (RPO), the maximum amount of data loss the business and the data protection owner accept, measured as the age of the newest usable copy. The recovery time objective (RTO) is the maximum time a dataset may stay unavailable before service or rights are affected. Both are plain business decisions, but they carry data protection consequences, so the data protection owner should sign off on them alongside the service owner.
These objectives have to be written down before an incident, not agreed during one. A written register, kept with the record of processing, should list each dataset or system, its owner, its RPO and RTO, the backup method, where copies are held, and the person who can authorize a restore. Without that record, the controller cannot show an assessor what it intended, and staff under pressure tend to pick whatever the tool allows. The register also feeds the breach decision: if a ransomware event removes access to a dataset with a short RTO and no usable backup, the controller has less room to argue that the impact was limited. Confirm with your own risk owners how often the register is reviewed and who approves changes, since the GDPR does not prescribe a cycle.
The objectives also constrain design. A short RPO means backups or replication must run often enough to meet it, and a short RTO means restore capacity, credentials and runbooks must be ready in advance. Backup copies also raise an erasure question: the EDPB's 2025 coordinated action on the right to erasure found controllers struggling to delete personal data held in backups, so retention and restore rules for backups should be part of the same register. Ask your implementation partner to show how each objective maps to a schedule, a retention setting and a tested restore, and check the open-source tooling you choose against those objectives before you commit to it.
How an assessor tests restore capability for personal data
This table lists what an assessor typically reviews for Article 32(1)(c), what evidence satisfies each step, and where organizations usually fall short. Read it as a checklist to prepare your records before an assessment, since the gaps that appear most often are usually documentary rather than technical.
| Assessor step | What the assessor looks for | Common shortfall |
|---|---|---|
| Restore objectives | Documented recovery time and recovery point targets for each system holding personal data, approved by the business owner and tied to the risk assessment | Objectives exist for infrastructure but not for systems that hold personal data, or they were set without reference to risk |
| Backup scope against the record of processing | A mapping showing every system and processor location listed in the record of processing is covered by a backup job, with exclusions justified | Backups exclude key systems such as SaaS platforms, logs, file shares or databases that the record says hold personal data |
| Restore test records | Dated test logs showing which datasets were restored, who ran the test, the start and end times, and whether the result met the objective | Restores are described in policy but no dated test record exists, or only a successful backup job log is provided |
| Coverage of personal data in restores | Evidence that restored datasets contained personal data and that record counts or checksums matched the source | Tests restore an empty or synthetic dataset, so the restored personal data was never actually checked |
| Access controls on restored data | Proof that permissions, encryption keys and authentication settings were reapplied to restored systems before users regained access | Restored systems come back with default or broader access, or key material needed to decrypt backups is not recoverable |
| Backup integrity checks | Verification job results or repository check output showing backups are readable and unmodified before a restore is relied upon | Backups are written but never verified, so corruption or ransomware encryption is discovered only during a real incident |
| Link to breach assessment | Evidence that loss of availability was assessed as a possible personal data breach and that backup availability informed the notification decision | Incident records treat outages as purely operational and do not document whether personal data access was lost |
| Erasure in backups | A documented approach for removing or suppressing deleted personal data from backups and restores, consistent with the erasure process | Restores silently reintroduce records that were erased from production, and the organization has no procedure to catch them |
Implementing restore capability step by step
This sequence turns Article 32(1)(c) from a policy statement into a tested capability: each personal data store is known, covered by backups, assigned a recovery objective with an owner, restored successfully, and linked to a breach response path.
Inventory personal data stores and backup coverage
Start by listing every system that holds personal data, including production databases, file shares, SaaS exports, logs, analytics stores and the backup repositories themselves. For each store, record the data categories, the business owner, where a copy is kept and whether a backup job already covers it. The output is a register with one row per store and a column showing backup status, with gaps flagged for remediation. Ask the platform team to confirm the list against infrastructure records, since shadow copies in spreadsheets or exports are a common omission.
Set restore objectives per dataset with owners
For each store in the register, the data owner and the platform owner agree in writing how quickly the service must return and how much data loss the business can accept. These targets are set per dataset because a customer record store and a diagnostic log store rarely warrant the same recovery path. The output is a signed recovery objectives table naming an accountable owner for each dataset. Article 32(1)(c) asks for timely restoration, so the table is the reference against which later restore tests are judged.
Choose and configure backup tooling
Select backup tooling that fits the data types and the environment, then configure schedules, retention, encryption and access to the backup repositories. Bareos is one option for centralized scheduling, restore and catalog management of file and database backups, and restic is another for deduplicated repositories with a built-in consistency check. Confirm each tool's current capabilities, supported platforms and licences against its own documentation before committing. The output is a documented configuration per store, stored under version control, with backup credentials held separately from production administrators.
Run and record restore tests with access checks
Restore a representative sample from each backup class into an isolated environment, then measure the elapsed time against the agreed objective and the data loss against the recovery point. Verify integrity with the tool's verification features, such as restic check with read-data options, and confirm that restored records are complete and readable. Check that role-based access controls on the restored copy match production, so that recovery does not create an unprotected copy of personal data. The output is a signed test record per store showing date, scope, result, deviations and the owner's acceptance.
Define the procedure for availability breach notification
Write a procedure that treats loss of access to personal data as a potential personal data breach to be assessed, not only as an operational incident. EDPB Guidelines 9/2022 describe accidental loss of access or destruction as an availability breach, and EDPB Guidelines 01/2021 show ransomware cases where the presence or absence of proper backups changed the notification outcome. The procedure should state who assesses the incident, how backup availability is recorded in that assessment, and how processors notify the controller. The output is a breach runbook section approved by the data protection function, linked to the Article 33 process.
Link monitoring to backup and restore signals
Configure alerts that show when backup jobs fail, verification does not complete, repositories approach capacity or restore tests fall outside the objectives. Prometheus can collect metrics from instrumented backup jobs, and Grafana Alerting can build rules across those metrics and logs and route them to the owners named in the register. Confirm that the exporters and data sources you use support the signals you need. The output is a set of alert rules with named owners and a test showing that a deliberately failed job produces an alert.
Schedule recurring restore tests and erasure checks
Put restore tests on a recurring calendar set by the data owners, with the frequency justified by the risk assessment rather than by habit. Each cycle repeats the sampled restore, updates the register for new stores and reviews whether backups still hold data that must be erased under the right to erasure, a point the EDPB raised in its 2025 coordinated action. The output is an approved test calendar, a log of completed cycles and a list of corrective actions with owners and closure dates. Keep these records, because they are the evidence an assessor or regulator will ask to see.
Why backup design affects both restoration and erasure
Backup design decides whether a controller can restore personal data after an incident and, later, whether it can erase that data when a person asks. The EDPB's 2025 coordinated action on the right to erasure found controllers struggling to delete personal data held in backups, so this tension is now a supervisory focus rather than a theoretical one. A backup that preserves data well for recovery can make a specific erasure request hard to honor, and the two duties have to be designed together.
The core tension is between retention and immutability for recovery and erasure obligations. Immutable copies protect against ransomware and deletion, and long retention gives room to recover from a late-discovered corruption. Both properties also keep personal data alive after the production copy is erased. Tools such as Bareos keep a catalog of backed-up files and support restores from a chosen point in time, so the catalog, retention pools and job definitions are the places to record what personal data sits where and for how long. Restic's snapshot model works similarly, since forgetting a snapshot and pruning its data are separate steps that must be run and evidenced. Confirm with each vendor exactly what deletion of an individual record inside a backup set involves before you rely on it.
A workable reconciliation combines three documented decisions: a backup expiry period that is short enough to justify, written into the retention schedule; a rule for how erased records are handled in backups that are still within that period, such as restoring to a clean state and then reapplying deletions; and a log of erasure requests that the restore process checks before data returns to production. Illustratively, a team that restores after an incident should confirm that people whose erasure requests were completed do not reappear in live systems. Whether any particular arrangement satisfies the regulation is a legal judgment for the controller and its data protection officer, not something a tool setting can establish.
Evidence that shows timely restore works
Article 32(1)(c) is only demonstrated when the organization can show, with dated records, what it promised to restore, how fast it actually restored, and whether the restored data was intact. The cards below cover the documents, test results, logs and review routines that an assessor or a supervisory authority would ask to see, and that should exist before anyone asks.
Documented restore objectives
Record a recovery time objective and a recovery point objective for each system that holds personal data, approved by the system owner and the data protection function. These targets are the yardstick every later restore test is measured against. Check that the objectives reflect what the business and data subjects can tolerate, not what the backup tool happens to deliver, and that any system without a stated objective is listed as a gap.
Backup policy and scope
The backup policy should state which systems, databases, file stores and logs are backed up, how often, where copies are kept, and who may start a restore. Map each in-scope system to the record of processing so that personal data categories are traceable to a backup job. Confirm that processor-hosted systems are either covered by the processor's contract and evidence or flagged as dependencies the controller cannot verify alone.
Dated restore test reports
A restore test report should name the system, the backup set restored, the start and end times, the measured elapsed time against the recovery time objective, and the data integrity result. Reports dated only once a year rarely show whether restore performance has drifted. Ask for the most recent set of reports and check whether failed tests led to a documented corrective action with a retest date.
Backup catalog and job logs
The backup catalog and job logs prove what was backed up and when, and they let a restore target a point in time. Bareos, for example, keeps a SQL catalog of backed-up files and its Director records schedules and job outcomes. Check that logs are retained long enough to cover the recovery point objective, that failed or partial jobs generate alerts, and that the catalog itself is backed up.
Integrity verification records
Verification records show that stored backup data is still readable and unmodified before it is needed in an incident. In restic, the check command confirms structural consistency, and running it with the read-data option reads pack files back to confirm the stored data is unchanged. Keep the output of these checks with timestamps, and confirm that a check failure opens an incident rather than being overwritten by the next run.
Incident restore records
After a real outage or ransomware event, record what was lost, which backup was used, when service and data access returned, and whether any personal data could not be recovered. These records feed the breach assessment, because EDPB Guidelines 01/2021 show that proper backups change whether a ransomware case needs notification. Confirm that the record also notes whether a copy held by a processor was available to the controller.
Review cycle between audits
Restore objectives, backup scope, test reports and verification results go stale when systems change. Set a review cadence, assign an owner, and tie reviews to change management so that new systems are added to backup scope before they go live. Metrics from monitoring tools such as Prometheus and Grafana Alerting can show backup job failures between formal reviews, and the review should confirm those alerts were acted on.
What meeting Article 32(1)(c) costs in money and effort
The first cost is the work of deciding what must come back, how quickly, and from which copy. Organizations usually pay for this as project time inside a fixed scope agreed in writing before the build starts. The GDPR sets no recovery time or backup frequency, so the controller must derive these figures from its own risk assessment and from the processing it runs.
- Scoping the personal data estate: List every system holding personal data, including databases, file shares, SaaS exports, logs and their backup copies. Systems missed here usually surface during the first restore test.
- Objective setting: Agree recovery time and recovery point targets for each system, signed off by the business owner and the security lead. These targets become the benchmark that later evidence is measured against.
- Initial tooling and configuration: Install and configure backup software such as Bareos, which schedules backup, restore, verify and archive jobs and keeps a SQL catalog of backed-up files. Add integrity checks such as restic check.
- Alerting and runbooks: Build alerts for failed or late jobs and write restore runbooks that a second engineer can follow without help.
Check that the setup quote lists each of these items separately, so you can see what is included and what is deferred.
Recurring costs continue for as long as backups run and personal data is held. They cover storage, compute for backup windows, monitoring, key management and the upkeep of evidence. Most of these costs grow with data volume and retention length, so they should be reviewed whenever either changes.
- Storage capacity: Full and incremental copies, retention periods and offsite or immutable copies multiply the storage footprint. Ask for an estimate based on your measured change rate and retention schedule.
- Job monitoring: Someone must act on failed or late jobs. Grafana Alerting can combine metrics and logs in one view, and Prometheus can collect job metrics, but an operator still has to respond.
- Integrity verification: Scheduled verify jobs in Bareos and restic check runs, including reads of a rotating subset of pack files with --read-data-subset, keep the backup set trustworthy between formal tests.
- Evidence upkeep: Job logs, catalog reports and change records for schedule and retention changes must be kept for the period an assessor will review.
- Access and key management: Credentials, encryption keys and access to backup repositories need rotation and periodic review, just like production access.
Ask which of these items sit inside a retainer and which fall to your own staff hours.
A backup only proves recovery once a restore has succeeded. Restore testing is therefore a recurring activity with its own effort: planning, running, recording and fixing what the test finds. The effort rises with the number and size of systems tested and with how often the recovery objectives are checked.
- Test planning: Select representative systems, define the restore point to be used and write down what success means before the test starts.
- Execution time: Restores of large datasets can take many hours. Plan for an isolated environment with enough capacity to run the restore without touching production.
- Remediation: A failed restore creates fix work whose size is hard to predict until the cause is known. Budget a contingency for this, not only for the planned run.
- Erasure checks: The EDPB's 2025 coordinated action on the right to erasure found controllers struggling to delete personal data held in backups. A restore test should confirm that restored data still respects erasure decisions, which adds effort to each cycle.
- Records: Log the date, system, objective achieved and any anomalies, so the test becomes evidence rather than a memory.
Ask the quote to state the test frequency, the number of systems covered in each cycle and who performs the erasure check.
Outside help comes in three forms: an implementation partner that builds and documents the backup design, a reviewer of restore test records, and an independent assessor if you pursue certification. The GDPR requires no audit or certificate, and Article 42 certification is voluntary. A partner prepares systems and evidence, but only an independent certification body can issue a certificate.
- Implementation partner: Designs and builds the backup architecture, prepares runbooks and assembles evidence, usually under a fixed scope with deliverables and dates agreed in writing.
- Restore test review: An outside engineer checks test records against the recovery objectives. Effort depends on the number of systems and how complete your records already are.
- Certification body fees: If you seek Article 42 certification, the certification body sets its own scope and charges. Certification does not reduce your controller or processor responsibility.
- Ongoing retainer: Continuous support, upgrades and testing are available as retainers, which suit recurring restore cycles better than one-off projects.
- Privacy specialist input: Legal review of how erasure applies to backups may need a privacy specialist or your data protection officer. This is separate from the technical work.
Ask whether each outside item is listed separately, with the party that performs it and the party that signs off the result.
Five inputs move the cost of meeting Article 32(1)(c) more than any others: data volume, number of systems, recovery objectives, retention length and deployment model. Tighter objectives and longer retention raise recurring cost, and a more complex environment raises setup and testing cost. Each input should appear as a separate line in the quote.
- Data volume and change rate: Larger datasets that change often need more storage and longer restores.
- Number of systems: Each system adds scope, backup jobs, runbooks and test effort.
- Recovery time and point objectives: Shorter recovery times usually need standby capacity or replicated copies, and shorter recovery points need more frequent backups.
- Retention length: Longer retention multiplies storage and makes erasure in backups harder to demonstrate.
- Deployment model: Air-gapped or multi-site designs add hardware, transfer work and separate test environments.
Illustrative example: a team that halves its recovery time may need standby capacity that it did not previously pay for, so ask the quote for options at two objective levels before choosing.
Self-hosted open-source tools for backup, verification and alerting
This table compares three open-source components by the restore-related job each performs, the evidence it can produce for an assessor, and what the client must confirm in its own environment. Read it as a set: Bareos performs the restores, restic check tests whether stored backup data is intact, and Grafana with Prometheus shows whether backup jobs are succeeding. No single tool proves that personal data can be restored within the organization's own timeframe.
| Component | Role for Article 32(1)(c) | Evidence it can produce | Confirm in the client environment |
|---|---|---|---|
| Bareos (AGPL-3.0-only) | Schedules backup, restore, verify and archive jobs and keeps a SQL catalog of backed-up files | Job logs, catalog records of backups, and restore job records showing files restored from a chosen backup or point in time | Retention periods, the backup scope covering all systems holding personal data, and the restore time the business has agreed to meet |
| restic check (BSD-2-Clause) | Verifies structural consistency of snapshots, trees and pack files | Check output from scheduled runs, including runs using --read-data or --read-data-subset that read pack files back to confirm stored data is unmodified | Whether full or subset reads are used, how often, and whether results are retained as evidence |
| Grafana Alerting (AGPL-3.0-only) | Builds alert rules across data sources and alerts on metrics and logs together | Alert rule definitions, notification history and records of how failed backup jobs were acted on | Who receives backup failure alerts, escalation paths, and whether alerts reach a team that can act outside business hours |
| Prometheus (Apache-2.0) | Collects metrics from instrumented jobs over HTTP and stores them as time series queried with PromQL | Time series showing last successful backup, job duration and failure counts over the reporting period | Which jobs are instrumented, how long metrics are retained locally, and whether monitoring itself is backed up |
| Restore testing as a process | The tools above can run restores, but the organization must decide what to test and record | Documented restore test scope, dated results and corrective actions, which an independent assessor can sample | Restore test frequency, who signs off results, and whether tests cover erasure-affected backups |
Your team, a partner and the auditor's role
The controller remains responsible for Article 32(1)(c) even when a partner builds the system. Internal owners set the restore objectives for each system holding personal data, decide which datasets are business critical, and approve the risk acceptance when a recovery target cannot be met. They also make the decisions during an incident: whether a loss of availability is a personal data breach, whether to notify the supervisory authority, and whether to notify affected individuals.
- Restore objectives: Business and data owners define acceptable downtime and acceptable data loss per system, and record who approved them.
- Data owners: They identify where personal data sits, including backups and logs, so restore scope matches the processing record.
- Incident decisions: Legal and the data protection function assess breach status, the 72-hour clock and notification content.
- Vendor oversight: If a processor holds the backups, the controller reviews its restore tests and contractual recovery commitments.
- Ownership of evidence: Someone internal signs off on each restore test report and keeps it with the control records.
Check that every restore objective has a named owner and an approval date that predates the most recent test.
An implementation partner prepares the technical system and the evidence that shows it works. DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, so backup architecture, tooling, runbooks and restore test records are built in that environment. The partner does not own the controls, set the risk appetite or decide on notifications.
- Architecture: Design of backup targets, retention, separation from production and immutability options, scoped to the agreed objectives.
- Tooling: Configuration of platforms such as Bareos for scheduled backup and restore, and restic for repository checks, with settings recorded in version control.
- Monitoring: Alert rules for failed jobs and stale backups, built with Grafana Alerting and Prometheus where the client uses them.
- Runbooks: Step-by-step restore procedures for each system, reviewed by the client's operations staff.
- Restore test evidence: Documented test scope, dates, results and open findings, delivered to the client for its own control records.
Confirm in the written scope which deliverables the partner signs off and which remain the client's responsibility.
An independent auditor, assessor or certification body tests the control and issues any report or certificate. The GDPR requires no audit or certificate, and Article 42 certification is voluntary and does not reduce the controller's responsibility. Where a customer or framework requires an external assessment of restore capability, the assessor samples evidence, observes restore tests and forms its own conclusion. DeployOpen does not issue audit reports, attestations or certifications.
- Sampling: The assessor selects systems and checks that restore objectives match the processing record.
- Observation: It may witness a restore and compare the result with the documented runbook.
- Independence: The partner that built the system should not also be the assessor of that system.
- Scope limits: Assessments cover only what is in the agreed scope, so unlisted backup copies can fall outside them.
- Reporting: Findings and any report come from the assessor, not from the implementation partner.
When selecting an assessor, ask how it will test restore evidence and whether it has a conflict with the implementation work.
Organizations usually outsource the build, configuration, runbook drafting and first-round restore testing, because these need specialist skills and sustained effort. They usually keep objective setting, data classification, incident decisions and sign-off. Recurring work such as scheduled restore tests, upgrades and monitoring tuning can be retained as a service, but the controller still reviews the results.
- One-time work: Architecture, initial configuration, runbooks and the first test cycle, fixed in a written scope.
- Recurring work: Scheduled restore tests, backup software upgrades, alert maintenance and periodic review of objectives.
- Kept internal: Restore objectives, risk acceptance, breach assessment and notification decisions.
- Quote drivers: Number of systems, data volume, backup targets, and whether restores are tested across environments.
- Quote requests: Ask each vendor for a written split of deliverables, the test evidence format and who keeps the records.
No published price applies here, so compare quotes on the same written scope and ask for the cost of each recurring element separately.
Where organizations fall short on restore capability
Most restore failures under Article 32(1)(c) are not caused by missing backup software. They come from backups that were never proven to restore, objectives that no one tied to the data's risk, and gaps in how backups interact with processors, access controls, erasure and breach assessment. The cards below describe each gap and the check that closes it.
Backups that were never restored
A nightly job reporting success proves that data was written somewhere, not that it can be read back in a usable state. Article 32(1)(c) asks about the ability to restore availability and access in a timely manner, so a backup without a recorded restore test is unproven evidence. Check whether the team has restored a full system, a single record set and a database from the current backup and from a point before a given date. Schedule a restore test and keep its results as evidence. Bareos can restore files from the current backup or from an earlier point in time, which is useful for testing both cases.
Recovery objectives not tied to risk
Recovery time and recovery point targets are often copied from infrastructure defaults rather than set from the harm that data loss or downtime would cause to individuals. Under Article 32, the measures should follow an assessment of the risks to the rights and freedoms of data subjects, so the restore design should reflect which personal data is most sensitive and how quickly its absence would hurt people. Ask who approved each target and whether it appears in the risk assessment. Set objectives per system from the documented risk, then record who approved them.
Processor-held data without confirmed copies
When a processor hosts personal data, the controller may not know whether a backup exists, where it is stored or whether it can be restored. EDPB Guidelines 9/2022 note that whether the controller still holds a copy or backup of data lost at a processor may affect whether a notification is needed. Review processing agreements and service descriptions for backup frequency, retention, location and restore support, and ask for evidence of a recent restore. Confirm in writing whether the controller holds an independent copy of processor-held data.
Access controls and logs not restored
Restoring the data alone may not restore the ability to use it. If identity configurations, role assignments, encryption keys or audit logs are lost or rebuilt from memory, users may be locked out or the record of who accessed personal data may be incomplete. Both outcomes affect the ability to restore access in a timely manner and to investigate an incident. Include identity provider configuration, key material handling and log stores in restore tests and confirm each one comes back in a usable state. Put access configuration, keys and logs in the restore test scope.
Backups that cannot honor erasure
Restoring an old backup can bring back personal data that was erased from production after a request, which creates a fresh compliance failure. The EDPB's 2025 coordinated action on the right to erasure found controllers struggling to delete personal data held in backups, so backup design affects both restoration and erasure. Decide how erased records are suppressed after a restore, how long backups keep data, and how the team documents this. Confirm that a restore procedure reapplies deletions before users see the data. Document how restores reapply erasure decisions before data returns to production.
No link from data loss to breach assessment
Accidental loss or destruction of personal data is an availability breach, and it can be notifiable even without any disclosure. Teams that restore data quietly often never record the incident, the period of unavailability or whether a backup existed, which makes the later decision to notify hard to justify. EDPB Guidelines 01/2021 include ransomware examples with and without proper backups, showing how backup availability changes the outcome. Connect the restore runbook to the breach register and decision steps. Make every restore that follows a loss of personal data open a breach assessment record.
Questions buyers ask about restore obligations under GDPR
How much effort does restore testing take, and what drives it?
The effort depends on how many systems hold personal data, how many restore paths each one has, and how much of the restore is manual. No supplied fact gives a duration or fee for restore testing, so ask your team or any partner to estimate it from your own environment. The main drivers are the number of data stores (databases, file shares, SaaS exports, logs), whether restores can be scripted and repeated, how long a full restore takes at your data volume, and whether backups are encrypted with keys that must also be recovered. One-time costs include designing the test plan and building the restore runbooks. Recurring costs include running tests on a schedule, recording results and fixing gaps. Ask any quote to separate these two lines and to state which systems are in scope.
Does having a backup alone satisfy Article 32(1)(c)?
No. Article 32(1)(c) asks for the ability to restore availability of and access to personal data in a timely manner after a physical or technical incident, so a backup that has never been restored, or that cannot be restored within the time your business needs, does not show that ability. A backup is one input. You also need documented restore objectives, a tested procedure, access to decryption keys and credentials, and records of what was restored and when. The EDPB Guidelines 9/2022 treat loss of access to personal data as an availability breach, so a backup that fails in a real incident can become a notifiable event in its own right.
Does a processor's backup count for the controller?
It can, but the controller still carries the obligation. Under the GDPR, the controller must make sure that its processors provide appropriate security, and the EDPB Guidelines 9/2022 note that whether the controller still holds a copy or backup of data lost at a processor may affect whether it must notify the breach. Before relying on a processor's backup, ask for written evidence of backup frequency, restore objectives and the date of the last restore test, and confirm the contract states who performs restores and how quickly. If the processor's backup is the only copy, your own risk assessment should reflect that single point of failure.
How often should restore tests run?
The GDPR does not set a frequency, so the answer should come from your risk assessment and the restore objectives you have set for each system. Systems that hold sensitive or high-volume personal data, or that support time-critical services, usually justify more frequent tests than low-change archives. Run a full restore at least after major changes to the backup tool, storage or encryption keys, and record each test with its date, scope, result and any corrective action. Confirm the chosen frequency with your supervisory authority guidance, your own auditor, or your contract requirements, since some customers and sector rules set their own expectations.
Can self-hosted open-source tools be used for backup and restore?
Yes, several open-source tools can cover parts of this work, but you must verify each capability against your own requirements. Bareos is described as a backup system whose Director schedules backup, restore, verify and archive jobs and keeps a SQL catalog of backed-up files, which lets operators restore files from the current backup or from one taken before a given date and time. restic provides a check command that verifies the structural consistency of snapshots, trees and pack files, and with --read-data or --read-data-subset it reads pack data back to confirm it is unmodified. Grafana Alerting and Prometheus can monitor backup job health and alert on failures. Confirm the license terms (Bareos is AGPL-3.0-only, restic is BSD-2-Clause) with your legal team before deployment.
Do we need an outside partner to meet this requirement?
You do not have to hire one, but many organizations use an implementation partner for the parts that need specialist time. The controller owns the obligation and the decisions about restore objectives and risk acceptance. An implementation partner can prepare backup configuration, restore runbooks, test scripts and evidence records within a written scope. DeployOpen plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with deliverables agreed in writing before work starts. DeployOpen does not issue audit reports or certifications. If you need independent assurance, an independent auditor or certification body provides that, and the GDPR itself requires no certificate. Ask any partner to show which deliverables they will produce and what your own staff must still do.
What should we ask for in a restore quote?
Ask for the written scope first, because a restore quote is only comparable when the systems, data volumes and recovery targets are defined. Request a list of deliverables such as a restore objective per system, backup configuration, runbooks, a test plan, the first full restore test with results, and an evidence pack. Ask which tasks are one-time and which recur, such as scheduled restore tests and ongoing support. Ask how the partner will handle encryption keys, credentials and access during a restore, and what happens if a test fails. No public price list applies, so the quote should follow from the agreed scope.
How DeployOpen prepares restore evidence
DeployOpen scopes restore capability as a fixed-scope engagement inside the client's own cloud accounts, data centers or air-gapped networks. Before any build work starts, the written scope names the systems holding personal data, the backup and catalog components in use (for example Bareos for scheduled backup and restore jobs, or restic for snapshot-based repositories), the restore objectives the controller has set, and the restore tests that will be run and recorded. The controller owns those objectives and every decision about what counts as acceptable recovery for its processing. DeployOpen prepares the systems, configuration, monitoring and documentation that let the controller show how it meets them. DeployOpen does not issue audit reports, attestations or certifications. An independent auditor or certification body makes that judgment.
During implementation, the deliverables are written so an assessor can follow them without a walkthrough. Typical items include the backup configuration and job definitions, the restore runbook with named roles and escalation steps, the records of each tested restore including the data set, the time taken and the outcome, and the integrity checks such as restic check with --read-data-subset or Bareos verify jobs. Monitoring of backup job failures and capacity can be built with Prometheus collection and Grafana Alerting, so that a failed job generates a record rather than surfacing months later during an incident. The exact capabilities of any platform version should be confirmed against its current documentation before the scope is signed.
Ask DeployOpen for a written deliverables list that maps each restore test record to the controller's own objectives, and ask your assessor which evidence format they expect before the work begins. Confirm with your legal and privacy team how backup retention interacts with erasure obligations, since backup design affects both restoration and erasure. Retainers can cover recurring restore tests, backup upgrades and evidence refreshes after the initial build, and their scope should be agreed in writing with the same care as the first engagement.
