Data processing agreement

The Article 28 GDPR agreement between each gym and miaforo about its members’ data.

Last updated: 3 October 2026

Clauses

1. Subject matter and scope

1.1. This agreement governs the processing of personal data that the Processor carries out on behalf of the Controller when providing the miaforo service (the Service), and it is the contract required by Article 28(3) GDPR. The parties are identified in Annex I.

1.2. The subject matter, duration, nature and purpose of the processing, the type of personal data and the categories of data subjects are described in Annex II. The technical and organisational measures are in Annex III and the authorised sub-processors in Annex IV. The annexes form part of the agreement.

1.3. This agreement does not cover the data that the Processor processes as controller about the Controller itself as a customer, such as the account, the invoicing and the collection of the subscription to the Service. That data is governed by the terms of the Service and the Processor's privacy policy.

2. Definitions and applicable law

2.1. Terms defined in the GDPR have the same meaning in this agreement.

2.2. Data protection law means the GDPR and the national data protection law that applies to the Controller (in Spain, Organic Law 3/2018, LOPDGDD). Nothing in this agreement shall be interpreted in a way that contradicts the rights and obligations that law establishes.

3. The Controller's instructions

3.1. The Processor processes the personal data only on documented instructions from the Controller, including with regard to international transfers, unless it is required to process them by Union or Member State law. In that case it shall inform the Controller of that legal requirement before processing, unless that law prohibits it on important grounds of public interest.

3.2. The Controller's documented instructions are: this agreement, the terms of the Service and the use that the Controller and its staff make of the functions and settings of the Service, including switching on optional functions.

3.3. Any other instruction is given in writing to chema@miaforo.com or to the Processor's contact address in Annex I. If an instruction requires work that the functions of the Service do not offer, the Processor may charge its reasonable cost, communicated to the Controller in advance, or refuse it if it is not technically feasible, explaining why.

3.4. The Processor shall immediately inform the Controller if, in its opinion, an instruction infringes data protection law, and may suspend carrying it out until the Controller confirms or changes it.

3.5. The Processor does not process the data for its own purposes, does not disclose it and does not sell it. If it determined the purposes and means of a processing operation, it would be considered the controller of that processing under Article 28(10) GDPR.

4. Obligations of the Controller

4.1. The Controller warrants that it has a legal basis for the processing and for entrusting it to the Processor, and that it informs data subjects in accordance with Articles 13 and 14 GDPR, including anyone who asks for a trial class from its public page.

4.2. The Controller does not enter into the Service special categories of data under Article 9 GDPR, data relating to criminal convictions and offences, or bank or card details, including in free text fields. Annex II describes the fields where that risk is highest.

4.3. The Controller is responsible for the content that it and its staff enter or publish through the Service, including the messages it writes to its members and the photographs it publishes on its public page, and for obtaining the consents that content requires.

4.4. The Controller supervises its staff's use of the Service and keeps the access credentials of its account safe.

5. Confidentiality

5.1. The Processor ensures that the persons authorised to process the personal data have committed themselves to confidentiality or are under a statutory obligation of confidentiality, including after their relationship with the Processor ends.

5.2. The Processor limits access to the data to the persons who need it to provide, maintain and support the Service.

6. Security of processing

6.1. The Processor applies the technical and organisational measures in Annex III to ensure a level of security appropriate to the risk, in accordance with Article 32 GDPR. Each Controller's data is kept separate from that of the Service's other customers.

6.2. The Processor reviews those measures periodically and whenever there are significant changes to the Service. It may replace or update them provided that the overall level of security does not decrease.

7. Communications to data subjects

7.1. On behalf of the Controller, the Processor sends by email only the notices needed to provide the Service that Annex II lists.

7.2. The Processor does not send any commercial communication to data subjects on its own account and does not use their addresses for any purpose of its own.

8. Sub-processors

8.1. The Controller gives general written authorisation for the Processor to engage sub-processors. Those authorised on the date of this agreement are listed in Annex IV.

8.2. The Processor shall notify the Controller by email, at least 30 days in advance, of any addition or replacement of a sub-processor. Within that period the Controller may object on reasonable grounds relating to data protection. The parties shall seek a solution in good faith. If they find none, the Controller's only remedy is to terminate the contract for the affected Service before the change takes effect, without penalty and with a refund of any amounts paid in advance for the unused period.

