What Makes a Contact Form GDPR Compliant WordPress

Most WordPress contact forms fail GDPR compliance not on one count but on five or six simultaneously. The site owner installs a form plugin, adds a consent checkbox because someone told them to, and assumes the job is done. It is not. The checkbox addresses one element of compliance — and only when consent is actually the correct lawful basis, which for a standard inquiry form it usually is not. Meanwhile, the plugin is silently logging IP addresses into the database, reCAPTCHA is transmitting browser fingerprints to Google before any cookie consent is obtained, submissions are accumulating with no deletion schedule, no privacy notice exists at the point of collection, and the privacy policy does not mention a single third-party service that touches the data. That form is non-compliant on five independent grounds, and the checkbox fixes none of them.

This is not an academic concern. In March 2026, twenty-five European Data Protection Authorities launched the EDPB’s coordinated enforcement action targeting transparency and information obligations under GDPR Articles 12, 13, and 14. Contact forms are explicitly cited as a data collection point under review. DPAs are sending standardised questionnaires to controllers and conducting formal enforcement actions. The gap between what the law requires and what most WordPress contact forms actually do is wide enough that even basic automated screening will surface violations at scale.

A compliant WordPress contact form satisfies eight specific requirements simultaneously. Not seven. Not the five easiest ones. All eight. Here is what they are.

The lawful basis must exist before the form goes live

Every contact form must process data under a lawful basis documented before the first submission arrives. For a standard inquiry form where the visitor initiates contact, legitimate interest under GDPR Article 6(1)(f) is the correct basis — not consent. GDPR Recital 47 supports this directly: a person who voluntarily fills in a contact form and clicks submit has a “relevant and appropriate relationship” with the controller and reasonably expects a response. The ICO, the Irish DPC, and the EDPB’s Guidelines 1/2024 on Legitimate Interest all support this position.

This means no consent checkbox is legally required for the inquiry itself. Adding one does not create compliance. Worse, it can undermine it — if a user later withdraws the consent you collected but did not need, you lose a lawful basis you never should have relied on, and the ICO has stated that controllers should not retrospectively switch bases.

Consent under GDPR Article 6(1)(a) becomes necessary only when the form does something beyond responding to the question: subscribing the visitor to a newsletter, sharing their data with a partner, feeding it into a marketing CRM. That marketing element requires its own separate, unticked checkbox with purpose-specific text — not bundled with the inquiry submission. The CJEU’s Planet49 ruling (C-673/17) and EDPB Guidelines 05/2020 established this beyond dispute.

The lawful basis must be documented in a Legitimate Interest Assessment applying the ICO’s three-part test: the interest is legitimate, the processing is necessary, and it does not override the individual’s rights. This document sits in your compliance file. It does not need to be published, but it must exist and be datable to before the form was deployed.

Only the fields that survive the necessity test belong on the form

GDPR Article 5(1)(c) requires data to be “adequate, relevant and limited to what is necessary.” The EDPB’s Guidelines 4/2019 on Data Protection by Design and Default use a web form as their worked example, stating explicitly that fields not necessary for the processing purpose must be removed. GDPR Article 25(2) reinforces this: by default, only data necessary for each specific purpose should be processed.

For a form whose purpose is email-based inquiry handling, the defensible field set is name, email address, and message body. A subject line or category dropdown aids routing and is defensible. Everything beyond that requires justification specific to the stated purpose. A required phone number field on an email inquiry form is indefensible. Company name and job title as required fields are excessive for a general contact form. Date of birth has no defensible purpose on any contact form.

Every field that exists on the form is a field you must justify in your ROPA, disclose in your privacy notice, store securely, delete on schedule, and produce in response to a data subject access request. Removing an unnecessary field eliminates all five of those obligations in one action.

The privacy notice must be at the form, not buried in the footer

GDPR Article 13 mandates twelve categories of information at the time personal data is collected. Not somewhere on the website. Not in a privacy policy accessible through a footer link three clicks away. At the point of collection.

