GDPR Compliance for Online Forms: A Practical Checklist

Most GDPR guides explain the regulation in the abstract. This one focuses on something more specific: what GDPR actually requires when you collect data through online forms, and what you need to check before you publish one.

If your organization collects data from individuals in the EU — through a contact form, a lead generation form, an event registration, or any other form that touches personal data — GDPR may apply to you, regardless of where your organization is headquartered.

This article is for informational purposes only and does not constitute legal advice. Consult a qualified data protection professional for guidance specific to your organization.

Who GDPR applies to

The General Data Protection Regulation (GDPR) applies to any organization that:

• Is established in the EU, regardless of where the data processing occurs, or
• Processes personal data of individuals in the EU, even if the organization itself is outside the EU, when that processing relates to offering goods or services to individuals in the EU or monitoring their behavior

This means a US-based company running a lead generation form that individuals in the EU can submit may be subject to GDPR if the conditions in Article 3 are met. A SaaS company with European customers that collects data through onboarding forms may fall under GDPR on the same basis. The regulation’s territorial scope is broad — if you offer goods or services to individuals in the EU, or monitor their behavior, GDPR may apply to you regardless of where your organization is headquartered.

What counts as personal data in a form context

Under GDPR, personal data is any information that can identify a natural person, directly or indirectly. In the context of online forms, this includes:

• Directly identifying data: name, email address, phone number, physical address, date of birth
• Indirectly identifying data: IP address (if collected at submission), device identifiers, location data
• Sensitive data (special categories): health information, religious beliefs, political opinions, racial or ethnic origin, biometric data — these are subject to stricter rules under Article 9 and require a specific condition from the Article 9(2) list to be met before processing is lawful

If your form collects any of the above, GDPR compliance requirements apply to that data.

Lawful basis: which one applies to your form?

GDPR requires a lawful basis for every instance of personal data processing (Article 6). For online forms, the most relevant bases are:

Consent — The data subject has given clear, specific, informed, and unambiguous consent. This is appropriate for marketing forms, newsletter sign-ups, and optional data collection. Consent must be freely given and as easy to withdraw as it is to give.

Contract — Processing is necessary for the performance of a contract, or to take steps at the request of the data subject before entering into a contract. This applies to order forms, booking forms, and service agreements.

Legitimate interests — Processing is necessary for the legitimate interests of the controller or a third party, provided those interests are not overridden by the rights and interests of the data subject. This requires a documented three-part balancing test (purpose, necessity, balancing). It is not a catch-all, and data subjects retain the right to object to processing on this basis under Article 21 — though controllers may override that objection if they can demonstrate compelling legitimate grounds that override the interests of the data subject.

Legal obligation — Processing is required by law. Applies to compliance forms, tax documentation, and regulatory filings.

Practical guidance: Most marketing and lead generation forms require consent as their lawful basis. Most transactional forms (purchases, bookings, contracts) rely on the contract basis. Using the wrong lawful basis — or claiming consent when the user had no real choice — is one of the most common GDPR violations.

Consent fields: what makes them GDPR-compliant?

If your lawful basis is consent, the mechanism for obtaining that consent matters. GDPR sets specific requirements:

What valid consent looks like:

• A clear, affirmative action — an unchecked checkbox the user must actively tick, not a pre-ticked one
• Specific to the purpose — separate checkboxes for separate purposes (e.g., one for processing the form submission, a separate one for marketing emails)
• Informed — accompanied by a brief explanation of what the data will be used for, and a link to your full privacy policy
• Freely given — the user must be able to submit the form without being forced to consent to unrelated processing, and there must be no imbalance of power or detriment for refusing consent

What invalid consent looks like:

• Pre-ticked checkboxes
• Consent bundled into terms and conditions acceptance
• “By submitting this form, you agree to…” without a separate explicit consent mechanism
• Consent to marketing combined with consent to process the enquiry — these must be separate
• Asymmetric visual design that nudges users toward consent — for example, a prominent “Accept” button paired with a grayed-out or hidden “Decline” or “Settings” option. GDPR authorities have consistently found that such dark patterns undermine the “freely given” requirement, even when a technical opt-out exists

Withdrawal of consent: GDPR requires that withdrawal be as easy as giving consent. For form-collected data, this means providing a clear opt-out mechanism and honoring deletion requests when consent is the sole lawful basis.

Data minimization: only collect what you need

GDPR’s data minimization principle (Article 5(1)(c)) states that you should collect only the personal data that is adequate, relevant, and limited to what is necessary for the stated purpose.

For form design, this means:

• Audit your fields — does every field serve the stated purpose? A contact form doesn’t need a date of birth. A webinar registration doesn’t need a phone number unless you plan to call attendees.
• Make non-essential fields optional — if a field is useful but not required, mark it as optional and don’t require it for form submission.
• Don’t collect data you don’t process — if you collect a field but never use it, it creates unnecessary compliance exposure.

Data minimization is also a practical benefit: shorter forms have higher completion rates. GDPR and good UX point in the same direction.

Data retention: how long can you keep form responses?