8.3. The Processor imposes on each sub-processor, by contract, the same data protection obligations that this agreement imposes on it, in particular sufficient guarantees to implement appropriate technical and organisational measures. At the Controller's request, it shall provide a copy of the data protection clauses of that contract, and may leave out confidential commercial information.

8.4. The Processor remains fully liable to the Controller for the performance of each sub-processor's obligations, in accordance with Article 28(4) GDPR.

9. Providers the Controller engages directly

9.1. When the Controller switches on online collection of its members' fees, the payment is made through direct charges on the account that the Controller itself opens with Stripe, under the contract that the Controller concludes directly with Stripe. In that role Stripe is not a sub-processor of the Processor: it is a provider of the Controller, and the data it receives it receives on the Controller's instruction.

9.2. In that role the Processor, on the Controller's instruction, only creates through the Stripe API the payment session and the account onboarding link, and receives the signed notices Stripe sends about those payments. Annex II describes which data is sent to Stripe and which comes back.

9.3. The relationship between the Controller and Stripe, including where Stripe processes the data and with which safeguards, is governed by the Controller's own agreement with Stripe. The Processor is not liable for the processing Stripe carries out under that agreement.

9.4. The function is delivered switched off and sends nothing to Stripe until the Controller switches it on and completes the onboarding Stripe requires.

10. International transfers

10.1. Personal data is processed within the European Economic Area (EEA), except where Annex IV expressly states otherwise.

10.2. The Processor only transfers personal data outside the EEA on the Controller's documented instructions and with one of the safeguards of Chapter V GDPR. A new transfer through a sub-processor is notified and may be objected to under clause 8.

10.3. The data the Controller orders to be sent to its own providers, under clause 9, is governed by the relationship between the Controller and those providers.

11. Assistance to the Controller

11.1. Taking into account the nature of the processing, the Processor assists the Controller, through appropriate technical and organisational measures, so that it can respond to requests to exercise data subjects' rights. That assistance is given mainly through the self-service functions of the Service (access, rectification, export and erasure of data), at no extra cost.

11.2. If a data subject contacts the Processor directly, the Processor shall not respond on its own account, unless the Controller instructs it to, and shall pass the request to the Controller without undue delay.

11.3. The Processor assists the Controller in complying with Articles 32 to 36 GDPR, taking into account the information available to it, in particular by providing the information in this agreement and its annexes for impact assessments and prior consultations.

11.4. Assistance beyond the functions of the Service and the information in this agreement may be invoiced at its reasonable cost, communicated in advance, unless the request arises from a breach by the Processor.

12. Personal data breaches

12.1. The Processor shall notify the Controller of any personal data breach affecting data processed under this agreement without undue delay after becoming aware of it and, where possible, within 48 hours, in writing to the Controller's contact address in Annex I.

12.2. The notification shall include the information in Article 33(3) GDPR that the Processor has. Information not available at that time shall be provided in phases, as the Processor obtains it.

12.3. The Processor shall take reasonable measures to contain the breach and mitigate its possible effects, and shall assist the Controller in notifying the competent supervisory authority and, where appropriate, in communicating the breach to data subjects, which are the Controller's responsibility.

12.4. Notifying a breach does not mean that the Processor admits fault or liability.

13. Information and audits

13.1. The Processor makes available to the Controller the information necessary to demonstrate compliance with the obligations in Article 28 GDPR and this agreement, and keeps the record of processing activities required by Article 30(2) GDPR.

13.2. The Controller shall first exercise its audit right through the Processor's documentation and its answers to a reasonable questionnaire. If that information is not enough to demonstrate compliance, the Controller may carry out, itself or through an independent auditor, an audit or inspection, on the following conditions:

at most once a year, unless a supervisory authority requires it or it follows a personal data breach affecting the data processed under this agreement;
with at least 30 days' written notice and a scope agreed in advance;
during business hours and without unjustifiably disrupting the Processor's activity;
under a confidentiality undertaking from the Controller and the auditor, who may not be a competitor of the Processor;
without access to other customers' data or to information that could compromise the security of the Service.

13.3. The costs of the audit, including the reasonable time the Processor spends on it, are borne by the Controller. If the audit reveals a material breach of this agreement by the Processor, each party bears its own costs and the Processor remedies the breach at no cost to the Controller.

14. Duration, return and deletion

