GDPR Article 28: processor due diligence and the DPA checklist

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. If you only need the list, jump to the GDPR Article 28 checklist. The DPA clauses, the standard contractual clauses and transfer impact assessment, and the sub-processor checks each have their own section. This guide is general information, not legal advice; for a processing operation with real legal exposure, ask a data protection lawyer to review the contract.

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 organizational 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 authorization, 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 the eight terms in points (a) to (h). Here they are clause by clause, with what to look for when the vendor sends its own DPA:

Article 28(3) closes with one more duty: the processor must immediately tell the controller if, in its opinion, an instruction infringes data protection law. Look for it alongside (h).

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 authorization 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.

The rest of Article 28, briefly

• Art. 28(4): the processor must impose the same data protection obligations on any sub-processor by contract, and remains fully liable to you for the sub-processor’s performance.
• Art. 28(5): a processor’s adherence to an approved code of conduct (Art. 40) or certification (Art. 42) may be used as an element to demonstrate sufficient guarantees.
• Art. 28(6) to (8): the contract may be based on standard contractual clauses. The European Commission adopted a set for controllers and processors in Implementing Decision (EU) 2021/915. These are different from the international transfer SCCs in Decision (EU) 2021/914.
• Art. 28(9): the contract must be in writing, which includes electronic form. A click-through DPA counts.
• Art. 28(10): a processor that determines the purposes and means of processing itself is treated as a controller for that processing.

The UK GDPR keeps Article 28 in the same form, so a UK controller runs the same checks; the transfer tools differ (see below).

Sub-processors

Nearly every processor uses sub-processors: hosting, email delivery, support tooling. Article 28(2) allows either specific authorization for each one or a general authorization with a right to be informed of changes and to object. General authorization 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 organizations, 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.

GDPR Article 28 checklist

Work through this for each processor, in this order. Every line is either a check you make before personal data is shared or a term the DPA must contain; together they are what the file should show if a supervisory authority or a customer asks.

Before any personal data is shared

• Confirm the vendor acts as your processor for this processing, not as a controller in its own right (Art. 28(10)) or a joint controller (Art. 26)
• Name the contracting legal entity, and confirm it is the entity that will process the data
• Describe the processing: subject matter, duration, nature and purpose, types of personal data and categories of data subjects
• Record whether the data includes special-category data (Art. 9), data about children, or data about people in the EU or UK
• Assign a risk tier based on the data's sensitivity and volume, and record why
• Assess sufficient guarantees (Art. 28(1)): security measures, data handling, sub-processors, transfers, breach handling and support for data subject rights, in proportion to the tier
• Obtain the evidence the tier calls for, such as a SOC 2 Type II report or ISO 27001 certificate with scope, a completed questionnaire, and the processor's sub-processor list, and record your conclusion with a date
• Where the processor is not established in the EU or UK but Article 3(2) applies, note whether it has an Article 27 representative and, where Article 37 applies, a data protection officer

In the data processing agreement (Art. 28(3))

• The processing description above is in the contract, with the controller's obligations and rights
• (a) Processing only on your documented instructions, including on international transfers
• (b) Everyone authorized to process the data is bound by confidentiality
• (c) The security measures required by Article 32, described specifically enough to assess
• (d) No sub-processor without your prior written authorization; notice of changes, a right to object, and the same obligations flowed down (Art. 28(2) and (4))
• (e) Help responding to data subject requests
• (f) Help with security, breach notification, DPIAs and prior consultation (Arts. 32 to 36), with a breach notice period in hours
• (g) Deletion or return of all personal data at the end of the service, at your choice
• (h) All information needed to demonstrate compliance, and audit and inspection rights
• The processor must tell you immediately if an instruction would infringe data protection law
• The contract is in writing, which includes electronic form (Art. 28(9))
• Audit and liability wording does not make a real audit impossible: a clause that offers only the processor's own summary, with no path to further review, fails (h)
• The description of the processing in the DPA matches the data you will actually send, not a generic 'customer data' line

After signature

• A transfer mechanism is recorded for every processor or sub-processor outside the EEA or UK: adequacy (including a checked Data Privacy Framework certification), SCCs, or the UK IDTA or Addendum
• Where SCCs or another Article 46 tool are the mechanism, a transfer impact assessment is on file, with the supplementary measures you adopted and a date to revisit it
• Your Article 30 record lists the processor as a recipient, with any third-country transfers and the safeguard used
• You are subscribed to sub-processor change notices, and each one triggers the sub-processor checks below
• A next review date is set by tier, with triggers for an earlier one: a sub-processor change, a transfer-mechanism change, a breach, a change in the data you share, or expiry of a report you relied on

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.

DPA clauses, in the words to look for

The table above says what each point of Article 28(3) requires. This is the same list as clause language: what a sentence in the vendor’s DPA has to commit to, so you can mark a gap instead of accepting “we are GDPR compliant” as a term. It is a reading aid, not a template to paste. The European Commission’s own controller and processor clauses are in Implementing Decision (EU) 2021/915; those are different from the transfer clauses in Decision (EU) 2021/914, covered below. A DPA can be the vendor’s paper or yours. Either way, these are the commitments.

When a term is missing or weaker than this, record the gap, what you did about it (a negotiated change, a compensating control, or a decision not to use the vendor), and who accepted that. A signed DPA with a silent gap is not the same as a complete one.

Standard contractual clauses

If personal data moves to a country without an adequacy decision, Article 46 requires a transfer tool. The one processors use most is the European Commission’s standard contractual clauses adopted on 4 June 2021 by Implementing Decision (EU) 2021/914. There are four modules. Pick the one that matches the parties, and do not treat a module as optional wording:

