TimeTuna

GDPR checklist

Exactly where TimeTuna stands on GDPR, data residency, and data processing agreements, sorted by priority. What is done and how we do it, and what is not built yet. Last reviewed: August 27, 2026.

If you are weighing up TimeTuna for a business in the EU or the UK, this page is here so you do not need a sales call to get an answer. Every item is marked Done, In progress, or Not yet, and grouped by how much it matters. The Not yet items are real gaps we have not closed, listed on purpose rather than left for you to discover.

11
Done
2
In progress
7
Not yet
High priority: 7 of 11 done. The four still open are the data processing agreement, the legal entity it gets signed by, a consent gate for analytics, and confirming standard contractual clauses with each provider. The first two are paperwork rather than engineering, and they are the two we get asked for most.

High priority

The things an EU or UK business will check before it can buy, plus anything that puts personal data at risk today. These get worked on first. 7 of 11 done.

1. A data processing agreement (DPA) you can sign

Not yet
What it means. A contract required by GDPR Article 28 whenever one company handles personal data for another. When you use TimeTuna to book meetings with your clients, you are the controller of their data and we are your processor. The DPA commits us in writing to process it only on your instructions, keep it secure, disclose our sub-processors, help you answer requests from your own clients, and tell you about a breach. Many EU companies are not allowed to buy a tool without one.
Where we stand. We cannot countersign a DPA yet. This is our biggest gap. If you need one, email support@timetuna.com and we will contact you when it is ready.

2. A named legal entity and registered address

Not yet
What it means. GDPR requires the company responsible for your data to be identifiable by name and address, so you know who you are contracting with and who to complain about. It is also the thing a DPA is signed by, so nothing else on the contract side can finish until it exists.
Where we stand. Our privacy policy still carries a placeholder instead of a legal entity name and address. This has to be filled in before a DPA means anything.

3. Asking for consent before analytics and chat load

Not yet
What it means. Under the ePrivacy rules, anything that is not strictly necessary to run the site, such as analytics and support chat, needs the visitor to agree before it loads, not after. This one is high priority because it is not a missing document, it is something happening on every page view right now.
Where we stand. Today analytics, tag manager, and support chat start as soon as the page opens, with no consent step. A consent gate that holds them until a visitor agrees is designed but not built. We are weighing where it appears, because putting a banner in front of a guest who is trying to book a meeting costs bookings for the host.

4. Standard contractual clauses with our non-UK providers

In progress
What it means. Sending personal data to a country without an adequacy decision requires a specific legal safeguard. Standard contractual clauses are the usual one, and they have to be actually executed, not just offered in a provider terms page.
Where we stand. Each of our US providers offers these clauses in their own agreements. We are working through them one by one to confirm each is signed on our account rather than assumed.

5. Your core data stored in the UK, under EU adequacy

Done
What it means. Where the database physically sits decides which transfer rules apply. The UK sits outside the EEA, but the European Commission has ruled it offers adequate protection, so data can move from the EEA to the UK with no extra paperwork for as long as that decision holds.
Where we stand. Your accounts, booking pages, bookings, guest details, and connected calendar tokens are all in a database in London. Product analytics runs on an EU host. Email, SMS, and payments run on US providers.

6. A published list of every company that touches your data

Done
What it means. GDPR calls these sub-processors. You are entitled to know which third parties process data on our behalf, what each does, and where.
Where we stand. Published and kept current in our privacy policy: Supabase (database, login, file storage), Vercel (hosting), PostHog (analytics), Loops.so (email), Stripe (payments), Twilio (SMS), Google, Microsoft and Zoom (calendars and meeting links), Sentry (error tracking), and Crisp (support chat). There is no AI provider on this list, because we do not send your data to one.

7. Delete your account and everything in it

Done
What it means. The right to erasure. Asking for deletion has to actually remove the data, not just hide the login.
Where we stand. Self-serve from your profile settings, no support ticket needed. Deleting your account cancels any paid subscription, removes your login, and cascades the deletion through every table holding your data: booking pages, bookings, availability, calendar connections, and stored access tokens. We also remove your contact from our email provider. See Your account.

8. Download a copy of your data

Done
What it means. The rights of access and portability: getting everything we hold about you in a format you can read and take elsewhere.
Where we stand. Self-serve from your profile settings, directly above Delete account. We email you a link that works once and expires after 10 minutes, which produces a single JSON file containing your profile, booking pages, bookings, connected calendars, teams, subscription, and integration settings. The emailed step exists because the file holds every guest detail you have collected, so a stolen browser session should not be enough to pull it. Access tokens and encrypted secrets are left out so the file is safe to keep and hand to another provider, and a cohost appears by name and email but never by internal account id. Events already written into your Google, Microsoft, or Zoom calendar live with those providers and should be exported from them directly.

