What GDPR says about contact forms

For an ordinary contact form, GDPR turns on lawful basis, transparency, data minimisation, processor records, retention, security, and rights requests. Consent may be needed for a separate newsletter purpose, but it is not automatically required to answer an enquiry.

Ask a website owner what GDPR requires of a contact form and you will usually hear something about consent checkboxes. Ask what happens to those submissions after eighteen months and you will usually get a shrug.

The regulation is weighted almost exactly the other way round. Collecting a name, an email address and a message so you can answer somebody's question is among the least contentious processing there is. What you do with it for the next three years is where the obligations actually live.

That mismatch is why so much compliance effort goes into a checkbox that may not be needed while the genuine exposure, an unbounded archive of personal data nobody can account for, goes untouched.

This is a working explanation for people who run websites, not legal advice. If your processing is unusual or high-risk, take proper advice.

GDPR sets out six lawful bases for processing, and consent is only one. For a contact form it is frequently the worst fit.

When someone deliberately fills in a form asking you to contact them, you are not processing their data because they ticked a box. You are processing it because they asked you to do something, which lands naturally under performing a contract or taking steps at their request before entering one, or under legitimate interests.

Choosing consent creates a problem: consent can be withdrawn at any time, and withdrawal must be as easy as giving it. Building your ability to reply to an enquiry on a permission the person can revoke mid-conversation is legally awkward and practically silly.

The place consent genuinely belongs is anything beyond the enquiry. Adding them to a mailing list is a separate purpose, and that one really does need a freely given, specific, unambiguous yes.

Transparency is the obligation most contact forms actually fall short on. At the point of collection a person should be able to find out who is collecting the data, why, on what basis, how long it will be kept, who else sees it, and what rights they have.

None of that requires a wall of text beside the submit button. A short line and a link to a privacy notice satisfies it, provided the notice genuinely covers form submissions rather than only cookies and analytics.

The common failure is a privacy policy that describes a website in general and never mentions the enquiry form, the spreadsheet the enquiries end up in, or the third parties involved in getting them there. That gap is easy to close and it is the one an inspection would find first.

Data minimisation says collect what you need for the stated purpose, and no more. It is the principle with the highest ratio of benefit to effort, because reducing collection reduces every downstream obligation at once.

Most contact forms carry at least one field that exists because it seemed useful. Company size on a support form. Postal address on an enquiry that will be answered by email. Date of birth on anything that is not age-restricted. Each one enlarges what you must protect, disclose, retain and eventually delete.

There is a conversion argument for the same thing, which is convenient. Every field you remove from a form raises the completion rate, so the privacy-minimal version and the commercially optimal version tend to be the same form.

Modern forms capture more than the visible inputs. Campaign parameters, click identifiers, referrer, page URL and timing signals often travel with the submission, and they are personal data when tied to an identifiable person.

This is not a reason to stop capturing them. Attribution data has an obvious business purpose, and knowing which campaign produced an enquiry is a legitimate interest most regulators would recognise on sight.

It is a reason to say so. If your form quietly records a click identifier and the referring page, your privacy notice should mention that you collect technical and campaign information alongside the message. The problem is never the collection, it is the silence about it.

If a submission passes through anything you did not write, that thing is a processor and belongs in your records: the form plugin's cloud service, the spam-screening provider, the mail relay, the spreadsheet platform, the CRM.

Most sites can list the first and the last, and miss the middle. The relay that sends notifications and the service that screens for spam both see the full contents of the message, and both are as much part of the chain as the destination.

The practical exercise takes fifteen minutes. Follow one submission from the browser to wherever it comes to rest, write down every party that touches it, and check that each appears in your notice. Our own processing description exists for exactly this reason, because a customer completing that exercise needs to be able to describe our part of it accurately.

Personal data should not be kept in identifiable form for longer than is necessary for the purpose. That is the requirement, and it is the one almost nobody implements.

The typical contact form archive contains every enquiry since the form was installed, including many from people who asked a question once in 2019 and never came back. There is no purpose being served by that data now, which means the storage limitation principle is not being met.

The fix is a retention period you can state and a routine that enforces it. Both parts matter: a policy nobody executes is worse than no policy, because it documents the gap. Choosing a retention period is a short exercise once you separate enquiries from customers.

It is also much easier to enforce when submissions live in one place. A spreadsheet of enquiries can be sorted by date, filtered and pruned in a couple of minutes; the same data spread across a plugin database, three inboxes and an old export cannot be pruned at all.

People can ask for a copy of their data, ask for it to be corrected, and in many cases ask for it to be deleted. Responses are due without undue delay and generally within a month.

For a small business the difficulty is never the legal test. It is finding every copy. The enquiry is in the form plugin's database, a spreadsheet, two inboxes, an export somebody made for a report, and possibly a CRM.

This is the strongest argument for having one system of record rather than five copies. When submissions land in a single spreadsheet, handling a deletion request is a search and a delete, and the honest answer to what have you got about me is one you can actually give.

That is worth designing for deliberately rather than discovering during your first request. A single destination for enquiries turns a rights request from an archaeology project into a filter, and it is the same arrangement that makes retention enforceable.

The regulation asks for measures appropriate to the risk, which for ordinary contact data is a reasonable and reachable bar: transport encryption, access restricted to people who need it, no unnecessary copies, and a spreadsheet that is not shared with a public link.

That last one is worth an audit of its own. Sharing settings drift over years, and a sheet of enquiries readable by anyone with the link is a far more likely incident than anything sophisticated.

Nothing here demands enterprise tooling. It demands knowing where the data is, which is the same knowledge every other obligation depends on.

You almost certainly do not need consent to answer an enquiry, and you almost certainly do need it before adding that person to a mailing list. Tell people what you collect, including the invisible fields. Collect less than you currently do. Know every party that touches a submission.

Then set a retention period and actually run it. If you do only one thing from this list, do that one, because it is the obligation with the widest gap between what sites claim and what they do.

The obligations above map to specific articles of Regulation (EU) 2016/679, the General Data Protection Regulation. Consolidated text: EUR-Lex, Regulation (EU) 2016/679. Article-level references, all accessed 2026-09-03:

• Article 5 - principles, including data minimisation (5(1)(c)) and storage limitation (5(1)(e)).
• Article 6 - the six lawful bases, including contract (6(1)(b)) and legitimate interests (6(1)(f)); consent is 6(1)(a).
• Article 7(3) - consent can be withdrawn at any time and withdrawal must be as easy as giving it.
• Article 13 - what must be told to a person at the point of collection.
• Article 15, 16 and 17 - the rights of access, rectification and erasure; Article 12(3) sets the one-month response window.
• Article 28 and Article 30 - processors and records of processing.
• Article 32 - security appropriate to the risk.

Where a submission is handled by SheetLink Forms, the processors and retention windows are listed in the privacy policy and the security page; the retention habit itself is described in the spam protection guide alongside quarantine review.

Do I need a consent checkbox on my contact form?

Does GDPR apply if I am not in the EU?

Is a privacy policy enough on its own?

What about the IP address my form logs?

Do I need a data protection officer?

Can I keep enquiries forever if they became customers?

What is the single most common mistake?