Contact form privacy policy: GDPR basics and notice wording

Write one or two sentences explaining how you will use the submission, then make Privacy Policy a working link to the full details. Put the notice where someone can read it before sending the form. The examples below illustrate different uses; their retention periods and promises should only appear in your notice if they match your practice.

Three mini examples you can adapt:

• General enquiry: “We use your name, email, and message only to reply to you and keep the conversation for 12 months. Read our Privacy Policy for details and your rights.”
• Quote request: “We use these details to prepare your quote and follow up about it. If you become a customer, we keep them as part of your account. See our Privacy Policy.”
• With a newsletter option: “We use your details to reply to you. Tick the box if you also want our monthly newsletter; you can unsubscribe at any time.”

Make Privacy Policy a working link to the full document. Keep the notice visible, not hidden in a tooltip, and make sure it matches what actually happens. If messages are forwarded to a CRM or kept for two years, say so. For broader placement rules, read where to put a privacy policy link.

Personal data means any information relating to an identifiable person. A contact form collects that by design: a name, an email address, sometimes a phone number or company, and a free-text message that can contain almost anything. Behind the scenes, the form tool or server may also record the sender's IP address, browser details, and submission time.

That has three consequences:

1. You need to tell people what happens to their data. Under GDPR Article 13, the information must be given at the time you collect it.
2. Every provider in the chain counts. The form plugin or service, your email provider, your CRM, and any spam filter all process the message.
3. US laws can apply too. CalOPPA covers commercial websites that collect personally identifiable information, such as names and email addresses, from California residents.

If you are still deciding whether your site needs a policy at all, the answer for nearly every site with a form is yes. Our guide do I need a privacy policy? explains the legal triggers in more detail.

The GDPR's data minimisation principle in Article 5 says personal data must be adequate, relevant, and limited to what is necessary for the purpose. For a contact form, the purpose is replying to the person, so ask yourself what you genuinely need to do that.

A practical field checklist:

• Email address: required, because you need it to reply.
• Name: often useful, but consider making it optional or a single field.
• Message: required, with a hint not to include sensitive details.
• Phone number: optional unless you actually call people back.
• Company, budget, or project type: only if you use them to route or answer the enquiry.
• Date of birth, ID numbers, health details: almost never appropriate on a general contact form.

Every field you remove is a field you do not need to secure, retain, or explain. If you run a specialist service, such as a clinic or a law firm, add a line asking people not to send sensitive details through the form, and offer a more secure channel for that.

Many sites add a consent checkbox to every form by reflex. The UK regulator's guidance suggests that is often the wrong tool. Two other lawful bases in Article 6 usually fit better:

• Contract, Article 6(1)(b): the ICO explains that this basis covers processing necessary to take specific steps at a person's request before entering into a contract. A quote request or a question about buying your service is a typical example.
• Legitimate interests, Article 6(1)(f): for general enquiries, feedback, or press questions, replying is a legitimate interest that people expect. The ICO describes a three-part test: a legitimate purpose, necessity, and a balance against the person's interests.

The ICO's consent guidance warns that asking for consent is misleading when you would process the data anyway, because there is no real choice. Someone who sends you a question clearly expects a reply.

Marketing is different. Answering an enquiry does not cover adding the person to a newsletter. If ePrivacy rules require consent for the marketing message, consent is usually also the right lawful basis for it.

Usually not for replying to the message. A mandatory “I agree to the privacy policy” checkbox can actually blur things, because it suggests consent is your lawful basis when it is not, and because a privacy policy is information, not a contract people need to agree to.

Where a checkbox does make sense:

• Newsletter or marketing opt-in: use a separate, unticked checkbox, and do not make it a condition of sending the message.
• Optional extras: for example, permission to publish a testimonial or to share the enquiry with a partner.
• Special category data: if you genuinely need sensitive information, explicit consent may be one of the conditions you rely on.

Remember that pre-ticked boxes do not create valid consent under the GDPR. If you want an acknowledgement for the privacy notice, a simple sentence with a link next to the submit button does the job without pretending to collect consent. When in doubt about a specific form, the GDPR privacy policy generator page explains how lawful bases are reflected in a generated policy.

The full policy is where the detail goes. Add a section, or a row in your data table, that covers:

1. What you collect: the fields on the form, plus anything collected automatically, such as IP address and submission time.
2. Why: to respond to the enquiry, and any follow-up purposes such as preparing a quote.
3. Lawful basis: typically pre-contract steps or legitimate interests, and consent only for optional marketing.
4. Who receives it: the form provider, email host, CRM, help desk, and spam protection service.
5. Transfers: whether any of those providers process data outside the UK or EU, and the safeguard used.
6. Retention: how long messages are kept.
7. Rights: access, correction, deletion, and objection, and how to ask.

If you also run a newsletter, chat widget, or booking form, give each its own short entry rather than lumping everything under contact. The ICO's guidance on what privacy information to provide is a good cross-check for the required items.

The GDPR's storage limitation principle says personal data should be kept no longer than necessary for the purpose. No law sets a single number for contact form messages, so you set a period you can justify and then stick to it.

Common approaches:

• General enquiries that go nowhere: delete after a fixed period, such as 6 to 12 months after the last reply, long enough to handle follow-up questions.
• Enquiries that turn into customers: keep them as part of the customer record for as long as the relationship and your legal record-keeping duties require.
• Spam and abusive messages: delete promptly, unless you need them for security.
• Form entries stored in your website database: many form plugins keep a copy of every submission in addition to the email. Set the plugin to delete entries automatically or clear them regularly.

Write the period into your privacy policy and set reminders or automatic deletion so the policy stays true. Remember backups and email archives, which often keep copies longer than the inbox.

Yes. Spam protection tools process data about the people who use your form, so they belong in your privacy policy.

reCAPTCHA: Google's reCAPTCHA FAQ states that from April 2, 2026, customers are the sole data controller of the data processed, references to Google's Privacy Policy and Terms were removed from the reCAPTCHA badge, and customers should review their own end-user privacy disclosures to make sure they cover the security, fraud, and abuse prevention purpose. The FAQ still allows hiding the badge if you visibly tell users the site is protected by reCAPTCHA. It also notes that reCAPTCHA sets a necessary cookie for its risk analysis.

Other services: hCaptcha, Cloudflare Turnstile, and anti-spam plugins each process form data or device signals. Name the service you use and describe its purpose.

Honeypot fields and rate limits are lighter alternatives that run on your own server and involve no third party, although they may be less effective against determined bots. Whatever you choose, describe it in plain words: what is checked, by whom, and why.

Your contact form is rarely a single tool. A typical setup chains several providers together, and each one belongs in your policy.

• Form plugin or form service: stores submissions, sometimes on its own servers.
• Email delivery: sends notifications to your inbox through your host or a transactional email service.
• Inbox and CRM: where messages live long term, such as a shared mailbox, help desk, or sales CRM.
• Automations: tools that copy entries into spreadsheets or chat channels.

Where a provider processes data on your behalf, the GDPR's Article 28 requires a contract with processor terms, usually the provider's data processing addendum. List these providers by name or category in your policy, and keep the list current when you switch tools.

Legal Policy Generator's questionnaire lets you pick third-party services such as Mailchimp, HubSpot, Zendesk, Intercom, SendGrid, reCAPTCHA, and hCaptcha, and it selects matching clauses from your answers. The questionnaire, preview, and simple HTML download are free. Our guide to creating a privacy policy for a website covers the rest of the document.