GDPR for contact forms: the ten-minute compliance guide nobody wrote

Every time I look up "contact form GDPR" I find the same three articles. One is a law firm begging me to book a consultation. One is from 2018 and thinks Brexit is still news. One is an SEO page for a plugin that charges €49/month to add a checkbox.

None of them just tell you what to do.

So here it is. This is the plain-English version I wish I'd had the first time I shipped a contact form into the EU. I'm not a lawyer. I've read the regulation, I've been audited twice, I've shipped forms for clients in five EU countries, and I'm going to tell you what actually matters and what's noise.

If you want the two-minute version: a contact form is low-risk personal data collection. You need a privacy policy link, a lawful basis, clear purpose, and the ability to delete submissions on request. Most of the scary stuff in the regulation is aimed at people running ad networks and profiling users at scale. You're not doing that. Relax.

Here's the full checklist.

1. Pick a lawful basis — and it's not consent

The single most common GDPR mistake I see on contact forms is a "I consent to you processing my data" checkbox next to the submit button. People think consent is the safe choice because it sounds official. It is almost never the right choice for a contact form.

GDPR gives you six lawful bases for processing personal data. For a contact form, the correct one is usually legitimate interest (Article 6(1)(f)) or sometimes performance of a contract (6(1)(b)) if the form is a "request a quote" or "book a call" page.

Why not consent?

• Consent must be freely given, specific, informed, and revocable.
• If you make consent mandatory to submit the form, it's no longer "freely given" — the regulation is explicit about this.
• You then have to honour revocation, which means storing proof of consent and deleting on request with an audit trail. For a contact form. This is overkill.
• Legitimate interest is the boring, normal, correct answer for "someone is asking me a question and I want to reply."

What to actually do: remove the consent checkbox. In your privacy policy, state that contact form submissions are processed under legitimate interest for the purpose of responding to the enquiry. Done.

2. Your privacy policy needs three specific sentences

Open your privacy policy. Find the section on contact forms. If it doesn't exist, add one. It needs to say three things:

1. What you collect. "When you submit our contact form, we collect your name, email address, and the content of your message."
2. Why. "We process this data to respond to your enquiry under the legitimate interest basis of GDPR Article 6(1)(f)."
3. How long you keep it and how to delete it. "We retain contact form submissions for 24 months, after which they are automatically deleted. You can request earlier deletion by emailing privacy@yoursite.com."

Those three sentences, written plainly, cover the vast majority of what Article 13 and Article 14 actually require of a contact form. Your privacy policy will have other sections for cookies, analytics, and anything else — I'm just talking about the contact form part.

The sentences matter more than the legalese around them. An auditor wants to see that a normal person visiting your site could understand what you're doing with their data. Plain language wins.

3. Link the privacy policy near the form

The standard way to do this is one line of text below the submit button:

By submitting this form, you agree to our Privacy Policy. We'll only use your details to reply to your message.

No checkbox. No "I have read and accept" theatre. A visible link. That satisfies the "informed" part of the regulation. The reason checkboxes are everywhere is that cookie banners legally require opt-in consent for tracking, and people confuse that requirement with form submissions. They're different legal bases for different kinds of data.

4. Data processing agreement (DPA) with your form backend

This is the part most DIY builders miss entirely, and it's the one a GDPR audit will nail you for.

If you use any third party to process contact form data — and you do, unless the form submits to a server in your house — that third party is a data processor. You are the data controller. GDPR requires a written contract between controller and processor, called a Data Processing Agreement.

What you need:

• A signed DPA with your form backend (every serious vendor provides one; some require you to sign it explicitly, some include it in the terms of service by reference).
• A signed DPA with your email provider (Postmark, Mailgun, etc.).
• A signed DPA with your CRM or automation platform if you webhook to one.

What to check for in a DPA:

Item	What it should say
Data location	Where submissions are stored. "EU" is simplest. US with SCCs is acceptable. Vague is not.
Sub-processors	A list of the vendor's own vendors. Should be published and updateable with notice.
Breach notification	How quickly they'll tell you if something leaks. 24–72 hours is standard.
Deletion on request	How you request deletion of a specific user's data and how fast they comply.
Audit rights	You should be able to request an audit or see a SOC 2 report in lieu of one.

If a vendor can't show you a DPA, don't use them for EU traffic. FormTo publishes ours openly and the data stays in the EU by default — that's one of the reasons I joined. It's also why I get unreasonably annoyed when form vendors make compliance teams chase them for basic paperwork.

5. Data residency: where are submissions actually stored?

GDPR doesn't require your data to stay in the EU. It requires that if it leaves the EU, there are legal safeguards in place — currently Standard Contractual Clauses (SCCs) plus a transfer impact assessment. For most vendors in the US, that's the post-Schrems II reality, and it works, but it's paperwork.

