Privacy policy

This policy covers rotaaa.app: the public site and the product behind it. Rotaaa is built and run by ImKyleJK Studios, the trading name of ImKyleJK, based in the United Kingdom. Where this policy says we or us, that is who it means, and the defaults everything runs on are British: pounds sterling, Europe/London, and the United Kingdom as the country of a new business.

For anything in this policy — a question, a rights request, an objection — write to [email protected], or use the routes on the contact page. We have not appointed a data protection officer, and are not required to.

This describes what is held today. If we start collecting something we do not collect now, this policy is revised before the collection starts, with the change listed at the top of the page.

Two different relationships run side by side here, and almost every question about your rights turns on which one you are in.

Your staff records. Your business is the data controller. You decide who is in your team, what is recorded about them, why, and for how long. We are your processor: we hold that data on your instructions, to give you the service, and we do nothing else with it. We do not decide what it is for.

Your own account. The account you sign in with — your name, your email address, your sessions, the notifications we send you — is held by us as controller in our own right, because it is needed to run the service rather than to run your business.

So: if you are a member of staff and you want your shift history changed or removed, your employer decides, and “Your rights” below says what to do if they will not. If you want your sign-in gone, that is ours and it is a control you hold yourself.

These are the commitments we make to every business whose staff data we hold. They apply to all processing we carry out on your behalf, for as long as we carry it out.

• Subject matter and duration. We process your staff data to provide workforce scheduling and the records that come out of it — rotas, leave, attendance, timesheets and the reports drawn from them — for as long as your organisation is open.
• Who it is about, and what it is. The people are your employees, workers and anybody else you roster. The data is the categories set out in the sections that follow, and nothing outside them.
• Instructions only. We process it to give you the service and on your documented instructions, which include the settings you choose in the product. We do not use it for our own purposes, we do not sell it, we do not share it outside the providers named under “Who else is involved”, and we do not use it to train anything. If we ever thought an instruction required us to break the law, we would tell you rather than carry it out.
• Confidentiality. Everybody at ImKyleJK Studios who can reach your data is under a duty of confidence that survives their involvement with Rotaaa, and reaches it only to run and repair the service.
• Security. We keep the measures set out under “How it is protected”, and we tell you before we weaken any of them.
• Other providers. You give us general authorisation to use the providers named under “Who else is involved”, on the notice-and-objection terms stated there. Clerk and Resend are engaged on terms no weaker than these. The notification relay named there is not, and what is sent to it is limited instead to the fields stated. We remain answerable to you for all of them.
• Helping you. Where one of your people exercises a right, we help you answer them — with the export controls in the product, and by hand where the product cannot. We also help you with security, breach notification and impact assessments, to the extent the information is ours to give.
• Getting your data out. A copy of your organisation’s records — your people, rotas, leave, timesheets, clockings and the master data behind them — is available at any time from Settings, as a file you can read. An owner or an administrator can take it, and pay figures are in it only for somebody whose role already lets them see wages. Two things are not: support conversations and the record of changes, which we provide on request. Closing your organisation does not erase what is in it, for the reason given under “How long it is kept”; erasure is a separate request and we carry it out.
• Showing our working. We make available the information you need to demonstrate that these obligations are met, and we answer a reasonable audit request in writing.

Signing in is handled by Clerk. Clerk holds your credentials and verifies your email address; we never receive your password. When your Clerk account is created or updated, these fields are copied into our own database:

• your first name, surname and email address;
• your profile image address, if you have one at Clerk;
• the identifier Clerk uses for you, which is how the two records stay joined;
• your preferred time zone and language, where you have set them — language defaults to British English;
• when you were last seen in the product.

Alongside that sits your membership of each business: the role you hold there, any locations or departments a manager is narrowed to, and the dates you were invited and accepted.

Your current sign-ins. The Your account screen lists the sessions you have open and, for each, when it started, when it was last active, the device and browser, the address it was last seen from and the city and country that address resolves to. That is how you can tell one of them is not you, and it is the whole reason the list exists. It is read from Clerk when you open the page, shown to you and nobody else, and not copied into our database.

Its name, the address it lives at on the site, its currency, time zone and country, the plan and status of the account, optionally the kind of work it schedules, and its settings — how the week starts, whether staff may claim open shifts, when the leave year opens, the grace period before somebody counts as late, and so on. None of it is personal data about anyone.

Locations carry a name, an optional code, an address and, if you enter them, coordinates for the site itself. Those are the premises, not a person.

A staff record can hold:

