Back to blog
Blog
End the booking chaos today.
30-day free trial. No credit card required.
Blog
30-day free trial. No credit card required.
There is a moment in every board meeting. Someone suggests finally organizing bookings digitally, and then someone else says the word: "Privacy." A short silence. Everyone nods gravely. And the topic is postponed.
In companies the same sentence just sounds different. There it is not about the training room but about the pool vehicles, and the question goes: "Are we even allowed to record which employee had which car and when?" Here too the usual answer is an awkward pause, and the key rack stays.
That is understandable, but a shame. Because first, the legal situation around booking data is far less dramatic than most people fear. And second (this is the real punchline), the solution you stick with out of caution is usually the more problematic one under data protection law.
This article gives you practical orientation: what you may do, what you should avoid, the five questions to ask any vendor, and what additionally applies to company vehicles.
Note: This is practical orientation, not legal advice. If you have specific doubts, especially if your fire department is part of the municipality or you have a works council, talk to your supervisory authority, your data protection officer, or a specialist lawyer.
The moment somebody reserves the training room, you are processing personal data. That is neither unusual nor a problem. It just needs a legal basis, and you have one.
Whoever makes a booking wants to complete a transaction: they reserve something, you confirm it. Recording their name and a way to contact them is not nosy data collection, it is what that transaction requires. For the internal organization of your resources, you also have a legitimate interest of your own in knowing who had which vehicle and when.
What you may not do: use the same data for something else afterwards. More on that in a moment; it is by far the most common mistake.
For a room booking you need exactly two things in the vast majority of cases: a name and an email address. Plus the time period and perhaps a purpose ("summer party, football section").
What you almost never need: date of birth, full postal address, phone number, membership number. The temptation is strong to build a form "properly, once" and include every field that might be useful later. That is exactly the point where a harmless booking list turns into a data collection you have to justify.
Rule of thumb: for every field you should be able to say in one sentence why you need that detail for this booking. If you cannot, drop the field.
This is where the classic mistake happens. Over two years you accumulate 300 email addresses from people who once booked the clubhouse. And then the summer party comes around, and somebody has the obvious idea: "We do have all those addresses …"
No. Data collected to process a booking may not simply be reused for advertising or newsletters. Reserving the barbecue is not consent to receive club mail.
If you want a mailing list, collect a separate, active consent for it, for example a separate, non-pre-ticked checkbox with clear wording. That is not bureaucracy for its own sake: a list of people who actually agreed is a list that actually gets read.
Personal data may not be stored forever. A booking from spring 2023 serves no purpose today, unless something is attached to it that you are required to keep (an invoice, for instance, if you rented out the room).
Set a simple rule and write it down: "Bookings without billing relevance are deleted after 12 months." A rule like that is exactly what separates a maintained booking system from a spreadsheet that has been growing since 2019 and that nobody touches any more.
Who can actually access your booking list? With the shared spreadsheet in a cloud folder, the honest answer is often: anyone who ever received the link, including the three people who left the club back in 2022.
Two things help immediately:
Anyone who books with you is entitled to know who receives the data, what for, how long it is stored, and whom to contact. In practice that means: a short, linked privacy notice right on the booking page. Not hidden in the legal notice, but where the form is.
Part of this is being able to respond to requests: what do you have stored about me? Please delete it. If you can answer that with a handful of clicks, you have the topic under control. If you have to search three spreadsheets and two WhatsApp threads, you do not.
As soon as you use a tool that keeps your data on someone else's servers (so basically any cloud solution), that vendor processes data on your behalf. For that you need a data processing agreement (DPA). The vendor has to offer you one; you do not have to draft it yourself.
The five questions to ask any vendor:
If a vendor starts flailing at these questions, that is your answer.
Two side notes that come up often in clubs and associations: a dedicated data protection officer is only required once at least 20 people are regularly and permanently engaged in automated data processing, which applies to very few clubs. A record of processing activities, by contrast, you will need in practice almost always, because the exemption for small organizations only covers occasional processing, and member or booking data is not "occasional." And if your fire department belongs to the municipality organizationally, state data protection rules apply on top. In that case have a quick word with the municipality's data protection officer before you roll anything out.
With pool vehicles, vans, and demo cars, a layer is added that does not exist in a club: the people in your booking list are your employees. And data about employees is viewed more strictly than data about guests, simply because an employment relationship carries an imbalance of power.
Even so, the reassurance comes first here too: you may record who had which vehicle and when. In fact you need to be able to. As the registered keeper you need that attribution when a fine arrives in the post, when damage to a vehicle turns up, or when it has to be established who was driving at the time of an accident. A traceable vehicle booking is not a surveillance instrument, it is the basis for meeting your obligations as a keeper at all. Organize this with a key rack and magnetic tags and you simply do not have that traceability, and three weeks later you are left wondering who actually took the estate car on the 14th.
What matters is the line between organization and behavioral monitoring. These four points make the difference:
1. Purpose limitation, particularly important here. Booking data may serve vehicle dispatch, not performance assessment. "Who had which car when" must not turn into an analysis of who had the most appointments, who was on the road longest, or who supposedly blocks the vehicles most often. The moment booking data becomes metrics about people, you have left the purpose you collected it for.
2. The works council has a say. This gets overlooked regularly: technical systems that are capable of monitoring employee behavior or performance are subject to co-determination, regardless of whether you intend to use them that way. A booking system that logs per person can fall under this. So involve the works council early, not after the rollout. In practice that is not an obstacle but a shortcut: a short works agreement setting out purpose, access rights, and retention periods ends the discussion for good, instead of reopening it with every question.
3. Booking is not tracking. A booking plan says who reserved a vehicle. A telematics or GPS system says where that vehicle currently is and how it is being driven. Those are two completely different levels of intrusion with completely different requirements. Do not blur them out of convenience. And if you run telematics anyway, treat it as its own topic with its own legal basis.
4. Not everyone needs to see every name. For the colleague who needs a car at short notice, only one piece of information matters: taken or free. Who exactly booked it is something the fleet manager needs to know, not the entire workforce. A system that shows everyone the full history of names collects no additional data, but makes it unnecessarily broadly visible. That is the point where harmless dispatch and an uncomfortable working atmosphere part ways.
Retention periods work differently here than in a club: you should keep vehicle bookings for as long as fines, damage, or liability questions can realistically still surface, and delete them after that. That is typically longer than for a room booking, but it is not unlimited either. Set the period once, write it down, and let it run automatically.
One more note for the common case where pool vehicles may also be used privately: private trips are none of your business content-wise. You need the booking itself, period and vehicle, for dispatch; details about the purpose of the trip you do not.
We have written up how to set up pool vehicles cleanly in more detail here: Managing pool vehicles: goodbye key rack and Excel sheet. And our page for company cars shows what a shared car pool looks like day to day.
And now to the point that surprises most people.
Out of privacy concerns, many organizations stick with the tried and tested setup: bookings run through the WhatsApp group, the overview lives in a spreadsheet that circulates by email, and in a company the key rack hangs on the wall on top of that. It feels safer because it is familiar.
Except that is precisely the constellation with the biggest problems:
A properly set up booking system is not the risky step under data protection law. It is the step that turns an uncontrolled situation into a controlled one, with clear fields, clear deadlines, and one place where everything lives.
Additionally for company vehicles:
Because we built Dispoly for clubs, fire departments, and businesses, this was planned in from the start:
You can try all of this free for 30 days, without payment details: get started. And if someone on your board, or in IT, on the works council, or your data protection officer, looks closely at this topic: all the better. Those are exactly the questions we are happy to answer in a personal demo.