The WP29 Guidelines on Transparency endorse a layered approach: a concise first-layer notice near the submit button, with a prominent link to the full privacy policy section. That first layer must identify the controller, state the purpose, name the lawful basis, and reference the full details. Something like: “We use your information to respond to your inquiry. [Company Name] is the data controller. See our Privacy Policy for details including your rights and how long we keep your data.”

The full privacy policy must then dedicate a section to contact form processing: what data is collected, the specific purpose, the legal basis with GDPR article reference, every recipient including hosting provider, SMTP service, spam filter, and any CRM, the international transfer mechanism for US-based services, the concrete retention period, and the complete list of data subject rights. Most WordPress sites fail here — not because they lack a privacy policy, but because the policy says nothing about the specific services that actually touch the data.

With the EDPB’s 2026 enforcement action specifically targeting these transparency obligations, a contact form with no inline privacy notice is the lowest-hanging enforcement fruit imaginable.

Submissions must delete themselves on schedule

GDPR Article 5(1)(e) prohibits keeping data longer than necessary. GDPR Article 13(2)(a) requires disclosing the retention period. A compliant form needs both a defined retention period and a technical mechanism that enforces it.

For simple contact inquiries, 90 days after resolution is defensible. Lead generation forms may justify up to six months. Whatever the period, it must be documented in the privacy policy and enforced automatically. Form submissions that accumulate indefinitely in the database are a textbook storage limitation violation — and the Danish DPA’s recommended DKK 1.2 million fine against Taxa 4×35 established that database architecture does not excuse retention failures.

Gravity Forms handles this natively through its per-form Personal Data tab. Ninja Forms offers built-in submission expiration in its free tier. WPForms requires the paid Entry Automation addon. Contact Form 7 with Flamingo, Formidable Forms, Fluent Forms, and Elementor Pro all lack native automatic deletion — requiring either third-party plugins or custom wp_cron implementations. If your plugin cannot delete entries automatically, you need a different plugin or a custom solution. “We forgot” is not a defensible retention policy.

Data subject rights must actually work, not just theoretically exist

GDPR Articles 15 through 22 grant data subjects rights over their data. Under legitimate interest, access, rectification, erasure, restriction, and the right to object all apply. The controller must be able to locate, export, and delete a specific individual’s form submission data within 30 days of a request.

WordPress’s built-in privacy tools at Tools → Export/Erase Personal Data provide the mechanism — but only if the form plugin registers with the wp_privacy_personal_data_exporters and wp_privacy_personal_data_erasers hooks. Gravity Forms, WPForms Pro, Ninja Forms, and Formidable Forms do. Contact Form 7, HappyForms, and Jetpack Forms do not or have unclear integration. When a plugin does not register, its stored submissions are invisible to WordPress privacy tools, and every data subject request requires manual database searches across each plugin’s own interface.

The test is simple: go to Tools → Export Personal Data, enter an email address that has submitted your contact form, and verify the submission data appears in the export. If it does not, your data subject rights mechanism is broken.

The form must not leak data to third parties before consent

Every third-party service that receives form data creates a processor relationship requiring a Data Processing Agreement under GDPR Article 28 and potentially triggers international transfer obligations under GDPR Articles 44–49.

Google reCAPTCHA is the largest hidden risk. It collects IP addresses, sets cookies, performs browser fingerprinting, and tracks mouse movements — none of which qualifies as “strictly necessary” under the ePrivacy Directive. CNIL fined Cityscoot €125,000 and NS Cards France €105,000 specifically for deploying reCAPTCHA without consent. On April 2, 2026, Google switched reCAPTCHA from a data controller to a data processor model, making site owners bear full legal responsibility.

