Privacy Policy

RotaSync is operated by ROTASYNC LTD, a company registered in England and Wales (company number 17375462), registered office Flat 305, 350 The Highway, London, E1W 3HU. The company is the “data controller” for the personal data described below. Contact: support@rotasync.co.uk.

We are registered with the Information Commissioner's Office under reference ZC215084, which you can check on the ICO's public register of fee payers.

The service was previously operated by Milan Kapur as a sole trader. ROTASYNC LTD was incorporated on 2 August 2026 and now runs it; the way your data is handled is unchanged.

We store the minimum needed to turn your rota into a calendar feed: your account email, the rota link you provide, the name you selected, your shift-timing settings, the answers you give us about your own shift codes, and the shifts we extracted for you. We never keep the rota document itself: uploaded and linked spreadsheets pass through a short-lived processing cache and are then deleted, never added to your record. We don't sell your data, we don't run advertising or ad trackers, your rota is never sent to an AI model, and payments are handled by Stripe so we never see your card details.

• Account data: your email address and login (email + password, or sign-in with Google), managed by RotaSync locally via Better Auth. Used to sign you in and contact you about your account.
• Rota configuration: the spreadsheet link, the name you told us is yours, your shift-timing settings, and the layout mapping derived for your sheet. Used solely to generate your calendar feed. This includes the timestamp of your link-time confirmation that you're entitled to access the rota and that it contains no confidential information.
• Your extracted shifts: the dates, times and shift codes we found for your name in the rota, refreshed whenever the rota is re-read. Your calendar feed is built from these, minus any codes you have chosen to hide (below). Those shift codes are copied from the cells of your rota, so the caution further down about what a cell can contain applies to them too. The rota document itself (uploaded file or fetched spreadsheet) is never kept; it passes through a short-lived processing cache and is then deleted.
• Shift codes you have hidden: if you tell us to keep a code out of your calendar feed, we store that code, your choice, and which of your rotas it applies to, so we do not have to ask again. Hiding a code on one rota leaves it alone on the others, because the same code can mean different things on two different sheets. Nothing is deleted by hiding: the shifts stay in your account and on your dashboard, and untick it and they come straight back. We will not store a code whose text is the wrong shape for a shift code, because a cell like that can carry a colleague's name, so a few codes cannot be hidden at all.
• Which of two overlapping rotas you follow: if you link two rotas that cover the same days, we ask once which one to follow and store your answer. It is two references to your own linked rotas and your choice, with no rota content in it.
• Billing data: your plan, payment status and Stripe customer reference. Card details are collected and stored by Stripe, never by us.
• Pay & compliance calculator profile (optional, paid tier): if you use this feature, the nation you work in, your grade, specialty, student loan plan (and whether you have a postgraduate loan), pension opt-out status, any less-than-full-time working fraction or London-zone override you set, your annual leave entitlement, your one-time confirmations of whether each on-call shift code in your rota is resident or non-resident, and (for England only, if you tell us you work in or around London) the hospital/site you pick. If you choose to use the work-schedule comparison, we also store the headline figures you type in from your own work schedule (average weekly hours, hours at the enhanced rate, weekend frequency, whether it includes non-resident on-call, and the annual total it states). Used solely to compute your own indicative pay and safe-working estimates from shifts you've already linked; see below.
• Support requests: if you contact us, we store your message, our replies and the email address you wrote from, so the conversation has a history and we can answer you. Mail sent to our support address is filed the same way. Where a message arrives with an attachment, that attachment is forwarded to our support inbox so a person can open it.
• A record of the rotas you have linked: the date and type of each link, kept as a fair-use ledger so the limits in our terms (how many rotas you can upload in a rolling four-month window) can be applied. It records that a link happened, not what was in the document.
• Technical logs: standard server logs (e.g. errors, request metadata) used to keep the service running and secure.

Under UK GDPR, each processing activity needs a lawful basis (Article 6). Ours are:

• Contract (Article 6(1)(b)): everything needed to provide the service you signed up for. That means your account, your rota configuration, your extracted shifts and calendar feed, the optional pay & compliance calculator, billing, the email-in update channel, your support conversations, and the service emails described below (verification codes, reminders, receipts and notices about your account, including notice that these terms are changing). Those are messages about the contract itself rather than marketing, so they carry no opt-out.
• Legal obligation (Article 6(1)(c)): retaining billing and accounting records for as long as tax and company law require, even after you delete your account.
• Legitimate interests (Article 6(1)(f)): the incidental, transient processing of colleagues' names that appear in a rota document while we locate your shifts. We have carried out and recorded a legitimate-interests assessment for this; see the section above. The same basis covers the minimal technical logging needed to run and secure the service, and a small number of onboarding tips by email: a reminder to link your first rota if you have not, and a pointer to the email-in update channel if you update an uploaded rota by hand. Those tips are the only email we send that is not about your account itself. Each one carries a one-click unsubscribe link, you can switch them off in your account settings at any time, and turning them off never affects verification codes, receipts or billing notices.