The clauses have to be used without contradicting them. A DPA that says the processor may refuse an audit, or that local law always prevails over the clauses, fights the SCCs. The annexes have to be filled in: the parties, the description of the transfer, and the technical and organisational measures. Blank annexes are not SCCs.

Two other routes replace the SCCs for that transfer, and should be named in the file when they are the ones you rely on:

• An adequacy decision that covers the recipient. For the United States, that is the EU-US Data Privacy Framework for an organisation on the public certification list, for the data the certification covers. Check the list. A parent company’s certification does not cover an uncertified subsidiary.
• The UK tools, for a UK GDPR transfer. The UK Extension to the Data Privacy Framework (the data bridge), the International Data Transfer Agreement, or the UK Addendum to the EU clauses. The Article 28 analysis is the same; the transfer paper is not. Definitions of SCCs and the transfer impact assessment are in the glossary.

Decision (EU) 2021/915 is easy to mix up with 2021/914. 2021/915 is a set of Article 28 clauses for the controller-processor contract inside the EEA. Signing it does not authorise a transfer to a country without adequacy. If the vendor’s pack contains both, record which document does which job.

Transfer impact assessment

Since the Court of Justice’s judgment in Schrems II (C-311/18, 16 July 2020), signing SCCs is not the end of the transfer question. You have to assess whether the law and practice of the destination country stop those clauses from giving the data essentially equivalent protection, and adopt supplementary measures where they do not. The European Data Protection Board’s Recommendations 01/2020 set out the steps. Clause 14 of the 2021 SCCs requires the parties to warrant that they have done this. Call the record a transfer impact assessment or a transfer risk assessment; the UK ICO uses the second name for its own tool. The work is the same.

A proportionate assessment for one vendor, written so someone else can follow it:

• Map the transfer: what data, whose, to which legal entity, in which country, and for what purpose. Include every sub-processor that stores or accesses it, not only the vendor you pay
• Name the transfer tool for each hop: an adequacy decision (and, for the Data Privacy Framework, the certification entry you checked), SCCs with the module, the UK IDTA or Addendum, or a conclusion that the data does not leave
• Where the tool is SCCs or another Article 46 safeguard, assess the destination laws that could compel disclosure or frustrate your rights, using the vendor's own assessment as an input and recording where you disagree
• Decide the supplementary measures the case needs: encryption the destination party cannot defeat, pseudonymisation before the transfer, access split so no one party sees the content, or a decision not to send that data
• Record the conclusion, the date, the reviewer, and when it will be looked at again. A change of country, of sub-processor, or of the adequacy position is a reason to reopen it before that date

You do not need a transfer impact assessment for a transfer that rests on an adequacy decision which applies to that recipient. You do need one for every hop that rests on SCCs, including a sub-processor’s Module 3 clauses. Ask the processor for its assessment and for the supplementary measures it already applies, then write your own conclusion. Their memo is evidence. It is not your assessment.

Sub-processor checks

A sub-processor is a processor your processor engages to process personal data on your behalf: the cloud host, the email delivery service, the support desk that can open a ticket containing the data. Article 28(2) forbids that engagement without your prior specific or general written authorisation. Article 28(4) requires the same data protection obligations to be imposed on the sub-processor by contract, and leaves your processor fully liable to you for what the sub-processor does. Fourth parties that never see personal data are a different question; this check is about the ones that do.

General authorisation is the usual SaaS position and is lawful, provided you are told of intended changes in time to object. Read the notice period. A notice that arrives the day the new sub-processor goes live is not a chance to object. Subscribe to the list, and keep the message that proves you subscribed.

For each sub-processor that matters at the vendor’s tier, record:

• Legal name, what it does for this service, and the categories of personal data it can access
• Where it processes, and whether that is a country with an adequacy decision or a transfer that needs SCCs and a transfer impact assessment
• Whether your authorisation is specific to this party or general, and where that authorisation is written
• The notice period for a change, the address the notice comes to, and how an objection is raised
• That the processor's contract with the sub-processor imposes the Article 28 obligations, which the processor should be able to confirm even when the contract itself is confidential
• Security evidence proportionate to the tier: for a host holding the data, the same kind of report you asked of the processor; for a narrow tool, the processor's own assessment of it may be enough, if you record why
• The date you reviewed this list, and the date of the list itself. A list with no date is not a list you can rely on later

A change notice is a short review, not a new project: who is the new party, where are they, does the transfer position change, do you object. Record the answer either way. Objecting has a consequence the DPA should already describe, usually a right to stop the affected processing or to exit. Know which one you have before you need it.

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 vendor management: meeting Annex A 5.19 to 5.23 with evidence, describe what those reports actually show. To fit the privacy checks into onboarding as a whole, use Vendor onboarding checklist: the checks to finish before the contract is signed or the step-by-step vendor vetting process. If the vendor uses AI on personal data, add the questions in AI vendor due diligence: a checklist for vendors that use AI on your data; for US health data, see HIPAA vendor risk assessment: vetting business associates under the Security Rule.

VendorVett includes a GDPR Article 28 processor questionnaire on every plan, including the free plan. It asks the processor about sufficient guarantees, the Article 28(3) terms, sub-processors and international transfers. You can attach the DPA, the sub-processor list, the SCCs and a transfer impact assessment as evidence next to a dated conclusion. Scores come from the answers, through the same deterministic engine as every other questionnaire, and the record sits in a tamper-evident audit trail. See pricing. Terms such as sub-processor, SCCs and TIA are defined in the glossary.