• name, preferred name, and optionally an email address and phone number — an email address is genuinely optional, because somebody may never be given a sign-in;
• an employee number and a payroll reference, if your payroll needs one;
• employment type, employment status, start date and, for a leaver, a leaving date;
• contracted hours, a maximum weekly limit, and the days of the week they normally work;
• their base, their team, their job roles and the sites they can be rostered at;
• pay — an hourly rate, an annual salary, an overtime rate and a daily deduction for unpaid leave, in whichever combination applies;
• free-text notes, if a manager writes any.

What is not collected today. Date of birth, national insurance number, home address and emergency contact are not asked for anywhere in the product, and no screen writes them. The right-to-work fields and the staff sign-in code are in the same position: nothing enters them. If any of that changes, this section changes with it, and the change will be listed at the top of this page.

Pay is treated as the sensitive information it is. Screens that do not need it never load it, and it is removed from rota figures before they reach anybody whose role does not carry permission to see it.

Rotaaa asks for no special category data. No screen requests anything about health, beliefs, ethnicity or union membership, and nothing of that kind is needed to use the product.

Two places can end up holding it anyway, and both are your decision rather than ours. A free-text note is a free-text field, so what goes in one is up to you. And leave types are yours to create: a business that adds one for sickness is recording information about a person’s health in the leave record every time it is used, together with the reason given, if any. You remain the controller of that, and the additional condition data protection law requires for holding information of that kind is yours to establish — usually your obligations as an employer.

Rotas. Shifts with their times, site, team, job role, who is assigned and any notes on the day. A deleted shift is hidden rather than removed, so it can be restored.

Leave. Requests with their dates, type, reason if one is given, and the decision, who made it and when. Alongside each person’s entitlement for the leave year sits any carried-over balance, its expiry, manual adjustments and a running total of what has been taken and what is awaiting a decision.

Clocking in. Each punch records the time from the server’s own clock — never the time claimed by the device — the kind of punch, the working day it belongs to, that it came from the web, the shift it attaches to, whether any restriction applied, the note the person typed when they finished, and who entered it if a manager entered it on their behalf.

Clocking in does not record where you are, and does not take a photograph. Nothing in Rotaaa asks a browser or a phone for a position, and nothing stores one. If that ever changes, it will arrive with its own notice and its own controls, announced before it is switched on.

Hours. Punches are reconciled into a timesheet line per day: hours worked, breaks, paid minutes, overtime, and the pay those come to. A punch is never edited — a correction is recorded beside the original, so the evidence survives the correction.

Significant changes are written to a single trail: which business, which person did it (or that the system did), what kind of thing was changed, which one, what the action was, and the fields that changed — the changed keys only, never a copy of the whole row. Related changes made in one operation share an identifier, so a bulk action can be explained as one event rather than two hundred.

This is what makes “who approved this, and when” answerable. No network address or browser fingerprint is recorded against it.

Notifications — a shift published, a leave request received or decided, a timesheet approved, an open shift claimed — are stored against the recipient with a title, a short body and a link into the app. They are held back for a few minutes before they appear, so that a change corrected quickly never reaches anybody.

They are delivered in the product, and by email where the recipient has not turned that off. The email carries the same title, body and link, plus the name of the business, and goes to the address on the recipient’s account through Resend. Several notifications waiting at once become one email rather than several. Every one carries a link to the settings that control it, and each kind of notification can be switched off separately on the Requests page — the choice is the recipient’s, not their employer’s.

Push and text message are not built. There is no transport behind either, and the settings do not offer them.

The other email we send is an invitation: the recipient’s address, the name of the business inviting them and a link to accept. It is sent through Resend. If email is not configured, the invitation is still created and the failure is logged rather than being reported as a failure of the invitation itself.

Addresses we have been told to stop using. If an email hard-bounces, or its recipient reports it as spam, we record the address and the reason so that nothing further is sent to it. That list is the whole of what it does: it does not delete the address, does not unlink the person, and does not affect anything they see in the product.

Your account — your name, email address and sessions — is held to provide a service you have asked for: performance of the contract in the terms.

Your staff’s records are held on your instructions. The lawful basis for holding them is yours to establish as the controller, and in practice is usually your own employment contracts and your legal obligations as an employer.

Security, support and keeping the service working — the record of changes, the restriction outcomes, the technical records and the support conversations described below — rest on our legitimate interests. The interest is a service that can be operated, defended against abuse and repaired when it breaks, and a customer who can get an answer. We have weighed that against the interests of the people involved: the data is the minimum that does the job, it is not combined with anything else, it is not used to build a picture of anybody, and none of it is used to make a decision about a person. You can object to processing we do on this basis, and “Your rights” below says how.

