A contact form collects personal data, and that makes you a data controller under UK GDPR the moment someone submits it.

A contact form is a small piece of software that takes whatever a visitor types, a name, an email address, a message, and moves it from their browser across the internet to somewhere you can read it. Every step in that route is worth understanding, because each one is a place the data sits, however briefly.

The fields decide what you hold

Whatever fields you put on the form, that is the data you become responsible for. A name and an email address is already personal data under UK GDPR, the law governing how organisations handle information that identifies a living person. Add a phone number, or a message box where someone volunteers a home address or a health detail, and you are holding more than you may have planned for. The fix is not legal, it is design: ask for what you need to answer the enquiry, and nothing beyond that.

From the browser to your inbox

When someone submits the form, the data travels to your host, the company storing the website's files and running the software behind it. From there it is usually emailed straight to an inbox you check, though some setups also save a copy in a database on the server. If the form runs over HTTPS, the secure version of the connection between browser and server, the message is encrypted in transit. If it does not, that is a question worth putting to whoever built or hosts the site.

The trail it leaves behind

Once the message lands in an inbox, a copy usually sits there too: on the mail server, in any backup of that mailbox, and sometimes in the website's own database if the form was built to log submissions as well as send them. That is three places holding the same enquiry, and each is a place someone would need to check if a visitor later asked what you hold on them, or asked you to delete it. Knowing where the copies live before you need to find them saves a difficult afternoon later.

For the wider list of what a UK site needs to show and hold correctly, see What a UK website must show by law. This page deals with the form itself: what it collects, and where that ends up.

UK GDPR requires a lawful basis for processing personal data of any kind, and a name and email address typed into a contact form counts as personal data the moment it lands in your inbox. Article 6 of the regulation sets out six lawful bases in total, but for a small site running a plain enquiry form only two of them tend to matter: legitimate interest and consent.

Why legitimate interest covers a simple enquiry

Legitimate interest (Article 6(1)(f)) lets you process someone's data where you have a genuine reason to do so and that reason does not override their own rights. Someone filling in a contact form to ask about your plumbing rates or your choir's rehearsal times has given you their email address for one purpose: so you can reply. Using it for that purpose is the textbook case for legitimate interest, and it does not need a consent tickbox, because the person's own action already makes clear what they expect to happen next.

The ICO expects you to be able to show your working if asked. That means being able to say what the interest is (answering enquiries), why it's necessary (you can't reply without an email address), and why it doesn't unfairly override the sender's rights (they gave you the address for exactly this).

Where consent comes in, and why it's a different regulation

Consent becomes relevant the moment you want to do anything with that email address beyond answering the question it came with, chiefly adding someone to a mailing list or sending them offers. That's governed by PECR, the Privacy and Electronic Communications Regulations 2003, which sits alongside UK GDPR and covers electronic marketing specifically. PECR consent has to be a positive, unticked opt-in: no pre-ticked boxes, and no assuming that someone who asked about a boiler service wants a newsletter too.

Keeping the two uses apart

The two purposes are easy to blur on a single form, and blurring them is the mistake that causes the most trouble. If you want to reply to enquiries and also build a mailing list, treat them as two separate actions:

• Answer the enquiry under legitimate interest, with no tickbox needed.
• Offer marketing sign-up as a separate, unticked checkbox the person chooses for themselves.
• Keep a record of when and how consent was given, since PECR puts the burden of proof on you.

Your privacy notice needs to name both bases and say plainly which applies to which use of the data. If you're not sure whether your form and its wording meet the threshold, the legal essentials checker works through the relevant points against the named regulations, though it can't cover every situation and isn't a substitute for professional advice where your setup is unusual.

A contact form published on a website gets found by automated scripts before it gets found by a real enquirer, often within days of the site going live. These scripts submit entries at volume, testing whether the form fires an email, posts a link, or accepts a file upload. None of the countermeasures below stop every one of them, but each blocks a different kind of attempt, and each asks something different of the visitor filling the form in.

