A basic contact form does not automatically need a box saying “I accept the privacy policy.” It does need accurate information about what will happen to the data, and every purpose needs a suitable lawful basis.
The common mistake is to treat the checkbox as the legal basis. A checkbox can record consent, but consent is only one of the six bases in Article 6 GDPR. If a person asks for a quote or appointment, processing the fields needed to answer may instead be necessary to take steps at that person’s request before a contract under Article 6(1)(b). In another limited context, a controller may assess legitimate interests under Article 6(1)(f).
Choose the basis before designing the form. Do not add consent to make an uncertain process look safer.
Separate the purposes
Consider a form with four possible uses:
| Purpose | Typical question |
|---|---|
| Reply to the enquiry | What fields are necessary to answer what this person asked? |
| Prepare a quote or booking | Are the fields necessary for pre-contractual steps requested by the person? |
| Add the person to marketing | Is there a separate, optional, channel-specific permission? |
| Collect health or other special-category data | Which Article 9 condition applies, and should this information be collected through a public form at all? |
One submit button can start the requested conversation. It should not silently enrol the person in a newsletter or authorise unrelated processing.
What the form must explain
Articles 12 and 13 of the GDPR require clear information when data is collected. A short first layer beside the form can identify:
- the controller;
- the purpose of the form;
- the lawful basis;
- the main recipients, if relevant;
- the retention period or the criteria used to set it;
- how to exercise rights; and
- a link to the full privacy notice.
The Spanish Data Protection Agency recommends a layered approach in its guide to the duty to inform: concise information at collection, with a second layer containing the remaining details.
A basic request form might therefore say:
Controller: Example Ltd. Purpose: answer your enquiry and, if requested, prepare a quote. Basis: steps taken at your request before a contract. Retention: until the enquiry is resolved and for any period needed to handle resulting claims. Rights and more information: Privacy Policy.
That text is only an example. The controller, purpose, basis, recipients, and period must match the real service.
When a separate checkbox is useful or required
Use a separate, unticked choice when you actually rely on consent for an additional purpose, such as:
<label>
<input type="checkbox" name="marketingConsent" />
Email me product updates. I can withdraw this consent at any time.
</label>Consent must be freely given, specific, informed, and unambiguous. It cannot be bundled into a required acceptance if marketing is not necessary to answer the enquiry. The EDPB consent guidelines explain why pre-ticked boxes, inactivity, and tied consent fail that standard.
Special-category data needs a separate Article 9 analysis. Explicit consent under Article 9(2)(a) is one possible condition, but it is not the only one. For example, health professionals may rely on Article 9(2)(h) and Article 9(3) where their circumstances and applicable national law satisfy those provisions.
A release check for developers
Before publishing a form:
- List each purpose separately.
- Remove fields that are not necessary.
- Record the Article 6 basis for each purpose.
- If special-category data is involved, record the Article 9 condition.
- Put the first privacy layer beside the form.
- Keep optional marketing consent separate and unticked.
- Test that refusing marketing does not block the main request.
- Ensure the full policy matches the form.
GDPR.Direct can generate a draft information clause from your business details. You still need to verify that the draft matches the fields, purposes, vendors, and retention rules in the live form.
This article is educational information, not legal advice.
