GDPR does not use the word "backup" as an obligation, but Article 32 requires controllers and processors to keep personal data secure, available and restorable "promptly" after an incident. In practice, that means protected, access-controlled, regularly tested backups. Backup copies are still personal data, so storage limitation, erasure, processor contracts and transfer rules apply to them as well. Infringements can reach €10 million or 2% of worldwide turnover (Articles 32 and 33) and €20 million or 4% (Articles 5 and 17), whichever is higher.
Key Takeaways
No named backup mandate, but a functional one. Article 32(1) lists the ability to restore availability of and access to personal data after a physical or technical incident as a required capability, alongside confidentiality, integrity and resilience.
GDPR sets no RPO, RTO or backup frequency. Controllers must choose measures "appropriate to the risk" and be able to demonstrate them; regulators judge the result, not a number.
Backups are in scope for everything else. Encryption and access control (Article 32, security of processing), storage limitation (Article 5(1)(e)), processor contracts (Article 28) and international-transfer rules (Chapter V, transfers to third countries) all apply to backup copies.
Erasure requests reach backups, but not necessarily immediately. The UK ICO accepts putting backup data "beyond use" until it is overwritten on a documented schedule; EU authorities have not all taken the same line.
Backup quality changes breach-notification outcomes. In the EDPB's ransomware examples, a properly restored encryption-only attack can stay in the internal breach register, while the same attack without a usable backup does not.
Real enforcement exists. The Irish DPC fined Centric Health a total of €460,000 after a ransomware attack in which about 2,500 patients' data was deleted with no backup available.
Does GDPR Require Businesses to Back Up Personal Data?
Not by name, but Article 32 makes recoverability a required security capability, so a business that cannot restore personal data after an incident will struggle to show compliance.
Article 32(1) of Regulation (EU) 2016/679 requires controllers and processors to apply technical and organisational measures that are appropriate to the risk. It then lists examples "as appropriate":
1. pseudonymisation and encryption of personal data;
2. the ability to ensure ongoing confidentiality, integrity, availability and resilience of processing systems and services;
3. the ability to restore availability of and access to personal data on time after a physical or technical incident;
4. a process for regularly testing, assessing and evaluating the effectiveness of those measures.
Point 3 is the legal hook for backup and disaster recovery. Point 4 is the hook for restore testing. Article 32(2) adds that the risk assessment must consider accidental or unlawful destruction, loss, alteration, unauthorised disclosure of or access to the data, which covers both ransomware and hardware failure.
What the text leaves open. GDPR does not prescribe backup frequency, retention length, media type, RPO or RTO. It uses a risk-based standard that also weighs the state of the art, implementation cost and the nature, scope and purposes of processing. This depends on the organisation's data, risk and sector; two businesses with identical technology can have different obligations.
Evidence matters. Article 5(2) makes the controller responsible for demonstrating compliance. For backups, that means keeping a written backup policy, restore-test records and retention decisions, not only running jobs.
GDPR Requirements that Apply to Backup Data: Summary Table
Nine GDPR provisions reach backup environments. Each applies to the backup copy exactly as it applies to the production copy.
GDPR provision | What it requires | What it means for backups |
Art. 5(1)(f) integrity and confidentiality | Protect data against unauthorised processing, loss, destruction or damage | Encrypt, restrict and protect backup repositories from deletion or tampering |
Art. 5(1)(e) storage limitation | Keep identifiable data no longer than necessary for the purpose | Define and document a retention period for every backup set |
Art. 5(2) accountability | Be able to demonstrate compliance | Keep policies, restore-test results and retention rationale |
Art. 17 erasure | Erase data without undue delay when a ground applies, and no exemption does | Decide how erasure is handled in backups; document it and tell the individual |
Art. 25 data protection by design | Build safeguards into processing design | Plan retention, access and encryption when designing the backup architecture |
Art. 28 processor | Written contract; processor must take Art. 32 measures and delete or return data at the end of services | Contract with any backup or cloud backup provider; settle what happens to copies on exit |
Art. 32 security | Risk-appropriate measures including restorability and regular testing | Encryption, access control, separation, immutability options, tested restores |
Art. 33 and 34 breach notification | Notify the authority within 72 hours where feasible unless unlikely to cause risk; document all breaches | Backups decide whether an incident is an availability breach that cannot be reversed |
Chapter V (Art. 44 onward) transfers | Restrict transfers to third countries without a lawful mechanism | Check where offsite and cloud backup copies physically sit and who can access them |
Fine tiers
Under Article 83, infringements of Articles 25 to 39 (including Articles 28, 32 and 33) can draw fines up to €10 million or 2% of total worldwide annual turnover, whichever is higher. Infringements of the basic principles in Article 5, data subject rights such as Article 17, and transfer rules can draw up to €20 million or 4%, whichever is higher. These are ceilings; authorities weigh the factors in Article 83(2), including the technical and organisational measures in place under Articles 25 and 32.
See the official text of Articles 5, 17, 25, 28, 32, 33 and 83 on EUR-Lex.
How Should Backup Copies be Secured to Meet GDPR?
Short answer: treat the backup repository as a second production system holding the same personal data, then add protection against the specific attacks that target backups. Regulators and security agencies converge on four controls: encryption, separation from production, restricted access and tested restores.
Control | Why it matters for GDPR | Evidence base |
Encryption of backup data and careful key management | Article 32(1)(a) names encryption; a stolen backup is a confidentiality breach if readable. Keys stored beside the backups, or lost, defeat the purpose and can make restores impossible | Article 32; CISA #StopRansomware Guide recommends offline, encrypted backups |
Separation from production (offline, offsite or logically isolated) | Ransomware commonly searches for and deletes or encrypts reachable backups, turning an incident into permanent data loss | CISA explains that backups need to be offline for this reason; the EDPB's examples advise keeping medium- and long-term backup media separate from operational storage; ENISA's ransomware threat landscape recommends an up-to-date backup isolated from the network |
Restricted, separately authenticated administration | Backup consoles hold the keys to every protected system; a compromised domain admin should not be able to purge the repository | Follows from Article 5(1)(f) and Article 32(2) risk factors |
Regular restore testing | Article 32(1)(d) requires a process for regularly testing effectiveness; an untested backup is an assumption | CISA recommends testing availability and integrity in a disaster recovery scenario |
Where Backup Practice Gets Technical
Immutability is one way to achieve isolation, not a requirement. Write-once retention locks or object-lock features can prevent deletion before a set date. Availability and behaviour depend on the storage platform and its configuration, so verify them in that vendor's own documentation.
The 3-2-1 pattern is guidance, not law. ENISA's ransomware recommendations point to three copies on two media types with one offsite. GDPR does not mention it, but it is a defensible way to demonstrate risk-appropriate resilience.
Image-level backups capture everything on a disk. A virtual machine backup contains whatever personal data sits in that guest, including data nobody planned to protect. This matters later for erasure and for retention scoping.
How Quickly must Personal Data be Restorable Under GDPR?
GDPR gives no number of hours. Article 32(1)(c) requires restoration "in a timely manner", and the EDPB's examples show that timeliness is judged by what the delay does to the people whose data is affected.
The EDPB's Guidelines 01/2021 (version 2.0, adopted 14 December 2021) show this through paired ransomware cases. In Case 01, data was restored from backup within a few hours with no consequences for day-to-day operations, and the analysis concluded notification to the supervisory authority was not required. In Case 03, a hospital also had a backup, but special-category data and the risk of major delays to patient care from a long restoration pushed the outcome toward notification.
The backup existed in both cases. What changed the legal outcome was how long restoration took and who depended on the data.
Set RTO by Harm to Individuals, Not by System Tier
Most IT teams rank systems by revenue or operational impact. GDPR's yardstick is different: the risk to the rights and freedoms of natural persons (Article 32(1)). Those two rankings can disagree.
A small case-management or patient-records system may earn little revenue but hold special-category data about vulnerable people. A one-day outage can harm them more than a one-day outage of a larger marketing platform.
A revenue-critical system with no personal data adds no GDPR exposure when it is down, even though it is a business priority.
Why this matters in practice: a recovery plan built only on business tiers can leave the GDPR-critical dataset in a slow restore queue, which is the pattern the EDPB hospital example warns about. This is our analysis of the guidelines and Article 32, not a rule issued by a regulator, so confirm your thresholds with your DPO and legal counsel.
A workable method:
1. List the datasets and systems that hold personal data, including their backups.
2. For each, ask what happens to the affected individuals if the data is unavailable for 4 hours, 24 hours, and 72 hours.
3. Set RPO and RTO per dataset from that answer, and document the reasoning to satisfy Article 5(2).
4. Test the restore against the target, and record the measured time, not the planned one.
The 72-hour notification clock in Article 33 starts when the controller becomes aware of a breach, not when recovery completes, so recovery planning and breach-response planning should run in parallel.
How Do Retention and the Right to Erasure Apply to Backups?
Article 5(1)(e) means every backup set needs a justified retention period, and Article 17 erasure requests can reach backup copies. The regulator guidance we verified accepts delayed erasure in backups if the copy is unusable for any other purpose, is overwritten on a documented schedule, and the individual is told what will happen.
Article 17 and its recitals do not mention backups. The UK ICO's right to erasure guidance says the key issue is to put the backup data "beyond use" even if it cannot be overwritten immediately, and that organisations should be clear with the individual about what happens in both live and backup systems. That guidance covers the UK GDPR, which is textually close to the EU GDPR but is enforced by a UK regulator, so EU organisations should also check their own supervisory authority.
Authorities have not all said the same thing. Secondary summaries report that France's CNIL does not require whole backup sets to be deleted for an erasure request, while the Danish authority has said deletion from backups is required where technically possible. These positions may have changed since they were reported, so confirm against the current guidance of the authority that supervises you.
How Do Backups Affect GDPR Breach Notification?
A usable, quickly restorable backup can be the difference between recording an incident internally and notifying the supervisory authority, because ransomware that encrypts personal data is an availability breach.
Article 4(12) defines a personal data breach to include accidental or unlawful loss or destruction of personal data, not only disclosure. Under Article 33(1), the controller must notify the competent authority without undue delay and, where feasible, within 72 hours of becoming aware of the breach, unless it is unlikely to result in a risk to individuals. Late notifications must give reasons for the delay. Article 33(5) requires every breach to be documented, including those not notified, and Article 33(2) requires processors to inform the controller without undue delay. The EDPB's Guidelines 9/2022 explain when a controller is considered "aware".
The EDPB's Guidelines 01/2021 use four ransomware examples to show how backup status shapes the outcome:
EDPB example | Backup status | Exfiltration | Outcome in the EDPB analysis (summary) |
Case 01 | Proper backup, restored within hours | None | Record in the internal breach register; notification not required |
Case 02 | No proper backup | Not the focus | Availability breach with lasting effect; notification obligations are likely triggered |
Case 03 (hospital) | Backup available | None | Notification required, because of special-category data and the risk of delayed patient care |
Case 04 | No backup | Yes | Availability and confidentiality breach; the most serious notification outcome of the four |
Treat this table as a summary and read the relevant case in the guidelines before deciding a real incident. The cases are fictitious illustrations drawn from supervisory-authority experience; each real decision depends on the facts, including whether the attacker exfiltrated data and what data it is.
Practical implication: the evidence supporting a "no notification" conclusion is forensic proof that no data left the network, plus restore records showing a quick recovery. Keep both.
What Does Enforcement Look Like? The Centric Health Decision
In February 2023, the Irish Data Protection Commission fined Centric Health €460,000 in total after a ransomware attack in which backups failed to protect patient data.
The DPC's inquiry into Centric Health Ltd began after a ransomware attack on its patient administration system, notified to the DPC on 5 December 2019. About 70,000 data subjects were affected by unauthorised access, alteration and loss of availability of personal and special-category data. About 2,500 patients were permanently affected because their data was deleted with no backup available.
Infringement | Fine |
Article 5(1)(f), integrity and confidentiality | €275,000 |
Article 5(2), accountability | €50,000 |
Article 32(1), security of processing | €135,000 |
Total | €460,000 |
A legal analysis of the decision reports that the daily backup was kept on the same physical server rather than offsite, that the backups were infected at the time of the incident, and that there was no business continuity plan or records showing restores had been tested. The Irish Times also reported that backups of the system were affected by the ransomware.
What to learn from it: the failures map onto controls in this guide, namely separation of backup from production, tested restores and documented continuity planning. An accountability fine under Article 5(2) was imposed alongside the security fines, which shows that missing evidence is penalised in its own right.
What Applies When a Vendor, the Cloud or a Virtual Platform Holds the Backups?
A backup provider that stores or processes your backups is normally a processor, so Article 28 requires a written contract. Where copies leave the EU or EEA, the transfer rules in Chapter V apply. Virtual machine backups add a granularity issue that affects erasure and retention.
Processor and transfer checks
Article 28 requires the processor to take the measures required by Article 32, to assist the controller, and at the end of the services to delete or return the personal data and delete existing copies unless law requires storage. Use this as a contract checklist:
Which sub-processors can access or store the backups (Article 28(2) requires authorisation).
Where the copies physically reside and from where they can be administered. Article 44 restricts transfers to third countries unless a Chapter V mechanism applies, so confirm the legal basis for each destination.
Who holds the encryption keys, and whether the provider can read the data.
How and when copies are deleted at contract end or on instruction.
How quickly the provider must report a breach so you can meet the 72-hour window (Article 33(2)).
Virtual Machine Backup Considerations
Platform differences matter only where they change what can be erased, restored or isolated. This depends on the platform, version, and backup configuration.
Approach | GDPR-relevant effect |
Image-level VM backup (hypervisor level) | Captures the whole guest, including personal data nobody scoped. Erasing one person's records from a backup set is generally impractical, so retention length does the work (see above) |
Agent or file-level backup inside the guest | Finer scoping of what is protected, at the cost of per-guest management; restores can be targeted |
Hypervisor snapshots kept on the same storage | Share the storage failure and attack domain of the VM, so they do not provide the independent copy that separation requires |
Granular or instant restore from a backup set | Helps meet restore targets for priority datasets, and lets a team restore a single dataset instead of a whole host |
Vinchin Backup & Recovery is one VM backup product that covers virtualization platforms such as VMware, Hyper-V and Proxmox VE. Whichever tool you use, confirm in its current documentation how encryption, retention, copy separation and deletion are configured, and map them to your backup policy rather than assuming they satisfy a given requirement.
Which Backup Approach Fits Which GDPR Scenario? Decision Matrix
Match the design to the data, not the other way round. These are recommendations derived from the requirements above, not regulatory prescriptions.
Scenario | Main GDPR concern | Recommended approach |
Special-category data (health, HR, case files) | Severity of harm if unavailable; Art. 9 data raises risk | Shortest RTO tier; encrypted, isolated copy; documented restore tests |
High volume of erasure requests (consumer platforms) | Erased data lingering or returning after restore | Short operational retention; erasure register applied after restores; clear wording to individuals |
Regulated record-keeping duty (finance, tax, clinical) | Retention must be justified, not indefinite | Separate archive tier with a written legal basis and its own retention limit |
Ransomware resilience is the priority | Availability breach and notification risk | Offline, immutable or isolated copy; test full restore; keep forensic and restore evidence |
Backups at a cloud or managed provider | Art. 28 contract and Chapter V transfers | DPA with sub-processor, location and key-control terms; verify exit deletion |
Small business without dedicated IT | Accountability (Art. 5(2)) | Simple written policy, scheduled restore test, encrypted offsite copy, vendor DPA |
GDPR Backup Compliance Checklist and Common Mistakes
A defensible backup programme has a written policy, protected and separated copies, justified retention, a tested restore and a documented erasure and breach process.
Checklist
☐ Inventory systems and backups that hold personal data, including offsite and archive copies
☐ Write a backup policy covering scope, frequency, retention and restore objectives per dataset (Art. 5(2), 32)
☐ Encrypt backups and store keys separately from the data
☐ Keep at least one copy offline, immutable or otherwise isolated from production credentials
☐ Restrict and log administrative access to the backup platform
☐ Justify and document retention for every backup tier (Art. 5(1)(e))
☐ Run restore tests on a schedule and keep dated results (Art. 32(1)(d))
☐ Sign Article 28 contracts with backup and cloud providers; check locations and exit deletion
☐ Define how erasure requests are handled in backups and how erasure is re-applied after restores
☐ Prepare a breach procedure that covers backup-related incidents and the 72-hour decision (Art. 33)
Common mistakes
Treating a successful backup job as proof of recoverability. Only a completed restore test shows data can actually be recovered.
Keeping backups on the same network or with the same credentials as production. This is the pattern behind permanent data loss in ransomware cases.
Setting retention by storage capacity. Retention decided by whoever runs out of disk space cannot be defended under Article 5(1)(e).
Ignoring backups in erasure and access-request procedures. Decide a position and document it.
Assuming the vendor's compliance covers you. The controller stays accountable under Article 5(2) even when a processor holds the data.
Setting recovery targets by IT tier alone. Datasets with high impact on individuals may need faster recovery than revenue tiers suggest.
FAQ
Q1: Can I keep backups indefinitely if they are encrypted and never used?
Not without a justification. Article 5(1)(e) limits storage of identifiable data to what the purpose needs, and encryption is a security measure rather than a retention basis. Encrypted data generally remains personal data for whoever can decrypt it. Long-term copies need a documented purpose or legal obligation.
Q2: Do backups have to stay inside the EU or EEA?
GDPR does not impose a general data-residency rule. Article 44 and Chapter V restrict transfers to third countries unless a lawful mechanism applies, and remote access from a third country can count. This depends on the destination and the mechanism; check each location with your DPO.
Q3: Does a ransomware attack always require notifying the authority?
No. Article 33(1) exempts breaches unlikely to result in a risk to individuals, and the EDPB's Case 01 treats a quickly restored, encryption-only attack as a documented internal event. Every breach must still be recorded under Article 33(5), and exfiltration or special-category data changes the analysis.
Q4: Does GDPR require the 3-2-1 backup rule or immutable backups?
No. GDPR names neither. ENISA's ransomware guidance recommends the 3-2-1 pattern and isolated backups, and CISA recommends offline, encrypted backups, so they are recognised ways to demonstrate risk-appropriate protection, not legal requirements.
Q5: Does the same advice apply under the UK GDPR?
Largely, because the UK GDPR mirrors the EU text on security, storage limitation and erasure. The ICO's "beyond use" guidance is UK-specific, and notification rules and regulators differ, so UK organisations should follow ICO guidance and EU-based organisations their own authority.
Q6: What if a backup contains data I am legally required to retain?
Article 17(3) removes the erasure right where processing is necessary to comply with a legal obligation, among other grounds. Record which obligation applies, limit the data to what it covers, and tell the individual why the data was not erased.
Q7: Can a VM backup tool help with GDPR compliance?
It can support specific measures such as encrypted copies, scheduled retention and restore testing. It cannot make an organisation compliant on its own, because retention decisions, contracts, erasure handling and breach processes are organisational. Vinchin Backup & Recovery, like other VM backup tools, should be assessed against these requirements using its current documentation.
Conclusion
GDPR treats backup as part of security, not a separate checkbox. The defensible position is to protect copies as carefully as production, restore fastest what harms individuals most, justify every retention period, and be able to prove it. Retention length and restore-time behaviour decide whether erasure and breach obligations hold, so design them together rather than after an incident.
