What Is a Data Processing Agreement (DPA)?
**A Data Processing Agreement is the written contract required by GDPR Article 28(3) between a controller and a processor, setting out how the processor may handle personal data on the controller's behalf.** It is mandatory. Where a processor handles personal data for you and there is no such contract in place, the arrangement is non-compliant regardless of how carefully the vendor actually behaves. Most organisations have DPAs. Fewer have read them recently, and fewer still have checked them against what Article 28(3) actually requires. ---
What must a DPA contain?
Article 28(3) requires the contract to set out the subject matter, duration, nature and purpose of the processing, the type of personal data, the categories of data subjects, and the obligations and rights of the controller. It then requires the contract to stipulate that the processor:
- Processes personal data only on documented instructions from the controller, including on transfers to third countries • Ensures persons authorised to process the data are committed to confidentiality • Takes all measures required under Article 32 on security of processing • Respects the conditions in Article 28(2) and (4) for engaging sub-processors • Assists the controller, as far as possible, in responding to data subject requests • Assists the controller in meeting Articles 32 to 36, covering security, breach notification and impact assessments • At the controller's choice, deletes or returns all personal data at the end of the service, and deletes existing copies unless law requires storage • Makes available all information needed to demonstrate compliance and allows for and contributes to audits and inspections
If any of those is missing, the contract does not meet Article 28(3).
Which clauses actually deserve scrutiny?
Five, and they are not the ones that usually get negotiated.
Documented instructions. This is the clause that keeps a vendor from using your data for its own purposes. Read it against any language elsewhere in the agreement permitting use for "service improvement", analytics or model training. A processor doing that is acting as a controller for that processing, needs its own lawful basis, and should be telling you so.
Sub-processor changes. How much notice, through what channel, and what happens if you object. A clause allowing additions with no notice removes a right Article 28(2) intends you to have.
Breach notification timing. "Without undue delay" appears in the regulation, but your own 72-hour clock under Article 33 starts when you become aware. A processor allowed 14 days to tell you has effectively consumed your entire notification window.
Audit rights. Whether a third-party certification satisfies the obligation, or whether you retain the right to inspect. Blanket substitution of a certificate for any audit right is worth pushing back on for high-risk processing.
End of contract. Deletion or return, on whose choice, in what format, on what timescale, and covering backups. This clause is negotiated at the moment you care least and invoked at the moment you have least leverage.
Is a DPA the same as standard contractual clauses?
No, and they are frequently confused because they often arrive in the same document.
| DPA (Article 28) | SCCs (Chapter V) | |
|---|---|---|
| Purpose | Governs how a processor handles data | Provides a lawful transfer mechanism |
| Triggered by | Any processor relationship | Transfer to a third country |
| Form | Negotiated contract terms | Approved standard clauses |
| Needed together? | Often, yes | Only where a transfer occurs |
A DPA is needed whenever there is a processor. SCCs are needed on top of it when personal data is transferred to a country without an adequacy decision. Having SCCs does not discharge Article 28, and having a DPA does not make an international transfer lawful.
Does a signed DPA make the arrangement compliant?
No, and this is the most common misreading of Article 28.
Article 28(1) requires the controller to use only processors providing sufficient guarantees to implement appropriate technical and organisational measures. That is a due diligence obligation that sits on you, before and alongside the contract.
Practically, that means:
Assess before signing. Security posture, certifications, sub-processor chain, data locations, breach history.
Keep it under review. Guarantees given in 2022 are not evidence about 2026. Vendors change architecture, hosting and ownership.
Record it. The processor and the categories of recipients belong in your Record of Processing Activities.
A DPA in a folder, unread since signature, against a vendor nobody has assessed since onboarding, satisfies the paperwork and not the obligation.
What does this mean in a Salesforce estate?
Count the processors honestly. Most estates have more than the vendor list suggests.
Salesforce is a processor for the personal data in your org, with its own DPA and its own published sub-processor list.
Every connected app and integration that receives personal data is typically its own processor, needing its own DPA and its own assessment.
Data warehouses, backup tools, analytics platforms and support systems that pull CRM data are each processors, each with a chain behind them.
Managed packages need to be looked at individually. A package running entirely as Apex inside your org, with no external endpoint, does not receive personal data outside the Salesforce boundary, so there is no separate processing relationship to contract for. A package that calls out to a vendor-hosted service does transmit personal data externally, and that vendor is a processor requiring a DPA of its own. Both models are legitimate and they look identical on an AppExchange listing, so the question has to be asked directly.
Cloud Compliance products are the first kind. Processing runs as Apex inside your org and no customer data leaves the Salesforce boundary, so using them does not add a processor to contract with or a row to your Article 30 record. That removes paperwork for the privacy tooling specifically. It does not remove your DPA with Salesforce, or with any of your other integrations.
Key Takeaways
A Data Processing Agreement is the written contract GDPR Article 28(3) requires whenever a processor handles personal data on a controller's behalf. Without one, the arrangement is non-compliant regardless of how well the vendor behaves.
Article 28(3) lists eight specific things the contract must cover, from documented instructions through to what happens to the data when the contract ends.
The processor may only act on the controller's documented instructions. A vendor using your customer data for its own purposes, including training its own models, is acting as a controller and needs its own lawful basis.
The end-of-contract clause is the one most often skipped in review, and the one that matters at exactly the moment you have least leverage.
Having a DPA is not the same as the DPA being adequate. Article 28(1) also requires you to use only processors providing sufficient guarantees, which is a due diligence obligation on you.
Frequently Asked Questions
See how this works in your Salesforce org
30-minute demo tailored to your specific use case and data model.