Data processing agreements, and when you actually need one

The question is who decides why

A controller determines the purposes and means of processing. A processor acts on the controller's behalf. That is the whole test, and it turns on decision-making rather than on who is holding the data, who wrote the code, or who is bigger. A hosting provider storing terabytes of your customer records is a processor. A credit reference agency you send the same records to, which decides for itself how to score them, is a controller in its own right.

Getting the label wrong is not a paperwork error. It changes which party owes duties to the individuals concerned, who must answer a subject access request, who notifies the regulator after a breach, and which contract you need. The label the parties write in the agreement does not settle it either — the roles follow the facts.

What Article 28 requires the contract to say

Under the GDPR, processing by a processor must be governed by a binding written contract, and Article 28(3) prescribes its contents. It also requires the agreement to set out the subject matter and duration of the processing, its nature and purpose, the types of personal data, and the categories of data subject — the part usually relegated to an annex, and the part most often left as a template placeholder.

The two clauses actually worth negotiating

Sub-processors

A processor may not engage a sub-processor without prior specific or general written authorisation from the controller. Almost every SaaS vendor operates on general authorisation, because specific authorisation for each vendor of each vendor is unworkable at scale. Under a general authorisation the processor must inform the controller of intended additions or replacements and give it the opportunity to object.

• A list you can actually find. A named page, with a subscription mechanism for change notifications. A list "available on request" is not a control.
• A notice period before the change takes effect. Thirty days is a common and defensible figure. Notice given on the day of the change is not notice.
• A stated consequence of objecting. This is the clause vendors most often leave vague. The realistic answer is that if the objection cannot be resolved, the customer may terminate the affected service without penalty and recover prepaid fees. An objection right with no consequence is not a right.
• Flow-down and retained liability. The processor must impose the same data protection obligations on the sub-processor, and remains fully liable to the controller for the sub-processor's failures. Check that the DPA has not quietly reduced that to reasonable endeavours.

Audit

The audit right in Article 28(3)(h) is real, and vendor paper usually narrows it: once a year, on 30 days' notice, at the customer's cost, subject to confidentiality, and satisfied in the first instance by producing a current third-party audit report. That is a reasonable structure and worth accepting on one condition — that a genuine on-site or bespoke audit remains available where the report does not cover the issue, or after a security incident affecting your data. Without that carve-out you have exchanged an audit right for a PDF.

Breach notification, and the number that matters

A controller must notify its supervisory authority of a personal data breach without undue delay and, where feasible, not later than 72 hours after becoming aware of it. A processor must notify the controller without undue delay after becoming aware.

Where the data goes

Transfers of personal data out of the EEA need a lawful transfer mechanism. Three routes cover most software procurement: an adequacy decision, the standard contractual clauses, or binding corporate rules within a group.

• Adequacy. The European Commission has recognised a list of countries and territories as providing adequate protection, and the United States is on it for organisations that have certified to the EU–US Data Privacy Framework. Adequacy is the simplest route where it applies, but it is not permanent: adequacy decisions are subject to periodic review, and the Data Privacy Framework in particular has been under continuing legal challenge since it was adopted.
• Standard contractual clauses. The fallback, and the reason most DPAs have the SCCs bolted on as an annex with a module selection. Check the modules match the actual roles — controller to processor is not the same annex as processor to sub-processor — and that the transfer risk assessment referred to in the clauses has actually been done rather than merely mentioned.
• The UK and Switzerland. The UK requires its own addendum to the EU clauses, or the UK international data transfer agreement. Swiss transfers need their own adjustments. A DPA that annexes only the EU clauses does not cover UK data.

The US version of the same idea

American state privacy laws use different vocabulary — service provider, contractor, third party — and impose their own contract terms. Under the California regulations a contract with a service provider or contractor must contain ten specified provisions, including a prohibition on selling or sharing the personal information, a prohibition on combining it with data from other sources, a requirement that the business purposes be identified specifically rather than in generic terms, a right for the business to take reasonable steps to ensure compliant use including an audit no more than once every twelve months, an obligation on the vendor to notify the business when it can no longer meet its obligations, and a right for the business to stop and remediate unauthorised use.

The practical effect is that a European-style DPA does not automatically satisfy California, and a US vendor addendum does not automatically satisfy Article 28. Most vendors solve this with one addendum carrying jurisdiction-specific sections; read the section that applies to you rather than the whole document.

When you do not need a DPA

• The other party is an independent controller. Banks, accountants, insurers, regulated advisers, employers of record and credit agencies typically decide their own purposes and have their own legal duties. What you need there is a data sharing arrangement setting out lawful basis, transparency and security — not a processor contract, which would misdescribe the relationship.
• No personal data is involved at all. Genuinely aggregate or synthetic data, with no realistic route to identification. This exception is narrower than most teams assume; pseudonymised data with a key held anywhere is still personal data.
• The processing is entirely internal. Between departments of one legal entity there is a single controller and no contract to sign.
• You are the processor. The obligation to have the DPA in place sits with your customer, but you remain directly liable for the Article 28 duties, so offering a competent one beats waiting.

Putting one in place

1. 1

   Decide the role for each activity

   Not for the vendor as a whole. Write down what data they receive, what they do with it, and who decided that. Where they make their own decisions about part of it, that part is controller to controller.

2. 2

   Take the vendor's standard addendum first

   Most established suppliers publish one. Marking up a published DPA is faster than sending your own paper, and the vendor is far more likely to accept limited edits than a wholesale replacement.

3. 3

   Complete the annex properly

   Subject matter, duration, nature and purpose, categories of data and of data subject. A template placeholder here is a defect in the contract, and it is the first thing a regulator reads.

4. 4

   Check the sub-processor list and the objection route

   Subscribe to the change notifications. Confirm what happens if you object, and that the answer is not "nothing".

5. 5

   Check the transfer mechanism against where the data actually sits

   Region selection in the product is not the same as the contractual position, and support access from another country is a transfer even where the data is stored locally.

6. 6

   Record it where you will find it again

   Vendor, role, data categories, transfer mechanism, sub-processors, date signed. This is the record of processing activities that regulators ask for, and rebuilding it later from a shared drive takes weeks.

The DPA is the private half of a public obligation. The other half is the notice you give the people whose data it is, which is a separate document with a different audience — the legal pages a website needs covers that side. Neither substitutes for the other: a faultless privacy policy over a vendor relationship with no processor contract is a compliance gap that shows up in the first questionnaire a customer sends you, and usually before that.