What GDPR backup and restore requirements mean for your organization
When a customer, contract or regulator asks for evidence of backup and restore, the question sits under GDPR Article 32(1)(c), which requires the ability to restore the availability of and access to personal data in a timely manner after a physical or technical incident. No certificate or fixed backup standard exists under the GDPR, and the regulation requires no audit or attestation. The organization owns this control: it decides what is backed up, how often, where copies are kept, who can restore them and how quickly restoration must happen for the data and processing involved. An implementation partner such as DeployOpen can plan, configure, document and test backup and restore on self-hosted platforms inside your own infrastructure and assemble the evidence, but only an independent auditor, assessor or certification body issues any report, and Article 42 certification, if you pursue it, is voluntary and does not transfer responsibility.
The stakes are set by Article 83, which allows maximum administrative fines of EUR 10 million or 2% of total worldwide annual turnover for infringements such as Articles 25 to 39, whichever is higher. Security of processing falls within that tier, so a weak restore capability can be a fining issue even when no data was disclosed. The pillar facts do not supply backup cost or timeline figures, so any budget or restoration target should come from your own risk assessment and from written quotes. Before you commit, confirm with your data protection officer or legal team which systems hold personal data, what recovery time your processing actually needs, and whether your backup copies sit inside the same jurisdiction and access boundary as the primary data.
Start with three decisions. First, document who owns the restore process and who can authorize it during an incident. Second, define what a timely restoration means for each processing activity, based on the impact on individuals rather than only on business continuity. Third, decide whether the scope of any engagement covers design only, implementation and testing, or ongoing operation, because that choice drives the fixed-scope quote you should request in writing. Ask any partner to state which parts of the evidence they prepare and which parts your auditor must test independently.
How backups change the breach outcome in EDPB ransomware cases
In the EDPB's ransomware examples, the controller's position depends heavily on whether it can restore the affected personal data from a copy that was not encrypted or damaged by the attacker. Where a recent, intact backup exists and the controller can restore from it, the question shifts from whether data was lost to whether any confidentiality breach occurred and how long availability was affected. The guidelines show that the controller still has to investigate, document the incident and decide on notification based on the risk to individuals, rather than assume the backup settles the matter.
- Backup integrity: The controller should confirm the backup was not reachable by the malware and was complete at the time of the incident.
- Restoration evidence: Records should show when data was restored, to what point in time, and whether any changes made after the backup were lost.
- Exfiltration check: Restoring data does not answer whether the attacker copied it, so logs and forensic findings still matter.
- Documentation: The internal breach register should record the availability loss, its duration and the reasoning behind the notification decision.
- Risk assessment: The controller should weigh the effect on individuals of any temporary loss of access.
Before relying on a backup in a breach file, confirm with your own incident team that the copy was isolated, tested and dated before the attack began.
The EDPB's examples also cover ransomware where no usable copy of the data exists, either because backups were absent, encrypted with production data or too old to be useful. In this situation the loss of availability is more likely to be significant, and the controller has fewer ways to show that the data can be recovered. The guidelines treat this as a case where the breach is generally more serious, so the notification assessment should start from the presumption that the impact on individuals is substantial until the controller shows otherwise.
- Loss of availability: Personal data that cannot be restored in a timely manner is an availability breach, which can be notifiable without any disclosure.
- Notification clock: The 72-hour period under Article 33 runs from when the controller became aware of the breach, so delay in assessing backups does not pause it.
- Processor copies: If a processor holds the only copy, the controller should ask whether it has access to that copy and whether it must notify.
- Communication to individuals: Where the risk is high, Article 34 communication may be needed, and its content should explain practical steps.
- Recovery plan: The controller should document how it intends to restore data and what interim measures protect individuals.
Ask your incident team what the recovery point objective was on the date of the attack and whether any copy existed outside the attacker's reach.
The EDPB presents its ransomware cases as illustrations rather than fixed outcomes, and each one depends on the facts supplied. Readers should use them to understand the reasoning: the controller considers availability, confidentiality and the chance that an attacker accessed data, then decides whether the breach is likely to result in a risk to individuals. A backup changes the analysis at specific points, but it does not remove the duty to assess. Treat the examples as a method to apply to your own environment, not as a precedent that can be copied without checking the facts.
- Facts first: The outcome in each example follows from specific facts about the backup, the attack and the data involved.
- Separate questions: Availability, confidentiality and integrity are assessed separately, even when they arise from the same incident.
- Scope of the copy: A backup that holds only part of the affected data changes the assessment for the rest.
- Reassessment: The EDPB expects controllers to update their view as the investigation develops.
- Accountability: Whatever the decision, the reasoning should be recorded under Article 33(5).
Compare your own breach procedure against the examples and confirm that it asks the same questions about backups before an incident happens.
What a minimum backup policy should contain
The EDPB's guide for small businesses lists a data backup and retrieval policy among its minimum security measures. The cards below are the elements that policy should address, each to be written down, assigned an owner and tested, not copied from a fixed template. Values such as frequency and retention should come from your own risk assessment and recovery requirements.
Scope of personal data backed up
Write down which systems, datasets and processors' copies fall inside the backup scope, and which personal data each one holds. Include SaaS-hosted data, logs and file shares, since these are often missed. Check that the inventory matches your record of processing, because a backup you cannot map to a purpose and a category of data is hard to restore selectively or to erase later. Confirm with each processor whether it keeps its own copies and whether those copies are covered by your policy.
Backup frequency and recovery targets
Set how often each system is backed up and how much data loss and downtime the business can accept for it. These two values follow from the impact on individuals and the business, not from a default schedule. Record who approved them and when they were last reviewed. Check whether the schedule actually runs, using backup job reports rather than the configuration alone, since silent failures are a common gap.
Protection and access to backup copies
Backup copies usually hold the same personal data as production, so they need the same access control and encryption as the source. Write down who can read, restore or delete backups, whether backup administrators have separate accounts, and whether copies are isolated from the production identity system. Immutable or offline copies are the element that most often determines whether a ransomware incident stays an availability event. Confirm these settings in the platform, not only in the policy.
Restore testing
Write down how often restores are tested, which systems are included, and what counts as a successful restore, such as data integrity checks and application start-up. Article 32(1)(c) asks for the ability to restore availability and access in a timely manner, and a backup that has never been restored is unproven evidence of that ability. Keep the test records, the time taken and any gaps found, since these are the evidence an assessor or regulator will ask for.
Retention and erasure in backups
Set how long each backup set is kept and what happens when a data subject's erasure request is received. The EDPB's 2025 coordinated action on the right to erasure found controllers struggling to delete personal data held in backups. Write down whether erasure is applied at restore time, through backup expiry, or through another documented method, and confirm that the chosen approach is explained in your privacy notices and records.
Who decides to restore
Name the role that can authorize a restore, the role that carries it out, and the role that confirms the data is complete and current. A restore can reintroduce data that was deleted or rectified, and it can overwrite newer records, so the decision needs a record. Write down the escalation path to the DPO or breach response lead, and whether a restore is itself logged as a processing activity. Confirm these roles with the people who would actually perform the restore.
How to test that restoration is timely
This sequence gives you evidence that personal data can be restored within a timeframe you set and can justify, covering the scope, the test itself, the access checks on restored data and the record an assessor or regulator would ask to see.
Define recovery expectations for personal data systems
Start by listing every system that holds personal data, including databases, file stores, SaaS exports and backup repositories. For each one, the data protection lead and system owner agree on a recovery time objective and a recovery point objective, written as internal targets tied to the risk to individuals. Confirm these targets with your assessor before relying on them, because the GDPR does not set a number. The step is done when each system has a documented owner and an approved target, signed off by the people accountable for the processing.
Select the restore scenarios to test
Choose realistic failure cases that match your risk assessment: accidental deletion of a table, corruption of a file share, loss of a hypervisor, and a ransomware-style encryption event that forces restoration from an offline copy. Record which backup set and which system each scenario uses. Illustrative example: a customer database restored from the previous night's full backup plus transaction logs. The step is done when the scenario list is approved and each scenario names its source backup.
Run the restore into an isolated test environment
The operations team restores the selected backup into a segregated test environment that cannot reach production or send data to live users. Use the same procedure your runbook describes, not an improvised one, so the result reflects real recovery capability. Keep the restore log, the commands or tool actions used and any manual steps. The step is done when the restore completes or fails with a captured error and the environment is torn down or locked down as planned.
Record elapsed time and completeness
Measure how long the restore took from the start of the recovery decision to a verified usable system, and compare it with the target set in step one. Then check completeness by comparing record counts, file counts, checksums or hash totals against the expected figures from the source system at the backup point. Note any gaps, such as missing attachments or logs. The step is done when the timing, the completeness results and any variance from the target are written into the test record.
Verify access controls on restored data
Restored data often comes back with different permissions, service accounts or encryption keys, so confirm that only authorized roles can read it. Check that user and service accounts match the pre-incident access model, that privileged access still requires the approvals you normally apply, and that encryption keys for the restored copy are the ones you intended. Test a sample of accounts that should be denied access. The step is done when the access results match the documented model and every exception has an owner and a fix.
Confirm restored data reflects erasure and retention decisions
Before the restored environment is treated as current, check that records erased or restricted since the backup was taken are not silently brought back into live use. The EDPB's 2025 coordinated action on the right to erasure found controllers struggling to delete personal data held in backups, so this check tests whether your restore process re-applies those decisions. Document how the restore handles the erasure log. The step is done when a sample of erased records is confirmed absent or suppressed in the restored set.
Retain the test record and act on findings
Assemble one test record per scenario with the scope, dates, people involved, backup identifiers, timings, completeness results, access checks, erasure checks and any corrective actions with owners and due dates. Store it under your records and retention rules, because the record is your evidence for Article 32(1)(c) and for any regulator or assessor request. Repeat the test on a schedule you set and after significant system changes. The step is done when the record is approved, filed and linked to the open actions in your risk register.
Why erasure in backups is the hardest part
Erasure in backups is the hardest part of the GDPR backup problem because a backup built for restoration is, by design, a copy that brings deleted records back. The EDPB's 2025 coordinated enforcement action on the right to erasure, involving 32 supervisory authorities and 764 controllers and announced on 18 February 2026, found controllers having difficulty deleting personal data held in backups. The same action identified seven recurring challenges, and two of them matter most here: controllers using ineffective anonymisation in place of deletion, and failing to delete personal data in backups at all. Both are design failures, not single-ticket errors, so they are best prevented before a request arrives.
The design tension is simple to state. If a restore brings back a record that was erased from production, the controller has reintroduced personal data it had no basis to keep. Teams should decide, in writing, how long each backup set is retained, how rotation removes older sets, and whether erased individuals can be identified in any set still in existence. A documented restore-then-re-erase procedure should then run after every restore: check the restored data against the erasure log, delete again any records that were erased after the backup was taken, and record that the step was completed. Ask whether your backup platform can filter or mark individual records by identifier, because many tools restore whole databases only.
Confirm three things with your own backup vendor and data protection officer before relying on any approach. First, whether the backup tool can delete single records or only expire whole sets. Second, the retention period your records of processing and retention schedule set for backup copies, which must match the rotation actually configured. Third, whether the restore log records which erasure requests were re-applied. Treat anonymising backup data as a last resort, since the enforcement findings show that weak anonymisation is not an accepted substitute for deletion. The same backup design also determines whether a lost copy counts as an availability breach, so these decisions should be reviewed together.
What makes backup compliance harder or easier
Backup compliance is rarely hard because of the backup software itself. The effort follows from a handful of design decisions: how many systems hold personal data, who holds copies, where they sit, how they are encrypted and how long they live. Each driver below changes the restoration, breach and erasure work in a different way.
Number of systems holding personal data
Every system that stores personal data needs a backup entry in the inventory, a defined recovery point and a tested restore path. The more platforms involved, such as a core database, file shares, mailboxes and SaaS exports, the more restore procedures must be proven and the more places an erasure request must reach. Ask for a current data map that lists each store, its backup job and its owner before scoping the work. Where a system is undocumented, assume it is not yet covered by the restore test.
Backup copies held by third parties
When a cloud provider, managed service or processor holds backup copies, the controller still needs to know how those copies are restored and whether it can still reach them after an incident at the processor. EDPB Guidelines 9/2022 note that whether the controller still holds a copy of data lost at a processor can affect the notification decision. Check the processor contract for backup location, restore commitments, deletion timing and the sub-processors that touch the copies.
Geographic location of backups
A backup in another country is still processing of personal data, and copies moved outside the EEA can trigger transfer rules under Chapter V. A restore performed from a region that is not covered by an adequacy decision may require a documented transfer mechanism. Confirm the storage regions, the regions where administrators can reach the copies and whether any replication crosses a border before the first restore test is planned.
Encryption and key custody
Encrypted backups are easier to protect in transit and at rest, but they are only as recoverable as their keys. If the key store sits in the same environment that a ransomware actor can reach, restoration may fail exactly when it is needed. Record who holds each backup key, keep a tested offline or separately controlled copy and include key recovery in the restore test. Ask the platform owner to confirm how keys are rotated and escrowed without assuming a specific product feature.
Backup retention length
Retention determines how long personal data survives in backups after it has been deleted from production. A long retention period means more copies to search, more erasure requests that cannot be executed immediately and a larger exposure if backups are stolen. Set a retention rule per data category, justify it in the retention schedule and document how deleted records are handled when a backup is restored. Short retention reduces erasure work but must still allow restoration for the recovery objectives the organization has set.
Restore testing and documentation
A backup policy that has never been restored is difficult to defend under Article 32(1)(c), which asks for timely restoration. Regular restore tests that record the date, scope, duration and any gaps create evidence an assessor can inspect. Ask whether the test covers a full restore of a representative data set and whether the results feed back into the backup policy. Without this record, the organization cannot show that its measures are effective.
Who owns the backup controls and who prepares the evidence
The controller owns the backup policy, the recovery objectives it accepts for personal data, and the decision to restore. Under Article 32(1)(c), the ability to restore availability of and access to personal data in a timely manner is an obligation of the controller and, where it processes data for others, of the processor. Outsourcing the work does not move that accountability. The organization also decides how backup findings feed into breach assessments and erasure requests, since those decisions depend on business context and legal judgment.
- Backup policy: Approve the written policy covering what is backed up, how often, where copies are held and who may authorize a restore.
- Recovery expectations: Set the timeframes for restoring personal data after an incident and record them as management decisions.
- Restore authority: Name the people who can start a restore and who signs off that restored data is accurate and complete.
- Breach and erasure decisions: Determine whether lost or encrypted data affects notification duties and how backup copies are handled when an erasure request arrives.
- Records: Keep the approved policy, decision logs and restore outcomes so they can be shown to a supervisory authority.
Check that the policy names an accountable owner by role, that it has been approved by management, and that it is reviewed on a set schedule.
An implementation partner such as DeployOpen can plan, configure and document the backup infrastructure for self-hosted platforms inside the client's own environment, then prepare the evidence that the controls work. The partner builds the systems and runs restore tests under a written, fixed scope. It does not set the organization's policy, accept its risk, or issue any report or certificate. Its output is the material the organization and its assessor use to judge the controls.
- Design and configuration: Set up backup jobs, retention, copy locations and access controls for the platforms in scope.
- Restore testing: Run and record restore exercises that show data can be recovered within the agreed timeframes.
- Documentation: Produce runbooks, configuration records and restore procedures that a reviewer can follow.
- Evidence preparation: Collect job logs, test results and change records in a form the organization can hand to its auditor.
- Handover: Train the client's staff so the restore capability does not depend on the partner after the engagement ends.
Confirm in the written scope which systems, data sets and restore timeframes are covered, and who holds the backup encryption keys.
An independent auditor or a national supervisory authority tests whether the backup controls work as described. Supervisory authorities enforce the GDPR and can investigate how a controller restores data after an incident. For GDPR itself, no audit, attestation or certificate is required, so no body issues a GDPR compliance certificate for backups. Where a controller pursues voluntary certification under Article 42, an accredited certification body or supervisory authority assesses it, and the certificate lasts at most three years. Certification does not reduce the controller's or processor's responsibility for compliance.
- Testing: Review the policy, sample restore records and check that the stated recovery objectives match what the systems can do.
- Investigation: A supervisory authority may ask how data was restored after an incident and request the records behind that answer.
- Voluntary certification: Where Article 42 certification is pursued, an accredited body assesses the scope set by the organization.
- No substitute: A certificate or clean report does not discharge the organization's duty if its backups fail in practice.
- Independence: Assessors must be independent of the team that built the controls to give a credible view.
Ask any assessor which standard or scheme they test against and whether they will review restore evidence, not only policy documents.
Questions buyers ask about GDPR backup and restore
Does the GDPR set a backup frequency?
No. The GDPR does not prescribe how often you back up. 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 it sets an outcome rather than a schedule. The right frequency comes from your risk assessment: how much data loss the processing can tolerate, how quickly the business needs systems back, and what the data subjects would suffer if records were lost. Document the reasoning, because the regulator will ask why your schedule fits your risks. Confirm with your supervisory authority's guidance and your own recovery objectives before setting a number.
Is a backup legally required under GDPR?
The GDPR does not name backups as a standalone duty, but it does require the ability to restore personal data in a timely manner, and the EDPB's guide for small businesses lists having a data backup and retrieval policy as a minimum measure for any organization. In practice, a controller that cannot restore data after a ransomware attack or hardware failure will struggle to show appropriate security. Ask the supervisory authority's guidance what it expects for your sector, then test the answer against your risk assessment. Whether you use backups, replication, or another mechanism is your decision, provided it meets the restoration outcome.
What does a backup project need from our internal staff?
Expect the work to need named owners in several teams. Your data protection lead and business owners must define which personal data sits in each system, how long it is kept, and what recovery time the business can accept. Infrastructure staff must own the backup platform, retention settings and restore tests. Security staff must review access to backup copies, since backups often hold the same personal data as production and are a common target in ransomware cases. Legal or procurement must check contracts with any processor that stores copies. These roles are internal responsibilities that a partner cannot take over.
Can an outside partner certify that our backups are GDPR compliant?
No. The GDPR requires no audit, attestation or certificate, and only an independent body can issue one under Article 42 certification. An implementation partner can prepare systems, backup configurations, restore runbooks and evidence such as restore test records, but it cannot issue a compliance report or certificate. The controller stays responsible for its compliance, and certification, where it exists, does not remove that responsibility. Ask any provider to state its role in writing, and treat anyone who promises a certificate for backups with caution.
How do we handle erasure requests for data held in backups?
Deleting a record from production does not automatically remove it from backups, and the EDPB's 2025 coordinated action on the right to erasure found controllers struggling with exactly this. Common approaches include documenting that backup copies are overwritten on a defined retention cycle, restricting access to backup data until expiry, and recording the erased individual so that the record is not restored into production. Anonymising data in backups instead of deleting it was one of the recurring failures the EDPB identified, so avoid relying on it without a proper analysis. Design retention and restore procedures together, and confirm the approach with your legal team and supervisory authority.
What fines can apply if our backup and restore controls fall short?
Under Article 83, infringements of obligations such as Articles 25 to 39, which include the security of processing in Article 32, can attract administrative fines of up to EUR 10 million or 2% of total worldwide annual turnover, whichever is higher. Infringements of the principles, lawful basis, data subject rights and transfer rules can reach EUR 20 million or 4% of total worldwide annual turnover, whichever is higher. Fines are set case by case by the independent supervisory authority, so the actual amount depends on the circumstances. Regulators also weigh the measures you had in place, including tested backups, before an incident occurs.
How do working backups change the outcome of a ransomware breach?
Working backups can decide whether an incident must be notified. EDPB Guidelines 01/2021 include ransomware examples with and without proper backups, and the EDPB treats loss of access to personal data as an availability breach that can be notifiable even without disclosure. If you can restore the data promptly from a reliable copy with no lasting effect on individuals, the assessment may differ from a case where the data is unrecoverable. Keep restore tests and logs, because you will need them to justify the decision within the 72-hour window under Article 33. Confirm the analysis for your own case with your supervisory authority and counsel.
What to confirm before you scope the work
Before you scope a backup and restore project, confirm the facts that decide whether your backups can meet Article 32(1)(c). Start with encryption and key handling in the backup product. Find out whether backup sets, catalogs and replication copies are encrypted, which key management service or key store holds the keys, who can release them, and whether a restore is possible if the people who administer the backup platform are unavailable or compromised. A backup that cannot be decrypted during an incident restores nothing, and a backup whose keys sit next to the production estate may be lost in the same attack.
Next, establish where every copy lives and who can reach it. List the primary backup repository, any offsite or immutable tier, cloud replicas, disaster recovery sites and vendor-hosted management consoles, and note the country of each. Copies in a second region or a different account change both your resilience and your transfer analysis, so check them against your data residency decisions. Also confirm whether backup storage is included in your record of processing and retention schedule, since copies that exist outside those records are hard to answer for in an access or erasure request.
Then test the restore time you can actually achieve, not the one in the vendor brochure. Ask for a timed restore of a representative dataset to a clean environment, and record which steps depended on a single person or a manual approval. Compare the result with the recovery targets your business continuity plan sets for each system. Finally, review your processor contracts and any managed backup or hosting agreements. Confirm whether they require the processor to notify you without undue delay of an availability incident, whether they say what the processor will do if a backup copy is lost or corrupted, and whether they cover your duty to help with erasure from backups. If those terms are silent or weak, fix them before the project is scoped, not during an incident.
How DeployOpen scopes backup and restore work
DeployOpen works on GDPR backup and restore requirements as a self-hosted implementation inside your own infrastructure, starting from the restoration and erasure questions your records of processing and risk assessment raise. We plan, build and document the backup design, then hand over evidence your team and independent assessors can review.
How we scope
- Written scope lists which systems holding personal data are in backup, with their recovery objectives agreed with your data owners.
- We map backup copies, replicas, snapshots and processor-held copies so restoration and erasure responsibilities are assigned in writing.
- Engagements are fixed-scope, so deliverables and timelines are agreed before any backup configuration work begins.
How we build
- We configure encrypted, access-restricted backup repositories in your cloud accounts, data centers or air-gapped networks.
- We set retention and deletion settings for backup sets so that erasure requests can be carried through to backup copies.
- We run scheduled restore tests on representative data and record the results, including time taken and any gaps found.
How we hand over
- You receive a backup and restore policy, runbooks and configuration documentation that your staff can operate without us.
- Restore test records and backup logs are delivered as evidence that you can present to an assessor or supervisory authority.
- We document the residual risks, such as copies that cannot be erased immediately, so your DPIA and breach response plan reflect them.
How we support
- Ongoing support, upgrades and periodic restore testing are available as a retainer, sized to the written scope.
- We review backup design when systems change, new processors are added or a breach or incident exposes a gap.
- Your organization keeps ownership of its controls; DeployOpen prepares systems and evidence, and only an independent auditor issues reports or certificates.
