A scheduling link starts as one person's convenience. Nobody reviews it, because it is a link. Then it ends up on the pricing page, in the email signature of eleven people, and embedded on the site. At some point somebody in security or legal asks what it is doing with the data it collects.
That conversation goes badly when it is the first time anyone has thought about it. It goes fine when you already know the answers. This is the list, and what each question is really trying to establish. It is the companion to the audit of whether the tool works at all: different reviewer, different questions, and for anyone selling into a company of any size, this is the one that blocks the purchase.
What a booking link actually collects
Start here, because most teams under-estimate it by a wide margin. A scheduler with an intake form is not collecting a name and an email. It is collecting:
- Identity: name, work email, often a company and a role
- Everything the intake form asked, which is frequently commercial information the person would not put in a first email
- Calendar metadata for every host connected to it, which is a window into an employee's working day
- IP address and timezone, usually inferred rather than asked for
- A behavioural record: what they looked at, what they abandoned, when they rescheduled
The third one surprises people. Connecting a calendar does not just read free and busy. Depending on the scopes granted, it can read event titles, attendees and locations. That is your own staff's data, not the booker's, and it belongs in the review too.
The questions, and what they are really asking
1. Where is the data stored, and does it leave the region?
The literal question is about geography. The real question is whether a transfer mechanism is needed, and whether anybody has thought about it. A vendor that answers with a region name and nothing else has not.
What a good answer contains: the region, whether it can be pinned, what happens to backups, and which sub-processors touch the data on the way. That last one is where most surprises live.
2. Who is the controller and who is the processor?
This sounds like paperwork and is the question that determines everything else. If you are the controller, the obligations to the booker are yours: the privacy notice, the lawful basis, the response when somebody asks for their data back.
The trap: a scheduler that also uses the data for its own purposes, whether that is analytics across customers, model training or product improvement, is acting as a controller for those purposes, whatever the contract calls it. Ask directly whether the data is used for anything other than delivering the service to you.
3. Is there a DPA, and can we actually get it?
A data processing agreement is table stakes for anything holding personal data on your behalf. The signal is not whether one exists, because everybody says one exists. It is whether it is available without a sales call, whether it names the sub-processors, and whether there is a way to be told when that list changes.
4. How long is it kept, and can we set that?
Most tools keep everything forever, because deletion is work and storage is cheap. That is a growing liability: a booking from four years ago, with the answers attached, is data you have no purpose for and still have to protect.
Ask whether retention is configurable, what happens to a booking when the workspace is deleted, and whether deletion is real or a flag on a row that stays in the database.
5. What happens when a booker asks for their data?
Access and erasure requests are the ones that arrive without warning and have a clock on them. If the answer is that somebody exports a CSV by hand, that is workable at your current volume and will not be later.
6. Which calendar scopes does it request?
This is the question almost nobody asks, and it is the one with the widest blast radius, because it concerns your employees rather than your prospects.
There is a real difference between a tool that reads free/busy and one that reads full event details. Both let you avoid double-booking. Only one of them can see that your head of sales has a meeting titled 'Acme renewal, churn risk' on Thursday.
Ask for the exact scope strings, not a description of them. A scope string is a fact; a description is a summary written by the vendor.
7. Where does the AI go, if there is any?
Scheduling tools have started scoring, summarising and enriching bookings. All three usually mean sending the booker's answers to a model provider.
The questions that matter: which provider, whether the data is retained by them, whether it is used for training, and whether the feature can be turned off entirely while the rest of the product keeps working. If scoring cannot be disabled, it is not a feature, it is a condition of use.
How to run the review in an afternoon
- Write down what your intake form asks for, field by field. This is the actual scope of the problem and it is usually larger than remembered.
- Pull the privacy policy and the DPA. If the DPA needs a sales conversation, note that as an answer in itself.
- Check the calendar scopes on the connection screen, not in the marketing copy.
- Ask the vendor the seven questions above in one email. Response quality tells you as much as the responses.
- Decide what you would do if a booker asked for everything you hold on them tomorrow. If there is no answer, that is the finding.
What good looks like
A vendor that can answer all seven without a call, in writing, with specifics rather than reassurance. Scope strings quoted verbatim. A sub-processor list you can subscribe to. Retention you can configure. An AI feature you can switch off.
None of that is exotic. It is the difference between a tool built by people who expected this conversation and one that has not had it yet. You will find out which you have long before your security team does, simply by asking.