14.1. This agreement enters into force on the date it is signed or accepted and lasts as long as the Processor provides the Service to the Controller. The confidentiality obligations and those in this clause survive its termination.

14.2. Return. While the Service lasts and for the 30 days after it ends, the Controller can download its data itself from the Service's panel, in a structured and machine-readable format, as described in Annex II. The account stays open until that period ends: the Processor does not close it earlier and, if it were suspended, makes the download available at the Controller's written request.

14.3. Deletion. Once that period has passed, the Processor closes the account and the data stops being accessible through the Service. 30 days after the closure (31 at worst), an automatic process deletes the personal data, without manual intervention: it deletes every row of the account that relates to a person, member or staff, whether still active or not, as Annex II details. Those 30 days make it possible to reverse a closure made by mistake. The Controller accepts this period as its choice of deletion. Before termination, the Controller can erase each member itself with the Service's erasure function. If it asks in writing for deletion before the return period ends, the Processor closes the account without waiting for the period to end, deletion follows 30 days after the closure, and the Processor shall confirm in writing that it has been carried out.

14.4. Backups are not modified: they delete themselves within the period in Annex II. The rows that Annex II keeps after a member's anonymisation remain subject to this agreement until they are deleted with the account. Data that the Processor must keep under Union or Member State law is excepted from deletion, and remains protected by this agreement for as long as the Processor keeps it.

15. Liability

15.1. Each party is liable for the damage it causes by breaching this agreement or data protection law.

15.2. Towards data subjects, Article 82 GDPR applies, and this agreement does not limit it. The party that has compensated a data subject may claim back from the other party the part of the liability that corresponds to it, in accordance with Article 82(5) GDPR and within the limit in the following paragraph.

15.3. Between the parties, the total liability of each arising from this agreement shall not exceed the amount paid by the Controller to the Processor for the Service during the 12 months before the event giving rise to it, or 500 euros if that amount is higher.

15.4. The following are excluded from the limit above: damage caused intentionally or by gross negligence, and administrative fines imposed on a party for its own infringement, which that party bears in any case.

16. Order of precedence and changes

16.1. On data protection matters, this agreement prevails over the terms of the Service and over any other agreement between the parties.

16.2. The Processor may update Annexes II and III to reflect changes in the Service, notifying the Controller by email. No update may reduce the overall level of protection or extend the processing to purposes other than providing the Service. Changes to Annex IV follow clause 8.

16.3. A change that is not material under clause 16.4 takes effect on notification. Non-material changes include, among others, corrections of wording, clarifications, measures that keep or raise the level of protection, and new optional functions whose processing is described in the Annex II notified before the Controller can switch them on, because they process no data until the Controller switches them on under clause 3.2.

16.4. Apart from those optional functions, a change is material if it adds a category of personal data or of data subjects, a new purpose or a longer retention period. The Processor shall notify it at least 30 days before it takes effect, and the Controller may object within that period with the procedure and remedy of clause 8.2.

16.5. Any other change requires the agreement of both parties, in writing or by electronic means.

16.6. This agreement is written in English and translated into Spanish and German. If the versions differ, the English version prevails.

17. Electronic conclusion

This agreement may be signed or accepted by electronic means, in accordance with Article 28(9) GDPR. Electronic acceptance by a person with authority to bind the Controller has the same effect as a signature.

A Controller that opens its own account in the Service accepts this agreement when opening it, together with the terms of the Service, by ticking the box that names them. The Service records the date, the person who accepts and the version accepted.

18. Governing law and jurisdiction

This agreement is governed by the law of the Member State where the Processor is established, stated in Annex I, and the parties submit to the courts of that State. All of this is without prejudice to the GDPR, the data protection law that applies to the Controller, the powers of the supervisory authorities, the right of data subjects to go to the courts the GDPR gives them, and any mandatory rules that apply.

Annex I. Parties

Controller

The gym that signs this agreement or accepts it when opening its account in the Service (clause 17). If it accepts when opening its account, its details are those of that account, the person accepting is whoever opens it on its behalf, and the date of acceptance is the one the Service records.

Processor

Contact email: chema@miaforo.com

Annex II. Description of the processing

Categories of data subjects

The Controller's members, its staff (management and coaches), and anyone who asks for a trial class from the Controller's public page without being a member, when the Controller has those requests switched on. That last person is the only one about whom the Service keeps data without them having an account.

