Data Processing Agreement (DPA): Article 28 GDPR Guide

A Data Processing Agreement (DPA) is the contract that GDPR Article 28 requires between a controller and a processor. Without it, transferring personal data to a third-party service is unlawful regardless of how trustworthy the service is. The DPA is the legal scaffolding that turns "we trust this vendor" into "we are GDPR-compliant in our use of this vendor".

This guide covers when a DPA is needed, the eight subjects every DPA must address, how to recognise a compliant vendor offering, what to do when a vendor refuses to provide one, and how the European Commission's Standard Contractual Clauses for processors fit in.

The basic test: is this service a processor?

A processor is a natural or legal person, public authority, agency or other body that processes personal data on behalf of the controller. Three signals indicate a processor relationship:

• The service receives or accesses personal data that the controller has collected
• The service processes that data for purposes determined by the controller
• The service does not determine its own purposes for that data beyond what the contract permits

Most third-party services that a website connects to are processors. A short list of recurring patterns:

The classification matters because it determines the contract type. Processors need Article 28 DPAs. Independent controllers need Article 26 joint-controller arrangements or simply a documented controller-to-controller relationship.

What Article 28(3) requires the DPA to cover

Article 28(3) GDPR sets out eight subjects that the processor contract must address. A DPA missing any of them is non-compliant on its face, regardless of how strong the rest of the contract is.

1. Subject matter and duration of the processing
2. Nature and purpose of the processing
3. Type of personal data and categories of data subjects
4. Obligations and rights of the controller

Plus six processor-specific obligations:

5. Process only on documented instructions from the controller, including for international transfers (Art. 28(3)(a))
6. Ensure persons authorised to process are bound by confidentiality (Art. 28(3)(b))
7. Implement appropriate security measures under Article 32 (Art. 28(3)(c))
8. Engage sub-processors only with prior authorisation of the controller, and impose the same data protection obligations on them by contract (Art. 28(3)(d) + 28(4))
9. Assist the controller in fulfilling data subject rights under Chapter III (Art. 28(3)(e))
10. Assist the controller with breach notification, DPIAs and prior consultation under Articles 32 to 36 (Art. 28(3)(f))
11. Delete or return all personal data at the end of the provision of services, at the controller's choice (Art. 28(3)(g))
12. Make information available to demonstrate compliance and submit to audits (Art. 28(3)(h))

If you cannot find each of these in the DPA you signed, you do not have a compliant DPA.

How reputable vendors structure their DPAs

Most enterprise vendors offer a single click-to-accept DPA that incorporates the eight subjects above. The acceptance is then recorded in the account audit log. Workflow varies by vendor:

• Stripe: Data Processing Addendum accepted from the Stripe Dashboard under Settings > Compliance. Effective immediately upon acceptance.
• Google Workspace / Google Analytics: Data Processing Amendment auto-accepted on account creation; specific terms link from the admin console.
• Cloudflare: Cloudflare Data Processing Addendum accepted from the dashboard or signed offline by enterprise customers.
• Mailchimp / Intuit Mailchimp: DPA available from the Compliance page in the user portal; click-to-accept.
• HubSpot: Data Processing Agreement linked from the customer terms; auto-accepted with the master subscription agreement.
• Notion: Data Processing Addendum accessible from the workspace settings; click-to-accept for Business and Enterprise plans.

The acceptance event is your proof of compliance. Take a screenshot or download the executed PDF and archive it. Without proof of acceptance, you have no defence against an Article 28 inspection.

What to do when a vendor refuses

Sometimes a small vendor has no DPA at all and refuses to sign one. Three options:

1. Replace the vendor with one that offers a compliant DPA. Almost always the right move.
2. Use the Commission's Standard Contractual Clauses for processors (Implementing Decision 2021/915, 4 June 2021) and ask the vendor to sign. Some smaller vendors accept the SCC template because it removes drafting cost.
3. Stop sending personal data to the vendor. If the function can be performed without personal data (e.g. an internal tool used only with synthetic test data), the obligation does not arise.

