GDPR and Web Forms: What Compliance Actually Requires

Most web forms collect personal data, which means most web forms fall under the GDPR. Yet compliance issues on forms are rarely the result of anything complicated. They usually come down to a few principles applied inconsistently: no clear lawful basis, consent that was never valid, or data collected and then kept with no plan for deleting it.

This guide sets out what the GDPR actually requires of a web form, in plain terms, and gives a practical checklist you can hold your own forms against. It is written for marketing and operations teams rather than lawyers, so it focuses on the decisions you make when you build and run forms, not on legal theory.

This article is practical guidance, not legal advice. Confirm specifics with your data protection officer or legal team.

What the GDPR requires of a web form

Every time a form collects personal data, that processing needs a lawful basis. The GDPR sets out six lawful bases under Article 6, and for web forms three of them do most of the work: consent, contract, and legitimate interests.

Consent is the most familiar basis and also the most fragile. It suits marketing sign-ups and optional data collection, but it has to be earned properly to count. Contract covers processing needed to deliver something the user asked for, such as a demo request or an order. Legitimate interests can apply to expected follow-up, for example a genuine enquiry form, but only after a documented balancing test that weighs your interest against the user’s privacy.

The practical point is that the basis should be chosen and documented before the form goes live, not decided after the fact. Picking consent by default, when contract or legitimate interests would be more appropriate, creates work and risk that a moment of planning avoids.

Consent done right

Where consent is the basis, the GDPR is specific about what makes it valid. Article 7 and the surrounding definitions require consent to be freely given, specific, informed and unambiguous. In practice that translates into a handful of rules that are easy to check.

• Use an unticked box. Consent needs an affirmative action, so pre-checked boxes do not count. The user has to actively opt in.
• Keep it separate and specific. Bundle nothing. Consent to be contacted about a demo is not consent to receive a newsletter. Ask separately for separate purposes.
• Make it plain. The request has to be in clear, plain language, distinguishable from other terms, so the user understands what they are agreeing to.
• Make withdrawal as easy as opt-in. Users have the right to withdraw consent at any time, and doing so must be as simple as giving it was. A one-click opt-in cannot require a phone call to reverse.

There is a further requirement that is easy to overlook: you have to be able to prove consent was given. That means logging the timestamp, the exact wording shown to the user, and the affirmative action taken, then storing that record so it can be produced if a regulator asks. Consent you cannot evidence is, in practice, consent you cannot rely on.

The cost of getting this wrong is not theoretical. The French regulator fined Google €50 million in part because its consent was judged not to be informed, specific or unambiguous. The lesson is that the detail of how consent is requested matters as much as the fact of asking.

Language and clarity

Consent and privacy information have to be understandable to the people giving them, which has a direct consequence for forms serving more than one market. A consent notice shown only in English to an audience that does not read English can fail the plain-language test, regardless of how well drafted the English is. If a form is localised, its consent wording should be localised with it, not left in the source language.

Data rights and retention

Collecting the data is only the start of the obligation. The GDPR gives people rights over their data, and forms are where much of that data enters the business, so the two are linked.

Two rights matter most for form data. The right of access means you must be able to find what a person submitted. The right to erasure means that if someone asks you to delete their data, or withdraws the consent it was collected under, you need to be able to identify and remove that submission promptly. If form submissions disappear into scattered inboxes and spreadsheets, meeting these requests becomes slow and unreliable.

Retention is the other half. Data minimisation is a core GDPR principle: collect only what you need, and keep it only as long as you need it. Setting a retention period appropriate to the purpose, and deleting data when that period ends, is both good practice and a way to reduce the volume of data you have to protect in the first place.

A practical GDPR forms compliance checklist

Held against any individual form, these are the questions worth answering.

• Is the lawful basis identified and written down, rather than assumed?
• If consent is the basis, is the box unticked, the request specific, and the language plain?
• Can the user withdraw consent as easily as they gave it?
• Is consent logged with a timestamp and the wording shown, so it can be evidenced?
• Is the consent wording in the same language as the form?
• Does the form collect only the fields it genuinely needs?
• Is there a defined retention period, and a way to delete a submission on request?
• Is the form submitted over HTTPS, so the data is encrypted in transit?

Keeping forms compliant at scale

A single form is straightforward to get right. The difficulty appears when an organisation runs dozens or hundreds of forms across teams, campaigns and regions. Each one is a place where consent wording can drift, a field can be added that should not be collected, or a retention rule can be missed. Compliance that depends on every team remembering every rule on every form does not hold for long.

This is where treating forms as a managed estate rather than a scatter of individual builds pays off. When the consent mechanics, the field standards and the retention rules live in a governed template, every form inherits them by default, and a change can be made once and applied everywhere. The compliance baseline stops being a matter of memory and becomes part of how forms are built.

This is the problem Formulayt is built to solve: managing web forms at scale with governance, consent handling and compliance built into the platform rather than bolted onto each form. If keeping a large form estate compliant is becoming difficult to sustain, our form governance and compliance capabilities are a sensible place to start.

Frequently asked questions

If a form collects personal data from someone in the EU or UK, then yes. Personal data includes names, email addresses and anything else that can identify a person, so most contact, sign-up and lead forms are in scope. The GDPR requires a lawful basis for collecting it and gives the person rights over how it is used.