Shyft Teams data processing agreement
Version 1.0. Effective 1 December 2026. This agreement is part of the Shyft Teams Terms of Service. It takes effect on 1 December 2026 for every Teams workspace, including workspaces created before then. It explains how Shyft handles your staff’s records on your behalf.
Updated
The parties
This agreement is between:
The Customer: the business that uses Shyft Teams (“you”): the company, partnership, sole trader or other organisation (or a private individual who employs staff, see the Terms, section 1) named in its billing details or, before there are billing details, named when an administrator accepted the Terms for it. The workspace itself is not a party; and
Aryan Kumar, trading as Shyft: a sole trader based in the United Kingdom (“Shyft”, “we”, “us”).
This agreement forms part of the Terms of Service for Shyft Teams, and accepting those Terms accepts it (clause 9.1). If it conflicts with the Terms or the Privacy Policy about how Workspace Data is handled, this agreement wins. Words like “controller”, “processor”, “personal data” and “personal data breach” mean what they mean in the UK GDPR and the Data Protection Act 2018. Shyft Teams is designed for employers in the United Kingdom. If the EU GDPR also applies to some of your processing, this agreement applies to that processing too, and references to the UK GDPR include the matching provisions of the EU GDPR.
1. What this covers
1.1 Workspace Data is the personal data of your workers, your administrators and the people you invite that we process for you through your Teams workspace. It is listed in Schedule 1. As between you and us, you keep all rights in Workspace Data (see the Terms, section 9).
1.2 This agreement does not cover the following. For these we are an independent controller under our Privacy Policy: (a) each member’s own Shyft account: their sign-in details, the shifts they log, their pay and tax settings, their personal analytics and anything else in their personal account. Members keep this data if they leave your workspace. You can see parts of it through the workspace, and once you have seen it you are responsible for what you do with it; (b) billing contact details, payment records, and records of who accepted the Terms and this agreement and when; (c) security records we keep to prevent abuse, such as who sent invitations and when, and the service statistics described in clause 3.2; (d) information about website visitors and people who contact us.
2. Roles
2.1 For Workspace Data, you are the controller and we are your processor.
2.2 You are responsible for: having a lawful basis (and, if you deliberately record special category data, a condition under Article 9) for what you put in Shyft; giving us only instructions that comply with the law; telling your workers how you use Shyft (a model notice is at shyft.live/dpa/staff-notice); responding to your workers’ requests about records you hold; and keeping statutory records (pay, hours, holiday, sickness, working-time opt-outs) in a form the law requires. Shyft is a tool, not your system of record.
3. What we will do
3.1 Instructions. We process Workspace Data only on your documented instructions. They are: this agreement and the Terms; the way your administrators use the Teams features; and any other written instruction you send to support@shyft.live that is within the service. They include instructions about transfers (clause 4). If we think an instruction breaks data protection law, we will tell you immediately and may pause it until it is resolved. We will not use Workspace Data for our own purposes, except for the statistics in clause 3.2. If the law requires us to process Workspace Data in any other way, we will tell you before we do so, unless the law forbids that.
3.2 Service statistics. You instruct us to produce usage counts from Workspace Data, on these terms: (a) counts are worked out from what happened and when (for example, how many members a workspace has, how many rota shifts were published in a week, or how many members used a feature), never from content such as names, notes, reasons, pay rates or place names; (b) we use the counts only to run, secure, support, bill and improve Shyft, and for that use we are an independent controller under our Privacy Policy. We do not sell them or use them for advertising; (c) anything we keep from Workspace Data after your workspace is deleted, or publish or share outside Shyft, is first anonymised so that it does not identify you, your workspace or any individual. To do that we follow the Information Commissioner’s Office anonymisation guidance, combine figures from at least 5 organisations, never show a figure that describes fewer than 10 people, and do not try to identify anyone from the result. We do not anonymise Workspace Data for any other purpose.
3.3 Our people. Shyft is run by one person, Aryan Kumar, who is the only person with access to Workspace Data and is bound by this agreement. We have no employees or contractors with access to it. If we ever give anyone else access, they will first be bound by a written duty of confidentiality and given only the access they need.
3.4 Security. We apply the measures in Schedule 2, appropriate to the risk (UK GDPR Article 32). We may improve them but will not materially weaken them.
3.5 Sub-processors. You give general authorisation for the sub-processors in Schedule 3. We will: (a) have a written contract with each that imposes the data protection obligations Article 28(4) of the UK GDPR requires. The one exception is Apple’s push notification service, which Apple offers only on its standard developer terms, with no separate data protection terms. So from 1 December 2026, notifications about your workspace that pass through Apple carry no content: Apple receives only a device token and a signal that the member has an update (Schedule 3); (b) remain responsible to you for their performance; (c) give you at least 30 days’ notice before adding or replacing a sub-processor, by email to the billing owner (and the workspace owner, if different), in the app to your administrators, and by updating Schedule 3; (d) if you object on reasonable data protection grounds within that time, try to resolve it. If we cannot, you may end the affected service before the change takes effect and we will refund prepaid fees for the unused period; (e) if we must replace a sub-processor urgently to keep the service running or secure, tell you as soon as we can; your right to object under (d) still applies; (f) on request, send you a copy of the data protection terms we have with a sub-processor (we may remove commercial terms).
3.6 Helping with rights requests. If a worker or anyone else contacts us about Workspace Data, we will pass the request to you within 5 working days and will not answer the substance ourselves unless you ask us to. If the request also covers the person’s own Shyft account, we answer that part ourselves as controller. We give you tools to view, correct and delete records, and will give reasonable further help, including a copy of a person’s Workspace Data on request (we may charge for unreasonable amounts, agreed in advance).
3.7 Helping with your own duties. Taking into account what we can see as a processor, we will give reasonable help with your security, breach notification, data protection impact assessment and prior consultation duties (UK GDPR Articles 32 to 36). On request we will send you a short description of how Shyft processes Workspace Data and its main risks, to help with your own impact assessment.
3.8 Personal data breaches. If we become aware of a personal data breach affecting Workspace Data, we will tell you without undue delay, and aim to do so within 48 hours of becoming aware of it. We email the workspace owner and the billing owner (breach notices always go by email) and show a notice in the app to your administrators. We tell you what we then know: what happened, the kinds of data and approximate numbers of people and records affected, the likely consequences, what we have done and will do, and who to contact at Shyft for more information. We send more as we learn it and keep a record of the breach. You decide whether to notify the Information Commissioner’s Office and the people affected; we will not notify them about your data unless the law requires us to. Keep the owner and billing email addresses current.
3.9 Records. We keep the record of processing activities that Article 30(2) requires of processors.
4. International transfers
4.1 Workspace Data is stored in the United Kingdom (London). The sub-processors in Schedule 3 process or store limited parts of it elsewhere, including in the United States. For each one, Schedule 3 shows where it processes data and what covers the transfer: the UK’s adequacy regulations (for the European Economic Area, and for US companies certified under the UK Extension to the EU-US Data Privacy Framework for the kind of data concerned), or the UK International Data Transfer Addendum to the EU Standard Contractual Clauses in that provider’s terms. For Apple’s push notification service, see Schedule 3. You authorise these transfers.
4.2 We will not start processing Workspace Data in a new country, or rely on a different safeguard, without the notice in clause 3.5(c). If a safeguard stops being valid, we will tell you and move to another valid safeguard or stop the transfer. You can ask us for a copy of the safeguard for any sub-processor (clause 10).
5. What goes into Shyft, working-time alerts and young workers
5.1 Shyft is designed for names, work emails, rotas, availability, leave dates, pay rates and shift records. You must not deliberately use it to store: (a) health information such as sickness reasons, diagnoses, fit notes or medical appointments; (b) other special category data (for example trade union membership, ethnicity, religion, sexual orientation); (c) criminal convictions or DBS information; (d) National Insurance numbers, bank details, passport or ID numbers; (e) personal data about customers, patients, residents or service users, including in shift notes.
5.2 Workers can type free text into leave reasons, swap reasons and notes. We tell them not to include health details. If health or other special category data ends up in those fields anyway, you are responsible for it as controller, including having an Article 9 condition. We will still process it as part of the service, but Shyft is not built to protect it differently.
5.3 If you want to record sickness absence in Shyft in future, tell us first. We would need to agree changes to this agreement and to the product before you do so.
5.4 You must keep administrator accounts secure, remove people who leave, and only give administrator access to those who need it.
5.5 Working-time alerts. Shyft shows administrators alerts worked out from rota hours, for example less than 11 hours’ rest between shifts, overlapping shifts, or hours that would take someone over the 48-hour weekly average. They are arithmetic on hours, not a judgement about anyone’s health or wellbeing, and you should not use them as one. Shyft does not show administrators any wellbeing or workload score from a member’s own account.
5.6 Young workers. Workers aged 16 and 17 may be members. Shyft does not ask for dates of birth and cannot tell who is under 18, and its working-time alerts use the limits for adult workers. Under the Working Time Regulations 1998, young workers have stricter limits that cannot be opted out of, including at most 8 hours a day and 40 hours a week, and 12 hours’ rest each day. You are responsible for applying them. Do not record a working-time opt-out for a worker under 18.
6. Ending and deletion
6.1 If your workspace is paused or closed (see the Terms on when a workspace is paused or closed), we keep it for at least 90 days from that day. During that time your administrators can still sign in and download the exports the app offers. At any time before deletion you can ask us in writing to give you a copy of the Workspace Data (in a common format such as CSV, within 30 days of the request and before the deletion in 6.2) or to delete it sooner.
6.2 After that, and after at least 14 days’ notice by email to the billing owner (and the workspace owner, if different) and in the app to your administrators, we delete the workspace and the Workspace Data in it, unless the law requires us to keep it or you have asked us for a copy we have not yet given (in which case we delete it once we have given it). Copies in our database provider’s backups are overwritten on a rolling window of up to 30 days. On request we will confirm deletion in writing.
6.3 When a member deletes their own account. You can delete individual workers’ records from the workspace at any time. If a member deletes their own Shyft account, we delete their personal account data (clause 1.2(a)) as our Privacy Policy describes. We keep the Workspace Data about them for you (their rota shifts, leave requests and decisions, availability, cover and swap requests, correction requests and decisions, working-time opt-out record and the audit trail), but remove the link to their account and show them as “Former team member”. These records are pseudonymised, not anonymous, so they remain Workspace Data: we keep and delete them on your instructions under this agreement, and you can delete them at any time. The shifts the member logged themselves, with your approvals and the clock-in place names on them, belong to their own account and are deleted with it (Schedule 1), so export what you need when someone leaves.
6.4 If the workspace owner or billing owner deletes their own Shyft account and another administrator exists, the workspace carries on and that administrator becomes its owner. Billing can pass to them only if they accept it in the app and add their own payment method; otherwise any subscription is cancelled at once. If ownership or billing passes, we tell the new administrator in the app, ask them to confirm the Terms and this agreement for the Customer, and remove the previous person’s payment details. If there is no other administrator, any subscription is cancelled at once, and the workspace and all Workspace Data in it are deleted immediately (Terms section 7). Export first.
6.5 If we decide to stop providing Shyft Teams, we will give you at least 30 days’ notice by email and in the app, and time to export, before we delete Workspace Data under 6.2.
7. Proving compliance and audits
7.1 We will give you the information reasonably necessary to show we meet Article 28: this agreement, our Privacy Policy, Schedule 2, copies of the transfer safeguards in Schedule 3, and summaries of sub-processors’ published certifications.
7.2 Once in any 12 months, and after a breach affecting you, you may send a written security questionnaire. We will answer within 30 days.
7.3 If our answers do not reasonably satisfy you, you, or an independent auditor you appoint who is bound by confidentiality and is not our competitor, may audit our compliance with this agreement. The audit will be remote unless an on-site visit is reasonably necessary. It needs 20 working days’ notice, takes place during business hours, lasts no more than one working day, gives no access to other customers’ data or to our providers’ systems (we will give you their reports instead) and must not disrupt the service. You pay your own costs and our reasonable costs, unless the audit finds that we have materially broken this agreement.
7.4 The questionnaire step, the notice period and the one-day limit do not apply to an audit or inspection that the Information Commissioner’s Office or another supervisory authority requires. We will cooperate with it as the law requires.
8. Liability
8.1 Nothing in this agreement limits liability that cannot be limited by law, or the rights workers have against either of us under Article 82 of the UK GDPR.
8.2 Otherwise, liability under this agreement is subject to the limits and exclusions in the Terms of Service (section 10). This agreement does not add a separate limit.
9. Start, changes and law
9.1 This agreement forms part of the Terms of Service for Shyft Teams. Accepting those Terms for a business accepts it too; no separate signature is needed. An administrator’s confirmation in the app records it (we keep who confirmed it and when) but is not needed for it to apply. We publish it before it takes effect so that you can read it first. It takes effect on 1 December 2026 for every workspace that exists on that date. That includes a workspace created before then: an administrator may confirm it for the Customer now, and for workspaces that existed before we published it we also give notice by email and in the app. For a workspace created after that date, it takes effect the day the workspace is created. Until it takes effect, we already handle Workspace Data as clauses 2 to 5 and 7 describe.
9.2 We may change this agreement for legal, regulatory, security or technical reasons, or to add or replace a sub-processor (clause 3.5), with at least 30 days’ notice by email to the billing owner (and the workspace owner, if different) and in the app to your administrators. Notice is given on the later of the day we send the email and the day the notice first appears in the app. If a change is materially adverse to you, you may end your subscription before it takes effect and we will refund prepaid fees for the unused period. A change the law requires may take effect sooner if the law requires it, and we will tell you as soon as we can.
9.3 This agreement lasts as long as we hold Workspace Data for you. Clauses that by their nature continue (including 6, 7 and 8) survive.
9.4 English law governs this agreement, and the courts of England and Wales have exclusive jurisdiction.
10. Contact
10.1 Data protection and breaches: privacy@shyft.live. Legal notices: legal@shyft.live. Postal: Aryan Kumar, trading as Shyft, [address for service to be added], United Kingdom.
Schedule 1: Details of processing
Subject matter: Running a Teams workspace: rotas, availability, leave, cover, swaps, shift approvals and corrections, member rates, working-time opt-out records, invitations, rota change history and audit trail.
Duration: From workspace creation until deletion (including at least 90 days after the workspace is paused or closed), then up to 30 days in backups.
Nature: Storage, display to authorised users, transmission, notifications (content-free push, and invitation and correction emails), rule-based calculations (hours totals, working-time alerts and coverage warnings), usage counts (clause 3.2), pseudonymisation when a member deletes their account (clause 6.3), export and deletion. No automated decisions with legal or similarly significant effects.
Purpose: To provide the Teams features to you, and the usage counts in clause 3.2.
Data subjects: Your workers (employees, workers, contractors, agency staff, volunteers) who join the workspace; people you invite; your administrators; incidentally, anyone named in free text (which should be nobody).
Special categories: Not intended (clause 5). Possible incidentally in free text.
Children: Workers aged 16 and 17 may be members (clause 5.6).
Retention: Workspace records are kept while the workspace exists unless you delete them sooner; the audit log for 14 days; unaccepted invitations until 30 days after they expire; clause 6 applies when a workspace is paused, closed or deleted. The retention table in our Privacy Policy lists every period.
Categories of Workspace Data
Member identity: Name, invited email address, role in workspace (owner, admin, member), join and leave dates.
Invitations: Email address, who invited, status, expiry. Administrators can also share invitation links through apps they choose; a link carries a token, not the email address.
Rota: Assigned shifts (date, times, break, workplace or role label), published status, admin notes.
Rota change history: Date, times, break, location label and status of each change to a rota shift, and who made it; never notes or pay.
Availability: Days and times a member can or cannot work.
Leave: Dates, hours requested, optional free-text reason, decision, reviewer, rejection reason.
Cover and swaps: Shift concerned, who asked, who offered or claimed, status, optional free-text swap reason.
Approvals and corrections: Approval status, correction request details and notes, decision.
Pay: Hourly rate the organisation sets for the member.
Working time: Whether a member has opted out of the 48-hour limit, who recorded it and when.
Place: Clock-in place name (not coordinates), shown to administrators on shifts logged at your workplace and stored on the member’s own shift (see below).
Audit log: Who changed what and when in the workspace, including the content of changed shift records (such as notes and clock-in place names) and invitee email addresses; never members’ pay and tax settings; kept 14 days.
Derived: Hours totals, working-time alerts and coverage warnings (clause 5.5).
Held in each member’s own account but visible to your administrators (see clause 1.2(a); Shyft is controller): shifts the member logs at your workplace. Approval status and clock-in place names are stored on the member’s own shifts and stay with the member if the workspace is deleted, and are deleted if the member deletes their account (clause 6.3).
Schedule 2: Security measures
- Encryption in transit (TLS) for all traffic; database encrypted at rest by our provider.
- Row-level security on every database table, so one organisation’s data cannot be read by another’s; workspace access is by role (owner, administrator, member) and limited to the member’s own records for non-administrators.
- Passwords hashed by our authentication provider; known-breached passwords refused; sign-in with passkeys (web), Apple or Google as alternatives; on iOS the session sits in the device Keychain.
- Secrets and integration tokens kept in tables and settings only server-side functions can read.
- Workspace changes recorded in an audit log (14 days).
- Error reports have identity, request bodies and authentication headers removed. The iOS app runs no analytics. Website analytics need consent and use a pseudonymous ID.
- From 1 December 2026, push notifications about a workspace carry no content, only a signal to open the app. Emails are composed from the fact that triggered them and never include notes, reasons or other messages that users write.
- Encrypted backups kept by our database provider on a rolling window of up to 30 days.
- Access to production data is limited to one person (the operator), through the providers’ authenticated dashboards.
- Shyft is run by one person; no employees or contractors have access to Workspace Data (clause 3.3).
- We have not commissioned independent penetration testing and hold no security certification of our own. Our infrastructure providers publish their own certifications.
- We do not offer a contractual uptime guarantee.
Schedule 3: Sub-processors
Supabase. Legal entity: Supabase Pte. Ltd (Singapore), with support from its affiliate Supabase, Inc. (United States). What it does: Database, sign-in, server functions, notification dispatch and backups. Workspace Data it sees: All Workspace Data. Where: Stored in London, United Kingdom, on Amazon Web Services. Supabase staff may access it from outside the UK to give support. How the transfer is covered: Stored in the UK. Support access is covered by the UK International Data Transfer Addendum to the EU Standard Contractual Clauses in Supabase’s data processing agreement.
Vercel. Legal entity: Vercel Inc. (United States). What it does: Hosts the web app’s files and keeps short request logs. Workspace Data it sees: IP address, browser details and the addresses of pages requested; no workspace content. Where: United States and a global network. How the transfer is covered: UK Extension to the EU-US Data Privacy Framework (Vercel is certified for HR and non-HR data), with the UK Addendum in Vercel’s data processing agreement as a fallback.
MailerSend. Legal entity: MailerSend, Inc. (United States). What it does: Sends invitation emails, and correction notices to administrators. Workspace Data it sees: Names and email addresses; in a correction notice, the member’s name, the shift date and any changed times, break or pay rate (never notes or reasons). Where: Stored in the European Union (Belgium). MailerSend may access it from the United States and uses US sub-processors. How the transfer is covered: UK Addendum to the EU Standard Contractual Clauses in MailerSend’s data processing addendum. MailerSend is also certified under the UK Extension to the Data Privacy Framework, but for non-HR data only, so we do not rely on that for staff records.
Apple (push notifications). Legal entity: Apple Inc. (United States). What it does: Delivers a content-free alert (such as “You have an update in Shyft”) to the iPhones of members who have allowed notifications; the detail stays in the app. Workspace Data it sees: A device token and the fact that a notification exists. From 1 December 2026, no names, dates, times or workplace. Where: United States and global. How the transfer is covered: None beyond Apple’s developer agreement, which has no data protection or transfer terms, and Apple Inc. is not certified under the Data Privacy Framework. That is why we send it only a content-free signal for the member’s own device. Members can turn notifications off on their iPhone.
Geoapify. Legal entity: KEPTAGO LTD, trading as Geoapify (Cyprus). What it does: Used only to turn clock-in coordinates into a place name, when a member clocks in with location switched on. Workspace Data it sees: Coordinates only, sent from our server with no name, email address or account ID. We save the place name, not the coordinates. Where: European Union. How the transfer is covered: UK adequacy regulations for the European Economic Area.
Sentry. Legal entity: Functional Software, Inc., trading as Sentry (United States). What it does: Crash and error reports. Workspace Data it sees: Technical details of an error. We remove identity, request bodies and sign-in headers before sending, so Workspace Data appears only by accident. Where: United States. How the transfer is covered: UK Addendum to the EU Standard Contractual Clauses in Sentry’s data processing agreement. Sentry is also certified under the UK Extension to the Data Privacy Framework, but for non-HR data only.
These providers do not receive Workspace Data, so they are not sub-processors under this agreement: Stripe (Stripe Payments Europe, Limited, Ireland, with US affiliates including Stripe, LLC), which takes payment for your subscription and sees billing details only, which are not Workspace Data (clause 1.2(b)); Google, which is used only for a member’s own Google sign-in and calendar sync, and for website analytics with consent; RevenueCat, which handles personal Pro purchases on iPhone; Have I Been Pwned, which checks a new password against known breaches using only the first five characters of its hash; GitHub, which stores our code and starts a scheduled clean-up job; it receives no personal data. Our sub-processors use their own sub-processors (for example, Supabase hosts on Amazon Web Services) under their own data protection terms; each publishes its list, and we will send you the links on request.