Nothing is collected for advertising, nothing is sold, nothing is used to train anything, and there is no profiling and no automated decision-making producing legal or similarly significant effects.

When somebody at your business opens a conversation with us from inside the product, we hold the subject line, the text of every message in the thread, which side wrote each one, who opened it, the business it came from, the times, and whether it is open or closed. A reply from us also carries the name and picture of the person who sent it, recorded as they were at the time, so that a thread does not change its author eight months later.

What goes in a message is whatever is typed. We do not ask for staff names, pay figures or anything about somebody’s health, and a conversation about a real problem sometimes contains them anyway. Please send us the least that explains the problem. Where you do include information about one of your people, you remain the controller of it and we hold it under the processing terms above like any other record you put here.

Who can read one. The people at ImKyleJK Studios who answer support, and nobody else. Answering means reading across businesses, so it is the one place in the product where that happens: it is restricted to accounts we have flagged for it, every such query is confined to a single file so that it can be audited, and none of those queries reads a rota, a person record, a timesheet or a pay figure. Support is a conversation, not a window into your business.

How we know a message has arrived. The subject, the message and the name of the business are sent to a notification relay so that somebody sees it rather than finding it a day later. That relay is named under “Who else is involved”, with what it receives and what its limits are.

A thread is the record of what was asked and what we answered, so it is kept while your organisation is open. “How long it is kept” sets that out with everything else.

Running a service on the public internet produces records that are about a request rather than about a person, and some of them contain an address that is personal data all the same. There are three, and this is all of them.

• Web server logs. The server Rotaaa runs on records the requests made to it in the ordinary way, including the address they came from. They are read when something has gone wrong and for nothing else, they are kept only as long as the server’s own log rotation keeps them, and nothing in the product is built on them.
• Policy-violation reports. Browsers can tell us when the site’s own content security policy blocked something. Anybody can post to that endpoint, so it is limited by the address a report came from — held in memory for a minute, counted, and never written down. What is recorded is the rule that fired and what it refused.
• Fault alerts. When the server throws, one line goes to the log on our own machine and a short alert goes to the person on the other end of it. What we put in that alert is the shape of the route — /[orgSlug]/timesheets — and a reference for finding the fault in the log. The address somebody actually visited and everything in its query string stay behind, in the log on our machine. The alert also carries the first part of the error message, which is the server’s own text rather than anything we compose: it is kept short, and it is usually a description of what broke, but a message that quotes the record it failed on would carry that much with it.

Elsewhere, where the product needs to limit how often something can be done, it counts against your signed-in account or your business rather than your address.

Everybody outside ImKyleJK Studios who holds or handles any of what is described above. There is no separate register kept somewhere else; this list is it.

• Clerk — authentication only. The account, the password, email verification and the session. Since 18 September 2026 it holds nothing about your business: organisations, memberships, roles and invitations are ours.
• Resend — the transactional email provider that delivers invitations and notification emails. It receives the recipient’s address and the content of that email, which is the title, short body and link described above.
• ntfy — the notification relay that tells us a support message has arrived or that the server has thrown. For a support message it receives the subject, the text of the message and the name of the business. For a fault it receives the error message and the shape of the route — never the address somebody visited or anything from its query string. Unlike Clerk and Resend it is a channel we post to rather than a provider engaged under a written processing agreement, and it may be operated outside the United Kingdom, which is why what reaches it is held down to those fields.
• The infrastructure we run on — the application and the PostgreSQL database behind it run on a server we rent rather than hardware we own. The provider does not use what is on it and has no account in the product, but it runs the machine and performs the backups of it, so it has access at the level of the disk to everything described on this page. Who they are and which region the server sits in are given on request, and “Where it is processed” says how to ask.

There is no analytics provider, no advertising network, no chat widget and no payment processor. We run no third-party error monitoring service either: a fault reaches us as the alert described under “Technical records”, and stops there. That is a statement about what is wired into the product, not an aspiration.

If this list changes, here is exactly what happens.