Categories of personal data

Category	Specific data
Identification	Name, the name they are called by in class if the Controller records one, email, phone if the member provides it, date of birth if the Controller records it. The date is optional; management writes it, the member sees it on their profile and cannot change it, and the age is calculated from it and not stored
Staff note	One sentence of free text that management or a coach writes about a member, to know which exercise to give them. It is kept with the identifier of whoever wrote it and the date, and the member reads it in full on their profile with both. Management and the coaches read it, and nobody else
Authentication	Cryptographic hash of the password and verification tokens, among them that of a pending email change, which keeps the new address until it is confirmed or expires. If the member turns on two-step verification, the key of their code app and their ten recovery codes, both encrypted. They are deleted when the member turns verification off, when the Controller removes it because the member has lost it, and on erasure
Connection	Sign-in date, IP address, browser and operating system
Language	Language in which the member chooses to read the app and the emails. It is a preference that identifies nobody, and erasure does not delete it. If they choose none, nothing is stored
Cuota	Places per month, start date, end date, status (active or paused)
Payments	Amount, payment method (cash, transfer, card, Bizum or other), month it covers, payment date and a free note from whoever records it. Recording «card» by hand stores no data about that card. If the payment arrived through online collection, the payment attempt is kept with it: the identifiers Stripe gave the session and the charge, the amount, the currency, the month and how it ended. No data of the card or the Bizum it was paid with
Bookings	Class booked, date and time of the booking, attendance, cancellation with its reason and notice in minutes, cancellation note
Place balance	Ledger of every place spent and returned, per month
Personal records	Exercise, value and unit, repetitions if the member counts them, the class in which they did it if they record it from there, date and a free note. The member writes them, and only if they want to. Management and the coaches read them
Profile photo	Optional image the member uploads. The browser reduces it before sending it, so the server does not keep the original. No screen shows it to anyone other than the member; the Controller receives it in the download of its data
Photo of a coach on the public page	Optional image of whoever teaches, uploaded by management, in JPG, PNG or WebP and up to 5 MB sent. The browser reduces it and only that version is kept. It is the only data in this annex that is published from a person's record: it appears on the Controller's public page, which is read without an account and indexed by search engines. The Controller obtains the consent of the person pictured and is responsible for it. It stops being served on the day the person leaves and the file is deleted on erasure
Photos of the gym	Up to two optional images the Controller chooses for its public page. They may include identifiable people, with the same consent obligations as the previous row. They are deleted when the account is closed; a copy that a failed deletion leaves behind is deleted with the Controller's files 30 days after the closure (31 at worst)
Role	Profile within the gym: member, coach or management
Notices sent	Which of the thirteen notices in this annex it was, to which member, when it was queued and when it went out, and the mail server's error if any attempt failed. While it waits in the queue it keeps what its text needs, such as the day and time of the class or the link token; that is deleted as soon as the notice goes out or is discarded, except in the one that runs out of attempts. It includes whether the member has turned off the reminder or the email copies of the notices already kept in the app
The gym's messages	The subject and text the Controller wrote, who on its team wrote it, which members it reached and when, so the member can read it again on their profile. Also the notices the Service leaves only in the app of the Controller's management when a member's card payment is disputed or a month is paid twice: the amount and the month, without the member's name
Trial class request	Name, email, phone if they leave it and the class they asked about. It records whether the Controller accepted or declined it, who decided and when and, if accepted, the account that was created
Application faults	When a screen breaks, on the server or in the browser: which screen it was, what it was doing, the method and path of the request, the gym, the profile of whoever asked for it, the error message and the first lines of its trace. Emails, identifiers and long sequences of digits in the message are struck out before it is saved. Never who that person was, what they had typed, the body of the request, its headers, their IP address or their browser. A browser fault is only recorded if a session is signed in, with a cap per hour
Action log	What the Controller's team does to another person's situation, and what the Processor does to the gym: add, remove, readmit or erase a member; issue again the invitation with which they enter their account; cancel it without issuing another; show in the panel the one they already had, so it can be read to them in person, without the link entering the line; the Controller setting the password instead of the member choosing it; changing the role they have in the gym, between member, coach and owner; removing their two-step verification when they have lost it and cannot get in any other way; correcting their name, the name they are called by in class, their phone or their date of birth; writing or changing the staff note, without the text of the note entering the line; changing the email they sign in with, which is recorded when the member confirms it from the new address and not when the Controller asks for it; changing, pausing or resuming a cuota; adding a one-off class; cancelling a class; restoring a cancelled class; changing a class's time; changing a class's places; cancelling another person's booking; suspending or reactivating the gym; closing it when the agreement ends; changing the plan the Controller has with the Processor; and entering or leaving the gym from the platform. For each: the gym, the action, the identifier of whoever did it, that of the member it happened to when there is one, that of the row it refers to, and the date and time. In the five actions that change a number, a plan, a role or a time, that value before and after. Never a name, an email, a free text, the request, the invitation link, the confirmation link or the password