If you choose to connect Google Calendar, that feature runs on your consent and stops when you disconnect it.

This feature computes an indicative safe-working compliance check and an expected gross/net pay estimate from shifts you've already linked. Nothing new is fetched from your rota to power it. It runs entirely from your own data: your pay profile and your extracted shifts. Nothing here is financial or legal advice; every figure is an estimate against published rates. See how it's calculated for the full methodology and sources.

Your grade, specialty, and hospital, taken together, can narrow down who you are within a small team (e.g. “ST4 in emergency medicine at a specific hospital”). We treat this combination as sensitive: it's used only to compute your own estimate, is never shown to any other user, is never included in any export or admin view beyond your own account session, and is never exposed via the public token-authed calendar feed. It's deleted along with the rest of your account if you delete it.

The comparison against your work schedule is optional and entirely under your control. If you use it, we store only the headline figures you type in: we never ask for, receive, or store the work schedule document itself, and we don't contact your trust or payroll. The figures are used for one thing: running the same calculation a second time so you can see it beside the estimate from your rota. You can change or remove them at any time from the same panel, and they're deleted with the rest of your account.

If your rota contains on-call shift codes, we show you our best guess of whether each code means resident (in the hospital) or non-resident (available from home) on-call, and ask you to confirm each one once. Those confirmations are stored per shift code: your own duty codes and your answer. They are deleted with the rest of your account data. As with the layout mapping above, a shift code is text copied from a cell, and we would rather drop a genuine code than keep one that could name somebody.

Rota spreadsheets naturally contain the names and shifts of other people in your department. RotaSync processes that data only to locate your shifts and generate your feed; we don't build profiles of, market to, or create accounts for anyone else named in a rota. You may only link or upload rotas you're entitled to hold as part of your work. You confirm this at link time, along with confirming the rota contains no confidential or patient information, and we record that confirmation.

Data that isn't yours is never permanently stored. When a linked rota is read, the workbook lives in a short-lived processing cache for up to 30 minutes, which is long enough to carry you through picking your name and confirming your shifts without having to upload it again, and stops colleagues on the same rota triggering repeated fetches. It is then deleted. What persists afterwards is only each account holder's own extracted shifts; the document, and everyone else's data in it, is discarded. The list you pick your own name from is rebuilt from that short-lived cache every time it is needed and is never saved. We also filter person-bearing text out of the small amount of layout information we do keep, though a rota cell is free text and that filtering cannot be guaranteed perfect: the section on layout analysis below sets out exactly what is kept, for how long, and how to have it cleared.