What is not an option: continue using a non-compliant vendor in production. Even if no one complains, the inspection risk does not go away; on the contrary, processors with no DPA tend to become the first focus when a controller is inspected for other reasons.

The Commission's Standard Contractual Clauses

Commission Implementing Decision (EU) 2021/915 of 4 June 2021 adopted Standard Contractual Clauses for controller-to-processor contracts that satisfy Article 28(3) and (4). These are different from the Decision 2021/914 SCCs for international transfers; both share the "SCC" abbreviation but they cover distinct gaps.

When to use the Decision 2021/915 SCCs:

• The vendor has no compliant DPA of its own
• You want a clean, regulator-recognised baseline
• The vendor accepts the template without modification

The SCCs come with annexes that the parties fill in: description of the processing, categories of data and data subjects, technical and organisational measures, list of sub-processors. The annexes are where the contract becomes concrete; the boilerplate clauses are not negotiable.

Sub-processors: chain-of-custody

Article 28(2) requires prior written authorisation of the controller before the processor engages a sub-processor. Most vendor DPAs operationalise this as "general authorisation": the controller authorises the processor's current list of sub-processors and any future additions, with the right to object within a notice period.

Practical implications:

• Ask each vendor for their current sub-processor list at onboarding
• Subscribe to the sub-processor notification mailing list if the vendor offers one
• Document in your record of processing activities the sub-processors involved in each tool
• If a vendor adds a sub-processor in a high-risk jurisdiction, evaluate the international transfer mechanism before the change takes effect

Common mistakes

No DPA in place at the start of processing. Adding the DPA after processing has begun does not cure prior non-compliance. Sign before integration, not after.

Click-to-accept lost on staff turnover. The DPA was accepted by a previous administrator and no one knows where the record is. Archive the acceptance event in a place that survives staff changes.

DPA addresses some but not all Article 28(3) subjects. Especially common: missing audit clause, missing sub-processor authorisation, missing return-or-delete clause.

Sub-processor list outdated. The vendor has added three new sub-processors since onboarding and the controller's record of processing activities still shows the original list.

Processor doubles as independent controller for marketing. Some vendors process the controller's data both as processor (for the controller's use of the service) and as independent controller (for their own analytics and product development). The DPA must clearly distinguish; the controller cannot legitimise the second processing on the basis of the Article 28 DPA alone.

Free-tier vendor with no DPA. A small organisation onboards a free analytics or email tool that has no DPA. The free price tag does not exempt the vendor from Article 28; if no DPA is available, the tool cannot be used in production.

Practical onboarding workflow

For each new third-party service that will receive personal data:

1. Identify the processing role (processor, joint controller, independent controller)
2. Locate the vendor's DPA in their documentation
3. Verify the DPA covers the eight Article 28(3) subjects
4. Accept the DPA and archive proof of acceptance
5. Note the international transfer mechanism (adequacy, SCCs, BCRs)
6. Add the vendor to the record of processing activities under Article 30
7. Add the vendor to the privacy notice recipients list
8. Subscribe to sub-processor change notifications

For the broader compliance map of which obligations apply to your site, the GDPR compliance checklist and the GDPR website audit checklist cover the controls that surround the DPA. The privacy policy generator helps surface the processor disclosure in the privacy notice.

Final checklist

• Inventory of every third-party service that receives personal data
• DPA in place for each processor before processing begins
• DPA covers all eight Article 28(3) subjects
• Proof of acceptance archived and accessible to current staff
• Sub-processor list current and reflected in record of processing
• International transfer mechanism noted per processor
• DPA review scheduled at least annually
• Process to evaluate new vendors before procurement, not after

---

This is technical analysis, not legal advice. For enterprise SaaS contracts with custom processing terms, regulated industries with sector-specific processor rules, or active supervisory authority investigations, consult a lawyer who specialises in data protection.