Data the Service does not process

Special categories. The Service is not designed to process health data or other special categories. The field where that risk is highest is the staff note: what goes in it is the adjustment to training («nothing overhead until October»), not the diagnosis, injury, operation or medication. The Service warns about it above the field, limits its length and shows the whole note to the member it is about. These measures limit the risk and do not remove it, because a free text field accepts anything. This agreement does not cover the processing of health data in the Service.

Bank and card details. The Service does not see or store a member's card number, IBAN or receipt stub. The payments the Controller receives on its own, outside the Service, are recorded by hand by its staff in the «Payments» category.

Online collection of fees with Stripe

The function is switched off until the Controller switches it on and completes the onboarding of its account with Stripe. Stripe's role and the Controller's relationship with it are governed by clause 9.

The Controller is the one who collects. The payment is opened on the account the Controller has with Stripe and the money goes straight there. It does not pass through any account of the Processor, which takes no commission on it and is not named as beneficiary. Refunds and chargebacks are handled by the Controller from its own Stripe dashboard.

What is sent to Stripe to open a payment: the amount, the currency, the name of the line the member reads («Cuota for September 2026»), the language of the page, the two addresses of the Controller's public page to which Stripe returns the member when they finish or back out, an opaque reference to recognise the payment, the member's email, with which Stripe's page appears already filled in and to which Stripe sends the receipt if the Controller has that on in its account, and a description of the charge with the member's name and the month they are paying, so the Controller recognises each charge in its Stripe dashboard. Neither the member's identifier nor the gym's is sent. The name and email stay in the Controller's Stripe account, under its own agreement with Stripe (clause 9.3): erasing or anonymising the member in the Service does not delete them there, and doing so, where appropriate, is for the Controller. What Stripe needs to collect (the card details, or the Bizum phone number and the confirmation of the payment) Stripe asks the member for on its own page and it does not pass through the Service.

What comes back from Stripe: a signed notice, with which the Service writes a «Payments» row (amount, payment method, month it covers, date and a short note) and keeps the identifiers Stripe gives that payment and its attempt, so the same payment is not recorded twice. Each refund and each chargeback writes a compensating negative row, and the original row is not modified. The notice of a refund or a chargeback also contains a summary of the payment method and the details the payer typed on Stripe's page. The Service reads from it only the identifier of the payment attempt, the amount refunded and the currency, after checking Stripe's signature; the rest is not kept. The log of notices received keeps the notice's identifier, its type and its dates, never its content.

The Controller's Stripe account. To create it, the Service sends Stripe the country the Controller states, the gym's identifier and an email address: the gym's contact address or, if there is none, that of the person on its team who starts the onboarding. That address is kept only while the account is being created, so the same request can be repeated if it fails. Of the account, the Service keeps its reference, Stripe's answers on whether the account can collect, whether onboarding is complete and whether Bizum is active, the dates of those answers and, if the Controller pauses the function, the date it did so. The onboarding happens entirely on Stripe's screens, and no document or bank account of the Controller reaches the Service.

What each profile reads

A coach reads the bookings, the attendance, the place balance with each movement, the date of birth, the staff note and the numbers of each member's records. They do not read the member's contact details (email, phone, address), identity documents or anything about money: the cuota, the payments, the payment method, the invoices or what they owe. Nor the email or phone of a trial class request. The Service does not ask the database for them when the reader is a coach. Management reads everything, and only management can download the gym's data.

Communications to data subjects

The thirteen notices the Service sends on behalf of the Controller. Twelve go out because somebody has done something; the reminder is the only one that goes out on a clock.

