GDPR's backup requirements come from its security and data protection principles, not from a backup clause. Article 32 says you must be able to restore personal data in a timely manner when systems fail.
The Article 5 principles that cover your live Salesforce org apply to every copy too. So a GDPR compliant backup has to be recoverable, stored securely, kept no longer than needed and ready for erasure requests.
Does GDPR require you to back up data?
Not in so many words, since the General Data Protection Regulation never uses the word backup. Instead, Article 32 asks for "the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident."
The same article asks for a process for regularly testing your security measures. Article 5 adds protection "against accidental loss, destruction or damage," and you're expected to demonstrate all of it under the accountability principle.
Salesforce runs the platform as your processor, but as controller your organization decides how its data is protected. That shared responsibility is covered in our Salesforce GDPR compliance guide.
Which GDPR principles apply to backup data and accountability?
A backup is more processing of the same personal data, so the core GDPR principles follow it into every copy. The table maps each article to what it asks of your Salesforce backup systems.
| GDPR article | What it requires | What it means for backups |
|---|---|---|
| Art. 5(1)(e) storage limitation | Keep data identifiable no longer than necessary | Set retention periods for backups, then delete old versions |
| Art. 5(1)(f) integrity and confidentiality | Protect against loss, damage and unlawful processing | Encrypt backups and limit who can open them |
| Art. 5(2) accountability | Be able to demonstrate compliance | Keep logs of backup jobs, restores and deletions |
| Art. 17 right to erasure | Erase data without undue delay when a ground applies | Erase records from backups too, or keep them out of use until they're overwritten |
| Art. 32 security | Restore data in a timely manner and test measures regularly | Run restore tests and record the results |
| Art. 33 breach notification | Notify the regulator within 72 hours where feasible | A tested restore shapes the risk assessment after an attack |
Under Article 83, security and breach notice failures can draw regulatory fines of up to EUR 10 million or 2% of worldwide turnover. Breaching the principles or the data subject's rights can cost up to EUR 20 million or 4%, whichever is higher.
Do you have to delete personal data from backups?
Yes, when a valid erasure request comes in and no exemption applies. Article 17 gives people the right to erasure on grounds such as withdrawn consent or data no longer being needed.
Regulators accept that a backup can't always be edited on the spot. The UK regulator's right to erasure guidance says the key issue is to put the backup data "beyond use," even if it can't be overwritten straight away.
That guidance is written for the UK GDPR. For the EU, the EDPB's right of access guidelines also note that erased data may only be overwritten in the backup at the next backup run.
The EDPB says that if a backup still holds data that was deleted from the live system, controllers need to be transparent about it when someone asks for access. Keeping your own log of deletions also tells you which erased records still sit in older versions.
Restores are the risky moment. If you restore a Salesforce org from a version taken before the deletion, check the log and remove those records again before anyone uses them.
How long can you keep Salesforce backups under GDPR retention policies?
Only as long as you need them. Storage limitation means data is kept in a form that identifies individuals for no longer than its purpose requires, and backups count.
Write a retention schedule with a defined period for each version, so you know how long it's stored and when it expires. Our post on Salesforce data retention policies shows how to define one per object and data type.
There are lawful reasons to keep data longer, since Article 17 doesn't apply where data is needed to meet legal obligations or for legal claims. A legal hold can stop specific data from being deleted in those cases.
Archives are different from backups, and each needs its own retention period across the data lifecycle. The EDPB's access guidelines separate archived data from backups, where data is stored solely to restore what was lost in a data loss event.
What security and encryption do GDPR backups need?
Article 32 asks for security appropriate to the risk, and it names encryption and pseudonymization as examples. A copy that holds your whole org deserves the same safeguards as production.
Encrypt backups in transit and at rest, as covered in our guide to encrypting Salesforce backups. Hold the encryption keys yourself where you can, so a stolen file is unreadable unless the attacker also has them.
Apply access controls with least privilege, and grant restore rights through permission sets only to the people who need them. Turn on multi-factor authentication for every account that can reach the stored copies, and keep audit trails of who opened them.
Test restores in separate environments on a schedule and document the results. The EDPB says "Backup procedures should be structured, consistent and repeatable" in its breach notification examples, and that methods should be tested.
How do backup and recovery affect GDPR breach notification?
Under Article 33, you notify your supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a breach. You can skip notice only when it's unlikely to result in a risk to people.
A good backup can change that risk assessment, as in an EDPB ransomware case where data was encrypted at rest and logs showed none had left. A backup restored it within a few hours, so neither the regulator nor the people affected had to be notified.
It still had to be documented under Article 33(5). In the matching case without an electronic backup, restoration took 5 working days, and the EDPB called a missing backup a factor that can raise risk.
Build restores into your incident response plan and disaster recovery steps, with named owners for handling each one. The EDPB advises keeping backups separate from operational storage and out of an attacker's reach, and our ransomware backup strategy covers how.
What Salesforce tools help with GDPR backups?
Salesforce offers several native options, and each covers part of the job. Check what each one stores, how often it runs and whether it can honor deletions in your org and in its copies.
- Data Export Service: exports CSV files once every 7 days in Enterprise, Performance and Unlimited Editions, or every 29 days in Professional and Developer Editions. Its zip files are deleted 48 hours after the email.
- Salesforce Backup & Recover (formerly Own Recover): a paid product that copies data and metadata, with Continuous Data Protection sold as a separate add-on.
- Privacy Center: an add-on that can remove or anonymize an individual's data under the right to be forgotten. Its data management policies can also automatically delete old or irrelevant records and files.
Privacy Center works on the data in your org, so copies held by any backup provider still need their own deletion and retention policies. Our post on Salesforce GDPR features covers the in-org settings in more detail.
How Flosum supports GDPR compliant Salesforce backups
Flosum Backup & Archive runs scheduled, incremental and high-frequency backups of Salesforce data and metadata. You can restore to field, record or full-org level from a point in time, and the product page lists right-to-erasure support.
Flosum offers three deployment options: Salesforce-native, Flosum-hosted cloud and customer-hosted. Backup & Archive runs as a Flosum Cloud App, either Flosum-hosted on Flosum-managed AWS or customer-hosted on your own AWS, Azure or GCP.
Customer-hosted lets you pick the region and generate the keys yourself. If copies are kept outside the EU, transfer safeguards such as standard contractual clauses apply, as our guide to GDPR data residency requirements explains.
Legal hold stops specific data from being deleted, and policy-driven retention expires the rest on schedule. For the wider plan, see our Salesforce backup best practices.
FAQs
Does GDPR apply to backups?
Yes. Backups hold personal data, so storage limitation, security and accountability under Article 5 apply to them as they do to live data.
Do I have to erase data from backups after a right to be forgotten request?
If no exemption applies, yes, though the EDPB notes that erased data may stay in a backup until the next backup run. The UK regulator says to put it beyond use until then and tell the person what will happen to their data.
How long should GDPR backups be kept?
GDPR sets no fixed period, only storage limitation. Keep each backup version only as long as its purpose requires, write that period into a retention schedule, and use a legal hold when you must keep data longer.
Is the 72-hour breach deadline affected by backups?
The deadline under Article 33 stays the same. A tested backup can lower the risk to people, which affects whether you have to notify at all.
Is Salesforce data backed up for GDPR by default?
Salesforce provides the Data Export Service, which runs weekly at most and keeps its files for 48 hours. For regular, tested backups you can restore from, you need a dedicated backup tool such as Salesforce Backup & Recover or Flosum.
Book a demo to see how Flosum Backup & Archive keeps your Salesforce backups encrypted, recoverable and ready for a GDPR compliance audit.
Thank you for subscribing
