Calendly provides the processor-side contract GDPR asks for, and it is already in place. Its data processing addendum is incorporated into its Terms of Use, and Calendly states plainly that there is nothing additional for you to sign — accepting the Terms puts the DPA in effect. It self-certifies under the Data Privacy Frameworks and falls back to Standard Contractual Clauses if a Framework stops working. The unresolved questions are about your booking form and your connected calendar.
This article covers how the DPA attaches, how the transfer position is built, what the subprocessor list gives you that most do not, and the two places where scheduling tools quietly collect more personal data than anyone recorded.
The DPA Is In The Terms, With Nothing To Sign
Calendly's help centre states the position directly: it has incorporated a data processing addendum into its Terms of Use, there is nothing additional for you to sign or execute, and by accepting the Terms the DPA is already in place. The addendum itself is published at calendly.com/legal/data-processing-addendum, describes itself as incorporated into the Customer Terms between you and Calendly LLC, and carried an effective date of 1 June 2026 when we checked.
That is Article 28-sufficient and it removes a common source of delay. It also creates the familiar evidence problem: your contract is a document that can be revised, and what binds you is the version live when you agreed. Calendly's own materials note the addendum has been updated over time, including to add the UK Addendum. Record the date you accepted the Terms and keep a copy of the addendum as it then stood, in your processor file alongside everything else. Our guide to data processing agreements covers what the document needs to contain.
Two obligations in the addendum are worth quoting back at a reviewer, because they are the ones buyers actually ask about: Calendly commits to assisting you with your obligations under Articles 32 to 36, and to maintaining a record of the categories of processing carried out on your behalf under Article 30(2). We checked these pages on 7 August 2026.
Transfers: Framework First, Clauses Behind It
Calendly is a US company and its transfer position is built in two layers.
The addendum provides that transfers of customer personal data out of the EU, Switzerland or the UK to the United States are governed by the applicable Data Privacy Framework, and that Calendly is self-certified under them. If a Framework is invalidated or otherwise ceases to work as a transfer mechanism, the addendum provides that such transfers are instead governed by the Standard Contractual Clauses — Module 2, controller to processor — together with the UK Addendum where UK data is involved.
Two details are worth recording alongside that. The addendum names the Irish Data Protection Commission as the competent supervisory authority for the Clauses and picks Irish law and Irish courts, which is the answer to a question buyers occasionally ask and almost nobody has ready. And Calendly's privacy notice states that it has designated representatives in the European Economic Area and in the United Kingdom — the Article 27 mechanism giving European individuals and supervisory authorities a contactable point in their own jurisdiction, with contact details published in the notice.
One more thing that is genuinely useful and easy to miss. Calendly's help documentation points customers to request a transfer impact assessment FAQ covering US law. If you need to write a transfer impact assessment and have been putting it off because you do not know what to say about the importer, ask for that document.
A Subprocessor List That Answers The Right Questions
Calendly publishes its subprocessor list in its help centre, and the format is better than most.
Each entry carries not only the subprocessor and its processing activity, but a data protection officer contact and data centre locations. Most published lists give you a name and a purpose and leave you to find out where the processing happens; this one answers the residency question inline. Calendly also offers a subscription so you are notified when the list changes, and states that its subprocessors have signed DPAs.
Sign up for the notifications, and note why this one is not optional. The addendum gives thirty days' notice of a new subprocessor — but only to customers who have subscribed, and it states that a customer who does not subscribe waives any right it may have to receive prior notice of subprocessor changes. That is unusually blunt, and it means the two minutes it takes to subscribe is the difference between a contractual right and no right at all.
If you do subscribe, you have thirty days from notification to object by email on reasonable data protection grounds, silence counts as consent, and if the objection cannot be resolved you may terminate the affected portion of the Services without penalty. Our guide to subprocessor management covers how to review those notices without it becoming a standing meeting.
Invitee Data Is Yours, And There Is More Of It Than You Think
Here is where the compliance work actually sits.
You are the controller for everyone who books with you. That is not controversial and Calendly's documentation reflects it. What gets missed is how much personal data a booking page accumulates without anyone deciding to collect it.
A default booking collects a name and an email address, which is unremarkable. Then someone adds a custom question. "What would you like to discuss?" is a free text field into which people type things — a health condition before a consultation, an accessibility requirement, a dispute with an employer, a financial situation.
And here the contract bites, in a way most write-ups miss. Calendly's addendum records that, per the Customer Terms, you are not permitted to submit personal data to the Services that counts as sensitive personal information or special categories of data. So the problem with a free text field inviting health disclosures is not that you need an Article 9 condition. It is that you are not supposed to be putting that data there at all, and doing so puts you outside the terms you agreed to as well as outside your own lawful basis.
That reframes the fix. The answer is not "find a justification," it is "do not ask the question, or ask it somewhere built for the answer." Three things follow, and none of them are vendor problems. Every custom question is a collection decision that needs a purpose. Free text fields are where prohibited categories arrive, so the field itself is the control. And the bookings accumulate: a page that has run for two years holds everyone who ever met you, with whatever they typed, until somebody decides otherwise.
Worth knowing while you audit the fields: the categories the addendum contemplates now extend beyond names and emails to personal data in connected calendar event details, and to audio and visual meeting recording data and anything shown on screen during a meeting. If recording features are in use, the scope of what you are controller for is wider than a booking form.
The Calendar Connection Nobody Documents
The second gap is subtler and almost never appears in a processing record.
A scheduling tool works by reading your calendar to find out when you are free. That calendar contains other people's meetings — colleagues, clients, candidates, the people you had lunch with — and none of those people ever visited your booking page or agreed to anything. The connection is the core function, not an add-on, and it is the reason the product is useful.
It is not a theoretical concern, either. Calendly's own addendum lists personal data contained in connected calendar event details among the categories of personal data transferred, so the contract already contemplates the calendar's contents being in scope.
This is worth a sentence in your record and a moment's thought about scope. Which accounts are connected. Whether the connection is read-only or writes events back. Whether anyone has connected a personal calendar to a work account. These are not exotic questions, but they are the ones that come up when a regulator or a customer asks what a scheduling tool can see, and "it checks my availability" is not a description of a data flow.
Common Mistakes With Calendly And GDPR
Inviting sensitive answers in a free text field. The addendum records that customers are not permitted to submit special category data to the Services at all. "What would you like to discuss?" is where that rule gets broken, and the fix is the question, not a justification.
Leaving bookings forever. Nothing ages out on its own. Set a retention period for invitee records and enforce it, including anywhere you exported them.
Ignoring the calendar connection. The tool reads a calendar containing people who never used it. Document what is connected and with what scope.
Not subscribing to subprocessor updates. The addendum states that a customer who does not subscribe waives the right to prior notice of changes. Two minutes of setup buys you a contractual right you otherwise do not have.
Embedding without reading Exhibit D. If you embed Calendly on your site, its addendum treats you and Calendly as separate and independent controllers of the cookie data collected there — a different relationship from the processor terms covering bookings, with different obligations on each side.
FAQ
Do I need to sign a DPA with Calendly?
No. Calendly states that it has incorporated a data processing addendum into its Terms of Use, that there is nothing additional for you to sign or execute, and that accepting the Terms puts the DPA in place. Record the date you accepted and keep a copy of the addendum as it then stood.
Does Calendly rely on the Data Privacy Framework or SCCs?
Both, in order. Its addendum provides that transfers out of the EU, Switzerland or the UK to the United States are governed by the applicable Data Privacy Framework, under which Calendly self-certifies, and that if a Framework is invalidated the Standard Contractual Clauses apply instead — Module 2 for controller to processor, with the UK Addendum where relevant.
Who is the controller for my invitees' data?
You are. Calendly acts as processor for the booking data you collect, which means the lawful basis, the retention period, the wording of your custom questions and the handling of any erasure request are all yours. Calendly's subprocessors are published with their processing activities and data centre locations.
Can I use Calendly for appointments involving health or other sensitive topics?
Not for collecting the sensitive detail itself. Calendly's addendum records that, per the Customer Terms, customers are not permitted to submit personal data to the Services that constitutes sensitive personal information or special categories of data. So a booking question inviting someone to describe a health condition is a contractual problem as well as a lawful basis problem. Scheduling the appointment is fine; capturing the diagnosis in a free text field is not.
Closing Thought
Scheduling tools are trusted in a way their data footprint does not really justify. Booking a call feels like an administrative act rather than a disclosure, so nobody treats the confirmation page as a privacy notice and nobody wonders where the answer to "what would you like to discuss?" ends up. It ends up in a list, indefinitely, alongside everyone else's.
The fix is not a different scheduling tool. It is deciding what your booking page asks for, how long you keep the answers, and being able to say so when someone asks. ComplyDog gives you a compliance portal on your own domain covering your DPA, your subprocessor list, your data subject request intake and your security page. It will not audit your booking questions. It will mean that when an invitee asks what you did with what they told you, there is somewhere to send them.