9. Hiding what guests type from session replay

Done
What it means. Session replay records how people move through a page so we can see where they get stuck. Without masking, it also records the personal data they type into forms.
Where we stand. Every form input is masked at capture time, before anything leaves the browser. We can see that a guest reached the form and where they hesitated, and we cannot read their name, email address, or the answers they gave to the custom questions on a booking page.

10. Database access locked down per account

Done
What it means. GDPR expects appropriate technical measures against unauthorised access. The strongest version enforces this in the database rather than trusting application code to filter correctly.
Where we stand. Every single table has row level security enabled, so a query can only ever reach rows belonging to the signed-in account. A bug in application code cannot leak another account data past it.

11. Encryption in transit and at rest

Done
What it means. Data should be unreadable both while travelling over the network and while sitting on disk.
Where we stand. All traffic is served over TLS, and the database and file storage are encrypted at rest. On top of that, secrets you supply yourself, such as your own Twilio token, are separately encrypted with an application key before being written, so a copy of the database alone does not reveal them.

Mid priority

Real obligations that matter, but that rarely block a purchase on their own and are not putting data at risk while they wait. 3 of 6 done.

12. The same extra encryption for calendar tokens

Not yet
What it means. The access tokens for your Google, Microsoft, and Zoom calendars are among the most sensitive things we hold, so they deserve the strongest protection we apply anywhere.
Where we stand. They are protected by row level security and by at-rest disk encryption, but not yet by the separate application key we already use for host-supplied secrets. Bringing them under the same scheme is a known task.

13. A written commitment to report a breach in 72 hours

Not yet
What it means. GDPR requires a controller to notify its regulator within 72 hours of becoming aware of a breach. As your processor, we have to notify you fast enough for you to meet that deadline.
Where we stand. We run error monitoring and alerting, but the commitment is not yet written down as a process you can hold us to. It ships with the DPA.

14. A route for guests to ask about their own data

In progress
What it means. Guests who book a meeting never create an account, but they still have full GDPR rights over the name, email, and answers they submitted.
Where we stand. Guests can email us or the host and we action it, but there is no self-serve flow for them yet. Note that the host of a booking page is the controller of bookings on it, and normally keeps a copy in their own calendar.

15. Correct your details or withdraw calendar access

Done
What it means. The rights to rectification and to withdraw consent. Both need to be doable at any moment, without asking permission.
Where we stand. Your name, avatar, phone number, booking page content, and availability are editable from the dashboard at any time. Disconnecting a Google, Microsoft, Zoom, or iCal connection deletes the stored token or URL for it, and you can also revoke access from the provider directly.

16. Analytics hosted in the EU

Done
What it means. Analytics tools are a common quiet route for EU data to end up on US servers, which is why auditors ask about them specifically.
Where we stand. Our product analytics runs on an EU-hosted account, and the browser sends it through our own domain rather than straight to a third-party host.

17. No selling data, no ad targeting, no AI training

Done
What it means. Beyond the legal minimum, what a scheduling tool chooses not to do with your calendar is often the real question.
Where we stand. We do not sell, rent, or trade personal data, and we never use calendar or booking data for advertising. We removed our AI page generator and its provider, so there is now no code path that sends your data to any model, and nothing of yours can end up in training data. Suggested meeting times are picked by a deterministic rule you choose, not by a model.

Low priority

Either internal paperwork with no outside impact, or requirements that only a narrow set of buyers ever ask for. 1 of 3 done.

18. Data that never leaves the EEA

Not yet
What it means. Some organisations, mainly in the public sector or in regulated industries, are required to keep personal data strictly inside the EEA. UK adequacy does not satisfy that stricter rule.
Where we stand. We do not meet this today, and the honest answer is that it would take a database migration on our side. It is low priority only because few buyers ask for it. Tell us if it is blocking a purchase and that changes.

19. A record of processing activities

Not yet
What it means. GDPR Article 30 asks organisations to keep an internal register of what data they process, why, who it is shared with, and how long it is kept. It is an internal document that regulators can ask for, not something customers normally see.
Where we stand. Not yet kept as a formal register. This page informally covers much of the same ground.

20. Booking without forcing guests to create an account

Done
What it means. Data minimisation: not collecting more than you need. It also explains why our cancel and reschedule links work without a login, which security reviewers sometimes ask about.
Where we stand. Guests book, reschedule, and cancel without an account, so we never collect a password or build a profile on them. Those links carry a long random booking identifier that cannot be guessed or enumerated, and it is only ever sent to the guest who made that booking.

Questions, or something you need signed

Email: support@timetuna.com

Also see: Privacy Policy and Terms of Use

If GDPR paperwork is standing between you and using TimeTuna, tell us which document you need. Real requests are what move these items up the list.