Most teams treating GDPR compliance as a backup checkbox are solving the wrong problem. GDPR doesn't say "have a backup." It says you must be able to restore availability and access to personal data in a timely manner after an incident — and separately, it says you must not keep data longer than necessary. Those two requirements pull in opposite directions, and how you resolve that tension is exactly what an auditor will ask about.
This article walks through what GDPR actually requires, maps those requirements to DigitalOcean's native backup capabilities, and gives you the documentation structure you need to survive an audit. It won't give you legal advice. It will give you clarity on the technical side.
What GDPR actually says about backup
GDPR doesn't have a section called "backup." The word doesn't appear in the regulation. What it has are three articles that, taken together, define the backup-adjacent obligations.
Article 32 requires appropriate technical and organizational measures to ensure security "including as appropriate the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident." [verify — Article 32(1)(c) quoted directly] That's the closest GDPR gets to mandating backup. The critical phrase is "timely manner" — the regulation doesn't define what timely means, which leaves room for your own documented RTO/RPO targets.
Article 17 is the right to erasure, sometimes called the right to be forgotten. It requires you to delete personal data when a data subject requests it or when you no longer have a lawful basis to hold it. It does not require you to immediately purge every backup copy the moment a deletion request arrives.
Article 5(1)(e) is the storage limitation principle: personal data must be kept "in a form which permits identification of data subjects for no longer than is necessary." This is where retention policy comes in. Long-lived backups containing personal data can conflict with this principle if you haven't documented why the retention period is necessary.
The short version
GDPR creates an obligation to protect and restore personal data, an obligation to delete it when required, and an obligation to document how long you keep it. It does not mandate any specific backup technology or architecture.
The practical implication: your backup strategy needs to satisfy Article 32 (you can restore), be reconcilable with Article 17 (you have a documented erasure path), and respect Article 5(1)(e) (you have a written retention policy and your backups honor it).
The requirements that matter for DigitalOcean
Translating those three articles into concrete requirements for a DigitalOcean-hosted application produces a short list. The table below maps each article to what DigitalOcean's native backup covers, and where the gaps are.
| GDPR requirement | What it demands | DigitalOcean native backup | Gap |
|---|---|---|---|
| Article 32: restore availability | Ability to restore personal data after an incident | Droplet backups (weekly/daily), Managed DB daily backups | Native backups stay in the same account; account-level incident takes backup with resource |
| Article 32: timely manner | Documented RTO/RPO; regular restore testing | Restore is possible but not downloadable or testable off-platform | No off-account restore testing path |
| Article 17: right to erasure | Documented path to eventual deletion from backups | No per-record deletion from native backups | You must document the rotation schedule as the erasure path |
| Article 5(1)(e): storage limitation | Documented retention policy; backups expire | Droplet backups: 4 weeks. Managed DB: 7 days | Snapshots don't expire; no lifecycle policy for Spaces data |
| Data residency | Personal data stays in documented regions | EU regions available (AMS2, AMS3, FRA1, LON1) | You must provision resources in EU regions deliberately |
This isn't an indictment of DigitalOcean's backup system. The gaps are architectural choices that apply to any single-cloud backup setup. What matters is that you know which gaps exist and document how you're addressing them.
For a deeper look at what DigitalOcean's native backup system does and doesn't do, how DigitalOcean native backup works covers the mechanics in detail.
Data residency: where your backups physically live
GDPR requires that personal data transferred outside the EU has an adequate level of protection. For backups, this means your backup copies need to stay in an EU region or a region covered by an adequacy decision, unless you have explicit data transfer mechanisms in place.
DigitalOcean's datacenter regions and their GDPR status:
| Region | Location | GDPR status |
|---|---|---|
| AMS2, AMS3 | Amsterdam, Netherlands | EU |
| FRA1 | Frankfurt, Germany | EU |
| LON1 | London, United Kingdom | UK adequacy decision [verify current status] |
| NYC1, NYC3 | New York, USA | Non-EU |
| SFO1, SFO3 | San Francisco, USA | Non-EU |
| TOR1 | Toronto, Canada | Non-EU |
| SGP1 | Singapore | Non-EU |
| BLR1 | Bangalore, India | Non-EU |
LON1 operates under the UK's adequacy decision with the EU. The UK government has maintained this status post-Brexit, but it is subject to review. If data residency is a hard requirement for your use case, AMS2, AMS3, or FRA1 give you direct EU jurisdiction with no adequacy dependency. [verify current UK adequacy status]
The residency question has a second layer that most teams miss: native DigitalOcean backups for a Droplet in AMS3 stay in AMS3 — that's fine. But if you create a manual snapshot and transfer it to NYC3 for redundancy, you've moved personal data to a non-EU jurisdiction. That transfer needs documentation or needs to be routed to another EU region instead.
For cross-region backup strategies that stay within GDPR boundaries, DigitalOcean cross-region backup covers the region pairing options in detail.
Right to erasure and backup retention
Article 17 is the one that makes engineers nervous: a user submits a deletion request, and you're sitting on thirty days of backups that contain their data.
The good news is that GDPR does not require immediate deletion from backup systems. The regulation distinguishes between primary systems and backup systems. Supervisory authorities, including guidance from various EU data protection authorities, have consistently acknowledged that immediate backup purging is technically impractical. [verify — flag for legal review]
What GDPR does require:
- You have a documented retention policy for backups.
- You apply the deletion when the backup rotates naturally (the data is gone when the backup expires).
- You don't restore deleted data to the primary system from backup after an erasure request, unless there's a specific lawful basis for doing so.
- Your documentation makes all of this legible to an auditor.
Right to erasure doesn't mean you delete backups immediately. GDPR allows reasonable retention periods for backup integrity, as long as you document the policy and apply the deletion when the backup rotates.
In practice, for DigitalOcean:
- Managed Database backups: 7-day retention. A deletion request received today means the personal data is gone from backups within 7 days of natural rotation.
- Droplet backups: 4-week retention. The same principle applies; document that the 4-week window is your retention limit.
- Snapshots: No automatic expiration. This is the problem. A snapshot taken two years ago and never deleted still contains whatever data the system held at that point. You need a written policy and a process to expire snapshots, or they become a GDPR liability.
The snapshot retention gap is the most common oversight we see on DigitalOcean setups. You can see a broader discussion of how snapshots differ from backups in the DigitalOcean snapshots vs. backups breakdown.
Documenting your backup process for an audit
Documentation is where most teams fail a GDPR audit, not the technical setup itself. An auditor isn't inspecting your Droplet configuration — they're reading your policies and asking whether your technical reality matches what you wrote.
The minimum viable GDPR backup documentation covers six things:
1. What you back up List every DigitalOcean resource that contains personal data: Droplets, Managed Databases, Spaces buckets. Be specific. "We back up our production Postgres cluster on db-postgres-ams3-001" is better than "we back up our databases."
2. Where backups are stored Region, account, and provider. "DigitalOcean managed backup, AMS3" or "Spaces bucket sb-backups-ams3 in our DigitalOcean account." If you have off-site backups, include the destination region and provider.
3. Retention periods and rationale How long each backup type is kept, and why that period is necessary. "Managed Database: 7 days (native retention, supports point-in-time recovery within the operational window). Droplet backup: 4 weeks (supports recovery from incidents discovered after the immediate window). Snapshots: 90 days maximum (pre-migration or pre-deployment only; deleted after the deployment window closes)."
4. Access controls Who can access backup data. At minimum, document that backups are restricted to the same access controls as production. For DigitalOcean, that means documenting your team-member roles and any API tokens that have access to backup or snapshot operations.
5. Erasure path for backups How you handle Article 17 requests with respect to backup data. Write this out: "Deletion requests are applied to the primary system immediately. Backup data containing the deleted records will expire naturally within [your retention period]. Deleted records will not be restored from backup following an erasure request."
6. Restore testing cadence Article 32 requires that restores actually work. Document when you last tested a restore, what the result was, and how often you test. Untested backups are not "the ability to restore."
The same-host problem
GDPR does not require off-site backup. But Article 32 requires "the ability to restore the availability and access to personal data in a timely manner." If your only backup sits inside the same DigitalOcean account as the compromised resource, an account-level incident takes the backup down with the primary. You can't restore what you can't reach. The off-site question isn't a GDPR box to check — it's what Article 32 actually demands when you follow the logic through.
If you're mapping your current setup against Article 32's restore requirement and finding gaps, DigitalOcean off-site compliance covers the architectural options for taking backups outside the primary account.
For a thorough look at what DigitalOcean's native backup leaves uncovered, what DigitalOcean native backup doesn't cover is the right starting point.
Common GDPR backup mistakes on DigitalOcean
These are the gaps we see most often when teams think they've handled the compliance side.
Mistake 1: Treating native backup as GDPR-sufficient without documentation. DigitalOcean Managed Databases include daily backups with 7-day retention. That's a reasonable RPO for many applications. But an auditor doesn't care that the backup exists — they care that you have a written policy, a documented retention rationale, and evidence that you've tested a restore. The technical feature and the compliance posture are not the same thing.
Mistake 2: Snapshots with no expiration policy. As covered above, snapshots don't expire. A snapshot of a Droplet from three years ago is sitting in your account right now, containing whatever personal data the system held at the time, with no GDPR-compliant retention rationale attached to it. Audit your snapshot inventory and set a written policy.
Mistake 3: Assuming LON1 is always safe. LON1 operates under the UK's adequacy decision. The adequacy decision has been maintained, but it is not permanent EU membership — it's a political determination that can change. Teams with hard EU residency requirements should use AMS2, AMS3, or FRA1 directly. See the DigitalOcean docs on Managed Databases for region availability.
Mistake 4: No process for restoring selectively after an erasure request. If a user requests erasure and you later need to restore from a backup (due to an incident), you need a documented process: restore, then re-apply the deletion. Without that process written down, you're at risk of restoring deleted data without a lawful basis.
Mistake 5: Confusing same-account redundancy with off-site backup. Copying a snapshot to a second DigitalOcean region still leaves both copies inside the same DigitalOcean account. That protects against a region-level outage, but not against account suspension, billing issues, or credential compromise. If Article 32's restore guarantee is your target, same-account redundancy doesn't get you there.
Mistake 6: No documentation for Spaces. Spaces has no native backup. If your application stores personal data in Spaces — user uploads, exports, attachments — that data has no automatic protection at all. It also has no lifecycle policy unless you configure one. GDPR applies to that data exactly as it applies to database records.
What to do next
Start with the documentation gap, not the technical gap. Write the six-point documentation structure from the previous section before you change anything in your DigitalOcean account. Once you have the policy written, you'll see clearly which technical controls are missing and which ones you already have.
The most common thing that's actually missing isn't a backup — it's the restore test. Pick a non-production time slot, restore a copy of your Managed Database, verify the data, and write down the date and the result. That single step moves you from "we have backups" to "our backups work," which is what Article 32 is actually asking for.
The reason we built SimpleBackups for DigitalOcean is exactly the gap this article describes: native backup covers the easy part, and none of the hard part. If you want off-site backup with documented retention, automated alerting, and a restore you can actually test, that's what it does.
FAQ
Does DigitalOcean backup comply with GDPR?
DigitalOcean's native backup features (Managed Database daily backups, Droplet backups) provide the technical capability to restore data, which satisfies part of Article 32. However, GDPR compliance requires more than a backup feature: it requires documented retention policies, a documented erasure path for backup data, regular restore testing, and appropriate data residency. Native backup alone is not a complete compliance posture.
Where does DigitalOcean store backups geographically?
DigitalOcean stores backups in the same region as the resource. For GDPR purposes, the EU regions are AMS2 and AMS3 (Amsterdam, Netherlands), FRA1 (Frankfurt, Germany), and LON1 (London, UK, under an adequacy decision). NYC1, NYC3, SFO1, SFO3, TOR1, SGP1, and BLR1 are outside the EU. If you need EU data residency for backups, you must deploy your resources in an EU region.
How does the right to erasure affect backups?
GDPR does not require immediate deletion of personal data from backup systems when an erasure request is received. You must apply the deletion to primary systems immediately, document that backup data will expire within your stated retention period, and ensure deleted data is not restored to primary systems after an erasure request without a lawful basis.
Do I need to encrypt DigitalOcean backups for GDPR?
GDPR's Article 32 lists encryption as an "appropriate technical measure" for protecting personal data, but it's listed alongside pseudonymization and other controls — not as a mandatory requirement in all cases. In practice, encrypting backups is strongly recommended and expected for any serious compliance posture. DigitalOcean encrypts data at rest on its managed infrastructure [verify specific encryption coverage], but if you're copying backups off-site, you should apply your own encryption before the data leaves the primary account.
What documentation do I need for a GDPR backup audit?
For a backup audit, you need: a written description of what you back up and where it's stored; documented retention periods with rationale; a documented erasure path explaining how deletion requests are handled with respect to backup data; access control documentation covering who can reach backup data; and evidence of regular restore testing. The technical backup capability matters less to an auditor than the documentation showing you've thought through all of these dimensions.
This article is part of The complete guide to DigitalOcean backup, an honest, practical reference from the team that backs up DigitalOcean every day.