The honeypot field

A honeypot is a form field that is hidden from a sighted visitor using CSS, but left in the page's underlying code where an automated script can still find it and fill it in. A script that fills in every field on the page, name, email, message and the invisible one, has given itself away, so the submission is quietly discarded. Done correctly, using an off-screen positioning technique rather than simply hiding the field, a honeypot costs a genuine visitor nothing and costs a screen reader user nothing either, since the hidden field is skipped by both. It stops the least sophisticated scripts, but nothing against one written specifically to leave blank fields blank.

Rate limiting

Rate limiting caps how many submissions a form accepts from one source within a given period, most often the IP address, the number identifying the connection a visitor is submitting from. A script trying to submit hundreds of entries a minute hits that limit almost immediately, while a person filling in one form once never notices the limit exists. The cost falls on the rare edge case: several people submitting from the same office or university network in quick succession, or someone resubmitting after correcting a typo, who may find the second attempt blocked. Rate limiting has to run on the server that receives the form, because a script bypassing the browser altogether ignores any check written into the page itself.

CAPTCHA

A CAPTCHA asks the person submitting a form to prove they are a person, typically by solving an image puzzle or ticking a box that checks their browsing behaviour. It stops far more automated traffic than a honeypot or a rate limit alone, but it is the one countermeasure that asks something of every visitor, including all the ones who were never going to spam the form.

• Every visitor pays a small toll in time and attention, whether they were the target of the countermeasure or not.
• Image-based challenges can be impossible for a visitor using a screen reader unless an audio alternative is offered, and WCAG 1.1.1 requires a text alternative for non-text content such as this.
• Many CAPTCHA services run on a third party's servers, so solving one can send data about the visitor's browser and behaviour to that third party before the enquiry form has even been submitted.

For most small enquiry forms, a honeypot field combined with server-side rate limiting catches the bulk of automated spam without the visitor noticing either one exists. CAPTCHA is worth adding if spam keeps arriving despite both, but it is worth adding as a second line, because it is the only one of the three that asks a real enquirer to do anything at all. The accessibility trade-offs touched on here are covered in more detail, alongside the rest of what makes a small site usable, on Making a Small Site Fast and Accessible.

A privacy notice is the page you link from your contact form, telling anyone who fills it in what happens to their details afterwards. UK GDPR (the UK General Data Protection Regulation) applies to any form that collects personal data, and a contact form counts even when all it asks for is a name and an email address. The notice does not need to be long, but it does need to answer four questions plainly.

How long you keep the enquiry

State a retention period: how long the message and the sender's details stay in your inbox or database before you delete them. A reasonable period for a simple enquiry form is however long it takes to deal with the query plus a short period afterwards, perhaps a few months. If you keep enquiries as a record of past customers, say so and say for how long.

Who sees the message

Name who has access: yourself, a colleague, a mailbox held with your email provider, or a third-party service if the form submits into a customer relationship management (CRM) tool or a spreadsheet hosted elsewhere. If the form data passes through a form-handling service before it reaches your inbox, that service sees it too, and the notice should say so.

What the sender can ask you to do

Under UK GDPR, the person who filled in the form has the right to ask what you hold about them, to ask you to correct it, and to ask you to delete it. They can also object to how it is used. The notice should say how to make that request, which in practice is usually just your contact address.

Where they can complain

If someone believes you have mishandled their data, they have the right to complain to the Information Commissioner's Office (ICO), the UK's data protection regulator. Your privacy notice should give the ICO's contact details so a visitor does not have to search for them: ico.org.uk carries the current address and phone number, and stating that the ICO is the relevant body is enough. You are not expected to resolve a data protection dispute yourself; the notice exists so the sender knows where else to go.

The UK Website Legal Essentials Checker works through this alongside the other things a UK site is required to show, and What a UK Website Must Show by Law covers the rest of the notice.