GDPR-Compliant Forms in Laravel: A Practical Checklist | FilaForms [ ![Filaforms Logo](https://filaforms.app/logo.svg)FilaForms ](https://filaforms.app) [ Features ](https://filaforms.app#features) [ Pricing ](https://filaforms.app#pricing) [ Blog ](https://filaforms.app/blog) [ Documentation ](https://docs.filaforms.app) [ Try Demo ](https://filaforms.app/login) [ Get Started ](https://filaforms.app#pricing) [ Features ](https://filaforms.app#features) [ Pricing ](https://filaforms.app#pricing) [ Blog ](https://filaforms.app/blog) [ Documentation ](https://docs.filaforms.app) [ Try Demo ](https://filaforms.app/login) [ Get Started ](https://filaforms.app#pricing) ![FilaForms](https://filaforms.app/logo.svg) FilaForms TutorialsGDPR-Compliant Forms in Laravel: A Practical Checklist ====================================================== filaforms.app/blog [ Back to blog ](https://filaforms.app/blog) [ Tutorials ](https://filaforms.app/blog/category/tutorials) GDPR-Compliant Forms in Laravel: A Practical Checklist ====================================================== Manuk Minasyan · June 2, 2026 · 8 min read I pushed a contact form to prod on a Friday for a Berlin client. Monday morning the stakeholder pinged me: "Is this GDPR-compliant?" Most form plugins answer with a marketing page. "Trust us, we're privacy-first." That isn't an answer. It's a brand promise. Before going further: I'm not a lawyer. Your DPO has final say. None of this is legal advice. It's a developer's checklist — six habits I run through when building a GDPR-compliant form in Laravel. It gets you 90% of the way there. The last 10% is a conversation with legal counsel. Most things that get a form flagged aren't subtle. They're the same five or six mistakes repeated across every framework. Laravel doesn't protect you. Filament doesn't. FilaForms doesn't either — what it does is stay out of your way so the habits below are easy to follow. What makes a Laravel form GDPR-compliant? ----------------------------------------- A Laravel form is GDPR-compliant when it collects only the data you need, on a lawful basis you can name, with the user's informed consent where required, and with a defensible plan for storage, deletion, and transparency. The framework isn't the regulator. Your habits are. The three principles in plain English ------------------------------------- Strip [the GDPR](https://gdpr.eu/) down to what affects a form and you get three rules. **Lawful basis.** You need a reason you're allowed to collect this data. For most public forms that's consent or contract. "Because it's useful" isn't on the list. **Minimization.** Collect what you need. Not what might be useful. The data you don't collect is data you can't lose, can't be asked to delete, and can't be subpoenaed. **Transparency.** Tell the user what you're collecting, why, where it's stored, and how long you'll keep it. Before they hit submit, not three clicks deep in a policy nobody reads. Everything below is the practical version of these three rules. Checklist item 1: Explicit consent checkbox ------------------------------------------- ### A separate, unchecked checkbox that names one purpose Add a consent checkbox to any form collecting personal data on a consent basis. Not pre-ticked. Not bundled with the submit button. Not bundled with the newsletter opt-in. One checkbox per purpose, each unchecked. The label should read: "I agree to {company name} processing my email and message to respond to this enquiry." Link "processing my email and message" to your privacy policy. No legalese. The common mistake is bundling. One tick meaning "subscribe to the newsletter AND agree to data processing AND accept the terms" isn't valid consent under the GDPR — any auditor will flag it on sight. Split them. One purpose per box. If consent is your only lawful basis and the user doesn't tick the box, you don't get to store the submission. That's the trade-off. Checklist item 2: Data minimization ----------------------------------- ### Don't ask for what you won't use this week If you can't name what you'll do with a field within seven days, drop it. "Annual revenue" on a contact form? Drop it. "How did you hear about us?" before the user knows what you do? Drop it. I've written more on this in [the lead-form template that drops most fields](/blog/lead-generation-forms-in-laravel-a-template-that-converts) — the same instinct applies for privacy as it does for conversion. The field you don't collect is the field you don't have to defend, store, audit, or delete. The test I use: for every field, can I write one sentence about what happens to that data in the next workflow? If the answer is "we might use it for segmentation eventually", drop it. Add it later, on a profile page, with a clear purpose. Checklist item 3: Tell them where it goes ----------------------------------------- ### A boring microcopy line under the submit button One line below the submit button: "We use this to respond to your message. Stored on our EU servers, deleted after 24 months. Request deletion at hello@yoursite.com." That sentence is boring. It also does more for trust and compliance than any cookie banner you'll ship. It names the purpose, the location, the retention period, and an action. If submissions are forwarded out of your stack — to a CRM, to Slack, to a partner endpoint — name that too. Anywhere [the outgoing webhooks layer](/blog/webhooks-in-filaforms-send-submissions-anywhere) sends data, the user has a right to know. Hiding it is the problem. Checklist item 4: Right to deletion ----------------------------------- ### A documented process, even if it's manual A user can ask you to delete their data. You have one month to comply, and you have to confirm the deletion happened. You don't need a self-service "delete me" button in version one. You do need a process: an email inbox, an admin action that locates submissions by email, confirmation back to the user, a log entry. Manual is fine. Undocumented is not. In a FilaForms install this maps to a filter in the submissions resource — filter by email, bulk-delete, log the action somewhere durable. Because submissions live in your database, you control the deletion. The [UK ICO's guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/) is a clear read on the timelines and what a defensible response looks like. What you don't want: a "we'll get back to you" reply with no internal owner. Checklist item 5: Don't ship third-party trackers in the form ------------------------------------------------------------- ### Self-host fonts, avoid reCAPTCHA, gate analytics behind consent A lot of "GDPR non-compliance" comes from third-party scripts the developer didn't think of as trackers. reCAPTCHA loads from Google's domain, sends fingerprints, and counts as a data transfer to a US processor. Google Fonts served from `fonts.googleapis.com` does the same. Analytics is the obvious one. EU regulators have fined sites for embedding Google Fonts directly. That's the bar. Self-host the fonts. Use [Cloudflare Turnstile](https://developers.cloudflare.com/turnstile/) instead of reCAPTCHA — no Google fingerprinting, the docs are short. Gate analytics behind an explicit consent step, or use a privacy-respecting alternative that doesn't store IPs or persistent cookies. Rule of thumb: if a script on your form page makes an outbound request to a US ad-tech vendor before consent, that's a problem. Audit your network tab once. You'll find at least one surprise. Checklist item 6: Logs and retention ------------------------------------ ### A defined retention period and a scheduled cleanup Pick a retention period. 24 months is a reasonable default for contact-form data. Some categories need shorter. None should be "forever". Document the period in your privacy policy. Then build a scheduled Laravel command — `php artisan submissions:prune` — that deletes submissions older than the window and runs nightly. The command is fifteen lines. Schedule it in `routes/console.php`. The hard part isn't the code; it's deciding the period and writing it down. The same applies to logs. If your app logs request payloads, those logs include form submissions. Rotate them. Set a retention. A defined retention policy is one of the first things a competent auditor asks for. What FilaForms gives you for free --------------------------------- FilaForms is GDPR-friendly by default. Compliance is a habit, not a feature. What you get: submissions live in your database, not a third-party SaaS. Analytics are session-fingerprinted with a daily-rotating SHA-256 hash — no IP, no PII. No third-party trackers, no Google Fonts, no reCAPTCHA bundled with the plugin. Data never leaves your stack unless you send it somewhere. What you don't get: a per-form retention policy with a built-in scheduled prune. That's on the roadmap; it isn't shipped yet. Today retention is something you build with a scheduled job — the fifteen-liner from checklist item 6. I'd rather be honest than ship a half-baked toggle. FAQ --- ### Is FilaForms GDPR-compliant? FilaForms is GDPR-friendly by default — self-hosted, no third-party trackers, no PII in analytics — but compliance is a property of how you use it, not the plugin. The six habits above are what make a specific form compliant. ### Where is form submission data stored? In your Laravel app's database, on whatever infrastructure you run. FilaForms doesn't host submissions. If your database is in the EU, your submissions are in the EU. ### How long can I keep form submissions? As long as you can defend in your privacy policy and no longer. A common default is 24 months for contact-form data. Pick a period, document it, enforce it with a scheduled deletion job. ### Do I need a DPA with FilaForms? FilaForms is self-hosted; we don't process your submissions, so a DPA for the plugin usually isn't required. You may need one with any third-party service you forward submissions to. Check with your DPO. The takeaway ------------ GDPR-compliance for forms isn't a feature you buy. It's six habits — consent, minimization, transparency, deletion, no trackers, retention — applied to every public form. Get them right and the regulatory question stops being a blocker. FilaForms makes the habits easier because the data lives in your stack. You control consent copy, retention, and deletion. Nothing happens off-platform unless you decide it should. Coming up: [the WCAG 2.2 walkthrough](/blog/accessibility-for-laravel-forms-wcag-22-in-practice) — the other regulatory question that lands in your inbox the week after this one. Related posts ------------- [ Tutorials May 22, 2026 Stop Spam in Laravel Forms: Honeypot, Rate Limits, and Smarter Defaults ------------------------------------------------------------------------- reCAPTCHA isn't the answer. Or at least, it's not the first answer. Here's the layered approach we use to keep junk out of FilaForms submissions. ](https://filaforms.app/blog/stop-spam-laravel-forms-honeypot-rate-limits) [ Tutorials Apr 30, 2026 File Uploads in Filament Forms: Storage, Validation, and Security ------------------------------------------------------------------- File uploads are where most form builders cut corners. They'll let you add a file field and call it done, leaving you to figure out storage and validation ](https://filaforms.app/blog/file-uploads-in-filament-forms-storage-validation-and-security) [ Tutorials Mar 30, 2025 Conditional logic in Laravel forms: when fields should show (and hide) ------------------------------------------------------------------------ How to build forms where fields appear based on previous answers. Covers Filament's reactive forms, Livewire approaches, and common patterns. ](https://filaforms.app/blog/conditional-logic-in-laravel-forms-when-fields-should-show-and-hide) ![FilaForms Logo](/logo.svg) FilaForms Laravel form infrastructure for Filament. Stop rebuilding forms on every project. ### Product [ Features ](https://filaforms.app#features) [ Documentation ](https://docs.filaforms.app) [ Blog ](https://filaforms.app/blog) [ Pricing ](https://filaforms.app#pricing) [ Contact ](mailto:hello@filaforms.app) ### Legal [ Terms of Service ](https://filaforms.app/terms-of-service) [ Privacy Policy ](https://filaforms.app/privacy-policy) © 2025-2026 FilaForms. All rights reserved. [ ](mailto:hello@filaforms.app) [ ](https://x.com/MinasyanManuk)