Uploaded-rota fingerprints are anonymised. For uploaded rotas we keep a small fingerprint of the document (its tab names and staff roster), so that when you upload an "update" we can check it really is a newer version of the same rota rather than a different one. The roster names in that fingerprint are stored only as salted one-way hashes: irreversible values that can be compared against a future upload of the same rota but cannot be turned back into names (and each rota uses its own salt, so hashes can't be matched across rotas). Your own name isn't included in the fingerprint at all, and no readable colleague name is stored in the fingerprint.

Your rota is never sent to an AI model. Working out a spreadsheet's layout (which column holds dates, where names sit, what the shift codes mean) is done entirely by our own software running on our own infrastructure. No part of your rota is sent to a language model, an AI service, or any third-party AI provider, so there is nothing for such a provider to retain or train on.

What we keep afterwards is the resulting layout mapping: column positions, and the shift codes found on the sheet with what we worked out each one means ("LD" is a long day, "N" is a night). Keeping it means the analysis doesn't have to be repeated, including for colleagues who later link the same spreadsheet. The name-picker roster is not part of it: that list is rebuilt from the short-lived cache each time it is needed, and is never saved.

Those shift codes are copied from the cells of your rota, and a cell is free text. Most hold nothing but a code. Some do not: a cell recording who covered a shift can carry a colleague's name beside the code, sometimes with a reason such as sickness. We filter person-bearing text out of what we keep, and we would rather drop a genuine code than retain a name. We cannot promise that filtering is perfect, because there is no fixed format for what a hospital types into a spreadsheet, and we would rather say so than imply a guarantee we cannot hold to.

So we bound it instead of relying on the filter alone. This layout mapping is a cache: it expires within 30 days and is rebuilt from the rota when next needed, it is deleted when the last person linked to that spreadsheet unlinks it or closes their account, and you can ask us to clear it at any time using the contact details below. If you believe we hold something about you that we should not, including if you are a colleague on somebody else's rota rather than a user, tell us and we will remove it.

Until August 2026 this step could optionally call a model hosted inside our own Cloudflare account (never a third-party AI provider, never retained, never used for training). We tested it against real rotas, found it made our results no better and occasionally worse, and switched it off. Parsing is now fully deterministic. If that ever changes we will update this policy before it does, not after.

• Stripe: payments, subscriptions and refunds.
• Cloudflare: hosting and our database; your configuration and feed data live here. Email both ways runs here too: the messages we send you (verification and password-reset codes, trial and renewal reminders, payment receipts, service notices about your account and rotas, and the optional onboarding tips described above) and inbound email to your ingest address. No AI service processes your rota.
• Google: fetching Google Sheets you link, sign-in with Google if you choose it (Google tells us your name and email address, and sign-in alone gives us no access to anything else in your Google account), reading a rota that is shared with you privately if you connect that and pick the file yourself (below), and Google Calendar sync if you connect it (below).
• Microsoft: fetching Office 365/SharePoint workbooks you link.

Each provider processes data only to provide their service to us. We never sell personal data to anyone. Sign-in and session management are handled by software running on our own infrastructure (the open-source Better Auth library, on our Cloudflare-hosted database), so no separate provider receives your login data.

We are a UK company and your data is processed under UK GDPR. Some of the providers above are based in, or process data in, the United States:

• Stripe (payments): transfers are safeguarded by Stripe's data processing terms incorporating the UK International Data Transfer Addendum to the EU standard contractual clauses.
• Cloudflare (hosting, database and email): data may be processed at Cloudflare's edge locations worldwide; transfers are safeguarded by Cloudflare's data processing addendum incorporating standard contractual clauses with the UK Addendum.
• Google and Microsoft (fetching sheets you link; Google sign-in, the private-rota read and Calendar sync if you use them): transfers are safeguarded by each provider's data processing terms incorporating standard contractual clauses with the UK Addendum.

Where the UK government has made an adequacy decision covering a transfer (for example the UK–US Data Bridge, for providers certified under it), we may also rely on that. You can ask us at support@rotasync.co.uk for more detail on the safeguards applying to a specific transfer.

If you choose Connect Google Calendar, RotaSync writes your own extracted shifts into a dedicated calendar (“RotaSync – Hospital Rota”) that we create in your Google account, so updates appear on your devices within minutes. We request Google's narrowest calendar permission (calendar.app.created): it lets us manage only calendars RotaSync itself created: we cannot see, read or change your own calendars or any events in them, and we never read anything back from Google Calendar.

For this feature we store: the email address of the Google account you connected, an encrypted access credential (the OAuth refresh token, encrypted at the application layer before it touches our database), the ID of the calendar we created, and the IDs of the events we've pushed. What we push is only what your own calendar feed already serves: your shifts and RotaSync notices, never anyone else's data. Disconnecting (from your dashboard) removes the RotaSync calendar from your Google account and revokes the credential; you can also revoke access at any time at myaccount.google.com/permissions.

RotaSync's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.

Most live rotas are set to “anyone with the link can view”, and we read those with no permission from you at all. Some are instead shared privately, by name, with each member of the team. If you link one of those, we offer to read it as you rather than asking anyone to make the rota public.

You connect your Google account and pick the one rota file. We request Google's narrowest Drive permission (drive.file): it reaches only the files you pick for RotaSync, so we cannot see, search or open anything else in your Google Drive. Your rota coordinator does not need to do anything, and the rota stays private. You do not need to own the rota or make a copy of it: being able to view it is enough, because Google checks your own access every time we read.

For this we store: the email address of the Google account you connected, and an encrypted access credential (the OAuth refresh token, encrypted at the application layer before it touches our database). We do not store the rota, exactly as with every other route: it passes through the same short-lived processing cache described above, your own shifts are extracted, and the document itself is never kept.

You can withdraw this at any time from your dashboard, which also tells Google to revoke it, or at myaccount.google.com/permissions. If we lose access for any reason, your calendar keeps showing the last shifts we could read and we email you once to say so, because a calendar app has no way of telling you that it has stopped updating.

RotaSync's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.

Each account has a unique inbound address of the form u-…@ingest.rotasync.co.uk, shown on your dashboard. Emailing a spreadsheet to it updates a rota you have already linked: it can never create a new rota, and the attached file is processed exactly like a dashboard upload: parsed, your own shifts extracted, and the document itself never kept. The email is not stored; only the spreadsheet attachment is read, and only if the sender address checks out (below).

Verified sending addresses. Updates are accepted only from your account email or from up to two extra addresses you have verified (many people sign up with a personal address and automate the send from a work mailbox). Verifying an address means we email it a 6-digit code, which we store only as a salted one-way hash and destroy on verification. A verified extra address is send-only: it cannot sign in, cannot receive password resets, and never becomes your account email. We store the address itself, when it was verified, and nothing else; you can remove an address at any time from your dashboard, and all of them are deleted with your account.

Your feed URL contains a long, unguessable token instead of a login, so calendar apps can fetch it. Anyone who has the URL can read the calendar it serves, so treat it like a password and only paste it into calendar apps you trust. Unlinking and re-linking a rota issues a fresh token.

If personal data is ever exposed, we assess the incident and, where there is a risk to people, report it to the Information Commissioner's Office within 72 hours, and tell affected users where the risk is high. ROTASYNC LTD also carries cyber and data insurance of £1,000,000, which covers the forensic investigation, recovery and notification work a response involves. That is a fact about the company rather than a promise about your data: it does not make a breach less likely, and it changes none of the protections described above. We mention it because it is what lets a very small company respond properly rather than cheaply.

Rota documents are never retained: both uploaded files and fetched spreadsheets pass through a short-lived processing cache, cleared within 30 minutes while you complete setup, and are then deleted. Your rota configuration and extracted shifts are deleted when you unlink the rota. You can delete your account and all associated data yourself at any time from the dashboard (Billing & Subscription → Delete my account & all my data): this removes your rotas, extracted shifts, feeds, configuration and login immediately. Stripe retains billing records as required for tax and accounting law, and the per-spreadsheet layout mapping (which describes the spreadsheet, not you) outlives your account so colleagues on the same rota aren't affected; it expires within 30 days by itself, and the section on layout analysis above sets out what it can contain. You can also email us (below) to request deletion.

A few records outlive your account, and we would rather be specific about which. When you delete your account we remove your rotas, extracted shifts, feeds, configuration, support conversations, acceptance records and login. Four things are deliberately kept, none of which contains rota content, and none of which is ever shared or used for advertising:

• A ledger of billing events and a record of any promotional discount applied: financial records we are required to keep for tax and company law, and what lets a past charge be proven correct. They hold an amount, a date and Stripe's own reference, not your contact details.
• Which days your account used the service (signed in, or a calendar app fetched your feed). These are daily counters against an internal identifier that no longer points at anybody once your account is gone.
• The fact and date of the deletion, with the reason if you chose to give one, plus a note of whether the account had ever paid. Your email address is not kept here: it is stored as a one-way scrambled value that cannot be turned back into your address, so the record cannot be used to identify you.

Stripe separately retains its own billing records as required for tax and accounting law. The per-spreadsheet layout mapping also outlives your account: it describes the spreadsheet rather than you, and deleting it would make every colleague on the same rota re-run the analysis. It is not anonymous, and the section on layout analysis above sets out what it can contain, that it expires within 30 days by itself, and how to have it cleared sooner.

We use only the cookies needed to run the service: session cookies that keep you signed in (set securely by Better Auth) and for security. When you tick the terms box on the sign-up form, a short-lived cookie (rotasync_tos, deleted after an hour) records which version of the terms you accepted so that acceptance can be stamped on your new account. If you sign up through an invite link, we also set a short-lived cookie (deleted after an hour) that applies the invite to your new account. There are no analytics, advertising or cross-site tracking cookies, which is why you don't see a cookie banner.

Under UK GDPR you can ask for access to, correction of, or deletion of your personal data, object to or restrict processing, and request portability. Contact us at support@rotasync.co.uk and we'll respond within one month. If you're unhappy with how we handle your data you can complain to the Information Commissioner's Office (ico.org.uk).

We'll update this page when our practices change and revise the “last updated” date above. Every revision is recorded, and the recent ones are listed below.

If a change is significant we will email you before it takes effect, telling you what is changing and the date it starts. Where a change also alters the Terms of Service in a way that affects what you have agreed to, we give at least 30 days' notice and ask you to accept the updated terms from that date; you are free to cancel or delete your account before then, and your calendar feed keeps working either way. We will not apply a changed term to you retrospectively.