If you take appointments online, you process customer data, and there are rules for that. This article shows you which data a booking really needs, which legal basis holds, what to settle with your software provider, and what your booking page's privacy notice must say. It ends with a checklist. This is orientation for businesses, not legal advice.
Which data an online booking actually needs
A booking needs very little: a name, a way to reach the person, the service they want, and the time. That is it. A mobile number is usually enough as the contact, because confirmation and reminder run through it. An email address makes sense if you send receipts. Date of birth, postal address or title rarely have any place in a booking form.
Fewer fields are not only more convenient for customers, they are required: the GDPR calls it data minimisation, and it means you may only collect what you need for the purpose. Every field you leave out is one you never have to protect, explain or delete. A free-text notes field is handy, but ask yourself whether you need it. Customers often write more into it than you want to know.
- First and last name, so you know who is coming
- Mobile number for confirmation and reminder, one channel is enough
- Email address only if you send receipts or invoices
- Service, date, time and, where relevant, the preferred staff member
- No date of birth, no postal address, no mandatory notes field
Appointment booking and the GDPR: the legal basis is the appointment
Every processing of personal data needs a reason the GDPR recognises. For an appointment booking, the reason is close at hand: the appointment is a contract, or at least the run-up to one, and you need name, number and time to perform it. That is Article 6(1)(b) GDPR. You therefore do not normally need consent for the booking itself, and a checkbox saying "I agree to the processing of my data" does more harm than good.
Why harm: consent can be withdrawn at any time. If the booking rests on it, it rests on shaky ground. Performance of a contract, by contrast, holds for as long as the appointment exists. You need consent only for extras that have nothing to do with the appointment: newsletters, birthday messages, discount campaigns. Those get their own checkbox in the form, unticked, with their own wording.
A reference to the privacy notice still belongs next to the booking button. Not as a checkbox, but as a sentence with a link: information about how we process your data is in our privacy notice. That satisfies the duty to inform without asking customers to click anything.
The data processing agreement with your booking provider
As soon as a software provider stores customer data on your behalf, it is your processor. Article 28 GDPR requires a contract for that: the data processing agreement, often called a DPA. It sets out what the provider may do with the data, which sub-processors it uses, how it protects the data, and what happens when you cancel. Without a DPA you are processing data without the required footing, even if the provider itself does everything right.
With serious providers the DPA is there to read and is concluded when you create your account, with no paper and no signature. Still, read it once in peace. What you should look at fits on one hand. terminio.ai publishes its DPA under Article 28 GDPR openly, including sub-processors and technical measures, and its booking page asks for a name and mobile number only.
- Is there a DPA under Article 28 GDPR, and can you conclude it yourself?
- Which sub-processors are involved, for hosting, messaging or payment?
- Where is the data stored, and in which country do the servers sit?
- What happens to the data after cancellation: export, deletion period, confirmation?
- Which technical and organisational measures does the provider describe?
Where the data lives: why EU hosting matters
The GDPR applies wherever data of people in the EU is processed. The location still makes a difference. If the data sits on servers in the EU, European law applies to the operator directly, and you have no extra safeguards to check. If it sits outside, you need a basis for the transfer, depending on the country perhaps standard contractual clauses or an adequacy decision.
For you as a business that means: a provider hosting in the EU saves you checking work and a paragraph in your privacy notice. Ask not only where the company is registered, but where the servers are, and which sub-processors also see the data. A payment service such as Stripe or a messaging channel such as WhatsApp is often part of the setup and must be named in the notice.
The booking page privacy notice: what it must say
Your booking page needs its own privacy notice or its own section in the one you already have. It must be reachable from every step of the booking, usually in the footer. The text should be understandable, not legally exhaustive at any price. If you generate the notice with a tool, check afterwards whether the booking is even mentioned in it.
The mandatory information is listed in Article 13 GDPR. Translated to a booking page, it comes down to six points that should always be there. Write them so a customer understands them on first reading, and name the service providers rather than speaking vaguely of partners. One paragraph per point is enough.
- Who is responsible: your business with address and contact details
- Which data is collected: name, number, service, time
- What for and on what basis: arranging the appointment, performing the contract
- Which service providers are involved: booking software, payment, messaging
- How long data is kept and when it is deleted
- Which rights customers have: access, correction, deletion, complaint
Health data in practices: the appointment yes, the diagnosis no
Physiotherapy, dentistry, alternative medicine, psychotherapy: here the appointment itself is health information, because it points to a treatment. The GDPR treats such data as a special category under Article 9, with stricter requirements. That does not rule out online booking, but it calls for restraint: as little as possible in the booking, none of it in messages.
In practice: name services neutrally on the booking page where you can, and drop the free-text field for symptoms. What the patient has belongs in the conversation and the file, not in the booking form. Confirmation and reminder should give only date, time and practice. In health professions, a short consent for reminders by message is also the safer route, even though the appointment itself runs on the contract.
Deletion, cookies and the checklist to finish
Old appointments must not sit around forever. Storage limitation means: out they go once the purpose is served and no retention obligation applies. Invoices are subject to tax retention periods, the bare appointment is not. Set your own period, for example a set time after the last appointment, put it in the privacy notice and stick to it. Good software deletes or anonymises automatically when the period is up.
Cookies and analytics: a booking page needs none. Cookies that the booking itself requires, such as for the session, are allowed and need no banner. Tracking pixels, advertising cookies or analytics tools, on the other hand, need consent and bring you little on a booking page. Leave them out and you save yourself the banner and a risk.
- Form cut down to what is needed, no mandatory notes
- DPA concluded with the provider, server location clarified
- Privacy notice with a section on booking, reachable from every step
- Consent only for extras, in a separate checkbox, unticked
- Deletion period set and implemented in the software
- No analytics tools or advertising cookies on the booking page
