GDPR backup requirements: what the regulation asks of SaaS data

GDPR backup requirements are easy to overlook, because the regulation never uses the word "backup". What Article 32(1)(c) does require is "the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident" — and Article 32(1)(d) requires a process for regularly testing that ability. If the personal data in your Microsoft 365, Google Workspace, Slack or Atlassian Cloud tenants has no restore path beyond a rolling trash bin, that is a compliance gap, not only an IT risk.

Here is what the regulation actually asks for, where SaaS-native retention falls short of it, and how the right to erasure interacts with the copies you keep.

Losing data is a breach, even if nobody stole it

Article 4(12) defines a personal data breach as "a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to" personal data. Note the first three words after "unlawful": destruction, loss, alteration. Exfiltration is not required.

That has a direct consequence for ransomware. An attack that encrypts a SharePoint library or a Google Shared Drive without taking a single byte off your tenant is still a loss of availability, and therefore still capable of being a notifiable breach under Article 33 — with the 72-hour clock running from the moment you become aware of it. The EDPB's Guidelines 01/2021 on examples regarding personal data breach notification work through exactly this family of scenarios, and the presence or absence of a reliable, tested restore is what separates the mild outcomes from the severe ones.

Put plainly: your backup is not just a recovery tool, it is a factor in your own breach risk assessment.

What Article 32 asks for in practice

Article 32 requires security measures "appropriate to the risk", judged against the state of the art, the cost of implementation, and the nature and scope of the processing. Four of its clauses bear on backup directly:

• Availability and resilience of processing systems and services (32(1)(b)) — not just confidentiality.
• Restoration in a timely manner after a physical or technical incident (32(1)(c)).
• Regular testing, assessing and evaluating the effectiveness of those measures (32(1)(d)).
• Article 5(2) sits on top of all of it: the accountability principle means you must be able to demonstrate compliance, not merely assert it.

"Timely" is deliberately undefined — it scales with your risk. But an untested restore is, by the plain reading of 32(1)(d), not yet a measure whose effectiveness you have evaluated.

Where SaaS-native retention falls short

Native retention in the major SaaS platforms is built for the accidental-deletion case, and it shows up short against Article 32 in three ways:

• Rolling windows, not point-in-time. You can usually recover something deleted recently. You generally cannot reconstruct "our tenant as it stood on the morning of the 14th", which is what a mass-encryption or mass-corruption event actually demands.
• Same blast radius. Data held inside the tenant shares the fate of the tenant. An attacker with administrative credentials can purge the recycle bin alongside the live data. This is the SaaS shared responsibility model: the provider is responsible for the platform's availability, you remain the controller responsible for your data.
• No evidence trail. There is no restore report, no measured recovery time, no retention proof to place in front of a supervisory authority — and accountability under Article 5(2) is an evidence obligation.

The specifics differ by platform — Slack's retention behaviour is not what most admins assume, and Atlassian Cloud's native limits are stricter still — but the shape of the gap is the same everywhere.

The right to erasure versus your backups

This is the question that stalls most GDPR backup discussions: if a data subject exercises Article 17, do you have to reach into every backup copy and surgically remove them?

The pragmatic position that has emerged in regulator guidance — the UK ICO's is the most explicit and is a useful reference even outside the UK — is that erasure must extend to backups, but can follow the backup's own cycle. If the data cannot be deleted from a backup immediately, it should be put beyond use: not available for any ordinary processing, protected, and erased when that backup is overwritten or expires. Guidance from EU supervisory authorities on this point is broadly comparable, but confirm the position with your own authority rather than assuming.

What matters operationally is that this is a documented, deliberate process rather than an improvisation:

• A written retention and expiry schedule for backup copies, so "eventually" has a date.
• A control that prevents an erased record from being silently reintroduced by a later restore.
• A response to the data subject that states the timeline honestly.

A backup system you cannot describe in those terms is harder to defend than one with a shorter retention window that you can.

Storage limitation cuts both ways

Article 5(1)(e) — storage limitation — means personal data must be kept no longer than necessary for the purpose. Indefinite backup retention is therefore not the automatically safer choice it feels like. The defensible answer is a retention period you have consciously chosen, tied to a purpose, documented, and actually enforced by the system rather than by intention.

Your SaaS providers are processors, and that is a contract

Under Article 28, a processor must implement Article 32 measures and assist you with your own obligations, all of it governed by a written data processing agreement. Microsoft, Google, Slack and Atlassian each provide one. What none of them assumes on your behalf is the controller's duty to restore your data after your incident — the Microsoft 365 and Google Workspace platform pages set out where that line falls for each workload. If you are already working through NIS2 backup obligations, the evidence you build there covers most of what GDPR accountability asks for too.

GDPR backup requirements: a practical checklist

• Map the personal data in each SaaS tenant — mailboxes, Drive files, Teams and Slack messages, Jira tickets and Confluence pages all commonly contain it, and Article 30 records of processing should already reflect that.
• Define a recovery point and recovery time for each, then verify them by testing rather than assuming.
• Keep an independent copy stored outside the tenant, so a tenant-level compromise cannot reach it.
• Retain restore evidence — a dated report showing what was restored and how long it took.
• Write down the erasure-versus-backup process before someone exercises Article 17, not after.
• Re-test on a schedule. Under 32(1)(d) an untested control is not an evaluated one.

The 30-second self-test

Ask yourself: "If ransomware encrypted our tenant tonight, could we restore the personal data in it and produce a report proving how long it took?" If the answer is no, the availability gap is already there — Article 33 would simply be the moment it becomes visible.

That capability is what we help you put in place across Microsoft 365, Google Workspace, Slack and Atlassian Cloud: we help you choose the right solution for your stack and guide the deployment, so you get independent point-in-time copies, tested restores and audit-grade evidence. You own and run it.

---

Want to know where you stand? Book a free risk assessment — we'll review your SaaS tenants against GDPR restore and evidence expectations and give you a straight list of the gaps.