• A new provider is published here at least 30 days before it starts processing anything, as a new version of this page, with an entry at the top naming who they are, what they are for and which of the data described above they would receive.
• You can object inside those 30 days, by writing to [email protected] or through the contact page. A person answers, not a form. If the objection cannot be resolved, you may close your organisation before the change takes effect and take a copy of your data with you — Settings has a “Download a copy” control, and help with it is part of the answer rather than a favour. That is the remedy for an unresolved objection.
• If a provider fails, or has to be replaced at once for security reasons, 30 days may not exist. In that case the change is published here as soon as it is made and no later than five working days after, with the reason it could not wait. That is the only exception, and it is not a way to shorten the notice for a change that could have been planned.
• Removing a provider, or narrowing what one receives, is published here too, without a waiting period. Less processing is not a change anybody needs protecting from.

Two of the entries above did not get that notice. The notification relay has been receiving support messages since support was built, and the server has always run on rented infrastructure; both should have been on this page before either started, and neither was. So the 30 days and the right to object run again from the effective date of this version, on exactly the terms above, for every business already using Rotaaa. Notice you were owed and did not get is not notice you have lost.

Nothing is emailed automatically when this list changes, because an announcement list that quietly stops being maintained is worse than never having offered one. If you would rather be told directly than check this page, ask and you will be emailed at the same time as the change is published here.

Everything in the database stays in the database, on the server described above. The providers named alongside it are international and may process what is described there outside the United Kingdom.

For Clerk and Resend, the transfer rests either on the United Kingdom’s adequacy regulations for the country concerned, or on the International Data Transfer Addendum to the European Commission’s standard contractual clauses, in each case as set out in that provider’s own data processing terms. Ask us which one a given provider relies on and we will tell you and point you at the current document, rather than pointing you at a clause. For the notification relay, what limits the transfer is how little is sent to it, as stated above.

If you need the hosting provider and the region the server sits in before committing your staff data, ask and you will be told. That is the fact your own assessment turns on, and it should not take a negotiation to get it.

The measures below are the ones in place today. They are stated specifically because a list of adjectives is not something a controller can rely on.

• Separation. One business cannot reach another’s data. Every query is bound to the business in the address bar, and your membership of it is the access check — asking for a business you are not in returns nothing found. The single exception is support, described under “Support conversations”.
• In transit. Traffic between your browser and Rotaaa travels over an encrypted connection.
• Credentials. Passwords are never seen by us. They are Clerk’s, and so is the verification of your email address. Invitation links are stored as one-way hashes, so a read of the database hands nobody a working key.
• Access. Reaching the production server or its database is limited to the people who operate Rotaaa, over authenticated connections, for running and repairing the service. Answering support is separately restricted and separately confined, as “Support conversations” describes.
• Least privilege inside. Pay columns are not read by screens that do not need them, and are removed from figures shown to roles without permission for them.
• Evidence. Punches cannot be edited or deleted, so a correction is visible as a correction, and the record of changes says who did what.
• Changes to the service. Tests run before a release on a machine that cannot touch the live service, the new version is built before the running one restarts, and a release that fails its check is rolled back automatically. The service level agreement sets that out in full.

Limits. We hold no security certification. We state nothing about encryption at rest: the database sits on infrastructure we rent, what that provider encrypts at the level of the disk is its arrangement rather than a measure of ours, and we will not offer you something to rely on that we have not verified. Backups are the ones that infrastructure performs, and no restore has been rehearsed end to end, so neither this policy nor the service level agreement promises a recovery time — and will not until one has been tested. No system is perfectly secure, and the section below says what happens when something goes wrong.

If personal data your business holds in Rotaaa is lost, exposed or destroyed, we will tell you without undue delay and in any event within 24 hours of becoming aware of it. You are the controller of that data and your own clock for telling the regulator starts when we tell you, so a vague notice late in the day is worse than useless to you.

What you will be given, so far as it is known at the time:

• what happened, and when;
• which data and roughly how many people and records are involved;
• what the likely consequences are;
• what has been done about it, and what we suggest you do; and
• a name to reply to. Where the facts are still coming in, you get what is known and the rest as it arrives, rather than silence until the picture is complete.

You will not be told that “an issue was identified and resolved”. Reporting a breach of your staff’s data to the Information Commissioner’s Office, and telling the people affected where that is required, is yours as the controller, and we help you do it. Where the breach concerns account data we hold as controller in our own right, the report is ours to make and we make it.

