Contact Form GDPR Requirements: Article 13 Compliance

Steven | TrustYourWebsite · May 15, 2026 · Last updated: May 2026

The contact form is the entry point through which a website typically collects personal data for the first time. A name and an email address might be the minimum; many forms collect more. Whatever the field set, Article 13 GDPR engages from the moment the data is submitted, and the controller's transparency duty has to be discharged on or near the form itself.

This guide covers the four operational decisions a contact form embodies: the information block under Article 13, the correct legal basis for the enquiry, the role of consent checkboxes (often misused), and the retention period for what comes through. It also covers the recurring failure modes that appear in supervisory authority decisions across the EU.

What the contact form processes

A standard contact form on an SME website typically collects:

  • Name (often required, can be optional)
  • Email address (required to respond)
  • Phone number (optional in most cases, sometimes required for booking flows)
  • Message body (free text, may contain additional personal data the sender chooses to disclose)

Plus, server-side, the request automatically generates:

  • IP address of the submission
  • Timestamp
  • User agent
  • Possibly session identifier or device fingerprint, depending on the form library

The IP, timestamp and user agent are personal data under Recital 30 GDPR, as confirmed in Breyer (C-582/14, 19 October 2016). The free-text message body is also personal data once it relates to an identified or identifiable person.

A bare-bones contact form is a personal data processing activity that needs the full Article 13 treatment.

Article 13 information: layered disclosure

Article 13 GDPR requires the controller to provide a defined list of information at the time when personal data are obtained. The EDPB allows layered disclosure: a brief first layer at the moment of collection, with a link to the full privacy notice as the second layer.

For a contact form, the first layer typically appears immediately above or below the submit button. Recommended minimum content:

BlockText pattern
Controller"Controller: [legal name], [registration number]"
Purpose"Purpose: handle the enquiry you send and respond to you"
Legal basis"Legal basis: Article 6(1)(f) GDPR legitimate interest, or Article 6(1)(b) precontractual measures if your enquiry relates to a future contract"
Recipients"Recipients: your message is processed only within [our organisation]; we use [email provider] as a processor"
Rights"Your rights: access, rectification, erasure, restriction, objection, portability"
Full notice link"Full information in our Privacy Notice"

The full privacy notice (second layer) covers the rest: transfers, retention periods, complaint right to the supervisory authority. For the privacy notice itself, the privacy policy generator guide covers the complete Article 13 list.

A form that has no information block and only a link buried at the bottom of the page does not satisfy Article 13. The first layer must be visible from the form.

Three Article 6 bases cover the contact-form universe, depending on the nature of the enquiry. Confusing them produces about half of the contact-form findings in supervisory authority decisions.

Article 6(1)(f) — legitimate interest

For a general enquiry with no immediate commercial intent. A visitor wants to know your opening hours, your services, your location. The processing is necessary for your ordinary business operations; the data subject has a reasonable expectation that you will read and respond.

When invoking legitimate interest, the controller must perform a balancing test (the "Legitimate Interests Assessment" or LIA) and document it. The EDPB's Guidelines 3/2024 on legitimate interest provide the operational test. The LIA does not have to be published; it has to be available on request from the supervisory authority.

Article 6(1)(b) — precontractual measures

For an enquiry that initiates a potential commercial relationship. Quote requests, demo bookings, first appointment with a service provider, RFP submissions. The visitor wants something that requires the data as a step toward a contract.

No checkbox required, no LIA required. The processing is necessary to take steps at the request of the data subject prior to entering into a contract.

Article 6(1)(a) — consent

Only required when the form does something beyond responding to the enquiry. Common patterns:

  • A "Subscribe to our newsletter" checkbox attached to the form
  • "Allow us to use your data for marketing" attached to the form
  • A loyalty programme opt-in
  • A field that allows sharing data with a partner or group company

Each separate consent is a separate purpose and needs its own unticked checkbox. Consent for marketing is never implied from a request for information.

When checkboxes are needed, and what they must look like

Three rules from Planet49 (C-673/17) and EDPB Guidelines 05/2020:

  1. Unticked by default. A pre-ticked box does not produce valid consent under Article 4(11) GDPR.
  2. One purpose per checkbox. A single checkbox covering "I accept the privacy policy and want to receive newsletters" combines two distinct purposes and is not specific consent. The user has no granular control.
  3. The submit button is not a consent action. Clicking Submit signals that the form is being submitted; it does not signal consent to additional processing beyond the form's stated purpose.

For pre-checked boxes specifically, the practice has been confirmed illegal since the Planet49 ruling in October 2019. It still appears regularly in audits.

Minimum data: a real test, not a slogan

Article 5(1)(c) GDPR imposes data minimisation: only adequate, relevant and limited data may be collected.

For a contact form, the practical test is:

  • Name: required, supports a respectful response
  • Email: required, the response channel
  • Message: required, the actual enquiry
  • Phone: optional unless the response requires a phone callback (e.g. urgent service request)
  • Company name / role: optional unless the form serves B2B with specific routing
  • NIF/VAT number, postal address: optional unless the enquiry concerns a quote that requires it
  • Date of birth, gender, demographics: virtually never justified for a contact form

