Privacy notice
What Kit Intelligence does with personal data in Bolton Wanderers, who decides why it is held, and how a person exercises their rights over it.
Last updated 27 July 2026 · Sub-processors · Terms
Who is responsible for your data
There are two organisations involved, and the difference matters for where you send a request.
- Bolton Wanderers
- The controller. Bolton Wanderers decides which players and staff are recorded, why, and for how long. Their own privacy notice covers the lawful basis for holding the data, and any request about a player is theirs to answer first.
- Kit Intelligence
- The processor. We run the software and store the data on the club's behalf, and we only process it on the club's documented instructions. We do not sell it, mine it for our own purposes, or share it between clubs.
We are separately a controller for a small amount of our own data: the accounts of staff who sign in, our security logs, and the billing contact at each club. That processing rests on our legitimate interest in running and securing the service, and on performing our contract with the club.
Children's data
Most of the people recorded in Bolton Wanderers are academy players, and most of them are children. We treat that as the defining fact about this system rather than a footnote.
What that means in practice: we hold the smallest set of fields that makes a kit room work — a name, a squad, a shirt number, and what kit that person has been given. There is no date of birth, no home address, no parent contact, and no medical or safeguarding record anywhere in the system. Your club is responsible for the lawful basis for recording a child (including anything their safeguarding policy requires of them), and we act only on their instruction.
Free-text notes are the one place a club could put more than that. Notes are for kit — “kept from last season”, “awaiting replacement”. Anything about a child's health, background or welfare belongs in your club's own safeguarding system, not here.
What we hold
- Identity
- Name. Email address where the club records one (optional on player records, required for staff logins).
- Operational
- Squad, jersey number, site, and the history of kit issued, returned, lost or written off.
- Free text
- Notes typed by kit-room staff against an item, a movement or a person. Content is whatever the club's staff type — see the caution below.
- Account + security
- For staff logins only: password hash, encrypted authenticator secret, sign-in and lockout events, IP address, browser user-agent, and the audit trail of admin actions.
What we deliberately do not hold
The database has no column for any of these. Adding one would be a change we tell every club about in advance.
- Date of birth
- Home address or phone number
- Parent or guardian name, address or phone number
- Medical, injury or safeguarding records
- Next of kin
- Payment card details
- Biometric or special category data (UK GDPR Art. 9)
Who else sees it
We use a small number of external services to run the platform. Each one is contracted as a sub-processor, each is listed publicly with what it sees and where it processes, and your club gets at least 14 days' notice before we add another one.
- Fly.io — Application hosting and managed Postgres database. (London (LHR), United Kingdom)
- Backblaze B2 — Encrypted off-site backup storage. (EU Central (Amsterdam / Frankfurt) — UNCONFIRMED, under review)
- Tigris Data (via Fly.io managed Postgres backups) — Managed Postgres snapshot storage for Fly.io's built-in backup feature. Separate from, and additional to, the restic/Backblaze path above. (UNCONFIRMED — Fly configured AWS_REGION as 'auto'; Tigris is globally distributed by default and no region has been pinned.)
- Anthropic, PBC — Large language model for AI assistant queries and delivery-photo parsing. (United States)
- Sentry (Functional Software, Inc.) — Application error tracking and alerting. (European Union (Frankfurt))
- Browser push services (Apple, Google, Mozilla) — Transport relay for web-push notifications to a staff member's own browser/device, where they have opted in. (Operated by the relevant browser vendor; varies by recipient device.)
- Resend (Resend, Inc.) — Outbound email transport — account setup links, low-stock alerts, invoices and the weekly digest. (European Union (Ireland). Verified 18 Aug 2026 from the sending domain's own DNS: the MAIL-FROM host is feedback-smtp.eu-west-1.amazonses.com, i.e. AWS eu-west-1.)
Read the full sub-processor disclosure →
Most processing happens in the United Kingdom. The one routine transfer outside it is to the AI model provider that powers the assistant, in the United States; names, squads, sites and emails are replaced with meaningless tokens before that request leaves the UK. The sub-processor page documents the single exception — an uploaded photo of a paper delivery note, which cannot be tokenised.
How long we keep it
These are the retention windows written into the platform. Two things to be clear about. Every automated deletion policy is currently switched off — the last column is not decoration — so today nothing is purged automatically and your data is retained until your club asks us to remove it. And these policies are platform-wide, not per club: there is no per-club setting, so if we ever switch one on it affects every club, and we would notify each club's data protection contact in writing before it took effect. A club that needs a shorter window agrees it in its Data Processing Addendum and we honour it by hand.
| Record | Window | Counted from | Auto-delete on? |
|---|---|---|---|
| Kit movements (stock ledger) | 3 years | Date of the movement. | No — opt in |
| Kit allocations to a person | 3 years | Date the allocation was CLOSED. An allocation still open — kit a player currently holds — is never in scope. | No — opt in |
| Low-stock alert records | 1 year | Date the alert was raised. | No — opt in |
| Security audit log | Kept indefinitely | Never purged today. The table is append-only — a database trigger blocks any edit or deletion, including by us — so it is the record that an erasure happened. A 7-year window is written into the policy table but is inert while the append-only block stands. | No — opt in |
| Player and staff records | Set by your club | No automated purge yet — the schema has no 'departed' date to anchor one to. Deletion is on the club's instruction, and is honoured within 7 working days. | No — opt in |
Encrypted backups cycle out on their own schedule (daily, weekly and monthly snapshots) after a record is deleted from the live database. Nobody but us can read them, and they age out naturally rather than being edited.
How we protect it
- Every club's data is separated at the database level by row-level security, not by application code alone — a query that forgets to filter by club returns nothing rather than another club's rows.
- HTTPS only, with HSTS in production.
- Passwords stored as bcrypt hashes; every personal account needs two-factor authentication (authenticator app) as well as a password to sign in.
- The shared kit-room tablet is the one exception: it signs in with a per-site PIN rather than a personal login and has no second factor, so it is scoped to one site and its PIN is rotated when staff change.
- Authenticator secrets are encrypted at rest with a key held outside the database.
- Security-relevant actions are written to an append-only audit log that a database trigger prevents anyone — including us — from editing or deleting.
- Nightly off-site backups, encrypted on our side before they leave the platform, so the backup provider stores ciphertext only.
- Error reports are scrubbed of personal fields before they leave the platform, and request bodies are dropped entirely.
- Data sent to the AI assistant's model provider is pseudonymised first — see the sub-processor page for the one documented exception.
If a breach affects your club's data we tell your club without undue delay, and we aim to do it within 24 hours of knowing. We hold no security certification today — no ISO 27001, no SOC 2, no Cyber Essentials — and we would rather say so than imply otherwise.
Your rights
A player, a parent or a member of staff has the rights below under UK GDPR. Start with your club — they are the controller, and they hold the context we do not. They then instruct us, and we act within 7 working days.
- Access (Art. 15)
- Ask your club. They ask us, and we assemble everything held about the person — their record, their kit history, and the security-log entries that mention them — and return it within 7 working days. This is done by hand by an operator today, not by a self-service button.
- Rectification (Art. 16)
- Your club's kit-room admin can correct a name, squad, number or email directly in the app, immediately.
- Erasure (Art. 17)
- On your club's instruction we delete the person's record and their allocation history, using a script that first restores any kit they still held back to stock. The deletion itself is recorded in the audit log (the fact a deletion happened, not the deleted data).
- Restriction (Art. 18)
- On your club's instruction we flag the record so it is retained but no longer used operationally.
- Portability (Art. 20)
- A structured, machine-readable export, provided to your club on request. Same manual route and same 7 working days as access above.
- Object (Art. 21)
- Raise this with your club — they decide the lawful basis for holding the record, so the objection is theirs to weigh.
Today none of this is a self-service button. Deletion runs through a purpose-built script that records what it did in the audit log; an export is assembled by an operator by hand. That is a deliberate disclosure rather than an evasion — the seven working days is a commitment about people, not about software, and a self-service export and erasure screen for club admins is planned.
Cookies
One cookie, and only for people who sign in: a session cookie that keeps you logged in. It is strictly necessary, it times out after a period of inactivity, and it is set with the HttpOnly and SameSite protections. There is no advertising, no analytics and no third-party tracking anywhere in the app, which is why you have not been shown a cookie banner.
Every script and font the app loads is served from our own domain, so no outside network learns that you opened a page or what device you did it on. That now includes the barcode-reading library behind the camera scanning screens, which used to be fetched from a public content delivery network and is served by us instead. The one thing your browser may fetch from elsewhere is your club's own crest, if your club supplied it as a link to an image hosted on their site rather than as a file.
Contact, and how to complain
Ask Bolton Wanderers first — their data protection contact can answer most things and can instruct us on the rest. To reach Kit Intelligence directly, use the data protection contact named in your club's Data Processing Addendum.
If you are not satisfied with the answer, you can complain to the Information Commissioner's Office — the UK's data protection regulator. Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF. Helpline 0303 123 1113. https://ico.org.uk/make-a-complaint/. Complaining to the ICO does not cost anything and does not affect any other route open to you.
We update this notice when what we do changes. Material changes are notified to each club in writing; the date at the top tells you when it last moved.