Who the parties are, and when this agreement applies
On one side the sports club, which is the CONTROLLER: it decides what data to collect about its athletes, for what purposes and for how long. On the other Lorenzo Vitale (CPSS, CSCS), Italian VAT number 01344880867, who is the PROCESSOR and processes that data on the controller’s behalf and on its instructions.
Inside the software a club processes health data (Art. 9 GDPR) and, in youth teams, data about minors. Art. 28(3) GDPR requires all processing carried out by a processor to be governed by a contract: this one.
The agreement is accepted before any data is uploaded, and we keep a record of who accepted which version and when. The version published here is 1.9.
The customer accepts this agreement when signing up: the accepted version stays linked to their organisation, with the date and time of acceptance. The text of the current version is the one on this page; the text of earlier versions is kept on record.
1Subject matter, nature and purpose of the processing
1.1 The processor processes personal data solely to provide and maintain the software, and for no other purpose.
1.2 The details of the processing are set out in Annex A, which constitutes the controller’s documented instruction under Art. 28(3)(a).
1.3 The controller states that it has identified a valid legal basis for each purpose and has given data subjects the notice required by Art. 13. The processor is not liable for the lawfulness of the processing decided on by the controller, but must immediately inform it if an instruction appears to infringe the law.
2The controller’s instructions, and what we do not do with its data
2.1 The processor processes data only on the controller’s documented instructions, including instructions on transfers to third countries.
2.2 The following count as documented instructions: this agreement and its annexes, the software documentation, and the settings the controller configures inside the software — roles, permissions, metrics, thresholds, the health-data access levels, by role and by person.
2.3 The processor does not use the controller’s data for its own purposes. In particular it undertakes not to use it to build archives, reference values, statistics or benchmarks across clubs, not even in aggregated form; not to use it to train, tune or evaluate machine learning systems or statistical models; not to disclose it or make it available to third parties other than the authorised sub-processors; and not to use it for commercial or promotional purposes.
2.4 The processor may process anonymous data — carrying no direct or indirect reference to an identifiable person — for technical diagnostics and to improve the software. A series of daily measurements of a single athlete is not anonymous data for the purposes of this clause, and is not covered by it.
3Confidentiality
3.1 The processor ensures that the persons authorised to process the data have committed to confidentiality or are under an appropriate statutory obligation of confidentiality.
3.2 Access to the controller’s data is limited to staff who genuinely need it, and only to what is necessary for the support requested or for maintenance.
3.3 The processor does not access the controller’s health data unless the controller expressly asks for support, and in that case records the fact in writing.
4Security measures
4.1 The processor implements the technical and organisational measures described in Annex B.
4.2 The measures may be updated, but no update may lower their overall level of security.
4.3 The controller acknowledges that security also depends on its own conduct — keeping credentials safe, assigning roles, choosing who may see health data, managing the public links used to collect the questionnaire — and takes responsibility for it.
5Sub-processors
5.1 The controller gives general authorisation to use the sub-processors listed in Annex C.
5.2 The processor informs the controller of any intention to add or replace a sub-processor with at least 30 days’ notice. The controller may object within that period on reasonable and documented grounds; the parties then look for a solution in good faith, and failing that the controller may terminate, without penalty, the part of the service concerned.
5.3 The processor imposes on every sub-processor, by contract, the same data protection obligations as set out in this agreement, and remains liable to the controller for their failures.
6Transfers outside the European Economic Area
6.1 Data is stored in the European Union: the database sits in Ireland and the application runs in the Dublin (Ireland) region. Supabase, Vercel and Resend, among the sub-processors in Annex C, are, however, companies based outside the European Economic Area, and their staff may access the data from third countries for support and maintenance; Vercel also processes some data in the United States; service e-mails are kept by Resend in the United States and contain no athlete data. The support mailboxes are hosted by IONOS in the European Union. These transfers are covered by the safeguards stated in Annex C, and the controller authorises them by accepting this agreement.
6.2 Beyond those in Annex C, the processor does not transfer data outside the European Economic Area without the controller’s written authorisation. Any new transfer would take place only on the basis of an adequacy decision or the standard contractual clauses adopted by the Commission, accompanied by a transfer impact assessment.
6.3 The processor tells the controller if a sub-processor’s technical support may access data from a third country, stating the safeguards that apply.
7Assistance to the controller
7.1 The processor assists the controller in handling data subject requests. The software lets the club do the following itself: a complete export of a single athlete’s data in a structured format, rectification from the management screens, restriction of processing, and permanent deletion with anonymisation of the audit entries concerning that athlete.
7.2 If an athlete contacts the processor directly, the processor does not answer on the merits and passes the request to the club without delay.
7.3 The processor notifies the controller of any personal data breach without undue delay and in any case within 24 hours of becoming aware of it, with the Art. 33(3) information available to it. Those 24 hours are tighter than the regulation asks of a processor, and exist to leave the club a usable margin within its own 72 hours.
7.4 The processor assists the controller with the data protection impact assessment and with any prior consultation of the supervisory authority, providing the technical information needed.
8Liability
8.1 Each party is liable for the damage caused by its own breach, within the limits of Art. 82 GDPR.
8.2 The processor’s liability for damages arising out of this agreement is limited to €3,000 per contract year. The cap does not apply in case of wilful misconduct or gross negligence, nor to administrative fines imposed on one party for an act attributable to the other.
8.3 As to professional indemnity and cyber insurance cover, the processor states that it does not currently hold dedicated insurance cover.
9Audits
9.1 The processor makes available to the controller the information needed to demonstrate compliance with Art. 28.
9.2 The controller may carry out one audit per year, with at least 30 days’ notice, during working hours and without prejudice to service continuity. Further audits are allowed after a data breach or on a reasoned request from the supervisory authority.
9.3 The processor may discharge the obligation under clause 9.1 by providing the software’s technical documentation, its sub-processors’ security reports and any certifications held. The cost of the audit is the controller’s, unless the audit reveals a failure by the processor.
10Record of processing activities
10.1 The processor keeps the record required by Art. 30(2) and makes it available to the controller and to the supervisory authority on request.
11Term, return and deletion
11.1 The agreement lasts as long as the supply contract.
11.2 On termination of the contract, at the end of the read-only period provided for in the Terms of service, the controller may ask, at any time until the deletion provided for in clause 11.3, for the processor to return the data in a structured, machine-readable format, or to delete it. The processor carries out the request within 30 days of receiving it.
11.3 If the controller has made no request within 90 days of termination, the processor deletes the data, after notice by e-mail at least 14 days in advance, and confirms the deletion. Until then the choice remains open: the period exists so that a club’s inattention does not cause the irreversible loss of its athletes’ data.
11.4 The processor may keep the data beyond that period only if and for as long as a legal obligation requires, informing the controller.
11.5 Backups follow their own rotation cycle and are deleted at the latest within 7 days of the deletion of the live data; until then they remain subject to every measure in this agreement.
12Governing law and jurisdiction
12.1 The agreement is governed by Italian law, supplemented by the Italian Privacy Code (Legislative Decree 196/2003 as amended by Legislative Decree 101/2018).
12.2 The courts of Enna, Italy, have exclusive jurisdiction over any dispute.
Annex A — Description of the processing
This annex is the controller’s documented instruction: it says what is processed, about whom and why. It is the part a data protection officer reads first.
| Item | Content |
|---|
| Subject matter | Provision of the software for monitoring athlete workload and protecting athlete health |
|---|
| Duration | The term of the supply contract |
|---|
| Nature of the operations | Collection, recording, organisation, structuring, storage, adaptation, retrieval, consultation, use, comparison, erasure |
|---|
| Purposes | Planning and monitoring workload; recording what the staff saw and decided about reading flags; managing periods of unavailability (injuries, illnesses, other reasons) and the phases of return to play; describing the team’s season epidemiologically; producing reports and printable documents; keeping proof of consent; security and traceability of access |
|---|
| Categories of data subjects | Adult athletes; athletes who are minors; holders of parental responsibility (name and relationship); staff members and athletes with an account |
|---|
| Categories of ordinary data | Personal and sporting details (position, shirt number, preferred foot, nationality, optional photo, market value if the club enters it, external links, additional teams); GPS data from training and matches and measurements from other sources uploaded by the club, with the calculated metrics; perceived exertion and duration; declared reference values (maximal aerobic speed, maximum and resting heart rate); attendance and minutes played; absences for national-team duty, suspension or personal reasons (dates and reason, no details); consents given and withdrawn; credentials of the athlete’s phone link (code and PIN); staff notes on calendar days; staff and athlete accounts; access log |
|---|
| Special categories (Art. 9) | Health data: daily wellness questionnaire, including the body areas the athlete marks under the muscle soreness item (optional, one word per area: sore or pain); the athlete’s free-text notes on the questionnaire and on the session, which may contain health information, with a record of who read them and when; periods of unavailability due to injury or illness (dates, body region, side, activity in which the injury occurred, phases of return with their date, who recorded them and an optional one-line guidance note for the coaching staff, containing no diagnosis; planned return; days lost); the clinical detail of each period (diagnosis, tissue or organ system and cause, mode of onset, mechanism and contact, playing action, optional diagnostic code, clinical notes, recurrence), stored separately and available only at the highest level; what the staff saw and decided about an athlete’s reading flags (who saw which flags and when; optionally the decision, chosen from a closed list that includes referral to the doctor or physiotherapist, a short staff note and a link to a questionnaire or note sent by the athlete or to one of their periods of unavailability), which counts as health data because the note may contain health information and the decision may be a referral to the medical staff; force plate tests; anthropometric measurements including body fat and the method used |
|---|
| Data about minors | Yes, in youth teams |
|---|
| Excluded data | Genetic data; biometric data for identification; criminal offence data; data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, sex life or sexual orientation |
|---|
| Automated processing | The software computes descriptive indices (rolling averages, ACWR, monotony, deviations from the personal norm) and produces reading flags. It performs no profiling with legal effects and no automated decisions under Art. 22: it produces no diagnosis, computes no injury risk and expresses no fitness judgement. What is decided about a flag is recorded by a member of staff, under their own name: the software does not suggest the choice |
|---|
Annex B — Technical and organisational measures
These are the Art. 32 measures. Where a measure is enforced in the DATABASE and not only in the interface we say so, because that is the difference between a permission that is only drawn on screen, and can therefore be bypassed, and one that cannot.
| Area | Measure |
|---|
| Encryption in transit | HTTPS/TLS required on every connection |
|---|
| Encryption at rest | Volume-level encryption at the hosting sub-processor |
|---|
| Separation between customers | Access rules enforced in the database, on every table, by organisation identifier: one customer cannot read another’s data even in the face of a software defect |
|---|
| Access to health data | Enforced in the database and not only in the interface, on two levels the club assigns by role and, as an exception, by person: the first reads periods, phases and dates without diagnosis; the second also the clinical detail, and only the second, with edit permission, writes periods, phases and clinical detail. The clinical detail sits in a separate table with its own rules, so a defect in the software cannot show it to someone at the first level. The administrator always has the second level; the athlete sees their own data. Absence dates, with their type (injury, illness, other reason) and the activity but without diagnosis, reach all the staff, read-only accounts included, because the workload calculations need them |
|---|
| What the staff saw and decided | Written only under one’s own name, by staff (not by read-only accounts) and in the teams they can access: the limit is enforced in the database. Each person corrects or deletes only what they wrote. It is read by the staff who open the reading flags, read-only accounts included; the athlete does not see it in the software (this limit is also enforced in the database), but receives it in the export of their own data. Every opening and every write is logged. It is kept and deleted together with the athlete’s health data |
|---|
| The “athlete” role | Limited in the database to that person’s own data |
|---|
| Authentication | Passwords of at least 10 characters, kept as hashes and rejected if known to be stolen or too weak; no password in clear text. The 4-digit PIN of the athlete’s link stays readable by the staff, who hand it over and regenerate it, and locks for 15 minutes after 5 errors. The first account is created by whoever signs up on the website and cannot write any data until payment is confirmed; a sign-up that is never paid deletes itself. The other accounts are created by the club’s administrator. With the software open, the session closes after one hour of inactivity; with it closed, after two hours |
|---|
| No self-promotion | A user cannot raise their own role to administrator: the ban is enforced in the database |
|---|
| Write log | Automatic recording of creations, changes and deletions on the tables of athletes, periods of unavailability with phases and clinical detail, anthropometrics, consents, decisions on reading flags, accounts and configuration (teams, seasons, metrics, matches, sessions); for measurements, file uploads and manual entries are recorded |
|---|
| Read log | Recording of the opening of the medical area’s health record and register at the second level and of their export, of the infirmary view with diagnoses, of the inbox and the log of the reports sent by athletes, of what the staff saw and decided about the reading flags, of the consent register, of the complete export of an athlete’s data and of the export of the whole organisation. Not every single read is recorded (workload data, statistics, Dashboard tiles, periods without diagnosis at the first level): it would be hundreds of rows per person per day, and nobody opens a log like that |
|---|
| Minimisation | Screens ask the database only for the data they show; the clinical detail is neither requested nor sent to anyone without the second level |
|---|
| Deletion and anonymisation | Permanently deleting an athlete removes measurements, attendance, periods of unavailability with their clinical detail and phases, anthropometrics, reference values, consents, phone submissions with their notes and body areas, decisions on reading flags, links with their PIN, additional teams and photo, and anonymises the audit entries concerning them: the proof that an operation happened remains, the name and the diagnosis disappear. The athlete’s own account, if any, is removed separately, from user management |
|---|
| Export | Complete export per athlete in a structured format, which states what it does not contain (the credentials of the phone link); export of all the organisation’s data, tables and files, reserved to the administrator. Both are logged |
|---|
| Backups | Of the DATABASE: daily and automatic at the infrastructure provider, retained 7 days, encrypted in transit (TLS) and at rest. They cover data, permissions and accounts. The service opens to customers only once these backups are running. They do NOT cover uploaded files — the club logo, athlete photos, opponents’ logos, background images — which live in separate storage, at addresses that cannot be guessed or listed, without automatic copies: if they were lost, they would have to be uploaded again from the software. The restore is tested and documented before the service opens, then at least once a year and after every substantial change to the database structure (for example new tables holding athlete data): a backup that has never been restored is not a backup |
|---|
| Continuity | Maximum data loss (RPO) 24 hours, that is, back to the last daily backup. Target recovery time (RTO) 2 working days from detection. The service carries no availability commitment: these are stated targets, not guarantees |
|---|
| Environment separation | Development and production kept apart; production data is not used in development |
|---|
Annex C — Authorised sub-processors
These are the suppliers that process data on our behalf. An undeclared sub-processor breaches Art. 28(2), and is also the easiest breach to prove: that is why the list is here rather than on request.
No other recipients. While in use the software calls no external services: fonts are served from the software’s own domain, and no user IP address is disclosed to third parties. The only exception is PAYMENT: the payment page and, inside the software, the card for reactivating the subscription load Paddle’s form; Paddle’s customer portal and invoices open, on request, in a separate tab. It concerns the purchase of the subscription, not the processing of athlete data, and no athlete data passes through it.
| Sub-processor | Service | Place of processing | Safeguards |
|---|
| Supabase Pte. Ltd. (Singapore) | Database, authentication, file storage | AWS infrastructure, region eu-west-1 (Ireland); technical staff may access from third countries | Supabase data processing agreement with the standard contractual clauses (Modules 2 and 3) |
|---|
| Vercel Inc. (United States) | Running the web application | Dublin (Ireland) region; the company also processes data in the United States | Vercel data processing agreement with the standard contractual clauses; certified under the EU-U.S. Data Privacy Framework |
|---|
| Resend — Plus Five Five, Inc. (United States) | Sending service e-mails to the club’s administrator: name, address and organisation name, no athlete data | United States | Resend data processing agreement with the standard contractual clauses (Module 2); certified under the EU-U.S. Data Privacy Framework |
|---|
| IONOS SE (Germany) | Support mailboxes: the messages the customer writes to us and our replies, with whatever they contain | European Union | IONOS data processing agreement under Art. 28 GDPR |
|---|