GDPR, plainly stated
If you manage client WordPress sites in or serving the EU or UK, you are a controller and we are a processor. This page sets out what that means in practice, without requiring a lawyer to interpret it.
This page explains our position. The DPA is the contractual document.
Where agencies usually get caught
The uncomfortable part of GDPR for a WordPress agency is not the headline principles. It is that connecting a client site to a management platform makes you a controller of whatever that platform can see, and makes the platform a processor acting on your instructions.
That relationship requires a written agreement, a documented list of sub-processors, a defined retention position, and the ability to answer a client asking where their data goes. Agencies that cannot answer that question during a procurement review lose deals over it, often late in the process.
The practical fix is boring and effective: know what a tool actually processes, have the DPA signed before you connect production sites, and keep the sub-processor list somewhere you can find it.
What we actually process
- Site metadata: URLs, versions, plugin and theme inventories
- Operational records: update, backup and monitoring events
- Your team's account data: names, emails, roles
- Backup archives, which may contain your clients' personal data
- Support correspondence you send us
- Usage and diagnostic logs for the platform itself
The four questions procurement always asks
What is the lawful basis?
For your team's account data, contract performance. For platform diagnostics, legitimate interest in operating and securing the service. For any personal data inside backups we hold, we act purely as a processor on your documented instructions and assert no independent basis of our own.
Who are the sub-processors?
Infrastructure, storage and transactional email providers are documented on the security page with their function and location. The list is maintained rather than assembled on request, and material changes are notified in advance so you can object.
Where is data stored?
Storage region is documented and residency options are available on agency plans. Bring-your-own storage is supported on request, which for some agencies is the cleanest answer to a residency requirement because the backup archives never leave infrastructure you control.
How do we handle rights requests?
Data subject requests reaching us are routed to you as controller rather than actioned directly, because we do not have the context to verify them. We assist with access, erasure and portability within the timescales in the DPA.
What we give you to work with
Data processing agreement
A DPA covering scope, instructions, confidentiality, security measures, sub-processors, assistance and deletion on termination.
Sub-processor list
Maintained, published, with function and location for each, and advance notice of material changes.
Security measures
Encryption in transit and at rest, scoped access tokens, role-based permissions and audit logging, documented rather than asserted.
Retention and deletion
Defined retention for operational records and backups, with deletion on termination within the period stated in the DPA.
Export on demand
Complete account data export in machine-readable format at any time, which is portability in practice rather than in principle.
Breach notification
Notification to you without undue delay, with what we know, so you can meet your own 72-hour obligation as controller.
Backups are the part worth thinking about
Most of what a management platform processes is unremarkable: URLs, version numbers, event logs. The exception is backup archives, because a WordPress backup of a client site can contain everything from customer orders and addresses to form submissions and user accounts.
That makes backup storage the highest-sensitivity part of the relationship and the part your client's own privacy notice may need to reflect. It is worth checking whether their notice contemplates a processor holding a full copy of the site, because many do not.
Where residency or sensitivity is a firm requirement, bring-your-own storage is usually the cleanest answer: archives are written to a bucket you control, under your own terms, and the platform holds operational metadata only. Raise it before migration rather than after.
What to have in place
- A signed DPA before connecting production client sites
- Your own DPA with each client, naming your sub-processors
- A note in the client's privacy notice about backup processing
- A documented retention position you can actually state
- A named person who handles rights requests
GDPR questions
A processor, for anything relating to your clients' sites. You instruct us; we act on those instructions. For your own team's account data and for platform diagnostics we act as a controller, and that scope is set out in the DPA.
Residency options are available on agency plans and documented on the security page. If a specific guarantee is a contractual requirement, confirm it with us in writing before migrating rather than relying on a marketing page, including this one.
Yes, on request. Archives are written to storage you control, which for many agencies is the cleanest answer to a residency or sensitivity requirement because the client data never rests on our infrastructure at all.
You export everything in machine-readable format at any point, and we delete your data within the period stated in the DPA after termination. The connector removes cleanly from client sites without leaving residue.
Where transfers occur they rely on the safeguards named in the DPA, and the location of each sub-processor is published. If you need transfers restricted entirely, discuss it before migrating, because it may constrain which features are available to you.
Questions before procurement?
Send us the data-handling questions from your client's review. We would rather answer them in writing up front than during a deal.
Free during early access. No credit card required.