Most WordPress form plugins enqueue reCAPTCHA scripts globally via wp_enqueue_script, meaning they fire on page load before any consent management platform can intervene. A documented conflict exists between Contact Form 7 with reCAPTCHA v3 and cookie consent plugins — blocking the script before consent breaks form submission entirely. The clean solutions are replacing reCAPTCHA with Cloudflare Turnstile or honeypot techniques, or implementing consent-gated form display.

Fluent Forms introduces a less obvious risk: it uses ipinfo.io for geolocation, transmitting visitor IP addresses to a third-party US service without disclosure. The fluentform/ip_provider filter can disable this, but few site owners know it exists.

Every external service — Akismet, SendGrid, Mailgun, HubSpot, Mailchimp, Zapier — requires a signed DPA and privacy policy disclosure. Missing DPAs constitute an infringement under GDPR Article 83(4), carrying fines of up to €10 million or 2% of global annual turnover.

HTTPS is non-negotiable and default IP logging must be disabled

GDPR Article 32 requires appropriate security measures. For contact forms, the baseline is TLS/HTTPS encryption on every page containing a form — data submitted over HTTP travels in plaintext. Beyond transport encryption, secure SMTP for notification emails, restricted admin access, and controlled file upload directories all fall under this requirement.

The more insidious issue is default IP address logging. WPForms Pro, Gravity Forms, Formidable Forms, and Fluent Forms all record visitor IP addresses by default with every submission. Under GDPR, IP addresses are personal data (CJEU Breyer v. Germany, C-582/14). Storing them without necessity and disclosure violates both data minimisation and transparency. The fix is a single setting toggle in each plugin, but every plugin ships with it enabled:

WPForms: Settings → General → GDPR → Disable User Details. Gravity Forms: Form Settings → Personal Data → Prevent IP address storage. Formidable Forms: Global Settings → GDPR → Disable storing IPs. Fluent Forms: requires the fluentform/ip_provider filter or custom code.

After disabling, query the database to verify: existing entries are not retroactively cleaned by these toggles. Old submissions with IP addresses still stored must be manually purged.

If you cannot prove compliance, you are not compliant

GDPR Article 5(2) — the accountability principle — transforms compliance from something you do into something you document. A form that satisfies every technical requirement but lacks written records is, under the regulation’s own framework, non-compliant.

The documentation inventory: a ROPA entry for contact form processing under GDPR Article 30, specifying controller identity, purpose, lawful basis with article reference, data categories, recipients, international transfers, retention period, and security measures. A Legitimate Interest Assessment if relying on GDPR Article 6(1)(f), documenting the three-part test. Signed DPAs with every processor — hosting provider, email service, and any external integration. A privacy policy section specifically covering contact form data with full GDPR Article 13 disclosure.

The Irish DPC’s 2022–2023 ROPA sweep of 30 organisations found that the most common failures were missing retention periods, incomplete recipient lists, and treating DPIAs as substitutes for ROPA entries. These are the exact documentation gaps that contact form processing typically exhibits.

The audit that catches what you missed

Configuration does not guarantee compliance. The form must behave compliantly in practice, which means testing it.

Open your contact form in an incognito browser window. Before touching any cookie banner, open DevTools → Network tab and filter by third-party domains. Any requests to google.com/recaptcha, gstatic.com, rest.akismet.com, ipinfo.io, or analytics domains represent data transfers that should not occur before consent. Check Application → Cookies — no non-essential cookies should exist. Submit a test entry, then query your database directly for that entry’s IP field. If it contains a value after you disabled IP logging, the setting did not apply. Run an export request through Tools → Export Personal Data using the test email — if the form data does not appear, your data subject rights mechanism is broken. Check the oldest entry in your form submissions table — if it predates your stated retention period, your deletion mechanism is not executing.

Each of these tests takes minutes. Each catches a compliance failure that no amount of checkbox-adding will fix. A WordPress contact form is not made compliant by a single setting or a single checkbox. It is made compliant by eight interlocking requirements, all present, all functioning, all documented. The checkbox was never the hard part. Everything else was.