A supplier sent us a DPA. What now?

A data processing agreement, or DPA, is the contract Article 28 of the GDPR requires before a supplier processes personal data on your behalf. If one has landed in your inbox, your supplier is treating itself as your processor and you as the controller, and the document sets out what it may do with the data you hand over. The useful move is to read it against Article 28(3), because that paragraph is where the law lists what the contract has to contain. It doubles as a checklist.

What follows is what that list covers, which parts tend to be thin, and what a signature does and does not settle. It explains what the law requires. It is not advice on the document in front of you.

What a DPA actually is

Article 28(3) says processing by a processor "shall be governed by a contract or other legal act under Union or Member State law, that is binding on the processor with regard to the controller". Article 28(9) adds that it has to be in writing, which includes electronic form. So the DPA is not a formality your supplier invented, and it is not the same thing as their terms of service: it is the specific paperwork the GDPR asks for whenever one organisation handles personal data for another.

The split it describes is between two roles. The Data Protection Commission sets them out in its guide to controller-processor contracts: a controller "defines the purposes and means of the processing of personal data", while processors "must only process personal data on the documented instructions of a controller". Your payroll provider does not decide why your staff get paid. You do. That makes you the controller, them the processor, and Article 28 the join between the two.

Two things follow that are easy to miss. Article 28(1) requires a controller to use "only processors providing sufficient guarantees" that the processing will meet the Regulation, so picking the supplier is itself something the law puts on you, before any contract is signed. And under Article 28(10), a processor that goes past its instructions and starts determining the purposes and means of processing "shall be considered to be a controller in respect of that processing".

First, work out which side of it you are on

"A supplier sent us a DPA" usually means the supplier is the processor and you are the controller. The obligations in the document are mostly theirs, owed to you, and the checks below are yours to make.

It is not the only direction. If the document arrived from a customer rather than a supplier, and the personal data in question is theirs rather than yours, you are being asked to sign as the processor. The same Article 28(3) list applies, but it reads the other way around: every commitment in it becomes something your business has to actually do, including the security measures, the breach notification back to them, the deletion at the end, and the audit rights you would be granting over your own operations. That is a different piece of work to a different deadline, and it is worth being certain which one you are holding before you read any further into it.

There is a third possibility, which is that neither of you is processing on the other's behalf. Article 28 applies where processing is "carried out on behalf of a controller". Where two organisations each decide their own purposes, a processor contract is not the instrument that describes the relationship, whatever the file is called.

What Article 28 says has to be in it

Article 28(3) opens by requiring the contract to set out details of the processing itself:

• the subject-matter and duration of the processing
• the nature and purpose of the processing
• the type of personal data and the categories of data subject
• the obligations and rights of the controller

It then lists eight terms the contract must stipulate. In the GDPR's order, the processor:

• processes personal data only on documented instructions from the controller, including on transfers to a third country, unless required to do otherwise by law, Article 28(3)(a)
• makes sure the people it lets near the data are committed to confidentiality, Article 28(3)(b)
• takes all the measures required by Article 32 on security of processing, Article 28(3)(c)
• respects the conditions on engaging another processor, Article 28(3)(d)
• assists you in responding to requests from individuals exercising their rights, Article 28(3)(e)
• assists you with your own obligations under Articles 32 to 36, which covers security, breach notification and data protection impact assessments, Article 28(3)(f)
• deletes or returns the data at your choice when the service ends, and deletes existing copies unless the law requires it to keep them, Article 28(3)(g)
• gives you the information needed to demonstrate Article 28 has been met, and allows and contributes to audits, Article 28(3)(h)

(a)

Only on your documented instructions

(b)

Confidentiality from the people it lets near the data

(c)

The Article 32 security measures

(d)

The conditions on engaging another processor

(e)

Assists you with individuals' rights requests

(f)

Assists you with Articles 32 to 36

(g)

Deletes or returns the data at your choice, at the end

(h)

Gives you the information to demonstrate Article 28, and allows audits

Both the Irish and UK regulators publish walk-throughs of the same list: the DPC in its practical guide to controller-processor contracts, and the ICO clause by clause in its guidance on what needs to be included in the contract. Article 28 kept its number in the UK GDPR, so a DPA covering UK data is being measured against the same eight points.

The parts people skip

Most DPAs will have something under each of the eight headings. The differences that matter are usually in the detail of four of them.

Sub-processors

Under Article 28(2) a processor "shall not engage another processor without prior specific or general written authorisation of the controller", and where the authorisation is general, it has to tell you about intended additions or replacements and give you "the opportunity to object to such changes". Article 28(4) requires the same data protection obligations to be imposed on that sub-processor, and says the original processor "shall remain fully liable to the controller" for how the sub-processor performs.

