The GDPR contains no chapter headed "backup". That is exactly what makes the subject uncomfortable: the obligations apply, but you have to translate them into technical decisions yourself.
Here are the five points on which the questions come back every single time — and what can reasonably be answered.
This article describes general principles and does not constitute legal advice. For sensitive processing or a regulated context, have your analysis validated by a lawyer or by your data protection officer.
1. Does the right to erasure stop at the backups?
This is the most frequent question, and the answer comes in two parts.
Someone exercises their right to erasure (Article 17). You delete their data from production. But it is still present in the backups of the preceding weeks — and restoring a backup in order to extract one record surgically is technically absurd and dangerous.
The position taken by the supervisory authorities, including the French CNIL, is pragmatic: backups constitute a separate processing operation, whose purpose is security and continuity. Immediate purging of the archives is not required. Two commitments are expected in return:
- Data erased in production must not reappear: if a restore takes place, the erasure has to be replayed afterwards.
- The backups concerned must disappear in the normal course of rotation, within a period that is controlled and documented.
In practice: tell the person that their data will remain in the backups until the retention period expires, and state that period. And keep a record of the erasure requests to replay in the event of a restore.
2. How long backups are kept
A retention period that is "unlimited because it is safer" is a compliance problem, not a precaution.
The storage limitation principle (Article 5) requires a period justified by the purpose. For backups, the purpose is the ability to restore — not historical archiving.
In practice, a retention period is justified by tying it to a risk: the time it takes to detect silent corruption or slow-spreading ransomware. That is a defensible line of reasoning, and it generally leads to retention of a few weeks to a few months depending on criticality.
What matters is that the period should be decided, written down and applied, not accepted by default.
3. Your client is the controller, you are the processor
When you back up your client's data, they remain the controller of the processing and you become a processor within the meaning of Article 28. That requires a written processing agreement setting out at least:
- the subject matter, duration, nature and purpose of the processing;
- the categories of data and of data subjects;
- your security and confidentiality obligations;
- what becomes of the data at the end of the contract;
- the conditions for engaging a sub-processor — your hosting provider is one.
That last point deserves attention: if you host the backups with a third party, that third party is a sub-processor and your client must be informed of it. Hosting the backups yourself simplifies the contractual chain appreciably.
4. Where the data sits
Moving data outside the European Union is not prohibited but is regulated (Chapter V): a valid transfer mechanism, an impact assessment, supplementary safeguards. That means paperwork, legal monitoring, and exposure to regulatory changes you do not control.
The question is not only legal, in fact: it is also commercial. A client to whom you can say "your backups are on a server I administer, located at this address" is a reassured client.
A solution whose hosting you choose — at your own premises, at the client's, or on a dedicated server in France — simply removes the international transfer question altogether.
5. Encryption, and what it actually changes
Article 32 explicitly names encryption among the appropriate measures. But not all encryption is worth the same against the real risk.
Encryption at rest, server side: the data is encrypted on the backup server's disk. Protects against physical theft of the disk. Does not protect if the attacker gains access to the server, since the server holds the key.
Encryption at source: the data is encrypted on the machine being backed up, before it travels over the network, with a key that never leaves that machine. The backup server stores nothing but unintelligible blocks. Neither the hosting provider, nor the software vendor, nor an attacker who has compromised the server can read the content.
The difference is decisive for breach notification (Article 33). If data encrypted at source leaks and the key has not leaked, the risk to the data subjects is considerably reduced — which bears directly on the obligation to notify them.
The flip side is serious: whoever loses the key loses the data. Keeping the recovery key securely and traceably becomes an operational obligation of the first order. This is typically what a service provider takes on.
A checklist for your client files
| Point | What you need to be able to show |
|---|---|
| Record of processing activities | Backup appears there as a processing operation, with its purpose |
| Retention period | A written, justified retention period, not "unlimited" |
| Processing agreement | Signed, up to date, listing the sub-processors |
| Location | The physical location of the backup servers |
| Encryption | The level applied and the key custody procedure |
| Right to erasure | A procedure for replaying erasure after a restore |
| Restore tests | Dated reports |
That last line is the one most often forgotten. Article 32 calls for a process for regularly testing and evaluating the effectiveness of security measures. A backup that has never been restored does not satisfy that requirement — and, incidentally, protects nobody.
Need to clarify the processing chain and the data location for your clients? Let's talk.