GDPR processor due diligence: vetting vendors that handle personal data

Under the GDPR, a controller does not outsource responsibility along with the data. If your email provider, your CRM, your payroll service or your analytics vendor processes personal data on your behalf, Article 28 makes you answerable for having chosen them carefully, contracted with them properly, and kept watching. The regulators’ enforcement record shows they mean it.

This guide explains what Article 28 actually requires of a controller, what the “sufficient guarantees” test looks like as a practical assessment, what the contract must contain, how to handle sub-processors and international transfers, and how to document all of it so the file answers a supervisory authority’s questions.

What Article 28 requires of you

Four obligations sit with the controller.

1. Choose carefully — Art. 28(1). Use only processors providing sufficient guarantees to implement appropriate technical and organisational measures. This is the due diligence obligation, and it applies before the first byte is shared.
2. Contract properly — Art. 28(3). Processing must be governed by a contract (or other legal act) that is binding on the processor and contains the terms the Article lists. This is the data processing agreement.
3. Control sub-processors — Art. 28(2) and (4). The processor may not engage another processor without your prior specific or general written authorisation, and must flow the same obligations down to them.
4. Keep it under review — Art. 24 and 28(3)(h). Your measures must be reviewed and updated where necessary, and the contract must give you the information and audit rights to do so.

The “sufficient guarantees” test in practice

The Regulation does not define sufficient guarantees. Recital 81 says the controller should consider the processor’s expert knowledge, reliability and resources, and that adherence to an approved code of conduct or certification mechanism may be used to demonstrate compliance. The European Data Protection Board’s guidelines on controllers and processors add that the assessment should be proportionate to the risk of the processing, and that the controller should be able to show it was done.

A defensible assessment, proportionate to a small or mid-sized controller, covers six areas:

Scale the depth to the risk. A processor handling employee health data or large volumes of customer records warrants evidence in every row. A processor that sees business contact details for a newsletter warrants their public security page, their DPA and their sub-processor list. Record the tier and the reasoning either way; see Vendor risk tiering: how to classify third parties and set a review cadence for criteria.

What the contract must contain — Art. 28(3)

The DPA must set out the subject matter and duration of the processing, its nature and purpose, the type of personal data and categories of data subjects, and the controller’s obligations and rights. It must then bind the processor to eight things:

• (a) Process only on the controller's documented instructions, including for transfers, unless required by law — and tell you if the law requires it.
• (b) Ensure persons authorised to process the data are bound by confidentiality.
• (c) Take all measures required by Article 32 (security of processing).
• (d) Respect the conditions for engaging sub-processors in Art. 28(2) and (4).
• (e) Assist the controller, by appropriate technical and organisational measures, in responding to data subject requests.
• (f) Assist the controller in meeting Articles 32–36: security, breach notification, DPIAs and prior consultation.
• (g) At the controller's choice, delete or return all personal data at the end of the service, and delete existing copies unless law requires storage.
• (h) Make available all information necessary to demonstrate compliance, and allow for and contribute to audits and inspections.

Most SaaS processors offer their own DPA. Read it against the list above rather than assuming it is complete; the clauses most often weakened are (d) — general authorisation with no notice period or objection right — and (h) — audits limited to reading the processor’s own reports. Where a term is missing or weak, log it as a condition of the assessment with the compensating step you took.

Sub-processors

Nearly every processor uses sub-processors: hosting, email delivery, support tooling. Article 28(2) allows either specific authorisation for each one or a general authorisation with a right to be informed of changes and to object. General authorisation is standard and workable, provided the DPA gives a notice period long enough to review the change, and the processor actually notifies. Subscribe to the processor’s sub-processor update mechanism and treat a notification as a trigger for a short review: who is the new party, where are they, does it change the transfer position.

International transfers

If a processor or any sub-processor is outside the EEA (or the UK, for UK GDPR), Chapter V applies. The assessment needs to establish the mechanism: an adequacy decision for the destination country (which includes the EU–US Data Privacy Framework for certified US organisations, and the UK extension to it), or Standard Contractual Clauses — the 2021 EU set, or the UK International Data Transfer Agreement or Addendum — supplemented by a transfer impact assessment of the destination country’s laws, as required since the Schrems II judgment. Ask the processor which mechanism they rely on and for their transfer impact assessment where SCCs are used; record the answer and your own conclusion.

Documenting the assessment

Accountability (Art. 5(2)) means being able to demonstrate compliance, not merely being compliant. For each processor, the file should contain:

• the processing description: what data, whose, for what purpose, where;
• the risk tier and the reasoning;
• the assessment: what was reviewed across the six areas above, the evidence obtained, and the conclusion, with the reviewer and date;
• the DPA, checked against Art. 28(3), with any gaps and how they were addressed;
• the sub-processor list as at the date of assessment, and the transfer mechanism for each relevant party;
• the next review date, and the triggers for an earlier one.

If a supervisory authority asks how you satisfied yourself that the processor offered sufficient guarantees, that file is the answer. Without it, the question is hard to answer convincingly after the fact.

Reassessing

Reassess on a cadence tied to the tier, and on any of these triggers: a sub-processor change, a change of transfer mechanism (an adequacy decision withdrawn or granted), a breach at the processor, a change in the data you share, or the expiry of the certification you relied on. A reassessment can reuse most of the earlier file; what it needs is fresh evidence, a fresh conclusion and a new date.

Where to go next

The privacy assessment above is one part of the broader process in Vendor due diligence: a practical guide for small and mid-sized businesses, and the questions map into the questionnaire described in Vendor risk assessment questionnaire: what to ask, and how to score the answers. For the security controls a processor should evidence under Article 32, the SOC 2 and ISO 27001 guides — SOC 2 vendor management: what auditors expect from your third-party programme and ISO 27001 supplier relationships: meeting Annex A 5.19–5.23 with evidence — describe what those reports actually show.