In practice that turns into two questions. Is there a list of who else is involved, and is there a route by which you find out when it changes. A general authorisation with no notification mechanism gives you a right to object that you would have no way to use.

Data leaving the EU or the UK

Article 28(3)(a) already ties transfers to your documented instructions. Article 44 is the general principle: a transfer to a third country may happen "only if, subject to the other provisions of this Regulation, the conditions laid down in this Chapter are complied with by the controller and processor". So where a supplier processes or stores data outside the EU or the UK, the thing to look for is whether the document names the mechanism it is relying on, such as standard contractual clauses. How those mechanisms work is a subject of its own and not one to settle from a DPA.

How quickly you hear about a breach

Article 33(2) says the processor "shall notify the controller without undue delay after becoming aware of a personal data breach". Your own clock is tighter and more specific: Article 33(1) gives a controller "without undue delay and, where feasible, not later than 72 hours after having become aware of it" to notify the supervisory authority. Those 72 hours run on you, and in most cases they start with a message from your supplier. Article 33(2) does not put a number of hours on the processor, so whatever the contract says on that point is what you have to work with.

What happens to the data at the end

Article 28(3)(g) is a choice that belongs to you: at the end of the service the processor deletes or returns the data at the controller's choice, and deletes existing copies unless the law requires storage. The ICO's guidance is worth knowing on the practical edge of this. It accepts that data in backups or archives may not be deletable the moment a contract terminates, and says that provided appropriate safeguards are in place, such as the data being put beyond use, it may be acceptable for deletion to follow on the processor's next deletion cycle.

Security is the other place the detail varies, and legitimately so. Article 28(3)(c) requires the commitment to Article 32, and Article 32(1) asks for measures appropriate to the risk, listing pseudonymisation and encryption, the ability to keep processing systems confidential, available and resilient, the ability to restore access after an incident, and a process for regularly testing whether any of it works. The DPC's guide puts "detailed (technical) security provisions" among the terms that are not mandatory but may be added, so a short security clause is not automatically a defective one.

What signing it does not do

Signing a DPA does not move responsibility for your compliance onto your supplier.

This is the part most likely to be read as reassurance, so it is worth being exact. Article 5(2) states that "the controller shall be responsible for, and be able to demonstrate compliance with" the principles in Article 5(1). Article 24(1) requires the controller to implement measures "to ensure and to be able to demonstrate that processing is performed in accordance with this Regulation". Neither is satisfied by a countersignature.

The regulators say it in more direct terms. The ICO, on controllers using a processor: "A controller is primarily responsible for its own compliance and ensuring the compliance of its processors. This means that, regardless of the terms of the contract with a processor, the controller may be subject to any of the corrective measures and sanctions set out in the UK GDPR." The same page adds that the controller's responsibilities "do not end there" once a contract is in place, and that a processor's compliance should be checked on an ongoing basis. The DPC makes the parallel point about the GDPR's direct obligations: they "will apply to controllers and processors in addition to any contractual obligations which a controller and processor may be subject to under a data processing contract".

Two smaller things a signature also leaves undone. It covers that supplier and no other, so each processor is its own document. And it does not record itself anywhere: Article 30(1) requires a controller to maintain a record of its processing activities, including the categories of recipient the data is disclosed to, which is where a newly signed DPA becomes a line in your own paperwork. Article 30(5) narrows that duty for organisations under 250 people, though the exceptions to the narrowing are wide enough that a good many small businesses stay inside the obligation. That record is a topic in its own right.

If something looks wrong

Nothing above tells you whether to sign the document on your desk. That is a commercial and legal decision about your own business, and a blog post is not in a position to make it.

What the Article 28(3) list does give you is a set of questions with a source behind each one. Is the processing described in the document the processing that actually happens. Are sub-processors named, and will you hear about new ones in time to say something. If the data leaves the EU or the UK, is a mechanism named. What does it say about telling you there has been a breach, given the 72 hours that then run on you. What happens to the data when the relationship ends, backups included.

A supplier who answers those readily has told you something. So has one who cannot.

Keeping the record

The paperwork problem underneath all of this is that the answers live in your head or in an inbox, and the evidence someone asks for six months later has to come from somewhere.

That is what ComplyVox is for. You talk through the suppliers and systems you actually use, in your own words, and your in-house AI DPO turns that into the records and policies you are required to hold, in plain English, for you to review and approve. It is pre-launch, and you can join the waitlist.