Each required field needs a documented reason. "We might want this data later" is not a reason; it is the kind of statement that surfaces in inspections and converts into a finding.

Server-side logging: do it, but document it

Most form handlers automatically log the IP, timestamp and user agent of the submission. This is personal data processing under Recital 30 GDPR and Breyer.

To handle it lawfully:

  • Declare server-side logging as a separate processing activity in the Article 30 record
  • Set a short retention (30-90 days for security logs)
  • Use legitimate interest as the legal basis (security and abuse prevention)
  • Restrict access to administrators only
  • Reference the log in the second-layer privacy notice ("We log technical metadata of form submissions for security purposes")

Failing to declare and limit the log is the secondary failure mode after the missing Article 13 block.

Retention periods

The data flowing through a contact form has multiple retention paths:

CategoryTypical retentionReason
Message body and contact details (not converted to contract)12 months from last communicationLegitimate interest, follow-up
Message body and contact details (converted to contract)Contract lifecycle + national law (5-10 years)Contract performance, accounting
Logs (IP, timestamp, user agent)30-90 daysSecurity and abuse prevention
Newsletter signup attached to formUntil unsubscribeActive consent
Marketing opt-in attached to formUntil withdrawalActive consent

Indefinite retention of contact form messages because "they might be useful one day" is a violation of Article 5(1)(e) storage limitation. Build the deletion schedule into the form-handler database from day one.

Recurring failure modes in supervisory authority decisions

These patterns appear in published decisions of national supervisory authorities across the EU.

No Article 13 information at the form. The privacy notice is linked from the page footer, with no visible information block at the form itself. The most common failure.

Pre-ticked consent box for marketing. Settled illegal since Planet49 in October 2019, still common in 2026 audits.

Consent bundled with the privacy policy acceptance. "I have read the privacy policy and consent to marketing" as a single checkbox.

Automatic newsletter signup. The contact form's email field is added to the newsletter list automatically. Breach of Article 6(1)(a) GDPR and the ePrivacy Directive Article 13 on direct marketing.

Excessive required fields. Date of birth, full postal address, marital status required for a simple contact enquiry. Minimisation violation.

Logs retained indefinitely. Server-side log of every submission with no rotation. Storage limitation violation and an unmanaged inventory of personal data.

Form provider not declared as processor. Typeform, Tally, Google Forms or a similar SaaS handles the form. The provider is a processor; an Article 28 DPA must be in place and the provider must appear in the privacy notice. Often missing. See the DPA guide.

Cross-border transfer not disclosed. The form provider hosts in the US under the DPF; the privacy notice does not mention the transfer or the DPF mechanism.

Implementation patterns

WordPress with a plugin

Plugins like Contact Form 7, WPForms, Gravity Forms and Fluent Forms support custom information text below the form fields and optional checkboxes. Minimum configuration:

  • Add a text block with the first-layer Article 13 information
  • Add optional checkboxes (unticked) for any marketing or third-party consent
  • Configure the recipient address and disable the auto-reply unless it includes only confirmation language
  • Limit plugin-side log retention (most plugins offer a database table for submissions)
  • Add the plugin to the Article 30 register if it stores submissions in the WordPress database

SaaS form builders

Tools like Typeform, Tally, JotForm and Hubspot Forms ask for the form data in their own platform. Each:

  • Acts as a processor for the controller (the website owner)
  • Requires an Article 28 DPA, accepted via the platform
  • Has its own retention rules and security profile to declare
  • Usually involves cross-border transfer (US-hosted with EU regions optional)

Some, like Tally, default to EU hosting. Others, like Typeform, host in the US under the DPF.

Custom form on first-party infrastructure

If the form is built on the same backend as the website, the form data lives entirely under the controller. This simplifies the processor map but increases the security responsibility: the controller is now operating the form-handler directly.

For the broader compliance map of contact-form processing, the GDPR compliance checklist covers the controls that surround the form.

Final checklist

  • First-layer Article 13 information block visible at the form
  • Link to the full privacy notice from the form area
  • Correct legal basis identified per enquiry type (legitimate interest, precontractual, or consent)
  • For consent-based extras: unticked checkbox, separate for each purpose
  • Only adequate, relevant and limited fields required
  • Server-side log declared in the Article 30 register with short retention
  • Form provider, if a SaaS, has an accepted DPA and appears as a recipient in the privacy notice
  • Cross-border transfer mechanism declared if applicable
  • Retention schedule defined and implemented (not "as long as necessary")
  • Right-of-access channel reachable from the form area or footer
  • No automatic newsletter signup from contact form submissions

This is technical analysis, not legal advice. For internal whistleblowing forms, health-related forms, forms used in regulated sectors or active supervisory authority investigations, consult a lawyer who specialises in data protection.