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: [email protected].

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, 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. This is what your calendar feed serves, and it's refreshed whenever the rota is re-read. The rota document itself (uploaded file or fetched spreadsheet) is never kept; it passes through a short-lived processing cache and is then deleted.
• 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.
• 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 — your account, your rota configuration, your extracted shifts and calendar feed, the optional pay & compliance calculator, billing, the email-in update channel, and the service emails described below (verification codes, reminders, receipts and notices about your account — these are messages about the contract itself, not marketing, so no marketing opt-out is offered or needed).
• 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 (see the section above — we have carried out and recorded a legitimate-interests assessment for this), and the minimal technical logging needed to run and secure the service.

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, nothing else), so we don't have to ask again, and they're deleted with the rest of your account data.

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 — at most 10 minutes for a linked rota, or up to 30 minutes for a file you upload, which is long enough to carry you through picking your name and confirming your shifts without having to upload it again — so colleagues on the same rota don't trigger repeated fetches, and 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. Colleagues' names are never written to our database in readable form: the list you pick your own name from is regenerated from that short-lived cache each time it's needed, not stored.

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. No readable colleague name is ever stored.

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.

Only the resulting anonymous layout mapping (column positions and the meaning of shift codes like "LD" or "N", with no personal names) is stored, so the analysis doesn't need to be repeated (including for colleagues who later link the same spreadsheet). The names themselves are used only in the moment, to build your name-picker, and are not saved.

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.
• Resend: transactional email delivery — verification and password-reset codes, trial and renewal reminders, payment receipts, and service notices about your account and rotas.
• Cloudflare: hosting and our database; your configuration and feed data live here, and inbound email to your ingest address is routed here. 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; we don't access anything else in your Google account), 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) — 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.
• Resend (email delivery) — transfers are safeguarded by Resend's data processing agreement incorporating standard contractual clauses with the UK Addendum.
• Cloudflare (hosting and database) — 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 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 [email protected] 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.

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 10 minutes for a linked rota, or within 30 minutes for an uploaded file 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 anonymous per-spreadsheet layout mapping (derived from the rota document, not from you) is kept so colleagues on the same rota aren't affected. You can also email us (below) to request deletion.

We keep minimal first-party service records to operate, support and account for the service: which days your account used it (signed in, or a calendar app fetched your feed) and a ledger of billing events. These records contain no rota content, are never shared, and are never used for advertising. If you delete your account we also keep the deletion date and, if you choose to give one, your stated reason.

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 [email protected] 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. Material changes will be flagged to you directly.