Data processing agreements and analytics vendors
When you use a third-party analytics provider, they typically act as a processor handling personal data on your behalf. GDPR Article 28 requires a written data processing agreement (DPA) setting out the subject matter, duration, instructions, confidentiality, security, sub-processing, and deletion terms. No DPA with a processor is itself a compliance gap. This is an educational overview, not legal advice.
What this means
In data-protection terms, the site operator is usually the controller (deciding why and how data is processed) and a third-party analytics provider is the processor (acting on the controller's instructions). GDPR Article 28 requires that this relationship be governed by a binding written contract — the data processing agreement.
What a DPA must cover
Article 28 specifies mandatory contents: the subject matter and duration, the nature and purpose of processing, the types of data and categories of people, the controller's documented instructions, confidentiality obligations, security measures, terms for engaging sub-processors, assistance with data-subject rights, and what happens to data at the end (return or deletion). Using a processor without such an agreement is a gap regardless of how privacy-friendly the tool is.
- Controller instructs; processor acts on instructions
- Mandatory contents are set by Article 28
- Covers sub-processors and end-of-contract deletion
How it appears in analytics and logs
A signed DPA means your analytics processor is contractually bound to your instructions. Its absence is a compliance gap independent of how the tool behaves.
Diagnostic use case
Ensure any analytics vendor processing personal data on your behalf is bound by a DPA covering Article 28's required terms before you send them data.
What WebmasterID can help detect
Because WebmasterID minimises personal data, the scope of data a processing agreement must cover is smaller than for identifier-heavy analytics.
Common mistakes
- Sending data to a vendor with no DPA in place.
- Ignoring sub-processor terms in the agreement.
- Confusing the controller and processor roles.
Privacy and accuracy notes
The controller/processor relationship drives DPA duties. Self-hosting or processing less personal data can reduce how much a DPA must cover.
Related pages
- Cross-border data transfers in analytics
The GDPR restricts transfers of personal data outside the EU/EEA unless a valid mechanism applies — an adequacy decision, Standard Contractual Clauses, or another safeguard. Analytics that ships data to servers abroad therefore raises a transfer question, made sharper by case law on access by foreign authorities. Keeping data in-region or minimising it reduces the issue. This is educational, not legal advice.
- GDPR and web analytics: the practical picture
The GDPR governs processing of personal data of people in the EU. For analytics that means: identifiers and IP addresses can be personal data, consent is often required for cookie-based tracking, and minimisation matters. Cookieless, first-party, anonymised measurement reduces the surface — but this is a factual overview, not legal advice.
- Lawful basis for analytics processing
The GDPR requires a lawful basis for processing personal data. For analytics the realistic candidates are consent and legitimate interests, each with conditions: consent must be valid and is often required where ePrivacy applies to cookies, while legitimate interests demands a balancing test and grants the visitor a right to object. Picking and documenting the basis is the operator's job. This is educational, not legal advice.
- Privacy-first analytics
Less personal data narrows the DPA's scope.
Sources and verification notes
- EUR-Lex — GDPR Article 28 (processor)Primary text on DPAs. Educational, not legal advice.
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.