Notice	When it goes out
Class cancelled	The Controller cancels a class the member had booked
Class restored	The Controller restores a class it had cancelled and that the member had booked
Time changed	The Controller moves a class the member has booked to another time
Place free	A place is freed and it goes to the member from the waiting list
Reserve class opened	A class the Controller held in reserve behind another opens, because that one has filled up or because the Controller opens it. It goes to the members on the earlier class's waiting list, who stay on it, and to whoever teaches the class that opens
Booking made from the panel	The Controller books the member into a class from the panel
Booking cancelled from the panel	The Controller takes the member out of a class from the panel
Class reminder	The evening before a class the member has booked
Invitation	The Controller creates the member's account without setting a password, or gives them a new link because they cannot get in
Password	The member asks to reset theirs
Notice written by the Controller	The Controller writes to its members or to its own team, those who run the gym and its coaches, and chooses who
Email change confirmation	The Controller asks to change the address the member signs in with. It is the only one that goes to an address not yet on the record: the new one, so whoever reads it confirms it
Email change started	The Controller asks for that same change and the Service tells the address the member still signs in with. It says which address the account has been asked to move to, that nothing has changed yet, and that the member should tell the Controller if they did not expect the change

The reminder is the only one the member can turn off completely, from their profile; if the class has already started when it is due to go out, it is discarded. Another switch lets them stop receiving by email the notices already kept in the app: the cancellation, the time change, the free place, the reserve class opened, the booking cancelled from the panel and the notice the Controller writes when it sends it through both channels. The other emails always go out.

Each message carries the member's name and email; the day, time and title of the class it is about; whether the place was taken from the balance or returned to it, and whether that balance is weekly or monthly; whether there is still time to cancel the booking; and the links to the app that notice needs, including, in the invitation and the reset, the one carrying the token to choose a password. The sender shown is the gym's name over a miaforo address. Never the booking history, the cuota, the payments or the personal records.

The notice the Controller writes carries its subject and text as written, without review or translation, and the Controller is responsible for its content. It is for service notices: the Service asks for no consent and adds no unsubscribe link, so it is not fit for advertising.

Nature and purpose

Collection, recording, organisation, storage, consultation, alteration, disclosure by transmission in the cases in this annex, anonymisation and erasure, with the sole purpose of providing the Service to the Controller: account creation, class booking, control of capacity and cuotas, attendance records, payments, notices and, if the Controller switches them on, personal records and trial class requests; as well as the support, security and maintenance of the Service, including the fault log described in this annex.

Duration and retention periods

The processing lasts as long as the Service, with the following periods. An automatic process runs once a day, so each period may run one day longer at worst.

Active member: their data is kept while they remain active. The date of birth and the staff note have no period of their own: they disappear when the Controller removes them, with the member's erasure or with automatic anonymisation.
Member who has left: their record stops appearing in the app and their bookings in upcoming classes are released. It is anonymised 365 days after they leave (366 at worst).
Closed account: 30 days after the closure (31 at worst) every row of the account that relates to a person is deleted: records, bookings, attendance, place balance, payments, personal records, the action log, trial class requests, the Controller's messages and the notices. The Processor keeps no personal data of the Controller after that date, except backups until they expire (seven days, eight at worst). A record whose leaving period ends earlier is anonymised on its own date.
Trial class request: deleted entirely 90 days after it arrives (91 at worst), whether the Controller accepts it, declines it or does not answer it. Its legal basis, steps taken at the data subject's request before entering into a contract (Article 6(1)(b) GDPR), runs out once the class they asked about has passed.
Application fault: each distinct fault takes one row, which is deleted 30 days after the last time it occurred (31 at worst).
Action log: each line is deleted 365 days after the action (366 at worst), the same period as the member's record. There are 27 actions, listed in the «Action log» category of this annex.
Sessions: expire 30 days after their last use.
Backups of the database and the photos: kept seven days, eight at worst, and deleted automatically. That period counts from when the record is anonymised or deleted or the photo deleted, not from when the member leaves.

The rows kept after the anonymisation of a member who left while the account stays open (bookings, attendance, place balance, payments without their note and the action log until its period ends) are kept as the Controller's history until the account closes. Nothing is left in the Service that identifies the person, but those rows stay linked to a stable internal identifier and the Controller may have other information that makes it possible to link them to that person. That is why this agreement does not claim they stop being personal data and continues to apply to them for as long as the Processor keeps them.

