GDPR and WordPress Forms: What You Actually Need to Do

Almost every WordPress site has a form on it, and almost every one collects a name and an email address. That’s personal data — so the moment you publish a contact form you’re processing it, and if the people filling it in are in the EU or UK, data protection law applies to you. The good news: for an ordinary contact form, compliance is far less dramatic than the cookie-banner era made it feel. It’s mostly a few sensible decisions about what you collect, why, how long you keep it, and who else can see it. Here’s what that means in practice, with a checklist at the end.
This is practical guidance from people who build form software — not legal advice. Data protection law is fact-specific and varies by jurisdiction. If you handle sensitive data, operate at scale, or face a specific complaint or regulator question, get advice from a qualified professional where you operate.
What GDPR actually requires of a simple contact form
Under the GDPR you need a lawful basis for every processing activity. There are six; two usually fit a plain contact form. Legitimate interests covers reading and answering enquiries — you have a genuine interest, the processing is necessary for it, and it doesn’t override the sender’s rights, and someone who deliberately typed you a message plainly expects a reply. Steps prior to a contract fits quote or order enquiries made at the person’s request.
The frequently-missed point: a contact form usually doesn’t need a consent checkbox at all. Plenty of sites bolt an “I consent to my data being processed” box onto every form because it looks compliant, but consent has to be freely given — if someone can’t send a message without ticking it, it isn’t. A clear purpose plus a privacy notice link does more for you than a tickbox. What you must not do is quietly reuse the data for something the sender didn’t expect: answering the enquiry is one purpose, adding them to your mailing list is another.
Contact form vs marketing opt-in — the line that matters
Marketing email is where consent genuinely bites, governed in the EU and UK by ePrivacy rules (PECR in the UK) on top of GDPR. If your form feeds a newsletter, the opt-in needs to be:
- Unticked by default. Pre-ticked boxes, silence and inactivity are not consent.
- Separate. Not bundled into “I accept the terms”, nor a condition of sending the enquiry.
- Granular. Product newsletter and partner offers are different purposes — ask separately.
- Specific and informed. Who’s sending, what they’ll get, roughly how often.
- Recorded and withdrawable. Show when and how consent was given — a timestamped entry is the easiest evidence — and make opting out as easy as opting in.
Narrow exceptions exist (the UK’s “soft opt-in” for existing customers is the best-known), but they’re tighter than most marketers assume and never cover a cold contact form submission.
Data minimisation: stop collecting what you don’t need
The highest-value change most site owners can make is deleting form fields. GDPR expects collection to be adequate, relevant and limited to what’s necessary for the stated purpose, and every extra field is more to secure, disclose, delete on request and explain if something goes wrong. Worth auditing:
- Phone number — do you actually call people? If it’s optional, mark it optional.
- Postal address on an enquiry form that leads to an email reply; date of birth, company size, job title collected “for segmentation” you never do.
- Hidden fields and IP logging. Many plugins record IPs and user agents by default — justifiable for spam prevention, but it should be a decision you made, disclosed, and not kept forever.
If you’re rethinking the form anyway, our notes on WordPress contact page best practices cover the conversion side: shorter forms usually perform better, making this the rare compliance step that also earns money.
Transparency: say what you’re doing, where you’re doing it
People must know who is collecting their data, why, on what basis, how long it’s kept, who it’s shared with, and what rights they have. That means a real privacy notice reflecting your actual setup — not a template naming services you don’t use — plus a link to it at the point of collection. A short line under the submit button (“We’ll only use your details to reply to this enquiry. See our privacy policy.”) does the job; footer-only is weaker. Keep it honest: if you add people to a CRM, say so.
Storage and retention: decide how long, then enforce it
GDPR doesn’t hand you a number of months. It says don’t keep personal data in identifiable form longer than necessary for the purpose — so you set the period, document it, and be able to justify it. For form entries that usually looks like:
| Entry type | Typical rationale | Practical approach |
|---|---|---|
| General enquiry, no follow-up | Purpose ends when the conversation does | Delete after a short window (months, not years) |
| Quote request that became a customer | Now tied to a contract and to tax/accounting duties | Move into your customer records with their own retention rule |
| Newsletter signup | Kept while consent stands | Retain consent record; delete on unsubscribe request |
| Spam / rejected submissions | No ongoing purpose | Purge aggressively and automatically |
The failure mode we see most often isn’t a bad policy — it’s no policy, plus a database holding eight years of submissions because the plugin stores everything forever and nobody looked. Pick a period, write it in your notice, and use whatever scheduled cleanup your plugin offers so it’s real.
Data subject rights, in practice
The rights that most often touch form data are access (tell me what you hold, and give me a copy), rectification and erasure — the “right to be forgotten”. Erasure isn’t absolute; you may keep data you still have a lawful reason to hold, such as records needed for a contract or legal obligation. But you do have to respond, generally without undue delay.
The operational reality: when a request lands, you need to be able to find, export and delete that person’s entries across every form — a search problem before it’s a legal one. If submissions exist only as emails scattered through an inbox, answering accurately is painful; in a searchable store with export and delete, it’s a two-minute job. That’s the practical case for self-hosting entries rather than parking them in a third-party silo: the data stays on your own server, so erasure and export are things you can actually carry out. Our own free plugin EntryVault is one option (disclosure: it’s ours), keeping entries from the major builders in your database with search and CSV export. Whatever you use, the mechanics are in our guide to storing and exporting WordPress form entries.
Don’t forget the copies: if a submission also went to a mailing list, a CRM and an email archive, an erasure request covers those too.
Processors: where does your form data actually go?
Anyone processing personal data on your behalf is a processor: you’re expected to have a contract with them (most reputable vendors publish a data processing agreement) and to disclose it. For WordPress forms the list is longer than people expect — your web host, your email provider, anti-spam services (some send submission content or IPs off-site to score them), any hosted form SaaS whose embed keeps the data on their infrastructure, and the CRM, helpdesk and automation tools downstream.
Self-hosted form plugins narrow that list considerably, a genuine privacy advantage — though “self-hosted” never means nobody else is involved, since your host and mail provider still are. Transfers outside the EEA or UK are a separate consideration: sending data to a provider in a country without an adequacy decision needs an appropriate safeguard, commonly Standard Contractual Clauses, which vendors usually document. Not a reason to avoid non-EU tools outright — a reason to check rather than assume.
Security basics
GDPR requires appropriate technical and organisational measures — proportionate, not perfect. For form data that means:
- HTTPS everywhere, so submissions aren’t sent in the clear, and 2FA on admin accounts.
- Access control — not every author needs to read submissions.
- Updates to core, plugins and themes; most real breaches are unpatched software, not clever attacks.
- Careful exports and backups. A CSV of entries in a Downloads folder is still personal data, and backups need remembering at erasure time.
- A breach plan — who decides whether a notifiable breach occurred, and the reporting timeline.
The practical checklist
- List every form and what each field is for; delete the fields that fail the test.
- Write down the lawful basis per form — usually legitimate interests or pre-contractual steps, not consent.
- Make any marketing opt-in separate, unticked, granular and optional.
- Add a short privacy line plus policy link at the point of collection.
- Check whether your plugin logs IPs and user agents, and decide deliberately.
- Set a retention period per form type, state it, and enforce it automatically if you can.
- Make sure you can search, export and delete one person’s entries across all forms.
- Map where entries go afterwards — email, CRM, spam service, automation — and confirm DPAs exist, including for processors outside your region.
- Enforce HTTPS, restrict who can view entries, enable 2FA, keep everything updated.
- Revisit the list whenever you add a form or a tool — not once a year.
What about UK GDPR, CCPA and everyone else?
UK GDPR closely mirrors the EU version, with PECR covering electronic marketing and the ICO as regulator — compliant for the EU usually means close, but the regimes have been diverging, so don’t assume they stay identical. California’s CCPA/CPRA is structured differently: it leans on disclosure and opt-out rights (notably around “selling” and “sharing” personal information) rather than a lawful basis up front, and only applies above certain business thresholds. Brazil’s LGPD, Canada’s PIPEDA and a growing list of US state laws add their own variations.
The encouraging part: the habits transfer. Collect less, say what you’re doing, keep it for a defined period, secure it, and be able to find and delete it on request. A site doing those five things well is in decent shape almost anywhere — and is a nicer site to submit a form to, which was always the point.
Related reading
- File uploads in WordPress forms — uploads carry personal data too — handle them the same way
Frequently asked questions
Does a WordPress contact form need a GDPR consent checkbox?
Usually not. Responding to an enquiry is normally covered by legitimate interests or by steps prior to a contract, and consent that’s required in order to send the message arguably isn’t freely given anyway. What you do need is a clear purpose and a privacy notice link at the point of collection. Consent becomes essential when you also want to send marketing email, which must be a separate, unticked, optional opt-in.
How long can I keep WordPress form entries under GDPR?
GDPR sets no fixed number. It requires that you keep personal data no longer than necessary for the purpose you collected it for, so you set a retention period, document it in your privacy notice, and be able to justify it. In practice, enquiries with no follow-up are often deleted after a few months, quote requests that became customers move into customer records with their own rule, and spam should be purged aggressively.
How do I handle a GDPR erasure request for form submissions?
Find every entry relating to that person, delete what you have no continuing lawful reason to keep, and remember the copies — notification emails, the CRM, the spam service, exported CSVs and backups. This is far easier when submissions live in one searchable place rather than scattered through an inbox. Erasure isn’t absolute: you may retain data you still need for a contract or legal obligation, but you should tell the person what you kept and why.