Do you need a DPA for your contact form?
The Formward TeamFormward, Stockholm7 min read
If your contact form sends submissions to a third-party service, you almost certainly need a DPA for that contact form. A data processing agreement is the contract that the GDPR requires whenever one company processes personal data on behalf of another, and a contact form that posts to an external backend is a textbook case of exactly that relationship. This is a plain-English explainer of when the requirement bites, why, and what a good DPA actually contains so you can tell a real one from a token PDF.
Start with the roles, because the whole thing turns on them. Under the GDPR there are two relevant parties: the controller, who decides why and how personal data is processed, and the processor, who handles that data on the controller's instructions. When a visitor fills in your form, you are the controller. You decided to collect their name and message and what to do with them. The service that receives, stores, and emails you those submissions is your processor. It is handling personal data for your purposes, not its own.
Article 28 of the GDPR is explicit: whenever a controller uses a processor, that relationship must be governed by a contract. That contract is the DPA. So the question is not really do I need a DPA, it is am I sending personal data to someone who processes it for me. For a contact form, the answer is yes the moment the data leaves your own systems and lands in a tool you do not operate yourself. The form backend, and often the email provider and spam filter behind it, are all processors you need agreements with.
There is one case where you do not need a DPA, and it is worth naming so you do not over-engineer. If your form posts to your own server, stores data in your own database, and you never hand it to an outside service, there is no processor and no DPA, because you are processing your own data as controller. The instant you introduce a hosted form backend, a managed email API, or a third-party spam service, you have added a processor and the requirement comes back. Most teams do use one of those, which is why the practical answer is almost always that you need one.
People sometimes assume a contact form is too trivial to count. It is not. The GDPR does not have a smallness exemption for personal data. A name and an email address submitted through a form are personal data, full stop, and processing them on your behalf triggers the same Article 28 obligation as a thousand-record database. The volume changes your risk, not your obligation. A single contact form pointed at an external service still needs a DPA with that service.
So what does a good DPA actually cover? At minimum, the GDPR expects it to set out the subject matter and duration of the processing, its nature and purpose, the types of personal data and categories of data subjects, and the obligations of both parties. In human terms: it should say what data the processor handles, why, for how long, and what each side is on the hook for. If a document calls itself a DPA but never describes the actual processing, treat that as a warning sign.
A good DPA binds the processor to act only on your documented instructions. This is the heart of the controller-processor relationship: the processor should not decide on its own to use your visitors' data for its own purposes, such as training models or building marketing profiles, unless you have instructed or permitted it. If you read a DPA and find broad rights for the provider to use the data however it likes, you are not really the controller anymore, and that defeats the point of the agreement.
It should require confidentiality and appropriate security. The people at the processor who touch your data must be bound to confidentiality, and the processor must take suitable technical and organisational measures to protect it: encryption, access controls, the usual security hygiene. The DPA does not have to enumerate every control, but it should commit the processor to a real standard rather than vague assurances. Security is the part of a DPA that turns into an incident-response problem if it is hand-waved.
Sub-processors are where DPAs earn their keep, so read this section carefully. Your processor almost certainly uses its own processors, an email sender, a hosting provider, a spam service, and those become your sub-processors. A good DPA lists them or commits to maintaining a current list, requires the processor to flow the same obligations down to them, and gives you notice and a chance to object before new ones are added. This is also where data-transfer risk hides: if a sub-processor stores or routes data outside the EU, the clean EU story you thought you had can quietly break.
The DPA should commit the processor to help you meet your own obligations. That means assisting with data subject access requests, supporting you when a person asks for their data or its deletion, helping with breach notification, and notifying you promptly if it suffers a breach so you can meet your own reporting deadlines. A contact-form processor that gives you per-record export and delete is doing in software what this clause asks for on paper, which is a good sign the two are aligned.
It must say what happens when the relationship ends. On termination, a good DPA requires the processor to delete or return all the personal data it holds for you, and to delete existing copies unless law requires retention. You do not want a former vendor sitting on a copy of every contact submission you ever collected. The deletion-or-return clause is short but it is one of the most important, because it closes the loop on data you no longer control operationally but are still responsible for.
Finally, a good DPA gives you a way to verify, through audit rights or by the processor providing the information you need to demonstrate compliance. You will rarely exercise a full audit for a contact form, but the right to ask for evidence, and the processor's commitment to provide it, is what lets you answer a procurement questionnaire or a regulator honestly. A provider confident in its setup makes this easy rather than treating it as a threat.
In practice, a reputable form backend offers a DPA you can review and sign as part of onboarding, rather than something you have to chase. Formward, for example, stores submissions in the EU, keeps its sub-processors in the EU, and is built so the data-residency and deletion commitments in the DPA match what the system actually does. The agreement matters most when it describes real behaviour, not aspirations, so it is worth checking that the document and the architecture say the same thing.
The short version to take away: if your contact form sends personal data to any service you do not run yourself, you need a DPA with that service, no matter how small the form. When you read one, look for clear processing details, processing only on your instructions, real security and confidentiality, a managed and EU-aware sub-processor list, help with data subject requests and breaches, deletion on termination, and a way to verify. If those are present and they match what the product actually does, you have a DPA worth signing rather than a PDF worth filing.