Erasure of a member

When a member's right to erasure is exercised, or their automatic anonymisation arrives, the Service anonymises their record. It is not a deletion of rows:

The name is replaced with a generic label and the email with an address on the reserved .invalid domain, which can never resolve.
The name they were called by in class, the phone and the date of birth are removed.
The staff note is removed, and with it the identifier of whoever wrote it and the date.
The access credentials are removed and, if they had two-step verification on, the key of their code app and their recovery codes.
Every open session is removed, with the IP address and browser it kept.
The trial class request their account came from is deleted entirely, if there was one, with the name, email and phone they left, without waiting for its period. Any notices pending delivery are cancelled without being sent, and the invitation link they carried is deleted.
The free texts of the personal records, the cancellations and the payments are emptied.
All their photos are deleted from the server: the member's whole directory is removed, with the profile photo, those they had replaced before and, if they taught, the one published on the public page, which stops being served on the day they leave. Earlier backups contain them until they expire.
Bookings, attendance and the place balance are kept, without the data that identifies the member, as the Controller's occupancy history, including their position on the waiting list of a class that has already taken place.
What has not happened yet is not kept the same way: their upcoming bookings become cancelled, each place returns to its balance and to the calendar, and they are taken off the waiting lists of those classes.
Payments are kept without their note: the amount, the payment method, the month and the date are the Controller's accounting record, which it may be obliged to keep. The Stripe payment attempt kept with a payment is also kept; it contains no free text, and its identifiers point to the Controller's Stripe account, where the Controller can find the charge, with the name and email sent when it was opened (Annex II), which the Service cannot delete. This agreement does not claim that those identifiers stop being personal data.
The lines of the action log are kept unchanged, because they only hold identifiers and the name of an action, until their own period ends.

If the Controller needs a physical deletion of those rows, it must ask in writing and first consider whether any legal obligation prevents it. A trial class request is not anonymised: it is deleted entirely at the end of its period, or earlier with the erasure of the member who came from it.

Download of the Controller's data

The Controller's management downloads two files from the panel: one in JSON with the database rows, including those of members who have left or been anonymised, and a zip with the members' profile photos, in which each photo carries the name the corresponding JSON row states. A coach cannot download them.

Annex III. Technical and organisational measures

Encryption and credentials

Encryption in transit with TLS on all traffic, with a certificate that is renewed and applied automatically.
Passwords stored as a cryptographic hash, never in clear and never recoverable.
Two-step verification keys and recovery codes stored encrypted.
Secrets kept out of the code repository, injected as environment variables at deployment.

Access control

Separation by customer: every query to a table with member data is filtered by gym in the data access layer.
Access control by profile, checked on the server and not in the browser. A coach does not receive members' contact or financial data.
Sessions that expire 30 days after their last use.
The Processor's staff access the platform administration only with a second authentication factor. Entering a gym's account from the platform, and leaving it, is recorded in the action log the Controller can consult.

Infrastructure and availability

Database with no port published on the internet: only the application's own containers reach it.
Daily backups of the database and the photos, encrypted before they leave the server, kept for seven days in a separate location (Annex IV).
Reproducible deployment by container image, with the possibility of going back to the previous version.

Development and organisation

Code changes with prior review and automatic verification before publishing.
Log of application faults in the database itself, without sending it to third parties and with the personal data in the message struck out.
Review of these measures periodically and whenever there are significant changes to the Service (clause 6).

Annex IV. Authorised sub-processors

Sub-processor	Service	Location of the data	Contract and safeguards
IONOS SE	Server, database and the mailbox the notices in Annex II go out through	Berlin, Germany (EEA)
Hetzner Online GmbH	Encrypted backup of the database and the photos, in a Storage Box. It only receives bytes encrypted before they leave the server, which it cannot read	Falkenstein, Germany (EEA)	Processing agreement (Art. 28) accepted in the account, 2026-08-30

The Processor makes no transfer outside the EEA.

The Service uses no other sub-processors: no advertising services, no visit measurement or analytics services, no content delivery networks (the fonts are served from the Service's own domain), and no external error logging services.

Stripe is not in this annex. For online collection of members' fees it is a provider the Controller engages directly (clause 9), and for collecting the Controller's subscription to the Service it falls outside this agreement (clause 1.3).

Help