Draft v0.1, 15 September 2026. Last updated 9 October 2026 (section 3.1a revised the same day). Effective the day it is published. Version 1.
1. Who we are
Whole Team Ltd (company number SC902475) runs the Whole Team app and website for grassroots sports clubs, tournament organisers, coaches, parents, guardians and players. We are the data controller for the personal information described here. Our registered address is 5 South Charlotte Street, Edinburgh EH2 4AN. We are registered with the Information Commissioner's Office, registration number ZC248423.
Our data protection lead is David Godfrey, privacy@wholeteam.co.uk. You can write to us at the address above.
Clubs and organisers that use Whole Team decide who joins their club and what events they run. For those decisions they are controllers in their own right; for everything Whole Team does with the information, we are. Section 12 explains what that means for you.
2. The short version
- We hold the least we can, and children's information is held under stricter rules than adults'.
- Children under 13 never have an account. A parent or guardian answers for them.
- We never sell advertising or personal information, and we do not track you across the internet.
- One message a day is our default; you can turn it down, not up.
- You can see, correct, export and erase information, and a parent can do that for a child.
3. What we collect and why
3.1 Adults (guardians, coaches, managers, club officers, organisers, supporters)
| Information | Why | Lawful basis |
|---|---|---|
| Name, email, mobile number, display name | To run your account, sign you in with a code, contact you about the service | Contract |
| Your club, team and role | So the app shows you the right things and nobody else | Contract |
| Which children you are a guardian for | The family model: you see and answer for your children | Contract; and the child's best interests |
| Availability answers, messages, register marks, selections, minutes you enter | The service itself | Contract |
| Payments you make (amount, date, last four digits of card, receipt) | To take and record subs, entry fees, tea hut and shop purchases | Contract |
| Device tokens for notifications; digest time; email fallback | To send you one digest a day and the few immediate messages | Contract; legitimate interests (running the service well) |
| Support conversations | To answer you | Legitimate interests |
| Product events (signed in, availability answered, digest opened, payment made) against your account, in our own database only | To understand if the product works | Legitimate interests; never profiling, never shared |
| For coaches and officers: identity check reference numbers and dates (DBS, PVG, AccessNI), qualification names and expiry dates, code of conduct acceptance | The club's safeguarding register, which the club is required to keep | Legitimate interests of the club and Whole Team; legal obligation on the club |
| Your governing-body registration number (for example a SCRUMS number), where your sport requires one, and who entered it | So the club can confirm registration and file the reports its governing body requires | Legitimate interests (the governing body's rules require registration) |
Your mobile number is used to sign you in by text, and is shown to the club's coaches, team managers and leadership as the person to call if something happens. Nobody else can see it.
If you set up a club or become its main contact, we ask for your mobile number. We use it only to reach you about the club's account: security, safeguarding reports and problems with the service. Other members don't see it.
We never hold the content of a disclosure certificate, only its reference number and dates.
3.1a Emails about getting your club going
If you set a club up, or you are given a club-leadership role (admin, treasurer, safeguarding officer, president), we send you a few short emails over your first month about using Whole Team: one thing to try in each, and a film. If you ask us for the guide from a form on our website, we send you a shorter series instead.
| Information | Why | Lawful basis |
|---|---|---|
| If you set the club up: your email address, your club, and what your club has set up so far | To send a few short emails about getting the club going, and so that each one asks about something you have not done yet rather than something you have | Our legitimate interests (telling the person who asked us for the service how to use it), together with the soft opt-in in regulation 22(3) of PECR. We have weighed this: the emails go only to the person who set the club up, they are about the thing that person asked us for, there are six of them, every one carries a one-click unsubscribe, and the form that collects the address carries a box to refuse before any of them is sent |
| If you were given a club-leadership role by somebody else: your email address and your club | The same | Your consent, given by ticking an unticked box in the email telling you about the role. Without that tick we send you none of these |
| If you asked from the form on our website: your email address and the role you chose | To send you the short guide you asked for | Your consent, given by ticking an unticked box and then clicking the link in a confirmation email. Nothing is sent until you click it, and an unconfirmed request is deleted after seven days |
We never send these to a parent, a player, a child, a helper, or anyone invited into a club, and never to anyone under 18. Whether somebody can receive them is recorded against their subscription, not worked out at the time of sending.
How to stop them. One click on the link at the foot of any of them, which needs no sign-in and takes effect at once; or the switch on your account page; or by replying and asking. Stopping them does not affect anything else we send you: sign-in codes, invitations, receipts and the digest your club set up are not marketing and carry on.
How long we keep the record. Until you unsubscribe. After that we delete the subscription on our ordinary schedule, but we keep a one-way hash of your email address, with the date and the reason, for as long as we send marketing email at all. We cannot read an address back out of a hash; we can only check a new one against it. That is deliberate: it is the least we can hold that still lets us prove we were asked to stop, and still stops you being signed up again by a later form.
3.2 Children (under 18)
A child's record is created by a parent or guardian, or by a club through an invitation which the guardian must accept and confirm before anything about the child exists.
| Information | Why | Lawful basis |
|---|---|---|
| First name and initial (as shown to others), full name (to the guardian and club officers only), date of birth | To place the child in the right age group and apply the governing body's rules; the display name is the least that still works | Contract (with the guardian); child's best interests |
| Team, availability, selection, attendance, minutes played, results | The service | Contract |
| A short "what a coach should know" note and an emergency contact, if the guardian chooses to give them | So the people responsible for the child - their club's coaches, team staff and safeguarding officer - have what they need, before the day as well as on it | Explicit consent of the guardian (special category, health) |
| Fit-to-play stand-down: category, until date, guardian confirmation | To stop a child being selected while stood down, including at another club's tournament | Explicit consent of the guardian; the child's vital interests and safety |
| Photo consent (per child, per guardian, off by default) | To control whether the child appears in Moments | Consent |
| From 13, if a guardian enables it: a login and email for the child | To let the young person see their own fixtures and answer for themselves | Consent (guardian and young person) |
| The child's governing-body registration number (for example a SCRUMS number), where the sport requires one, and who entered it | So the club can confirm registration and file the reports its governing body requires, including serious-injury reports | Legitimate interests (the governing body's rules require registration) |
We also store your or your child's governing-body registration number — for example a SCRUMS number — where your club's sport requires one, so the club can confirm registration and file the reports its governing body requires. It is deleted when the record is erased.
Children are never shown advertising or sponsors. We do not profile children, do not use their location, and do not apply automated decisions to them.
3.3 Information we do not collect
Location or GPS; contacts from your phone; photos other than those a guardian consents to in Moments; browsing outside our service; social media accounts; card numbers (Stripe holds them, we see the last four digits); the content of disclosure certificates; a child's medical history beyond the one short note above.
Location. If you allow it, the app uses your phone's location on the phone only, to show where you are on a map. We never receive it or store it. You can switch it off in your phone's settings at any time.
Maps on a club's website. A club's public website can show a map of where it plays. Your browser fetches the map from OpenFreeMap, which uses OpenStreetMap's data: no account, no key and no cookies, and we send them nothing about you. Nothing else on that page comes from anyone but us.
4. Where information comes from
From you; from your club or organiser (name, team, email for an invitation); from Stripe (payment status); from Apple and Google (notification delivery and, if you use them, sign-in); from the governing bodies' published rules (no personal information).
5. Who we share it with
- Your club and the people in it, according to their role: a coach and the club's other team staff see the
club, including a child's short note and emergency contact on any day, not only on a day that child has an event; a safeguarding officer sees the club; a parent sees their own child and the names (first name and initial) of team-mates.
- The organiser of a competition your team enters: team names and a headcount, never children's names.
- Our processors, who act on our instructions under contract: listed in PROCESSORS_REGISTER.md and
summarised in section 13.
- Anthropic, only where a club has switched on a feature that uses it, and only what that feature sends.
Section 6a says exactly what that is.
- Authorities when the law requires it, or a child's safety requires it.
We never sell personal information, never share it for advertising, and never let a third party use it for their own purposes.
6. Where it is kept
Our database and files are in the United Kingdom (Supabase, London region). Email is sent from the United Kingdom (AWS SES, London); Resend (Ireland) is retained as a switchable fallback and sends nothing while SES is in use. If you sign in with a text code, your number and the message go to Twilio (Ireland), and the text reaches you over the UK mobile networks; text codes are only ever sent to UK mobile numbers. We hold your number as a hash in the record of codes sent, never as the number itself. So the core of your personal data - your account, your club's records, and the mail we send you - is held in the United Kingdom. What still involves a transfer outside the UK is web hosting and app compute (Vercel's edge network) and a few narrow specialist services - payments (Stripe), notifications (Google Firebase, Apple) and address lookup (Google) - under the UK's adequacy regulations for the EEA or, for the United States, the UK Extension to the EU-US Data Privacy Framework or the International Data Transfer Addendum to standard contractual clauses. Copies of the safeguards are available from privacy@wholeteam.co.uk.
6a. Where we use AI, and what it is sent
We use Claude, made by Anthropic, in two places. Both are off until a club admin switches them on, and each one says what it does before you use it.
Ask Whole Team answers a club admin's question from our help guides and the few records that person can already see. It is never sent a phone number, an emergency contact, a health note, a stand-down, a safeguarding or coach-register record, or a photo, and a child is named to it as a first name and an initial only.
Add people reads a list a club admin gives us so the club does not have to type it in. A spreadsheet, a pasted list or a contacts file is read by our own code and never leaves us. A picture or a PDF cannot be read that way, so it is sent to Anthropic as it is - which means a screenshot carries whatever is in the frame, including names as a group saved them and the mobile numbers of people the person has not saved. The screen says so before anything is sent. Claude sends back names, emails, mobile numbers and team names in a fixed form and nothing else: it does not describe the picture and nothing else is taken from it. We delete the file as soon as it is read.
What we keep from it is a name, an email, a mobile number and a team, on the team's own list, so that somebody the coach has already said yes to is let in when they join. It is seen by that team's staff and the club's leadership, and nobody else. A name leaves the list 30 days after that person joins, or after 90 days if they never do.
Anthropic process it in the United States under our contract with them, with the EU standard contractual clauses and the UK Addendum. They delete what is sent and what comes back within 30 days, and they do not train their models on it.
7. How long we keep it
Set out in RETENTION_AND_ERASURE_POLICY.md. In short: while a person is an active member of a club and for a limited period after; children's records are archived after 18 months without an active membership and anonymised after a further 6 months; financial records are kept for 6 years as the law requires; messages a person retracts are hidden immediately and kept only for safeguarding review.
8. Your rights
You can ask us to: give you a copy of your information (access); correct it; erase it; restrict or object to how we use it; move it (portability); and withdraw consent where consent is the basis. A guardian can exercise these rights for a child. A young person of 13 or over who understands what they are asking can exercise them for themselves.
To exercise a right: in the app, You > Your data; or email privacy@wholeteam.co.uk. We respond within one month. We may ask you to confirm your identity. For a child's erasure request there is a 30-day period in which any other guardian of that child, or the club's safeguarding officer, may object; see the retention policy.
You can complain to the Information Commissioner's Office at ico.org.uk/make-a-complaint or 0303 123 1113. We would rather you told us first.
9. Automated decisions and profiling
None. We do not make decisions about you or your child by automated means, and we do not profile anyone.
10. Cookies and tracking
Our app and the portal use only the cookies needed to keep you signed in. Our website also has one Google advertising tag, which loads only if you accept it. Its cookies show us which of our adverts led to a club being set up, and nothing else. No analytics cookies and no tracking pixels in emails. You can change your answer at any time from "Cookie settings" in the website's footer. See COOKIES_AND_TRACKING.md.
Where a club came from. When a club is set up from a link that carries campaign tags — for example from one of our adverts — we keep the three values that link named: source, medium and campaign. They are kept with the club, once, and never changed afterwards, so we can tell which adverts led to clubs. We do not keep the click identifier, the page you arrived on, the site you came from, or anything else about the visit, and nothing is stored on your device for this.
11. Children and the Children's Code
Whole Team is likely to be used by children, so we follow the ICO's Age appropriate design code. The choices it drives are: high-privacy defaults; the least information that works; no profiling, no location, no nudges; adults-only posting in chat; no direct messages; children's names shown as first name and initial; consent per child for photos, off by default; bite-sized explanations at the moment a use begins; a separate notice for young people; and a Data Protection Impact Assessment kept on file. That assessment is DPIA v1.1, signed by our director on 10 October 2026 (`DPIA_v1.md` in this set, with the signed copy held by the company). It is reviewed every 12 months, and whenever a new kind of information or a new processor arrives.
12. Clubs and organisers as controllers
Your club decides who is in it, what it asks you for and how long it keeps its own records. When a club enters information into Whole Team, we process it for the club and for you under this notice. If a club asks you for information we do not need for the service, the club's own privacy information applies to that. Questions about what your club holds go to the club's safeguarding officer or admin first.
What we may do with a club's information, and what we must do for it, is set out in the club data processing agreement, which the club accepts when it is set up and which forms part of Part B of the terms.
13. Our processors, in one line each
Supabase (database and storage, United Kingdom); AWS (email through SES, and encrypted backups in S3, United Kingdom); Resend (email, Ireland, retained as a switchable fallback); Twilio (sending a sign-in code by text to a UK mobile, Ireland); Vercel (web hosting and functions, EU and US); Stripe (payments, EU and US, an independent controller for card processing); Google Firebase (push notifications, US); Apple (push notifications and, if used, sign-in); Google (address lookup when a club adds a venue; sign-in if used); Anthropic (Claude, United States - only for the two features in section 6a, and only when a club has switched one on). Full details in PROCESSORS_REGISTER.md.
14. Changes
We will tell you in the app and by email before any change that affects you, and we keep every version. Version 1, the day it is published.
15. Contact
privacy@wholeteam.co.uk - Whole Team Ltd, 5 South Charlotte Street, Edinburgh EH2 4AN - ICO ZC248423
Appendix: retention and erasure policy
Also on its own page, to link to: the retention and erasure policy.
Draft v0.2, 15 September 2026. Last updated 10 October 2026 (Add people's team list and its call log added). Effective the day it is published.
0. Two words this policy uses precisely (added 20 Sep 2026)
Anonymised means the row stays and the person goes: name, date of birth, contacts, notes and consents are cleared, and the club's history (availability, selections, attendance, minutes, results) stays attached to an unnamed record. This is what happens to people.
Removed means the row is deleted outright. This applies only to operational records that are about a device or a session rather than a person's history: support conversations, product event rows, server logs, notification tokens, and coach register entries after a role ends. Principle 198's "nothing deletes" governs things a person made or a club needs; it does not oblige us to keep a 30-day-old server log for ever, and keeping one would breach data minimisation.
Where this policy says removed, delete. Where it says anonymised, anonymise. Nothing else is deleted.
1. Principles
We keep personal information only while it is needed for the purpose it was collected for, then archive, anonymise or delete it. "Nothing deletes data" inside the product means people cannot accidentally destroy records; it does not mean we keep information forever. Anonymisation removes the name, date of birth, contact details, notes and consents from a record and leaves the team's history (availability, minutes, results) attached to "Former player" so a club's records still add up.
2. Schedule
| Information | Kept while | Then |
|---|---|---|
| Adult account (name, email, phone) | The account is active | 24 months after last sign-in, or on request: anonymised |
| Child record (name, DOB) | An active membership exists | 18 months with no active membership: archived (hidden from clubs, restorable by the guardian); 6 further months: anonymised |
| Guardian-child links | The child's record exists | Ended with the record |
| Availability, selections, attendance, minutes, results | Indefinitely, attached to the (anonymised) record | Club history |
| Messages | Indefinitely within the thread | Retracted or hidden messages: hidden at once, body kept for safeguarding review, anonymised with the author's record |
| On-the-day note and emergency contact | While the child has an active membership and the consent stands | Removed on withdrawal of consent, on the child leaving, or on anonymisation, whichever first |
| Stand-down records | Until the until-date plus 12 months | Anonymised with the record; category and dates may remain in the club's safeguarding statistics without a name |
| Photo consent and other consents | While the child's record exists | With the record |
| Moments photos | While the child's record exists | Re-blurred, not removed, when any guardian withdraws consent (see the note under this table); removed with the child's record |
| Payments and receipts | 6 years from the end of the financial year (tax law) | Deleted; Stripe keeps its own records under its policy |
| Governing-body registration number, and who entered it | While the person has a Whole Team record | Deleted when the record is erased, or when the number is cleared (migration `20261112100000`) |
| Coach register (check references, qualification dates) | While the person holds a role | 12 months after the role ends, or as the governing body requires, then removed |
| Code of conduct acceptances | While the person is a member | 12 months after, then removed |
| Terms acceptances (which version of our terms a person or a club accepted, when, and on which surface) | 6 years after the account or the club closes | Deleted. Append-only while kept: a record of what somebody agreed to is worth nothing if a later version can rewrite it |
| Support conversations | 24 months | Deleted |
| Product events (analytics) | 13 months | Deleted or aggregated |
| Notification tokens | Until replaced or the device is removed | Removed |
| Server logs | 30 days | Deleted |
| A team's list of people to expect (a name, and an email, mobile or child's first name where the coach had one, from Add people) | 30 days after that person joins; 90 days if they never do | Deleted |
| What a file read by Claude cost (the club, the kind of file, the model, the tokens and the cost; never anything that was in the file) | 13 months | Deleted or aggregated |
| Job run records (which scheduled job ran, when, whether it succeeded, and counts; never a person) | 90 days | Deleted |
| Backups | 30 days rolling | Overwritten; anonymisation propagates at the next cycle |
Amended 20 September 2026 (David), principle 216: withdrawing photo consent re-blurs the child and keeps the photo. This row previously said the photo was removed. It was wrong, for two reasons.
First, a team photo carries other children whose guardians consented. Deleting it would take their memory away over someone else's decision, which is not a decision one guardian is entitled to make for another family.
Second, it is not what the guardian agreed to. The consent screen, which is what they actually read, says: "Off any time, blurred in every photo including old ones, within a minute. Other faces in the same photo may be blurred too, because we don't store who is who." A policy that promised deletion would contradict the screen the consent was given on.
So: on withdrawal, every photo of that child is re-rendered with their face blurred, everywhere, within a minute (proven at 986 ms), including photos added before the withdrawal and any board the child joins later. The blurring is not reversible from the stored image: the derived image is replaced, and the original was never uploaded. The child is no longer identifiable in it, which is what withdrawal is for.
A photo is still removed with the child's record, when it is anonymised or erased, exactly as this table says. An uploader may also hide their own photo at any time, and a coach may hide any photo on their team's board.
Principles 161, 170, 178 and now 216 say the same thing, and the code does it.
3. Erasure requests
- A guardian requests erasure of a child in the app or by email. A 30-day grace period starts.
- Every linked guardian is notified. If any objects, or the club's safeguarding officer objects, the
request pauses and the club's decision on membership governs; the data then follows that decision.
- If no objection, the record is anonymised on day 31.
- Adults may request erasure of their own account; it is anonymised within one month, except payment
records kept under tax law and any record needed for a safeguarding matter in progress.
- Requests are logged with dates in the rights-requests register.
4. Season rollover
Rolling a season forward copies memberships and ends the old rows; it never deletes. Past seasons stay readable to the club and the family behind a "Past seasons" link.
5. Review
This schedule is reviewed every 12 months and whenever a new category of information is introduced. Owner: David Godfrey.
Appendix: processors and international transfers
Draft v0.5, 16 September 2026. Last updated 10 October 2026. Reviewed with every new integration. v0.5: Anthropic's row rewritten for the two product uses - Ask Whole Team and Add people's picture reader - with the retention and training terms and the transfer basis. Neither is on for any club until David says so. Development tooling keeps its own line. v0.4: AWS's line covers encrypted backups in S3 (London), kept 30 days and encrypted with a key AWS does not hold, from 10 October 2026. v0.3: Twilio added - it has carried sign-in codes to UK mobiles since 2 October 2026. v0.2: the database moved to Supabase's London region and email moved to AWS SES in London; Resend is retained as a switchable fallback.
| Processor | Purpose | Location | Transfer basis | Contract | Sub-processors |
|---|---|---|---|---|---|
| Supabase Inc | Database, auth, storage, realtime, cron | United Kingdom (London, eu-west-2) | UK — no international transfer; DPA signed | Supabase DPA | AWS (London) |
| Amazon Web Services (SES, S3) | Transactional email (active sender), and encrypted backups (S3, from 10 October 2026) | United Kingdom (London, eu-west-2) | UK — no international transfer; DPA | AWS Service Terms; DPA | AWS |
| Vercel Inc | Web hosting, serverless functions, cron | EU and US edge; functions region set to Dublin | UK Extension to EU-US DPF; IDTA/SCC addendum | Vercel DPA | AWS |
| Resend Inc | Transactional email (retained as a switchable fallback; not sending while SES is in use) | Ireland region | UK adequacy; DPA | Resend DPA | AWS |
| Stripe Payments UK Ltd | Payments (independent controller for card processing; processor for the platform relationship) | UK/EU/US | Stripe's own framework; UK Extension to DPF | Stripe Services Agreement, Connect terms | Stripe Inc |
| Twilio Ireland Limited | Sending the six-digit sign-in code by text to a UK mobile. Twilio is given the number and the message, which carries the digits and never a link; it is not given a name, an email address or anything about the club. The number is stored here as a hash and never in clear | Ireland, with carrier delivery in the UK | UK adequacy for Ireland; Twilio's own DPA carries the SCCs and the UK Addendum for its US affiliate | Twilio DPA (part of the Terms of Service) | Twilio Inc (US); the UK mobile networks that carry the message |
| Google (Firebase Cloud Messaging) | Push notification delivery (device tokens) | US | UK Extension to DPF; Google Cloud DPA | Firebase terms | |
| Apple Inc (APNs) | Push delivery; Sign in with Apple (Phase 5) | US | UK Extension to DPF | Apple developer terms | Apple |
| Google (Places API) | Address to coordinates when a club adds a venue (no personal data sent beyond an address) | US | n/a for personal data; DPA in place | Google Maps Platform terms | |
| Google (Sign in, Phase 5) | Optional sign-in | US | UK Extension to DPF | Google terms | |
| OpenFreeMap (with OpenStreetMap data) | Map tiles on a club's public website (Find us). The visitor's browser fetches tiles, fonts and the map style; no account, no key, no cookies, and nothing about the visitor is sent beyond the request itself | EU (Germany) | No personal data is sent; no account or contract needed | openfreemap.org terms (free, commercial use allowed) | OpenStreetMap contributors |
| Microsoft 365 | Company email and documents (support mailbox) | UK/EU | Microsoft DPA | Microsoft Customer Agreement | Microsoft |
| Anthropic (Claude) | Two uses, both off by default and both switched on by a club. (1) *Ask Whole Team*: answers a club admin's question from the help guides and the few records that person can already see; no phone number, no emergency contact, no health note, no stand-down, no safeguarding or coach-register record and no photo is ever sent, and a child is named as first name and initial only. (2) *Add people's picture reader*: where a club admin chooses to add a picture or a PDF of a list, the file is sent as it is - a screenshot carries whatever is in the frame, including names as a group saved them and the mobile numbers of people the coach has not saved - and Claude returns names, emails, mobiles and teams in a fixed schema and nothing else. A spreadsheet, a pasted list or a contacts file is read by our own code and never sent. The file is deleted once read. | US | Anthropic DPA (effective 24 February 2025, part of the Commercial Terms) with the EU SCCs and the UK Addendum | Anthropic Commercial Terms and DPA | AWS, Google Cloud (Anthropic's own sub-processors) |
| Anthropic (Claude), development tooling | Writing and reviewing our own code. No production personal data is sent. Kept separate from the two product uses above because it is a different thing with a different basis | US | n/a - no personal data | Anthropic terms | - |
Not used: analytics SDKs, advertising networks, data brokers, map SDKs in the app.
What Anthropic keeps, and for how long
Taken from Anthropic's Commercial Terms and their Privacy Centre on 10 October 2026, and quoted here because the retention is the whole reason this row is acceptable:
- Inputs and outputs are deleted within 30 days of being received, except where a longer period is needed to
comply with the law or to enforce the terms, or where the content is flagged for trust and safety review.
- They are not used to train Anthropic's models. Training on commercial customers' inputs and outputs requires
the customer's explicit permission, and we have not given it.
- The processing happens in the United States, which is why the transfer basis above is the DPA with the EU
SCCs and the UK Addendum rather than adequacy.
Sources, for the next person to check rather than take on trust: <https://www.anthropic.com/legal/commercial-terms> and <https://privacy.anthropic.com/>.