A commenter in a discussion about custom software was sure we didn't even know what a DPA was. They reached that conclusion before asking what information the proposed app would store, whose accounts it would run in, or which companies would handle the data.
A DPA is a data processing agreement. It sets out what one organisation is allowed and required to do when it handles personal information for another. The European GDPR has specific rules for these agreements. Other places may use different terms and requirements, so I am using the EU version here rather than pretending one contract works everywhere.
Where do we fit?
Suppose a business hires us to build an app where its customers can see project updates and send messages. The business decides what information it needs. The app runs in the business's own accounts, including its Supabase account for the database. We build the app and help the business work out who should have access, which services receive information and what should happen to old records.
Under the GDPR, the business is generally the controller of its customers' information because it decides why that information is collected and used. Supabase handles information for the business, so it is a processor. The European Data Protection Board explains these roles.
Writing the code does not make us a controller of the business's customer records. If we build with made-up test records and do not handle the real records, we are not a processor of those records either. In that setup, the client does not need a DPA with us just because we built the app.
Support later needs its own answer. Adding a feature may be possible with test records and no access to live customer information. A particular bug might require us to see one real account. The business can approve limited access for that job and remove it afterwards. The EDPB gives an example where an IT consultant fixing a bug, with only incidental and very limited access to personal information, is not treated as a processor.
Ongoing support is different if it routinely involves access to real customer records. The same EDPB guidance treats general IT support with systematic access as processor work. If that is what the client hires us to do, we need a DPA with the client for that work. The question is what access the work actually involves, not whether our job title says “developer.”
Does the client have to sign a separate DPA with every service?
Look at the services an app might use. Supabase stores customer records. Cloudflare handles traffic to the app. Resend sends emails. The business's email marketing software holds its mailing list. If the app uses Mux for videos, that service may handle video files and information about viewers. These companies do different jobs, but several of them will handle personal information for the business.
The business needs a binding data processing agreement with each provider doing that kind of work. It does not necessarily need to contact each one and arrange a separate signing. Supabase's terms incorporate its DPA. Cloudflare, Resend and Mux also publish DPAs as part of their service agreements. The email marketing company's arrangement depends on which product the client uses.
When the client accepts an online service agreement that includes a DPA, that can be the formal agreement. The GDPR allows the contract to be in electronic form. It does not demand a separate PDF with two handwritten signatures. The EDPB recommends keeping clear evidence that the agreement is in force. A DPA sitting on a website is not enough by itself; it needs to be part of the terms the client actually accepted.
The client owns these service accounts, so the agreements are between the client and the providers. Supabase's DPA also links to a list of companies it uses to run its service. The client does not need to collect signatures from those companies; Supabase makes its own agreements with them.
We can help the client list the services that touch customer information and find the agreement for each one. That is a more useful job than sending them off to email every software company whose logo appears on the invoice.
What the agreement is for
Where the GDPR applies and a business uses a processor, their relationship needs a contract or another binding legal arrangement. It should describe what information the processor handles, why, and for how long. It should also cover security, other companies the processor uses, help with customer requests and what happens to the information when the service ends. The EDPB sets out those requirements.
Suppose a customer asks the business for a copy of the messages they sent through the app. The business may need help retrieving them. The supplier's DPA should say how it will help, so the business is not trying to arrange that while the customer waits.
When the business stops using a service, it may want its customer records returned and the supplier's copies deleted. Backups can hold copies too. The agreement should explain what happens to them and when.
What the agreement cannot do
A business can have every DPA in place and still collect information it does not need. It can leave old customer conversations in the system for years or give every employee access to every record. The contracts do not make those choices for the business.
The European Data Protection Board's small-business guide says businesses should collect only the personal information they need, keep it only as long as necessary, and protect it while they have it. The business has to decide what it needs. We can help build the app and set its permissions to match those decisions.
If a customer asks to have their information deleted, a supplier may be required to help. The business still needs to find that customer's records and work out which it can delete and which it must keep.
You can recite the GDPR at me all afternoon; eventually we still have to decide what is happening to the customer's information. And if you do not know who owns the accounts or who can open the live records, announcing “DPA” has not answered the client's question.