GDPR-compliant contact forms: a practical checklist

A contact form is personal data processing in its purest form: someone hands you their name, email, and a free-text message. GDPR applies the moment an EU visitor hits send. The good news is that a compliant contact form is mostly a handful of decisions made once.

Practical guidance from developers who ship this daily - not legal advice. For specific situations, ask a professional.

1. Collect only what the purpose needs

Data minimisation is the easiest principle to honor and the most commonly violated. A contact form needs an email and a message. Phone number, company size, budget dropdowns - every extra field needs a reason. Fewer fields also convert better, so compliance and conversion point the same direction for once.

2. Know your lawful basis (it's probably not consent)

For a contact form, the lawful basis is usually legitimate interest or steps prior to entering a contract - someone wrote to you; answering them is the point. You generally don't need a consent checkbox just to receive and reply to a message. Where you do need separate, unticked-by-default consent is anything beyond replying: newsletters, marketing follow-ups. Never bundle those into the send button.

3. Know where the data physically lives

Your form processor stores the submission somewhere, and where determines a chunk of your paperwork. If the processor stores data in the US, the transfer needs a Chapter V mechanism - currently the EU–US Data Privacy Framework and/or SCCs - and your privacy policy must describe it. That's workable, but it's homework that renews whenever the legal landscape shifts (Safe Harbor and Privacy Shield were both struck down; the DPF is under challenge).

The structurally simple option is a processor that stores submissions in the EU and never transfers them - then there's no transfer to document. Formhook stores submissions in Germany, full stop. Either way, the checklist item is the same: find the storage location in your processor's documentation and make sure your privacy policy matches reality.

4. Have a DPA with your processor

Article 28: if a service processes personal data on your behalf, a data processing agreement must exist. Any serious form backend offers one - here's Formhook's. If a provider can't show you a DPA, that's disqualifying by itself.

5. Decide retention - and be able to act on it

Storage limitation means knowing how long you keep submissions and why. "For the life of the client relationship" is a perfectly good answer - but you need two capabilities from your tooling: deleting individual submissions (erasure requests) and exporting everything (access/portability requests). Check both exist before you need them; in Formhook, deletion is per-submission and export is a full JSON ZIP on every tier.

6. Write the privacy policy paragraph honestly

The form's paragraph needs: what's collected, why, the lawful basis, who processes it (name the provider), where it's stored, how long it's kept, and how to request deletion. If the data stays in the EU, that paragraph is two sentences. If it crosses the Atlantic, it's longer - but the cardinal sin is a policy that doesn't match the actual data flow.

The checklist

• Form collects only necessary fields
• No pre-ticked consent; marketing consent (if any) separate from sending
• Processor's storage location known and documented
• Transfer mechanism identified (or made unnecessary by EU residency)
• DPA in place with the processor
• Retention decided; per-submission deletion and full export both possible
• Privacy policy paragraph matches the real data flow

Run this once per site and the contact form goes from compliance question mark to solved problem. More on how Formhook handles data in the FAQ and privacy policy.