• Invitations expire seven days after they are sent. The row is kept afterwards — accepted, expired or withdrawn — because who was let into a business and when is exactly what an audit asks. The link itself is stored only as a one-way hash, never in a form that could be used.
• Staff records are kept while the business keeps them. Archiving a leaver marks them as one and releases their future shifts; it does not erase their history, because the rota those shifts sit on is a record of what happened.
• Deleted shifts and notes are hidden and restorable rather than removed.
• Support conversations are kept while the organisation is open. Nothing removes one on a timer; a period nothing enforces would be a number rather than a commitment. Ask and a thread is deleted.
• The record of changes has no end date. It is what makes an approval or a pay change answerable years later, and a trail that expires is a trail that fails at the moment it is needed.
• Your sign-in is yours to delete, under Your account inside the product, and it is removed from our database in the same act: your name, your email address, your sessions, your membership of every business here, your notifications and the settings behind them. Your name also comes off the record of changes — what was changed stays, that it was you does not. It is also removed if your account at Clerk is deleted instead.
• What deleting your sign-in does not remove is your staff record and the rota history attached to it. Your employer is the controller of those, with their own reasons and usually their own legal obligations for keeping them, so they stay with the business and the link to your sign-in is cut rather than the record destroyed. Ask your employer if you want them erased. One case is refused outright: the only owner of a business cannot delete their account, because it would leave that business with nobody who can run or close it.
• Everything else is kept while the account is open. Where we are the controller, we erase it on request. Where your employer is the controller — which is everything about your employment — the decision is theirs, and some of those records carry retention periods of their own that the law puts on them rather than on us.

A sweep runs once a day to enforce what this section says, and it is deliberately narrow: it removes only things this page gives an end date to. That is currently one rule — a clock-in photograph past its retention date — and because no photograph is captured anywhere in Rotaaa today, as “Rotas, leave, clocking in and hours” states, it has nothing to remove. It runs anyway, so the rule is already in place and already logged on the day a camera is ever part of clocking in. Every run records what it removed, including the runs that remove nothing.

Nothing else is on a timer, and that is the point rather than a gap. An expired invitation keeps its row because an audit asks who was let in and when; a deleted shift stays restorable because this page says it is; the record of changes has no end date because nothing here gives it one. A sweep that removed any of those would be making this document untrue.

Closing a business is not erasing it. Closing an organisation ends access to it and stops its address resolving; the records survive, because a rota is a record of who worked when and the timesheets behind it are what people were paid from, and in the United Kingdom the retention the law puts on pay records outlives the business relationship by years. Erasure of a whole business is a separate request, done by hand, and it is carried out. Take a copy first: Settings has one.

Under UK data protection law you can ask for a copy of the personal data held about you, have it corrected, have it erased, restrict how it is used, object to it being used, and receive it in a portable form. Write to [email protected] or use the contact page.

What happens next. We answer within one month. Before anything is handed over we check you are who you say you are, proportionately — usually by replying to the address on your account rather than asking you to send us documents. If a request is genuinely complex, that month can be extended by up to two more; you will be told inside the first month if it is, and why. A request that is manifestly unfounded or excessive may attract a reasonable fee or be refused, in which case you will be told why, and you can complain about that decision.

Erasing your sign-in does not need a request at all. It is a control under Your account, it takes effect immediately, and “How long it is kept” sets out exactly what it removes and what it leaves with your employer. It is written down there rather than here because what a person most needs before pressing it is the list of what survives.

If you are a member of staff. Your employer is the controller of your employment records, so ask them first. A request sent to us about those records is passed to them rather than actioned over their head — we are not entitled to change an employer’s records on the say-so of somebody else, and a processor that did would be a worse custodian, not a better one. If your employer does not answer you, or answers badly, you can go to the Information Commissioner’s Office about them directly.

You can also complain to the Information Commissioner’s Office, the United Kingdom’s supervisory authority, at ico.org.uk, about anything we do. That right does not depend on our agreement, and raising it with us first is not a condition of it.

Rotaaa is a tool for businesses and is not directed at children. A business may lawfully employ young workers and hold their records here, in which case those records are the employer’s responsibility under the same terms as any other staff record, and the employer decides whether to give one of them a sign-in.

The short version: the cookies that keep you signed in, and — once you are signed in — one of ours that remembers which of your sites you last had a rota open for. There is no analytics or advertising of any kind, and nothing we set reaches a browser that has not signed in. The detail, including what is stored outside cookies and what the public pages load from anybody else, is in the cookie policy.

This policy is revised whenever what we collect changes. Each revision carries a version number, an effective date and a list of what moved, at the top of this page, and the version you agreed to when your organisation was created is recorded against it. Where a change widens what is collected, it is published before the collection starts, not after. That rule was broken by the notification relay, which shipped ahead of the page; it is recorded in the list of changes above rather than quietly corrected, and the notice it should have had runs again from today. A rule whose breaches are not published is not a rule.