Every field in an inquiry form is data you become responsible for afterwards — you have to store it safely, be able to explain why you collect it, and eventually delete it. The more fields you add "just in case," the more responsibility with no real benefit, and often fewer completed forms too, since people give up partway through a long list.
On this page: what the data minimisation principle from GDPR actually means, a simple three-question test for every field in your form, which data a service business most often collects without needing it yet, and how to gather the rest gradually, at the stage where it genuinely becomes necessary.
The GDPR data minimisation principle
UODO's guide — the Polish data protection authority — quotes Article 5 GDPR directly: personal data must be adequate, relevant and limited to what is necessary for the purposes for which it is processed — that is the data minimisation principle. The same article adds two more principles that apply just as directly to a form: data must be accurate and, where necessary, kept up to date, and stored in a form permitting identification of the person for no longer than necessary for the purpose for which it was collected (storage limitation).
Three principles, three questions
The minimisation principle means data must be limited to what's necessary. The accuracy principle requires data to be current and correctable. The storage limitation principle means data must be deleted when no longer needed. These three principles translate to three questions for each field: why do we need this data, how long will it stay current, and when will we delete it?
Three principles give you three questions to ask about every field before you keep it in the form: what specific purpose does this field serve right now, will the data in it stay accurate or need updating, and how long does it actually make sense to keep. A field with no answer to the first question shouldn't stay in the form.
How to check every field in your form
In practice this is a simple table you fill in once for the whole form, then return to whenever something changes:
| Field | Purpose now | What happens without it | When we delete it |
|---|---|---|---|
| Name and phone or email | callback about the inquiry | can't respond to the client | after the inquiry is handled, or per retention policy |
| Short description of the issue | matching the reply, initial quote | you'd need to ask again by phone from scratch | same as contact data |
| Full home address | crew travel to the site | can't schedule a visit | with the order data, once it's closed |
| Date of birth / national ID | issuing a contract or a named invoice | can't produce the legal document | per document-retention rules, not "just in case" |
The "what happens without it" column matters most: if the honest answer is "nothing happens, we'd just have more data," the field gets removed from the form, not just from the table.
Fields collected just in case by service businesses
At first contact — when a client is only asking about price or timing — a service business usually doesn't need: a full home address (a district or city, if anything, is enough), a date of birth, a national ID number, a scan or photo of an identity document, or a mandatory "how did you hear about us" field — that's data useful for marketing, not for answering the question at hand. None of these fields is forbidden by itself; the question is whether it's needed at this particular stage of the conversation.
When the same data becomes necessary
A home address matters once a crew is actually travelling there — that's the booking stage, not the price-inquiry stage. Full invoicing details are needed when issuing the sales document, not before. A date of birth is sometimes legally required for specific services (certain financial or medical services, for instance) — collected at the stage where the rule actually requires it, not preventively at the first click.
Why the "how did you hear about us" field is usually unnecessary
This field collects data useful for marketing, not for answering the client's question. If a business wants to know where clients come from, it can track this in Google Analytics or ask by phone — but it doesn't need to be a mandatory field in the first-contact form.
The fine against Glovo: where "just in case" leads
UODO's decision of 16 March 2026 shows where collecting data just in case leads. The operator of the Glovo app (Restaurant Partner Polska) obtained scans and photos of users' identity cards or passports for identity verification without a legal basis. The head of UODO found that the controller processed excessive data, without a legal basis and inadequate to the stated purposes, breaching among other things the data minimisation principle under Article 5 GDPR — and imposed a fine of 5 898 064 zł, also ordering deletion of the data collected this way within 30 days of the decision being served.
One line from the decision's reasoning is worth remembering word for word: fraud prevention cannot come at the cost of breaching the data minimisation principle. The practical takeaway for a small service business: "might come in handy" is never a standalone purpose for processing data.
Free-text fields and special-category data
A free-text field in a form has its own trap: people write more in it than the question calls for, sometimes far more than a company should have at all. In an "describe your issue" field, clients can mention illness, family circumstances, a conflict with another person — special-category data that needs extra protection and its own legal basis for processing.
The practical fix isn't removing the field — it's often the most useful one in the whole form — but a short hint next to it, like "describe briefly what this is about; we'll go into detail by phone," which naturally limits what people type there. If special-category data ends up in the field anyway, the decision on how to handle it — whether it can be processed at all and on what basis — is worth checking with a data protection officer, if the company has one, or a GDPR-specialised lawyer.
Fewer fields, more completed forms — a hypothetical example
Shortening a form has a practical side effect beyond legal compliance — fewer people abandon it midway. A hypothetical example, plug in your own assumed numbers: a form on a site is seen by 200 people a month who start filling it in.
A difference of 70 inquiries a month on the same traffic. This isn't an industry norm or a guarantee — it's an illustration of the mechanism: every extra field is another moment someone can close the tab.
Gradual data collection across stages
Instead of asking for everything upfront, data gets collected across the steps a conversation with a client naturally goes through anyway:
Scenariusz po godzinach:
- 01inquiry (contact + topic)
- →02phone call
- →03quote or booking (address, tax ID)
- →04contract
At the inquiry stage itself, the form only needs what lets you call back and understand what it's about. An address appears once you actually need to plan a visit, and full invoicing details only when the document itself is issued.
Hidden places where data gets collected
The minimisation principle applies to a contact form, but it applies exactly the same way to a chatbot on your site, a conversation in a messenger app, an AI reception line answering calls, and a "notes" field in a CRM where a staff member types down everything a client said. These are places where personal data piles up often unnoticed.
Poland's Ministry of Digital Affairs notes that the AI Act does not replace GDPR — the two apply in parallel. A chatbot that honestly says it's AI still has to follow the minimisation principle in what it collects.
Requests that never became clients
Not every inquiry ends in a contract, and that's normal — but data from inquiries that led nowhere is still subject to the storage limitation principle: kept for no longer than necessary for the purpose for which it was collected. The purpose of an inquiry that went nowhere expires at some point — and it's the company itself that decides when, and writes that decision down as policy.
The specific period — three months, six, a year — depends on the industry and on how realistically a client might come back to the topic; that's a decision worth setting jointly with a data protection officer or lawyer.
What to do yourself in 30 minutes
This audit needs no tool beyond the form itself and a sheet of paper:
- Take a screenshot of your current inquiry form — every field, including the hidden or optional ones.
- List each field in the table from earlier: purpose now, what happens without it, when we delete it.
- For every field without a clear answer to the first question, make a call: drop it from the first step, or move it to the stage where it actually becomes necessary.
- Submit a test inquiry through your own form and check exactly where that data lands and who has access to it.
What it looks like when a system collects the data
The scenario where data collection is designed in stages:
- 01short form
- →02CRM card
- →03missing data requested at the right stage
- →04reminder about the retention deadline
What's left for a person is the decision about which field is genuinely needed at each stage, and what retention period to set for inquiries that never turned into a contract — the system makes sure those decisions are applied consistently. CRM and automations bring phone, form, messengers and your Google Business card into one place. Lead forms let you build short forms with conditional logic, where the next question depends on the previous answer. Websites and stores with shorter forms usually go with a clearer site built around one decision the visitor has to make — order, book, or call. UX and conversion helps find where customers drop off, including long forms. AI Chatbot answers questions after hours and collects contact data. Customer Data merges information from different sources into one profile.
If you're wondering why people don't finish filling out forms at all, see why customers don't leave inquiries. About where customer data physically ends up, read automation and GDPR. About handling all requests from one queue, we write in query handling automation. About how quoting can take an hour instead of three days, read quote automation. About what happens to inquiries after the first conversation, see follow-up automation.
Frequently asked questions
Does the data minimisation principle mean a form should have as few fields as possible?
Not exactly — it means every field must have a specific purpose it's necessary for. Sometimes that means fewer fields, sometimes just a different moment to collect them: you move data from the first step to the stage where it genuinely becomes necessary, instead of asking for everything at once.
Is a "how did you hear about us" field forbidden?
It isn't forbidden by itself, but it's rarely necessary to answer a client's question — it's data useful for marketing, not for handling the inquiry. If you want to collect it, do so deliberately, with a clear purpose, rather than automatically in every form.
How long can you keep data from an inquiry that never became a client?
UODO's guide talks about storage limitation for as long as necessary for the purpose of processing, but doesn't give a specific number of days or months — the company itself sets the period and writes it down as policy, ideally after consulting a data protection officer or lawyer.
Does special-category data typed into a "describe your issue" field have to be deleted right away?
There's no single ready answer — it depends on whether a legal basis exists for processing it in that context. That decision is worth checking with a data protection officer or lawyer, rather than making it on your own while handling a single inquiry.
Does an AI chatbot on a site have to follow the same rules as a form?
Yes. The GDPR data minimisation principle applies to every place where a company collects personal data, whether that's a form, a chatbot, or a conversation in a messenger app. The AI Act adds a separate transparency obligation — a chatbot has to clearly say it's AI — but it doesn't replace data protection rules.
Does the fine against Glovo apply to small service businesses too?
The size of a fine depends on the scale of the breach and many other factors, but the principle UODO confirmed in that decision applies to every data controller: fraud prevention or "just in case" safety doesn't justify collecting more data than necessary for the purpose.
Does a conditional logic form help with data minimisation?
Yes. A multi-step form with questions that depend on previous answers shows users only fields relevant to their situation. Someone asking only about pricing doesn't see fields needed for booking an appointment. This implements the minimisation principle directly in the form design — you only ask what's actually needed in each scenario.