Last updated 31 July 2026
Data processing addendum
This addendum forms part of the terms of service and applies whenever Fullrack processes personal data on a gym’s behalf.
1. Roles
Your gym is the controller. You decide what member data is collected and why. Fullrack is the processor. We act on your documented instructions — using the service is an instruction — and we never use your members’ data for our own purposes. We do not sell it, we do not mine it, and we do not train anything on it.
There is one carve-out, and it runs the other way. The share link a personal trainer uses to tell another trainer about Fullrack is our marketing, not yours. For those leads we are the controller: the form is ours, it posts to our own endpoint, and it reads nothing from your database and writes nothing to it. A member referring a friend to your gym is the opposite case — that lead is yours, it lands in your admin list, and we are your processor for it like everything else. What we do with our own leads is in our privacy notice.
Either way the rule above holds. Your members’ data is never used for anything of ours.
2. Following your instructions
We process your members’ data only on your instructions. Using the service is an instruction; so is anything you ask us for in writing. That covers moving data as well as handling it — we will not move your deployment to a different country or a different provider on our own initiative, and section 5 says where it sits today.
The exception is UK law. If a court order, a regulator or a statute requires us to do something else with your data, we will do it — but we will tell you before we do, unless the same law forbids us from telling you.
If we think one of your instructions breaks the UK GDPR or another data protection law, we will say so and we will not act on it until it is settled. That is not us marking your homework. It is the clause that keeps both of us out of trouble.
3. What we process, and why
| Category | Data | Why |
|---|---|---|
| Members | Name, email, username, date of birth, membership tier, join date | Accounts, bookings, membership limits |
| Health — special category | Waiver and PAR-Q answers, medical conditions, emergency contact, weight, body composition, max heart rate | Safe training and the gym’s duty of care |
| Nutrition | Food diary entries, macro targets, adherence | Coaching |
| Activity | Bookings, attendance, PT sessions, lifts, PRs, plans | Running the gym |
| Payments | Amount, date, method, Stripe customer reference | The gym’s revenue ledger. No card numbers ever reach Fullrack — they stay with Stripe |
| Staff | Name, email, role, shifts, hourly and session rates | Rotas and payroll figures |
Health data is special-category data under Article 9 of the UK GDPR. It is collected behind its own explicit consent step, separate from the waiver. Who can see it is set out in section 6, and it is not the answer most gyms assume, so read that part.
The people behind those rows fall into four groups, and it is worth naming all four:
- Members — your gym’s members, including ones you have archived but not erased.
- Staff — your admins and personal trainers.
- Emergency contacts — the person a member names to be called if something happens to them in your gym. Their name and phone number sit in the member’s health record. They are usually not a member, they did not fill the form in, and they may not know they are in there. That is data you hold about somebody else, and it is your job to be able to explain it.
- Referral leads — friends of members who fill in your referral form. Name, a phone number or email address, your member’s name as the referrer, and whatever they type in the note.
We process all of it for one purpose: running your gym’s app for you. The processing starts when your deployment goes live and ends 30 days after the agreement does — those 30 days being the export window in section 12.
4. Sub-processors
| Who | What they do | Where |
|---|---|---|
| Netlify | Hosting, serverless functions, and the database (Netlify Blobs) for your deployment | US, with UK/EU regions available |
| Stripe | Payment processing under your own Stripe account. Fullrack receives webhook notifications, not card data | US / EU |
| Open Food Facts | Barcode lookups for branded food products. A barcode is sent; no member data is | EU |
| Google, Apple, Mozilla | Delivering push notifications to a member’s own device — Google FCM on Chrome and Android, Apple APNs on Safari and iPhone, Mozilla autopush on Firefox. Each receives an endpoint identifier for that one device and a payload it cannot read, because the payload is encrypted between our server and the device | US / EU |
| Our email, if you contact support | US / EU |
The barcode scanner your members use to log food is served from your own deployment rather than a public CDN, so no third party is told which of your members opened it. The lookup that follows sends a barcode number to Open Food Facts and nothing else.
We will give you 30 days’ notice before adding or changing a sub-processor. If you reasonably object you may terminate without penalty.
Every one of them is engaged under a written contract that puts the same data protection obligations on them as this addendum puts on us. If one of them fails, that is our failure — we stay fully liable to you for what they do with your members’ data, exactly as if we had done it ourselves.
5. Sending data outside the UK
Netlify, Stripe and Google can process data outside the UK. For each of them we have entered into their own data processing terms, which incorporate the UK International Data Transfer Addendum to the EU Standard Contractual Clauses. In that chain you are the exporter, we are your processor, and the provider is the importer.
We keep a transfer risk assessment covering those transfers and we will send it to you if you ask for it. If we ever move deployments to a UK or EU region we will say so here, because it is the first thing a gym holding health data asks about.
6. Security
- PINs hashed with PBKDF2 (210,000 iterations, per-user salt). We cannot read a member’s PIN.
- HTTPS everywhere, with HSTS on, so nothing travels between a member’s phone and the app in the clear. Sessions expire after 30 days; media links use separate short-lived signed tokens.
- At rest, Netlify encrypts the store your data sits in. We do not add a second layer of our own encryption on top, so anyone holding valid credentials for that store could read what is in it — which is why those credentials are the control that matters, and why they sit with one named person. PINs are the exception: hashed, and unreadable by anyone including us.
- Personal media is key-worker gated. Progress photos, voice notes and videos can only be opened by the member themselves, by the PT who key-works them, and by your admins.
- Health and waiver records are not. Every active member of your coaching staff can open any member’s PAR-Q answers, medical conditions and emergency contact — not only their own members. That is deliberate: PTs cover each other’s sessions, and the person taking the session is the person who needs to know about the knee. Everyone with that access is bound by the confidentiality obligation in section 7. Deactivating a member of staff cuts the access off immediately — their very next request fails, even if their session has not expired.
- Opening a health record is not written to the activity log today. Exports, erasures, PIN resets, billing changes and payment events are. We would rather tell you that than let you assume the log covers more than it does.
- Each gym runs on its own deployment with its own database. One gym’s data is not merely filtered from another’s — it is not in the same store.
- Daily automated snapshots, kept for 14 days, plus a one-click full export you can keep yourself.
- An activity log records PIN resets, billing changes, exports, erasures and every automated payment event. We keep it for at least 12 months.
- We rehearse a restore from a snapshot at least once a year, and write down how long it took, so that “we take backups” is a tested claim rather than a hopeful one.
If the health-record trade-off is wrong for your gym, say so. Gating it to key-workers is a setting we would rather build for you than have you discover after the fact.
7. Staff and confidentiality
Fullrack is one person. Thomas Green, director of Scarecrow Innovations Ltd, is the only individual with administrative access to your deployment, and he is personally bound by a written confidentiality undertaking covering everything he sees in it — during the contract and after it ends. There is no support team, no offshore desk and no rota of contractors holding a login.
If that ever changes, nobody gets access until they are under the same obligation in writing, and access stays limited to what support and maintenance actually require. “Everyone with access is bound by confidentiality” means considerably more when you can count them.
8. Your members’ rights
We will help you meet a member’s request, by appropriate technical and organisational measures and as far as it is possible for us to do so. Most of the time you will not need us — the tools are in the app, so you can answer a member without waiting on anybody:
- Access and portability — Download their data on any member record produces everything held about them, as one machine-readable file you can hand over as it is.
- Erasure — Erase this member permanently deletes their account, food diary, messages, photos, training log, plans and goals, deletes their media files, and anonymises their bookings and payment rows so your attendance counts and your books still add up. It requires the member’s name typed in full and is written to the activity log.
- Rectification — staff can correct any record directly.
- Objection and restriction — you can deactivate an account so it cannot be signed into or booked against while you work out what to do with it, which is how a restriction request gets held in practice. A member can withdraw their own marketing consent from the privacy section of their account, and that consent is stored with the date they gave or withdrew it.
Two honest notes about erasure. The record that an erasure happened stays in the activity log, including the member’s name, the date and who did it — we keep it deliberately, because it is how either of us proves to a regulator that the request was actually carried out. And an erased member remains inside the daily snapshots until those age out of the 14-day cycle; after 14 days they are gone from those too.
If you need something the app cannot do — an unusual request, an awkward regulator letter, a member who says the export is incomplete — email us and we will come back to you within five working days, sooner if the clock you are on is shorter. Tell us the deadline you are working to and we will work to it.
If a member contacts us instead of you, we will point them to you and tell you it happened.
9. Breaches, and the rest of the help you can ask for
If we become aware of a personal data breach affecting your members, we will tell you without undue delay and within 48 hours, with what we know, what we are doing, and what we would suggest you do. You decide whether the ICO and your members need to be told — you are the controller.
We will also help you with the things around a breach, using the information we hold and to the extent you cannot get there without us: keeping the service secure in the first place (Article 32), telling your members when a breach is serious enough to warrant it (Article 34), a data protection impact assessment if you carry one out (Article 35), and any prior consultation with the ICO that comes out of it (Article 36). In practice that means answering questions properly and quickly, not writing your assessment for you.
10. Audit
Ask us and we will give you the information you need to show that we are doing what this addendum says — a completed security questionnaire, our sub-processor terms, and whatever our providers publish about their own controls. That is usually the fastest way to an answer and it is where we would rather start.
If that is not enough, you can inspect. On 30 days’ written notice you or an auditor you appoint may audit our processing of your data, once a year, in working hours, without disrupting the service, and under a confidentiality agreement. Somebody else’s gym data is off limits. If something has gone wrong, or a regulator asks you to, the once-a-year limit does not apply. You cover the cost of your own audit unless it finds we have broken this addendum, in which case we cover it.
11. What you promise us
You are the controller, so some of this can only be true at your end. You confirm that:
- you have a lawful basis for everything you ask us to process, and that you can point to it;
- you have given your members the privacy information the UK GDPR requires — who you are, what you collect, why, how long for, and who else touches it;
- you have obtained valid, explicit Article 9 consent for the health data your members enter, or another Article 9 condition applies, and you have not pre-ticked, bundled or assumed it;
- the member list you import is data you are entitled to hold, accurate as far as you know, and lawfully obtained from whatever you were using before;
- your instructions to us are lawful, and you will not ask us to do something that puts either of us in breach.
None of that is boilerplate. It is the line between the two of us. We can build the consent step, log the erasure and hold the data properly, but we cannot know whether the member list you handed over was yours to hand over — and if it was not, that is on you and not on us. Section 10 of the terms says what happens then.
12. Deletion at the end
When the contract ends you choose: we return your data or we delete it. If you say nothing, we keep it for 30 days so you can export it, then delete it — including from backups as those age out of the 14-day cycle. Either way we confirm in writing when it is done.
The one exception is anything UK law requires us to keep, which we will name if it ever applies. Today nothing does.