DPA vs Standard Contractual Clauses (2026)

A Data Processing Agreement (DPA) and Standard Contractual Clauses (SCCs) are often confused, and vendors sometimes treat one as if it did the other's job. They do not. A DPA governs how a processor handles personal data on a controller's behalf. SCCs make an international transfer of that data lawful. You frequently need both, and they sit inside one document. This guide explains what each does, what the law requires, and when you need one, the other, or both. ## What a DPA is and what GDPR Article 28 requires Under the GDPR, whenever a controller uses a processor to handle personal data, there must be a contract that meets Article 28. That contract is the DPA. It is required for the relationship itself, not for any transfer. Article 28 says the contract must set out the subject matter, duration, nature, and purpose of the processing, the types of personal data and categories of data subjects, and the obligations and rights of the controller. It must also bind the processor to a specific list of duties: - process personal data only on the controller's documented instructions;

• ensure people authorised to process it are under confidentiality obligations;
• take appropriate security measures under Article 32;
• not engage a sub-processor without authorisation, and flow the same obligations down to it;
• assist the controller with data subject requests and with its security, breach, and impact-assessment duties;
• delete or return the data at the end of the service; and
• make available the information needed to show compliance and allow audits. If you use any vendor that processes personal data for you, cloud hosting, a CRM, a payroll provider, an analytics tool, you need a DPA with Article 28 terms, whether or not any data leaves the country. ## What SCCs are and what they do SCCs are a different instrument with a different job. They are pre-approved clauses that provide the appropriate safeguards the GDPR requires before personal data is transferred outside the EEA to a country without an adequacy decision. They are a transfer mechanism. They answer the question "may this data lawfully leave the EEA for this country?" not the question "how must this processor handle the data?" The SCCs are covered fully on the dedicated SCCs page. The key point here is that SCCs only become relevant when there is an international transfer to a non-adequate country. If your processor is in the EEA, or in a country with adequacy, you may not need SCCs at all, but you still need a DPA. ## The core difference Put simply: - A DPA governs the processing relationship. It is required whenever a processor handles personal data for a controller, regardless of location. Its legal basis is Article 28.
• SCCs govern the cross-border transfer. They are required only when personal data is transferred to a country without adequacy. Their legal basis is the Chapter V transfer rules. One is about how data is handled; the other is about where it may go. A domestic EEA processing arrangement needs a DPA and no SCCs. A transfer to a vendor in a non-adequate country needs both. ## When you need one, the other, or both - Processor in the EEA (or an adequate country), data stays there: DPA yes, SCCs no.
• Processor in a non-adequate country (for example the US without a valid framework route, or India): DPA yes, SCCs yes.
• Controller-to-controller sharing across a non-adequate border: no Article 28 DPA (that is only for processors), but SCCs yes, using the controller-to-controller module.
• UK data to a non-adequate country: a DPA under UK GDPR plus the UK IDTA or the UK Addendum to the EU SCCs. The practical answer for most SaaS vendors serving EEA customers from outside the EEA is: both, in one document. ## How they fit together in one document In practice a single agreement usually carries everything. A typical vendor DPA contains the Article 28 processing terms in the main body, lists sub-processors and security measures in schedules, and attaches the SCCs (with the correct module and completed annexes) as an appendix that applies to any restricted transfer. The UK Addendum is attached too where UK data is involved. This keeps one signed document doing three jobs: the processing contract, the transfer mechanism, and the UK bridge. Because they overlap in subject matter, keep them consistent. The security measures described for Article 28 purposes should be the same measures set out in SCC Annex II. The sub-processor list should be the same one the DPA and SCC Annex III both rely on. Divergence between the body and the SCC annexes is a common and avoidable error. ## Common mistakes to avoid - Treating SCCs as a substitute for a DPA. SCCs do not contain the full Article 28 processing obligations; you need both.
• Treating a DPA as a substitute for SCCs. A DPA alone does not make an international transfer lawful.
• Signing SCCs for a purely domestic EEA arrangement where no transfer happens, which adds nothing.
• Letting the DPA security schedule and the SCC Annex II describe different measures.
• Forgetting the UK, so UK data has neither a UK GDPR DPA nor an IDTA or Addendum.
• Skipping the transfer impact assessment that must sit behind the SCCs.
• Not updating either document when sub-processors or data flows change. ## Keeping DPAs and transfer terms aligned across vendors Most companies have dozens of vendor DPAs, each with its own sub-processor list, security schedule, and transfer appendix, signed at different times. The risk is drift: a DPA with no SCCs where a transfer happens, an SCC annex that no longer matches the DPA body, a vendor whose sub-processors changed. Seeing that across the whole vendor set means reading each agreement and comparing the processing terms, the transfer mechanism, and the annexes. An AI contract workspace that extracts those details across your vendor contracts and flags gaps keeps the picture aligned. Adira drafts, reviews, and tracks contracts, including data processing and transfer terms, in one place. More at Adira. The guidance above stands on its own. ## Bottom line A DPA and SCCs are not alternatives. A DPA is the Article 28 contract that governs how a processor handles personal data, required whenever you use a processor, wherever it sits. SCCs are a transfer mechanism, required only when data crosses into a country without adequacy. Most cross-border SaaS arrangements need both, usually in one document, with the UK Addendum where UK data is involved. Keep the security measures and sub-processor lists consistent across the DPA body and the SCC annexes, and get specialist data protection advice for live arrangements.