GDPR-compliant form submissions: what you actually need to know
If your form collects names, emails, or anything else that can identify a person, and any of your visitors are in the EU, GDPR applies. This post is a practical, non-lawyer guide to what that means for the people building and operating the form. It's not legal advice - for the genuinely tricky cases, talk to a lawyer who specializes in EU data protection. But for the 90% of cases (a contact form on a marketing site, a newsletter signup, a beta-access waitlist), the rules are simpler than the stack of consent banners suggests.
The five things GDPR cares about for forms
- Lawful basis - you need a justification for why you're collecting the data.
- Transparency - visitors need to know what you're collecting, why, and what you'll do with it.
- Data minimization - only collect what you actually need.
- Storage and processing - keep the data secure and only as long as needed.
- Subject rights - visitors can request a copy, correction, or deletion of their data.
Most form-handling failures are in 1, 4, or 5. Transparency and minimization are usually fine if you're being honest.
Lawful basis
You need one. The two that apply to most forms:
Legitimate interest (contact forms)
If someone fills out a "contact us" form, you have legitimate interest in receiving and responding. You don't need explicit consent. Document this in your privacy policy with a one-line "we use your submitted data to respond to your inquiry."
Consent (newsletter, marketing)
If the form's purpose is to add the person to a newsletter, marketing list, or send unsolicited follow-ups, you need explicit, opt-in consent. Pre-checked boxes don't count. The opt-in must be:
- Specific - checkbox for newsletter, separate checkbox for marketing emails.
- Unbundled - can't tie consent to a service the person is paying for.
- Withdrawable - must be easy to unsubscribe.
<label class="flex items-start gap-2">
<input type="checkbox" name="newsletter_consent" required value="1">
<span>
Yes, send me the Formspring newsletter. I can unsubscribe anytime.
</span>
</label>
Don't include checked by default. Don't bundle with the submit button.
What to put on the form itself
The minimum that satisfies GDPR transparency:
- A short notice near the submit button: "By submitting, you agree to our Privacy Policy."
- A link to your full privacy policy.
- For newsletter forms: explicit opt-in checkbox (see above).
For high-sensitivity data (health, finance, biometric), more is required - but those are special categories with their own rules.
Data residency: where is the data stored
GDPR doesn't require EU storage. It allows transfers to countries the EU has deemed "adequate" (UK, Switzerland, etc.) and allows transfers to other countries via Standard Contractual Clauses (SCCs).
In practice, for an EU-facing site, EU storage is the simpler path:
- Easy compliance: no SCCs to sign, no transfer impact assessments.
- Easy audit: data physically stays in the EU; supervisory authorities have jurisdiction.
- Marketing benefit: you can credibly say "EU data residency" on the privacy page.
Formspring stores submissions and files in EU regions only (Hetzner Falkenstein/Helsinki). US-hosted form backends require SCCs, transfer impact assessments, and continuous monitoring of US surveillance laws - that's an ongoing audit cost, not a one-time setup.
DPA (Data Processing Agreement)
If a third party processes personal data on your behalf, you need a Data Processing Agreement with them. Form backends, email senders, analytics, hosting - all are processors.
A proper DPA covers:
- The processor's role (processing on your instructions).
- The categories of data processed.
- Sub-processors (their contractors).
- Technical and organizational measures (security).
- Breach notification obligations.
- What happens to the data when you terminate.
Some US-hosted services lock the DPA behind their enterprise plan, which is annoying. Formspring includes a DPA on every paid plan; the German legal entity (Pixel & Process UG) signs it as the processor.
Retention: how long to keep submissions
The rule: only as long as you need them.
For a contact form: typically 30-90 days after the conversation ends. Once the inquiry is resolved, the data has served its purpose.
For a newsletter signup: as long as the person remains subscribed. When they unsubscribe, delete the record.
For an application form (job, beta access): retain until the application is decided + a reasonable period for record-keeping. Most companies use 6-12 months.
Formspring lets you set per-form retention rules: auto-delete after N days, with a manual override for retained leads. Free plan defaults to 30 days; Pro+ is unlimited with optional auto-delete-after-N.
Subject rights: what to do when someone asks
The rights:
- Access - give them a copy of their data.
- Rectification - fix incorrect data.
- Erasure - delete the data ("right to be forgotten").
- Portability - give them a machine-readable export.
- Objection - stop processing for direct marketing.
Practical setup:
- Have a
privacy@yourdomainemail that routes to whoever owns this. - Keep a way to find a person's data by email address (Formspring's dashboard search works).
- Have an export-and-delete script ready before you need one.
- Respond within 30 days. The clock starts the day you receive the request.
The privacy policy
You need one. Minimum sections:
- Who you are - legal entity, address, email.
- What you collect - list every form field, every analytics event, every cookie.
- Why you collect it - lawful basis, purpose.
- Who you share with - every processor (form backend, email sender, analytics, hosting).
- Where data is stored - region.
- How long you keep it - retention.
- What rights visitors have - access, deletion, etc.
- How to contact you - privacy email.
Don't copy-paste a generic template. Auditors notice. Write it for your actual site.
Cookies on the form page
The strict rule: any non-essential cookie or tracker requires opt-in consent before it loads.
The practical rule:
- Session cookies for the form (keeping form state through validation): essential, no consent needed.
- Cookieless analytics like Umami or Plausible (anonymous, no cookies): no consent needed under most EU DPA guidance.
- Google Analytics, ad pixels, anything with a cookie: explicit opt-in consent banner required.
Formspring uses Umami (cookieless, EU-hosted) for marketing analytics and zero tracking on dashboards. No consent banner needed on the form page itself unless your hosting site loads other trackers.
What good GDPR posture looks like in 2026
- EU-hosted form backend with a DPA.
- Honest privacy policy that lists every processor.
- Per-form retention rules.
- hCaptcha (not reCAPTCHA) as the spam-protection challenge.
- Umami, Plausible, or self-hosted Matomo instead of Google Analytics on form pages.
- Newsletter consent that's specific and opt-in.
- A documented process for subject access requests.
Most of these are zero-effort with the right tools and significant effort to build yourself.
Try Formspring free
EU hosting, DPA on every paid plan, configurable per-form retention, hCaptcha by default, Umami analytics (cookieless), no surprise data egress to US ad networks. Sign up - 50 submissions/month free, no credit card.
This post is not legal advice. For sensitive data, regulated industries, or large enterprises, consult a qualified data-protection lawyer.
Florian Wartner
Founder of Formspring and Pixel & Process. Senior Laravel and Vue engineer based in Lübeck, Germany. Building developer-first SaaS with EU data residency and honest pricing.