How to build a GDPR compliant contact form
The Formward TeamFormward, Stockholm7 min read
A GDPR compliant contact form is one where you can answer six questions without hesitating: what data you collect, why you are allowed to collect it, who else touches it, where it is stored, how long you keep it, and what you do when someone asks for their copy or its deletion. The form markup is the easy part. Compliance lives in the decisions behind it. This is a practical walkthrough of those decisions for an engineer who has to ship the thing.
Start with lawful basis, because everything else hangs off it. The GDPR requires a legal reason to process personal data, and for a contact form you almost always have one of two: consent, or legitimate interest. If someone fills in your form to ask a question, replying to that question is a legitimate interest and you do not need a separate consent checkbox to do it. You collected the data because they handed it to you for exactly that purpose. Do not bolt a mandatory I agree box onto a form whose only job is to let someone reach you. It is legally unnecessary and it trains people to click without reading.
Consent becomes the right basis when you want to do something beyond answering. Adding the submitter to a newsletter, profiling them, or passing their details to a sales tool is a new purpose, and that needs its own opt-in. The rule of thumb: one purpose, one basis. If your contact form quietly signs people up for marketing, you have merged two purposes and broken both. Keep the marketing opt-in as a separate, unticked checkbox with its own clear label, and make the form work whether or not it is ticked.
Next is data minimisation, which is the single most effective compliance move available to you and costs nothing. Collect only the fields you genuinely need to do the thing the form is for. A reply needs an email address and a message. It probably does not need a phone number, a company size, a job title, and a postal address. Every field you add is more personal data to secure, justify, retain, and eventually hand back or delete. When a stakeholder asks for one more field, the question is not can we, it is do we need this to respond. Most of the time the honest answer is no.
Be transparent at the point of collection. The person submitting the form has a right to know who is processing their data and why before they hit send. You do not need a wall of text on the form itself; a short sentence near the submit button linking to your privacy policy is enough, as long as that policy actually describes the contact form: what you collect, your lawful basis, how long you keep it, and who your processors are. Transparency is not a legal disclaimer you paste once. It is information the person can act on.
Now the part most teams forget until an audit: retention. Personal data cannot be kept forever just because storage is cheap. You need a defined period after which a submission is deleted, and it should match the purpose. If a contact message is resolved in a week, keeping it for five years is hard to defend. Pick a retention window, write it down, and make it enforceable in software rather than as a note in a wiki nobody reads. A good form backend lets you set a retention policy and deletes on schedule so you are not running cleanup scripts by hand.
Plan for data subject access requests before you get one. Under the GDPR, a person can ask what data you hold about them, ask for a copy, ask you to correct it, or ask you to erase it, and you generally have a month to respond. For contact-form data this is usually straightforward, but only if you can actually find every submission tied to an email address and export or delete it. If your submissions are scattered across an inbox, a spreadsheet, and a CRM, a single DSAR turns into an afternoon of archaeology. Centralising form submissions in one place with search and per-record export and delete is what makes DSARs a two-minute task instead of a fire drill.
Vet your sub-processors, because their data flows become your liability. The service that receives your form POST, the email provider that sends your notification, the spam filter, the analytics tool: each of these is a processor handling your visitors' personal data on your behalf. You are responsible for where they send it. A form backend that quietly relays submissions through US infrastructure makes you a data exporter and drags Schrems II and transfer assessments into what should have been a contact form. Knowing your processors and where they store data is not optional diligence; it is the part of compliance that is easiest to get wrong by accident.
Secure the data in transit and at rest. Serve the form over HTTPS so submissions are not sent in clear text, which is table stakes today but still worth checking. Make sure the backend stores submissions encrypted and behind proper access controls, so a contact message is not sitting in a world-readable log. Add basic abuse protection too, since an unprotected endpoint that gets scraped and spammed is both an annoyance and a data-quality problem. Privacy-preserving spam defences, like a honeypot field and rate limiting on a hashed rather than raw IP, keep bots out without turning your visitors into tracked data for a third party.
Get the consent and confirmation mechanics right in the markup. If you do use a consent checkbox for a secondary purpose, it must be unticked by default, separate from any terms acceptance, and described in plain language. Record the fact of consent with the submission so you can show it later if asked. For the contact purpose itself, a clear confirmation after submission, by on-page message or autoresponder, is good practice and reassures the person their data went where they expected. None of this needs a consent management platform for a simple contact form; it needs honest defaults.
Document what you built, briefly. You do not need a hundred-page record for a contact form, but you should be able to state its purpose, the fields, the lawful basis, the retention period, and the processors involved. If you ever maintain a record of processing activities, the contact form is one line in it. Writing this down once, when the form is fresh in your head, is far easier than reconstructing it under the pressure of a complaint or a procurement questionnaire.
This is the architecture Formward is built around, which is why we keep coming back to it. Submissions are stored in the EU, sent through EU email providers, scored for spam without shipping your visitors to a US tracker, and governed by retention settings and per-record export and delete so DSARs are quick. We mention it not as the only way to do this, but because most of the work above is the kind of thing you want handled by the backend rather than reimplemented for every form.
If you want a checklist to leave with, it is short. Collect the fewest fields that let you respond. Use legitimate interest for replies and a separate opt-in for anything more. Tell people who you are and link a privacy policy that matches reality. Set and enforce a retention period. Keep submissions somewhere you can search, export, and delete them in one place. Know your sub-processors and where they store data. Do those six things and a contact form stops being a compliance question and goes back to being a contact form.