GDPR’s storage limitation principle (Article 5(1)(e)) requires that personal data is kept no longer than necessary for the purpose for which it was collected.

There is no single GDPR-mandated retention period — the appropriate duration depends on the purpose, applicable sector regulations, and member state law. The following table illustrates common considerations, but your specific retention periods should be determined in consultation with your data protection officer or legal counsel:

What this means in practice: You need a documented data retention policy, and your form submission data needs to be deleted or anonymized when the retention period ends.

PlatoForms gives you configurable data retention at the account level — from 0 days (data instantly removed after syncing to your cloud drive) to Forever, with options for 7 days, 30 days, 3 months, 6 months, 1 year, and 3 years in between. See the data retention policy documentation for setup details.

The right to erasure: what it means for submitted forms

Under GDPR, data subjects have the right to request deletion of their personal data (Article 17). For form-collected data, this means:

• If someone submits a contact form and later requests erasure of their data, you must be able to identify and delete their submission
• If consent is withdrawn, the data collected on the basis of that consent must be deleted (unless another lawful basis applies)
• Erasure requests must be handled without undue delay and in any event within one month (with the possibility of a two-month extension for complex cases, per Article 12(3))

Practical requirements:

1. You need to be able to identify submissions by individual (searchable by email or name)
2. You need to be able to delete specific submissions, not just bulk-clear your database
3. If submission data has been exported to other systems (CRM, cloud drive, email), those copies must also be deleted or anonymized — unless a separate lawful basis exists for retaining them in that system

PlatoForms allows you to search submissions and delete individual records from the dashboard. The Erase All Submissions feature handles bulk deletion when needed.

Your form builder as a data processor: what to require

Under GDPR, when you use a third-party form builder to collect personal data, that form builder is acting as a data processor on your behalf. You are the data controller. This creates specific obligations under Article 28.

You should have a Data Processing Agreement (DPA) in place with your form builder. A DPA is a contract that specifies:

• What data the processor handles
• The purposes and duration of processing
• Technical and organizational security measures
• Sub-processor disclosure and authorization requirements
• Obligations in the event of a data breach

Using a form builder without a DPA to collect EU personal data may put you in violation of GDPR requirements under Article 28, even if the form builder itself is technically secure.

Cross-border data transfers: If your form builder stores or processes data outside the EU/EEA, additional requirements under GDPR Chapter V apply — such as Standard Contractual Clauses (SCCs) or reliance on an adequacy decision. Confirm where your submission data is stored and what transfer mechanism is in place.

What to look for in a form builder:

• A DPA available for review and signature
• Data stored in known, disclosed locations (with EU data residency options where relevant)
• Sub-processor transparency (which third parties does the form builder share data with, and have you authorized their use?)
• Encryption in transit and at rest
• Access controls and audit logging
• A documented breach notification process

PlatoForms provides a downloadable Data Processing Agreement (DPA) and a full breakdown of security infrastructure, sub-processors, and certifications in the Trust Center.

GDPR compliance checklist for online forms

Before publishing any form that collects EU personal data:

Lawful basis

• Identify the lawful basis for processing (consent, contract, legitimate interests, legal obligation, or other Article 6 basis)
• Document the lawful basis — don’t rely on memory
• If using legitimate interests: complete and document a balancing test; ensure data subjects can exercise their right to object (Article 21)

Special category data

• If collecting sensitive data (health, religion, ethnicity, etc.), identify a specific condition under Article 9(2) — explicit consent is one option, but not the only one
• Apply appropriate additional technical safeguards for special category data (e.g. encryption, restricted access controls)

Consent (if consent is your lawful basis)

• Use unchecked checkboxes, not pre-ticked ones
• Separate consent for separate purposes (submission processing vs. marketing)
• Include a brief purpose description and a link to your privacy policy
• Ensure consent withdrawal is as easy as giving consent

Data minimization

• Audit every field — does each one serve the stated purpose?
• Make non-essential fields optional
• Remove fields you don’t actually process

Data retention

• Document your retention period for this form’s data (determined with legal/DPO input where needed)
• Configure automatic deletion or set a calendar reminder to purge old submissions
• Ensure your form builder supports configurable retention

Right to erasure

• You can identify submissions by individual
• You can delete individual submissions on request
• You have a process for handling erasure requests without undue delay and within one month

Processor and transfer requirements

• You have a signed DPA with your form builder
• You know where your form submission data is stored
• You know which sub-processors your form builder uses, and have authorized their use
• If data is transferred outside the EU/EEA, a valid transfer mechanism (SCCs, adequacy decision, etc.) is in place

GDPR compliance for forms is less about legal theory and more about operational decisions: what you collect, how you get consent, how long you keep it, and what agreements you have in place with your tools.

The checklist above covers the practical minimum. For complex processing scenarios — special category data, high-volume lead collection, cross-border data transfers, or legitimate interests assessments — a qualified data protection officer or legal counsel should review your specific setup.

For PlatoForms’ compliance documentation, downloadable DPA, and security architecture overview, see the Trust Center.