A freelance web designer installs WooCommerce for a client, connects Stripe for payments, adds Mailchimp for newsletters, and configures Cloudflare for security. When asked who’s responsible for GDPR compliance covering all that customer data, she points to her hosting provider’s terms of service and assumes the matter is settled. Six months later, a German customer files a complaint with their supervisory authority. The designer discovers that pointing fingers at service providers doesn’t shift legal responsibility — and that she never understood the fundamental distinction determining who actually bears compliance obligations.
The controller-processor relationship sits at the heart of GDPR’s accountability framework. Controllers decide why personal data gets collected and how it gets used. Processors merely execute those decisions on behalf of controllers. For WordPress site owners, this distinction carries enormous practical weight: you cannot outsource your compliance obligations to hosting providers, plugin developers, or email marketing services. They work for you. When something goes wrong, regulators come looking for the entity that made the decisions — and that entity is almost always the site owner.
European supervisory authorities have issued over €5.65 billion in GDPR fines since May 2018, with a substantial portion targeting organizations that misunderstood their role in the data processing chain. Getting this distinction right isn’t academic exercise. It determines who faces liability, who needs Data Processing Agreements, and whose documentation must demonstrate compliance with the full weight of EU data protection law.
What the Regulation Actually Says
Article 4(7) defines a data controller as any entity that “determines the purposes and means of the processing of personal data.” Article 4(8) defines a processor as any entity that “processes personal data on behalf of the controller.” The European Data Protection Board’s Guidelines 07/2020 emphasize that these are functional concepts based on actual decision-making power, not contractual labels parties assign themselves.
The critical distinction lies in who decides the “why” and the “essential how” of data processing. Controllers determine the purpose of collecting data, the types of data collected, retention periods, and categories of recipients who receive the data. Processors handle non-essential technical means — which servers to use, what encryption standards to implement, how to structure database tables. A processor following instructions remains a processor. A processor making independent decisions about purposes or essential means automatically becomes a controller under Article 28(10) and faces full controller obligations regardless of what any contract says.
The UK’s Information Commissioner’s Office provides practical indicators. You’re likely a controller if you decided to collect personal data in the first place, determined what data to collect and from whom, decided the processing purpose, or obtain commercial gain from processing beyond payment for services. You’re likely a processor if another organization contracted you to process data on their behalf, told you what data to process, and determined the processing purpose while you simply follow their instructions.
Joint controller status under Article 26 arises when two or more parties jointly determine purposes and means. This doesn’t require equal involvement — the Court of Justice of the EU has ruled that joint controllership can exist even when parties have different levels of involvement or one party lacks direct data access. A WordPress agency that selects Facebook Custom Audience targeting criteria while a client provides the customer data may find itself a joint controller for that advertising campaign, sharing compliance obligations with the client rather than acting as their processor.
WordPress Site Owners Are Almost Always Controllers
When you launch a WordPress website that collects any personal data — contact forms, comments, user registrations, analytics tracking, e-commerce transactions — you are the controller. You decided to create the website. You chose what forms to add and what fields they contain. You determined what data to collect and for what purposes. You selected which plugins and services to integrate. Every decision about why data gets processed originated with you.
Consider what “determining purposes and means” looks like in practice. A site owner decides to add a newsletter signup form — that’s determining the purpose of marketing communication. The owner chooses to require name and email fields — that’s determining essential means regarding data type. The owner selects Mailchimp for delivery — that’s selecting non-essential means regarding technical implementation. The owner sets a five-year retention period for inactive subscribers — that’s determining essential means regarding duration. Every essential decision came from the site owner. Mailchimp simply processes data according to those instructions without independent authority over purposes.
Controller responsibilities under GDPR extend across Articles 24 through 31. Controllers must implement appropriate technical and organizational measures ensuring compliance. They must demonstrate that compliance through documentation — the accountability principle in action. They must maintain Records of Processing Activities documenting all processing operations. They must conduct Data Protection Impact Assessments for high-risk processing activities. They must respond to data subject access, rectification, and erasure requests within one month. They must notify supervisory authorities of qualifying breaches within 72 hours. And they must select processors providing “sufficient guarantees” of GDPR compliance before engaging them.
None of these obligations transfer to processors simply because processors handle the technical work. The site owner who installed the contact form plugin remains responsible for lawful collection even though the hosting provider stores the submissions. The site owner who connected Mailchimp remains responsible for valid consent even though Mailchimp sends the actual emails. Controllers cannot escape obligations by pointing at the service providers executing their instructions.
When Site Owners Also Become Processors
WordPress agencies and developers frequently occupy dual roles depending on whose data they’re handling. An agency managing its own business website acts as controller for visitor data collected through that site. The same agency managing client websites becomes a processor for client customer data, handling it strictly under client instructions rather than for independent purposes.
White-label developers hosting multiple client sites on shared infrastructure may function as processors for all those clients while simultaneously controlling their own operational and employee data. The critical requirement is maintaining clear separation. If an agency’s systems cannot distinguish between data it controls versus data it processes for clients — and cannot apply different handling procedures to each — regulatory guidance suggests this creates joint controller status rather than a clean processor relationship. Documentation and technical architecture must clearly delineate which role applies to which data.
Maintenance contracts create ongoing processor relationships that persist after initial site development. An agency with administrative access to client WordPress installations, performing updates and managing backups containing customer data, acts as processor for that data throughout the contract duration. The DPA governing this relationship should specify exactly what processing activities are authorized, what security measures apply, and what happens to data access when the relationship ends.
Common Processors in the WordPress Ecosystem
Every third-party service touching personal data from your WordPress site requires a Data Processing Agreement under Article 28. Most major providers now offer DPAs, though some act as pure processors, some as independent controllers, and some occupy hybrid roles requiring careful analysis.
Web hosting providers like SiteGround, Kinsta, and WP Engine act as pure processors. They store and serve your data according to your instructions without pursuing independent processing purposes. Kinsta offers a downloadable DPA with Google Cloud Platform infrastructure and EU data center options. WP Engine provides its DPA with Standard Contractual Clauses and a Frankfurt server option for EU data residency. SiteGround includes DPA provisions in standard terms with EU data centers in London, Amsterdam, and Frankfurt. Their processor status means they’re responsible for processing according to your documented instructions and maintaining adequate security — not for your overall GDPR compliance strategy.
Email marketing services present varying DPA arrangements. Mailchimp automatically incorporates its DPA into Standard Terms without requiring separate signature. The service maintains EU-US Data Privacy Framework certification with Standard Contractual Clauses for international transfers, storing data on US servers under these transfer mechanisms. Brevo, formerly Sendinblue, offers a significant advantage as an EU-based company storing data in European data centers. Their DPA is accessible directly through account settings, eliminating international transfer complexity entirely. ConvertKit, now operating as Kit, provides its DPA with Data Privacy Framework certification and Standard Contractual Clauses, plus an “Audit Concierge” team assisting with GDPR verification requests.
Payment processors occupy a unique position that catches many site owners off guard. Stripe acts as both processor and controller depending on processing purpose — processor for payment facilitation services you direct, but controller for its own fraud prevention and anti-money laundering compliance. Their DPA is automatically incorporated into the Services Agreement. For non-Americas accounts, Stripe Payments Europe Limited handles processing as an Irish entity, keeping data within GDPR jurisdiction. PayPal, however, operates as an independent controller rather than a processor. PayPal independently determines processing purposes for payment data under their own legal bases. Their Data Protection Addendum acknowledges this reality: PayPal and merchants are “independent controllers,” each responsible for their own GDPR compliance. You cannot instruct PayPal on how to handle payment data — they process it according to their own purposes.
Analytics providers present compliance tradeoffs worth understanding. Multiple EU supervisory authorities including Austria, France, Italy, and the Netherlands ruled earlier Google Analytics versions non-compliant due to US data transfers. While GA4 anonymizes IP addresses by default and Google offers Data Processing Terms, many privacy professionals recommend alternatives. Matomo holds CNIL approval from the French supervisory authority and can potentially operate without tracking consent when properly configured to avoid identifiers. Matomo Cloud stores data in European AWS regions with no US transfers, while self-hosted Matomo eliminates the processor relationship entirely since data stays on your own servers. Plausible Analytics takes privacy-by-design further by collecting no personal data whatsoever — no cookies, no IP addresses, no personally identifiable information. This approach eliminates processor relationships and consent requirements entirely.
CDN and security services like Cloudflare act as processors with comprehensive DPAs available through dashboard settings. Their Data Localization Suite can ensure EU data remains within EU data centers for organizations with strict residency requirements. Standard Contractual Clauses and UK Addendum provisions are incorporated into their agreements.
Plugin Developers Create Processor Relationships Only When Data Leaves Your Server
The distinction between plugin code and plugin services determines whether you need a DPA with a plugin developer. A plugin that processes data entirely within your WordPress database creates no processor relationship — you remain the sole controller handling data on your own infrastructure. A plugin that transmits data to external servers creates a processor relationship with those external services, triggering Article 28 requirements.
Jetpack syncs extensive data to WordPress.com servers regardless of which specific features you activate: IP addresses, user agents, comment data, page views, and usage analytics all flow to Automattic’s infrastructure. Automattic acts as data processor for this information, and their DPA should be requested through wordpress.com/me/privacy. Akismet sends all comment data — name, email, IP address, content, and user agent — to external servers for spam analysis. This creates a clear processor relationship with Automattic, which provides Standard Contractual Clauses in their DPA. Sites using Akismet should display appropriate notice about how comment data gets processed.
Wordfence offers cloud-based brute force protection that transmits visitor IP addresses to Defiant’s servers when certain features are enabled. For EU compliance without requiring tracking consent, disable “Participate in the Real-Time Wordfence Security Network” in plugin settings — brute force protection continues working using local data only. If cloud features remain enabled, obtain Defiant’s DPA by contacting their privacy team. Sucuri operates entirely cloud-based, routing all traffic through their Web Application Firewall servers. External processing is inherent to their security model, making their DPA essential for any site using their services.
Yoast SEO performs all analysis entirely within the browser — no content ever reaches Yoast servers. Their official position states that their plugins do not process, collect, or store personal data at Yoast’s premises. No DPA is needed for plugin usage since no processor relationship exists. Contact Form 7, WPForms, and Gravity Forms in basic configurations store submissions locally in your WordPress database with no external transmission. The site owner remains sole controller with no processor relationship to the plugin developer. However, enabling integrations like Akismet spam checking, Mailchimp subscription syncing, or CRM connections creates processor relationships with those third-party services — each requiring its own DPA.
UpdraftPlus for local backup operations involves no external data transmission and creates no processor relationship. Using UpdraftVault cloud storage or third-party providers like Dropbox or Google Drive creates processor relationships with those storage services, bringing their DPA requirements into scope.
What Data Processing Agreements Must Contain
Article 28 mandates written agreements between controllers and processors containing specific elements. Generic Terms of Service do not satisfy this requirement — DPAs must contain GDPR-specific provisions addressing the unique obligations of the controller-processor relationship.
Descriptive elements must cover the subject matter of processing, duration of the arrangement, nature and purpose of processing activities, types of personal data involved, categories of data subjects affected, and the controller’s obligations and rights under the agreement.
Processor obligations under Article 28(3) must address eight specific requirements. Processors must process data only on documented controller instructions, including regarding international transfers. All personnel authorized to process personal data must be bound by confidentiality obligations. Processors must implement all security measures required by Article 32. Written authorization must be obtained before engaging any sub-processors. Processors must assist controllers in responding to data subject requests exercising their rights. Assistance must extend to breach notification, Data Protection Impact Assessments, and prior consultations with supervisory authorities. Upon contract termination, processors must delete or return all personal data according to controller preference. All information necessary for demonstrating compliance must be made available, including allowing and contributing to audits.
The EDPB emphasizes that DPAs must contain specific, concrete information on how these requirements will be met in practice. Merely restating GDPR provisions verbatim without operational detail is insufficient to satisfy Article 28.
Sub-processor authorization deserves particular attention. Processors cannot engage sub-processors without written controller authorization — either specific authorization for each sub-processor individually, or general authorization with notification and objection rights when sub-processors change. General authorization must provide controllers a genuine opportunity to object, not merely formal notice that changes are happening. The original processor remains fully liable for sub-processor performance regardless of authorization type.
Most major processors maintain sub-processor lists and provide update notifications. Cloudflare, Stripe, and HubSpot all offer email subscriptions for sub-processor changes, typically with 20-30 day advance notice before new sub-processors begin handling data.
Determining Your Role in Practice
The EDPB provides a straightforward three-question framework for role determination. First, why is this processing taking place — what purpose does it serve? Second, who decided that processing should take place for this purpose — who made that call? Third, who decides which data to process, for how long, and who can access it — who controls the essential means?
Apply this framework to common WordPress scenarios. You installed a contact form, determined what fields to include, chose which email service receives submissions, set how long to retain inquiry data, and decided when to delete old entries. You’re the controller. Your hosting provider stores data you chose to collect, runs servers according to your service selection, implements security you specified or approved, and has no independent purpose for your visitors’ data. They’re the processor. Your email marketing service sends campaigns you design, stores subscriber lists you provide, and applies segmentation rules you create — even though they choose their own server infrastructure and security implementations. They’re the processor handling non-essential technical means while you control purposes and essential means.
WordPress agencies commonly occupy dual roles that require careful documentation:
| Role | Processing Activity |
|---|---|
| Controller | Agency’s own employee HR data |
| Controller | Leads from agency’s own website contact form |
| Processor | Managing client’s WooCommerce customer database |
| Processor | Running client’s email marketing campaigns |
System architecture matters for maintaining clean role separation. If agency infrastructure cannot distinguish and separately handle data it controls versus data it processes for clients, regulatory guidance suggests treating the agency as joint controller for all that data — significantly increasing compliance obligations and liability exposure.
Liability Flows Through the Controller-Processor Chain
Under Article 82, controllers bear primary liability for GDPR-violating processing. Where controllers and processors are both involved in processing that causes damage, each party faces liability for the entire damage under joint and several liability principles. Data subjects can pursue compensation from either party for the full amount. The paying party can then seek contribution from others based on their relative responsibility for the violation.
Controller liability persists even when processor failures cause the problem. If your hosting provider suffers a breach exposing customer data, you face enforcement action and compensation claims from affected individuals. Your contractual indemnification provisions with the processor affect your ability to recover costs from them — but they don’t affect your obligations to data subjects or supervisory authorities. You cannot defend against a complaint by arguing that your processor failed you.
Processors face direct liability under specific circumstances: acting outside or contrary to lawful controller instructions, failing processor-specific GDPR obligations, engaging unauthorized sub-processors without required authorization, or failing to inform controllers that their instructions violate GDPR requirements. Administrative fines for processors reach €10 million or 2% of global annual turnover under the lower tier of GDPR penalties.
DPA indemnification clauses typically require processors to cover damages caused by their breaches. Key negotiation points include liability caps often set as multiples of contract value — ensure caps adequately cover potential regulatory fines that could arise from processor failures. Consider carve-outs establishing unlimited liability for data protection breaches even when caps apply to other contract breaches. Audit rights allowing verification of processor compliance before incidents occur provide valuable risk management. Insurance requirements ensuring processors maintain adequate cyber liability coverage add another protection layer.
Mistakes That Create Compliance Gaps
The assumption that hosting providers handle GDPR compliance fundamentally misunderstands the controller-processor relationship. Hosting providers are processors acting on your instructions. Their DPAs document that relationship and establish their obligations as processors. Those DPAs don’t replace your compliance obligations as controller — they supplement them. You remain responsible for lawful processing purposes, transparent privacy notices, data subject rights fulfillment, and breach notification. You must verify processor compliance; processors don’t verify yours.
Confusing Terms of Service with Data Processing Agreements leaves organizations without required documentation. Generic Terms of Service govern the commercial relationship between you and your service provider — pricing, service levels, termination rights, and similar business terms. DPAs are specific GDPR Article 28 requirements containing mandatory provisions about personal data processing. Many services maintain separate documents. Mailchimp incorporates DPA provisions into standard terms, but WordPress.com requires a separate DPA request through privacy settings. Check whether your actual agreement contains the eight mandatory processor obligations from Article 28(3) — if it doesn’t, you need a proper DPA regardless of what the Terms of Service cover.
The belief that plugin developers bear responsibility for their plugin’s data handling ignores who makes the processing decisions. You chose to install the plugin. You activated features that process visitor data. You configured settings determining what data gets collected and transmitted. You are responsible for verifying GDPR compliance before deployment and maintaining it afterward. Plugin developers provide tools. Controllers decide to use those tools and bear responsibility for how they’re used.
The assumption that US-based services automatically create compliance problems overlooks available transfer mechanisms. The EU-US Data Privacy Framework provides adequacy decisions for certified organizations, making transfers to those organizations as straightforward as transfers within the EU. Standard Contractual Clauses remain valid for non-certified companies as a transfer mechanism. Most major US services including Mailchimp, Stripe, HubSpot, and Cloudflare offer both mechanisms. Verify the transfer basis documented in each processor’s DPA — don’t assume non-compliance based on geographic location alone, but don’t assume compliance either without checking the actual documentation.
Building Processor Management Into Your Compliance Practice
Start by mapping every data flow through your WordPress installation. Document all personal data collected — contact form submissions, comment information, user account data, order records, analytics tracking, security logs. Then document every service touching that data — hosting provider, CDN, email marketing platform, payment processors, CRM integrations, analytics tools, backup services, security plugins with cloud features.
Gather DPAs systematically for each processor relationship. Locate their DPA through legal pages, account settings, or support request. Verify the agreement contains all Article 28 mandatory provisions, not just generic privacy language. Execute the DPA through online acceptance workflow or signature as required. Store copies in organized compliance documentation where you can produce them if requested by supervisory authorities or during audits.
Maintain Records of Processing Activities documenting processor relationships. For each processing activity involving processors, document the processing purpose, categories of data involved, categories of data subjects affected, processor identity and contact information, any sub-processors they engage, international transfer mechanisms where applicable, retention periods, and security measures protecting data throughout the processing chain.
Implement ongoing processor governance rather than treating DPA collection as a one-time exercise. Review your processor list quarterly to ensure it remains current. Audit processor compliance annually through questionnaires or documentation requests. Monitor sub-processor change notifications from processors offering that service. Re-evaluate compliance requirements whenever you add any new plugin or service that might process personal data.
The controller-processor framework isn’t bureaucratic overhead imposed by regulators who don’t understand how websites work. It’s the accountability structure determining who answers when supervisory authorities investigate complaints, when data subjects exercise their rights, and when breaches expose personal information. For WordPress site owners processing EU visitor data, understanding this framework transforms compliance from overwhelming confusion into documented relationships with clear responsibilities. You’re the controller. Your processors work for you. Your documentation must demonstrate that you’ve selected them carefully, instructed them properly, and verified their compliance — because when something goes wrong, you’re the one who made the decisions that matter.
— Comments 0
No comments yet. Be the first to share your opinion!
Comments are closed for this post.