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 good news: you may
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.
Principle 1: only ask for what you actually need
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.
Principle 2: booking data is not a mailing list
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.
Principle 3: old bookings have to go
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.
Principle 4: not everyone needs to see everything
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:
- Personal accounts instead of shared passwords. A shared board login cannot be revoked when somebody leaves.
- Roles instead of full access. The groundskeeper needs to see the booking plan; they do not need to be able to export the contact details of every guest from the past year.
Principle 5: tell people what happens
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.
The point almost everyone misses: data processing agreements
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:
- Do we get a data processing agreement, and where do we find it?
- Where are the servers, and who are the sub-processors?
- How do we get at our data at any time (export)?
- What happens to the data if we cancel?
- How does the system support us with access and deletion requests for individuals?
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.
Special case company vehicles: when booking data becomes employee data
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.
The uncomfortable truth about the WhatsApp group and the key rack
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:
- The group contains names, phone numbers, and appointments, all processed through a service you have neither a DPA with nor any control over the data flows. Leaving the group does not remove you from the history.
- In a company, work-related vehicle coordination then runs over private mobile numbers. Employees do not have to hand over their private number for work purposes, and a group where everyone sees everyone's number is exactly that.
- The spreadsheet exists in five versions on five machines. Retention periods? Access control? Neither.
- You cannot realistically answer an access or deletion request completely, because nobody knows where all the copies are.
- And the key rack documents nothing at all: when the fine arrives, you have no defensible attribution whatsoever.
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.
The short checklist
- Only ask for name, email, period, and purpose, and justify every additional field
- Do not use booking data for newsletters (get separate consent for that)
- Define a deletion rule and write it down
- Personal accounts instead of a shared password, roles instead of full access
- Link the privacy notice right on the booking page
- Obtain the DPA from your vendor and file it
- Create a record of processing activities (one-off, manageable)
Additionally for company vehicles:
- Involve the works council early, fix purpose and retention in a works agreement
- No analyses about individuals from booking data: dispatch is the purpose, not performance control
- Names only for the fleet manager, "taken / free" is enough for everyone else
- Keep booking and telematics/GPS separate
How Dispoly handles this
Because we built Dispoly for clubs, fire departments, and businesses, this was planned in from the start:
- Less data from the outset: your members do not need an account to book. Where no account is created, no account data is created either. From guests we capture name, email address, booking period, plus optional notes and the custom fields you define yourself, so you decide how lean the form stays.
- Hosting in the EU: database and backend sit in the EU region, as does error logging, and product analytics runs via European servers in Frankfurt. Where providers outside the EU are involved, transfers are covered by standard contractual clauses or the EU-US Data Privacy Framework; every provider we use is named in our privacy policy.
- Clear deadlines: server logs are deleted or anonymized after 30 days at the latest, booking data once the transaction is complete and no retention obligations stand in the way.
- Traceable instead of improvised: vehicles, rooms, and equipment sit in the same plan as resources with a category and a location. When the question comes up three weeks later of who had the van on the 14th, the answer is in the reservation, not on a magnetic tag that has long since been moved.
- Your data belongs to you: the CSV and Excel export gives you full access to your reservations and resources at any time, including when you want to leave.
- Reliable requests without registration: guest verification by email (optionally with a PIN) makes sure bookings are genuine without anyone having to create an account.
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.