A WordPress backup is a copy of your client's database, and a client's database is full of other people's names, email addresses and, on a shop, order histories. When that copy sits in a vendor's cloud you have never audited, you have made a decision about your client's personal data, whether or not you meant to.
This post is not legal advice, and I am not a lawyer. It is a practical map of where client data ends up when you run backups, and the questions worth answering before a client, or a regulator, asks them.
Who is who under GDPR
The vocabulary matters because it decides who is responsible for what. Your client, the site owner, is normally the controller: they decide why and how visitors' and customers' personal data is used. An agency that hosts, maintains or backs up the site on their behalf is normally a processor. The tools and storage providers you use to do that work are, in turn, your sub-processors.
Article 28 of the GDPR sets out what this means in practice. A processor must work under a binding contract, process data only on documented instructions from the controller, and get authorisation before engaging another processor; on ending the service, it must delete or return the personal data at the controller's choice (Article 28 text). If you use a backup service, that service is a sub-processor, and your client is entitled to know about it.
Whether your agency counts as controller, processor or both in a given arrangement depends on the facts. A lawyer should confirm it for your contracts. But treating yourself as a processor for client sites is a safe working assumption.
The four places a backup can live
Every backup strategy puts copies in some combination of these locations, and each has a different answer to "where is the data?"
On the client's own server. The copy sits in the same hosting account as the site. The data has not moved anywhere new, which keeps the picture simple. The weakness is obvious: if the server is lost, so is the backup.
In your own offsite storage. An S3-compatible bucket, Google Drive or Dropbox that you control. You choose the provider and region, you hold the keys, and you can tell a client exactly where the copy is. You also become responsible for that account's security.
In a management tool's cloud. Many dashboards store backups on their own infrastructure. This is convenient, and it is also the case where you know least: which country, which provider underneath, how long copies are kept after you cancel.
In a host's snapshot system. Hosting providers often take their own snapshots. You may not have asked for them and may not be able to delete them, but they are still copies of the data.
The uncomfortable point is that most sites have copies in at least two of these, and the agency has only documented one.
Questions to answer per client site
Rather than a policy document nobody reads, keep an answer to each of these for every client:
- Where are backups stored, in which country or region, and with which provider?
- Who can access them, and how is that access removed when someone leaves your team?
- How long are copies kept, and what happens to them when the client leaves?
- Are the backups encrypted, and who holds the keys?
- Which of your tools are sub-processors, and does the client know?
If you can answer all five in a paragraph per client, you are in better shape than most agencies. If any answer is "I would have to check", that is your task list.
Region and transfers
A backup that leaves the EU or UK for another country is a data transfer, and transfers outside those areas have their own rules in Chapter V of the GDPR. You do not need to become an expert. You do need to know which region your storage is in, and to choose it deliberately for clients whose visitors are in Europe.
With an S3-compatible bucket, the region is a setting you pick when you create it. With a vendor's cloud, it is a fact you have to find in their documentation or ask them. Write the answer down; "I believe it is in Europe" is not an answer a client can rely on.
The right to erasure and old backups
A person can ask a controller to delete their personal data, and the site owner will pass that request to you. Deleting a user from the live database is easy. The awkward part is that the same person still exists inside every backup you hold.
The practical stance many teams take is to document a retention period, make sure it is reasonably short, and ensure that when a backup is restored, deletions made since are re-applied. Whether that is sufficient for a particular client is a question for their lawyer, but you cannot answer it at all without knowing how long copies live and where. Retention is worth deciding on purpose rather than by default.
Breaches and notification
Article 33 says a processor must notify the controller "without undue delay" after becoming aware of a personal data breach, while the controller has to notify the supervisory authority within 72 hours where feasible (Article 33 text). The 72-hour clock belongs to the controller, but your client can only meet it if you tell them promptly.
That means knowing, before an incident, how you would find out that a backup store or a management tool was compromised, and who at each client you would call. Sort that out on a quiet Tuesday, not during the incident.
Records of processing
Article 30 requires processors to keep records of the processing they carry out for each controller, including transfers and a general description of security measures. There is an exemption for organisations under 250 employees, but it does not apply where processing is not occasional, which regular backups arguably are (Article 30 text). Your legal adviser can say what that means for you. A one-page list of each client, each tool that touches their data, and where the data sits gets you most of the way regardless.
For a clear view of how to think about ownership of copies, see where should WordPress backups live.
Where this leaves you
You do not need to be a compliance expert to be a responsible processor; you need an accurate list of where each client's data is and who can reach it. In WPClientHub, backups are kept on the client's own server plus your own offsite storage, so you choose the region and the provider yourself. WPClientHub is free for 3 sites if you want to try this on a real client site: register here.