The simpler approach, if your users are EU-based, is to pick a vendor that stores data in the EU and never transfers it. Then the question doesn't apply. You skip the TIA. You skip the SCC attachments. You just tick a box in your privacy policy that says "we store your data in the EU" and move on.

If you're on a US-based form vendor and you have EU users, you need to either:

1. Move to an EU vendor, or
2. Make sure your vendor has a signed SCC package and you can articulate why the transfer is safe.

"Most sites ignore this" is not a defence. It's a calculated risk. Know which one you're taking.

6. Data retention — actually delete old submissions

GDPR's Article 5(1)(e) requires you to keep personal data only as long as necessary. For contact forms, "necessary" means roughly "long enough to have the conversation and follow up if needed."

My rule of thumb:

• 24 months is a reasonable default for most small and mid-sized sites.
• 12 months is better if you can get away with it.
• "Forever" is not a retention policy. It's a liability.

Set this up once. Most hosted form backends let you set a retention policy that auto-deletes submissions after N months. FormTo has this in the form settings. Formspree has it on higher plans. If yours doesn't, you're going to forget to delete things manually, and that's exactly the kind of sloppy behaviour regulators notice.

7. The "right to be forgotten" request flow

At some point, someone is going to email you and ask you to delete their contact form submission. Maybe two people in two years. Maybe more.

You need:

• A clear email address in your privacy policy where these requests go (privacy@, dpo@, or just hello@ if you're small — the point is that it reaches a human).
• A process for finding their submission in your backend. This is where "search" functionality in your form dashboard genuinely matters.
• The ability to delete that one submission without nuking everything.
• A reply within 30 days confirming deletion. 30 days is the legal maximum. Good hygiene is under 7.

One tip: keep a small log of deletion requests you've handled, with dates and what you deleted. Not for surveillance — for your own defense if anyone ever asks "did you actually process the request I sent you in April?"

8. Minimise what you collect

This is both the easiest GDPR principle to follow and the one most sites blow. GDPR Article 5(1)(c): "adequate, relevant and limited to what is necessary."

Translation: every field on your contact form you don't strictly need is a compliance risk. A 14-field contact form is not just bad UX — it's collecting data you don't have a legitimate basis to process, and every one of those fields is a small fine waiting to happen if a regulator ever takes notice.

For a contact form, "necessary" means:

• Name (so you can reply personally)
• Email (so you can reply at all)
• Message (obviously)
• Optional: a category/subject line if you route to different teams

Company name, phone number, job title, budget range, company size, "how did you hear about us" — none of these are necessary for a contact form. They might be necessary for a demo request form, in which case make a separate page with its own stated purpose and privacy notice. Don't conflate "someone has a question" with "we're qualifying a sales lead."

9. Children's data

If your site might be used by anyone under 16, you have extra obligations under Article 8. For most B2B sites this is a non-issue. For consumer sites, add a line: "Our service is not directed to children under 16. Please do not submit contact forms on behalf of minors."

That line doesn't fully protect you if you actively target kids. It does protect you from accidentally collecting a teenager's data once and panicking about it.

10. The audit-ready checklist

Print this. Tape it to your monitor. Run it once a quarter.

• Privacy policy names contact form data specifically
• Privacy policy states lawful basis (legitimate interest)
• Privacy policy states retention period
• Privacy policy lists deletion email contact
• Privacy policy linked near/below the submit button
• No mandatory consent checkbox (unless you genuinely need one)
• Signed DPA with form backend
• Signed DPA with email provider
• Signed DPA with any webhook destination (CRM, Zapier, etc.)
• Data residency documented (EU or SCCs in place)
• Retention policy configured in backend (auto-delete after N months)
• Deletion request flow tested (delete one of your own submissions, see if it works)
• Minimal fields only — every field justifiable on request

If you can tick all thirteen, you are in better shape than 95% of small sites serving EU traffic, and you're in fine shape for any routine audit.

What I'm not covering

This post isn't about cookie banners, analytics, ad pixels, newsletter double opt-in, or data subject access requests for non-form data. Those are real, separate topics with separate rules. If you're running a marketing site with trackers, you have more work to do. If you're just running a contact form, the list above is genuinely the bulk of what applies.

I'm also not covering the UK GDPR, which is GDPR with a hat on. If you serve UK users, the rules are 98% identical. Follow this list and you're covered.

The boring take

GDPR feels intimidating because most people encounter it through cookie banner hell and horror stories about €20M fines. A contact form is none of that. It's a polite conversation with someone who wanted to ask you a question, and the regulation mostly asks you to be honest about what you do with their message.

Be honest, delete old submissions, sign your DPAs, minimise your fields, and you are fine.

---

If you want a form backend that does the compliance work for you — EU data residency by default, DPA published openly, retention policies you can set in two clicks, deletion requests you can handle from the dashboard — FormTo was built with this specific checklist in mind.

And if you want to see how we think about the rest of the security picture, Security & reliability spells out the threat model in the same plain language I tried to use here.