A Practical Guide to data processing agreement

A data processing agreement, usually called a DPA, is the contract that governs how a vendor processes personal data on behalf of a customer. If your website, SaaS product, CRM, analytics tool, email platform, cloud provider, or support desk touches personal data, you need to know whether a DPA is required.

Under GDPR, the core rule is in Article 28: processing by a processor must be governed by a contract or other legal act that binds the processor to the controller and sets out key details about the processing (GDPR Article 28).

Controller, Processor, or Third Party?

The first step is role mapping.

Controller: Decides why and how personal data is processed. A company running a website and choosing an analytics provider is often the controller for its visitor analytics.

Processor: Processes personal data on behalf of the controller and under its instructions. A privacy-first analytics provider, email delivery tool, or cloud host may be a processor when it only uses data to provide the contracted service.

Independent controller: Decides its own purposes. Some advertising platforms and data-sharing arrangements may involve independent controller roles rather than pure processing.

Role labels should match reality, not marketing language. If a vendor uses customer data for its own advertising, enrichment, or cross-customer profiling, a standard processor DPA may not describe the relationship accurately.

What a GDPR DPA Must Cover

Article 28 requires the contract to address:

• Subject matter and duration of processing.
• Nature and purpose of processing.
• Type of personal data.
• Categories of data subjects.
• Controller obligations and rights.
• Processing only on documented instructions.
• Confidentiality commitments.
• Security measures.
• Subprocessor rules.
• Assistance with data subject rights.
• Assistance with security, breach, DPIA, and consultation obligations.
• Deletion or return of personal data at the end of services.
• Information needed to demonstrate compliance.
• Audit and inspection rights.

In practical terms, the DPA should let you answer: what data does the vendor receive, why, where is it stored, who else touches it, how is it protected, and what happens when the contract ends?

Why Analytics Vendors Need Review

Analytics vendors can process personal data even when reports are aggregate. Data may include IP addresses, cookie IDs, device information, URL paths, referrers, campaign parameters, approximate location, and account-linked events.

For each analytics tool, ask:

• Is the vendor a processor, service provider, or independent controller?
• Does the vendor combine data across customers?
• Are cookies or persistent identifiers used?
• Is data used for advertising or product improvement beyond the contracted service?
• Where is data hosted?
• Which subprocessors are involved?
• Can raw data be deleted?
• What retention settings are available?
• Does the vendor provide a DPA?

Privacy-first analytics reduces the data footprint, but a DPA may still be needed if any personal data is processed.

Subprocessors and International Transfers

Most SaaS vendors rely on subprocessors: cloud hosts, email providers, support tools, monitoring services, and payment systems. A DPA should say whether subprocessors are allowed, how customers are notified of changes, and how objections work.

International transfers need separate attention. If personal data moves outside the EEA or UK, teams may need standard contractual clauses, transfer risk assessments, supplementary measures, or another valid transfer mechanism. The DPA is not always enough by itself.

A Vendor Review Checklist

Before approving a tool:

1. Identify what personal data the tool receives.
2. Confirm the vendor role.
3. Review the DPA and subprocessors.
4. Check hosting region and transfer mechanism.
5. Review security documentation.
6. Set retention limits.
7. Disable unnecessary data sharing.
8. Confirm deletion/export workflows.
9. Document the business purpose.
10. Add the tool to the privacy notice if needed.

Common DPA Mistakes

• Signing a DPA but never configuring the product safely.
• Ignoring event properties and URL parameters that contain personal data.
• Assuming a US vendor's DPA resolves EU transfer risk automatically.
• Failing to review subprocessors.
• Keeping raw analytics data forever.
• Letting agencies add tools outside procurement.
• Treating all vendors as processors when some are independent controllers.

A DPA is not paperwork to file away. It is the operating manual for a data relationship. The more privacy-first your stack is, the easier that relationship is to explain, secure, and end cleanly.

How to Review an Analytics DPA

For analytics vendors, compare the DPA against the actual event payload. A contract may say the processor follows instructions, but the implementation may still send full URLs, identifiers, IP addresses, search terms, or ad click IDs. The GDPR's Article 28 processor requirements are the baseline: documented instructions, confidentiality, security, subprocessor controls, assistance with rights, deletion or return, audits, and clear liability boundaries.

Ask five practical questions. Can the vendor use data for its own product, benchmarking, advertising, or AI training? Where is data hosted and which subprocessors can access it? How quickly can data be deleted after termination? Are support and engineering logs covered by the same terms? Does the DPA match the public privacy notice and security page? If the answer depends on a sales promise, get it into the contract or reduce the data sent. A privacy-first analytics vendor should make this review shorter because the service is built around limited, purpose-specific data instead of broad behavioral profiles.

DPA Review Checklist

Compare the DPA with the actual analytics payload. The contract should cover documented instructions, confidentiality, security, subprocessors, international transfers, assistance with rights, deletion or return, audit rights, and incident notice, but those clauses only help if the implementation avoids unnecessary personal data.

Before signing, test whether full URLs, query strings, IP addresses, IDs, form values, or campaign parameters could expose personal data. If a vendor can reuse data for advertising, benchmarking, AI training, or unrelated product improvement, get the role and limits clear in writing or reduce the data sent.