What is a data processing agreement (DPA)?
The contract every European customer's lawyer asks for. Here is what it is and what your product has to back up.
Reviewed by Irfan Habib, Co-founder (engineering)
In short
A data processing agreement (DPA) is the contract required by Article 28 of the GDPR between a controller, the business that decides why personal data is used, and a processor that handles that data on its behalf. It sets out what is processed, why, how it is secured and which subprocessors are used.
Also called: DPA, Data processing addendum, Article 28 agreement
Who needs a DPA, and with whom?
If your app stores personal details about people in Europe or the UK, you are a controller, and every supplier that touches that data, your host, database, email and analytics providers, is a processor that needs a DPA with you. When you sell to businesses, you become their processor, and they will send you theirs to sign.
What must a data processing agreement contain?
The UK regulator, the ICO, summarises Article 28 as a set of details plus minimum terms. The details are the subject matter and duration of the processing, its nature and purpose, the types of personal data and categories of people, and the controller's obligations and rights. The minimum terms are below; the parties may add their own on top.
- The processor acts only on the controller's documented instructions, which can be any written form that can be saved, such as an email.
- Everyone who handles the data is bound to confidentiality.
- Security measures meeting Article 32, such as encryption, resilience, restoring access after an incident and regular testing.
- Subprocessors only with the controller's prior written authorisation, on equivalent terms, with the processor liable for them.
- Help with people's data rights, breach notification and data protection impact assessments.
- At the end, deleting or returning all personal data, at the controller's choice.
- Information and audits to show the processor complies.
What is a subprocessor under a DPA?
A subprocessor is a supplier your processor uses in turn. Under a general authorisation, the ICO says the processor must tell the controller about changes and let it object. For an app, that list is simply your infrastructure: where the database runs, who sends email, which AI models see user content. Ours is public at our subprocessors page.
How do you get a DPA with Supabase and other app vendors?
Many vendors build the DPA into their terms rather than sending one to sign. Supabase's addendum states that it supplements and forms part of its Terms of Service, and that accepting the agreement has the same effect as signing the EU Standard Contractual Clauses for international transfers. Check each supplier the same way and keep a copy of what applies.
What does a DPA require the product itself to do?
A DPA commits the product, not just the paperwork. The app has to delete a person's data on request everywhere it was copied, know which suppliers receive which data, have security measures you can describe accurately in the contract, and keep evidence for audits, such as a log of who touched what.
- Deleting a person's data on request, everywhere it was copied, including the end-of-contract deletion the ICO describes.
- Knowing which suppliers receive which data.
- Security measures you can describe accurately in the contract.
- Evidence for audits: an audit log of who touched what.
The common mistake is signing a customer's DPA that promises measures the app does not have. If you are unsure whether yours can delete a user everywhere or show who accessed their data, the production readiness check is a quick way to find out. This page is general information, not legal advice.
Common questions
Is a DPA a legal requirement?
Under the GDPR, processing by a processor has to be governed by a contract or other legal act meeting Article 28. So every supplier that handles personal data for you, such as your host or email provider, needs one with you. Most publish a standard DPA to accept online.
What is the difference between a controller and a processor?
The controller decides why and how personal data is used; the processor handles it on the controller's behalf and only on its documented instructions. Your app is usually a controller for its own users, and a processor when business customers put their own customers' data into it.
Do I need to sign a separate DPA with Supabase?
Usually not. Supabase's Data Processing Addendum states it supplements and forms part of its Terms of Service, and that accepting the agreement has the same effect as signing the EU Standard Contractual Clauses. Read it yourself, and check every other supplier in your stack the same way.
What happens to the data when a DPA ends?
The ICO's summary of Article 28 says the processor must delete or return all personal data at the controller's choice, and delete existing copies unless the law requires storage. Backups can be dealt with later if the data is put beyond use in the meantime.
Go deeper
Which rules your product actually has to meetGDPR, UK GDPR, CCPA, HIPAA, PCI DSS, SOC 2, ISO 27001 and the EU AI Act in plain words: who each applies to and what it means for a Lovable app.
Related terms
Read next
Sources
- Regulation (EU) 2016/679 (GDPR), Official Journal L 119, May 4, 2016
- European Data Protection Board: Guidelines 07/2020 on the concepts of controller and processor in the GDPR (July 2021)
- ICO: What needs to be included in the contract?
- Supabase: Data Processing Addendum
Sources checked October 24, 2026
More on this: Production architecture & security · All glossary terms
Built something in Lovable you want people to rely on?
We are the engineers who take it the rest of the way — secured, tested, released and supported.
