Data processing agreement

1. Purpose

1.1. This agreement governs the processing of personal data carried out by PT. LTVT CAPITAL GROUP (the “Publisher”) on behalf of the customer sports facility (the “Club”) in the course of supplying the FirstGym Tech software.

1.2. It supplements the terms of sale and prevails over them in all matters concerning the personal data of people registered with the Club.

1.3. It is entered into under article 51 of Indonesian Law No. 27 of 2022 (UU PDP) and, where it applies, article 28 of the GDPR.

Processor

PT. LTVT CAPITAL GROUP

Registered office

Jalan Pantai Batu Mejan Nomor 33A, RT. 000, Canggu, Kuta Utara, Kabupaten Badung, Bali, Indonesia

NPWP

10.979.476.8-906.000 — NPWP16: 0109 7947 6890 6000

Data protection contact

contact@firstgym.tech

Controller

The Club, as identified in the order form

2. Who decides, who executes

2.1. Should the Publisher itself determine the purpose or the essential means of a processing operation, it would be, for that operation, a controller and would assume the corresponding obligations.

2.2. Processing the Publisher carries out on its own behalf — prospecting, billing the Club, technical logs — falls outside this agreement. It is described in its privacy policy.

3. Which law applies

3.1. Always: Indonesian law. The Publisher is established in Indonesia and operates its servers there. Law No. 27 of 2022 on personal data protection (Undang-Undang Pelindungan Data Pribadi, UU PDP) applies to all the processing described here.

3.2. In addition, the GDPR, in two cases. Regulation (EU) 2016/679 applies where:

• the Club is established in the European Union, the processing taking place in the context of that establishment’s activities (art. 3(1) GDPR); or
• the Club is established outside the EU but offers its services to people located in the EU or monitors their behaviour (art. 3(2) GDPR).

3.3. Where both texts apply, the rule that is more protective of the data subject prevails. The Publisher does not rely on Indonesian law to offer a member located in the EU less than the GDPR provides.

3.4. It is for the Club to tell the Publisher, at subscription and on any change, whether it falls under the GDPR. A Club established in the EU remains bound by its own obligations: records of processing, informing data subjects, a data protection impact assessment where required, and appointing a data protection officer if the conditions are met.

3.5. The two texts use different vocabulary for the same realities: pengendali means controller, and prosesor means processor.

4. Duration of processing

4.1. Processing begins when the Club’s space is set up, including during the free trial, and continues for the term of the main contract.

4.2. It ends when the contract ends, subject to the return and deletion operations set out in article 14 and to the gradual disappearance of backup copies within the periods set out in article 9.3.

4.3. This agreement remains in effect for as long as the Publisher holds the Club’s data, including after the main contract has ended.

5. Nature and purpose of processing

5.1. The Publisher processes the data for the sole purpose of providing the Club with software to run its gym and of ensuring that it works, securely and continuously.

5.2. The operations carried out are:

• collection through the software’s interfaces and recording in a database;
• consultation, organisation, structuring and updating;
• display in the members’ app and in the administration console;
• management of registrations, memberships, bookings and access control;
• sending emails and notifications triggered by the Club or by the software;
• backup, restoration and temporary technical archiving;
• export at the Club’s request;
• hosting, technical monitoring and defect correction;
• erasure and destruction at the end of the contract.

5.3. The Publisher carries out no automated decision-making producing legal effects for members, and no profiling, on its own behalf.

5.4. The Publisher does not use member data to train or improve any artificial intelligence model.

6. Data subjects and data processed

6.1. Categories of data subjects

• The Club’s members — registered people, including prospects and former members for as long as their record is kept;
• Coaches and instructors — employees or contractors whose slots, classes and availability are managed in the software;
• The Club’s staff — front desk, management and anyone holding access to the administration console.

6.2. Categories of data

6.3. Sensitive data

The software is not designed to hold health data or other sensitive data within the meaning of article 4 of the UU PDP or article 9 of the GDPR. The Club must not enter such data in free-text fields — medical certificates, contraindications, conditions, biometric identifiers. If it needs to, it must inform the Publisher beforehand: such processing would require additional safeguards and an amendment to this agreement.

6.4. Minors

Where the Club registers minors, it is for the Club to obtain the authorisation of the holder of parental responsibility, in accordance with article 25 of the UU PDP and article 8 of the GDPR.

7. Documented instructions

7.1. The Publisher processes the data only on the Club’s documented instructions. The following constitute such instructions: this agreement, the terms of sale, the order form, the configuration the Club applies in the administration console, and written requests sent to contact@firstgym.tech.

7.2. Ordinary use of the software by the Club amounts to an instruction: creating a member, sending a notification, exporting a file, deleting a record.

7.3. The Publisher informs the Club promptly if it considers that an instruction breaches applicable law. It may suspend that instruction until it is confirmed or amended in writing.

7.4. The Publisher may process the data outside the Club’s instructions where a legal obligation requires it. It then informs the Club before processing, unless the law prohibits it on important grounds of public interest.

7.5. An instruction exceeding the software’s technical capabilities or requiring bespoke development is the subject of a separate agreement.

8. Confidentiality of personnel

8.1. The Publisher ensures that persons authorised to process the data — employees, directors, contractors working on the infrastructure — are bound by an obligation of confidentiality, whether contractual or statutory, which survives the end of their engagement.

8.2. Access to a Club’s data is limited to those who need it for operations, support or security, and to the extent of that need.

8.3. Those persons are informed of the nature of the data processed and of the applicable rules.

8.4. The Publisher is a small organisation: the number of people with technical access to the servers is very limited. The Club may ask for the current position at any time.

9. Security measures

9.1. Encryption in transit

• All traffic between browsers, mobile apps and the servers goes over HTTPS. Only TLS 1.2 and TLS 1.3 are accepted; earlier versions are refused.
• Certificates are issued by Let’s Encrypt and renewed automatically, with daily monitoring of expiry dates.
• HTTP requests are redirected to HTTPS.

9.2. Separation between clubs

• Each Club has a dedicated database, separate from every other club’s. There is no shared table in which several clubs’ data would sit together.
• Each database is reached through a database user specific to that Club, whose rights are limited to reading and writing that database alone. One club’s credentials technically cannot reach another club’s database.
• Each Club has its own application containers and its own subdomain, with its own secrets.

9.3. Backups

• Daily backup of the database, kept 14 days on the server.
• Off-site copy every night, AES-256 encrypted before sending and kept 30 days. The decryption passphrase is stored outside the code repository, readable only by the machine’s administrator account: the remote storage provider cannot open those archives.
• Decryption of the uploaded archive is verified on every run: an unreadable backup raises an alert rather than passing unnoticed.
• The restore has been exercised — not merely described. On 7 August 2026, that day’s archive was re-downloaded from off-site storage, decrypted, restored into throwaway databases (no production database was touched), then compared collection by collection against live production: 61 collections and 744 documents, all matching. The tool that replays this verification is versioned with the product and can be re-run at any time; it deliberately fails if the archive does not cover production, rather than declaring itself satisfied with a truncated backup.

9.4. Access control

• Member passwords are stored as salted bcrypt hashes, never in cleartext.
• Access to a space’s administration console is protected by a password specific to that space, distinct from every other club’s, delivered to the Club through a single-use, time-limited activation link.
• Known limitation, stated plainly: that administration password is shared among a Club’s administrators — there is currently no named account per administrator, no two-factor authentication and no throttling of attempts on that route. As a result, traceability of administrative actions down to the individual is not assured.
• The administration password is hashed with bcrypt as well, on the same footing as member passwords. It has been since 7 August 2026: before that date it was stored in cleartext, and this paragraph said so. A space created before then has its password re-hashed automatically on the first successful sign-in, with no interruption. The Club is nonetheless advised to reuse no password used elsewhere, to restrict its circulation, and to request a change whenever an authorised person leaves — for the reason set out above: this access is not individual.

9.5. Protection of secrets

• A Club’s secrets — database credentials, integration keys — are stored in a file specific to its space, outside the code repository, with permissions restricted to the machine’s administrator account alone.
• The code repository is configured to refuse secret files, private keys and certificates.
• No credential is passed on a command line during provisioning.

9.6. Operations

• Components run in isolated containers, updated along with the software.
• The database is not exposed to the public internet.
• Off-site backup every night, paired with an absence detector that checks each morning that a recent archive really does exist on the remote storage. A failed backup, like a missing archive, triggers an alert email to the Publisher: a backup that stops does not stop silently. It is that second check which separates a backup from an intention to back up.
• Daily watch on certificate expiry, which also verifies that the certificate actually presented by the server is the one on disk, and reloads the web server if the two diverge. A crossed threshold is recorded and escalated to operations; that particular check does not go out by email.
• Deleting a customer space is a human operation: no automated process destroys a Club’s data.

Automatic monitoring runs every five minutes as of 7 August 2026. It checks that every space responds (both the page and its programming interface — a space can serve its page while its engine is down), that containers are running and not restarting in a loop, that the database answers, and that disk space and memory remain sufficient. An anomaly triggers an email to the Publisher; recovery triggers a second one. A lasting outage does not produce repeated messages: one alert on detection, one reminder per day, one message on recovery.

9.7. Evolution

Measures evolve with the state of the art. The Publisher may change them provided the level of protection is not reduced. The Club may at any time request an up-to-date statement of the measures actually in place.

10. Sub-processors

10.1. The Club authorises the Publisher to use the sub-processors listed below. This list is exhaustive as at the date shown at the top of this page: no other third party takes part in the processing of a Club’s data. It has been cross-checked, row by row, against the configuration actually in service — hosting, backup storage, email delivery, DNS zone, and the resources the application loads on the member’s device.

10.2. The Publisher remains fully liable to the Clubfor those third parties’ performance of their obligations: a failure by any of them is attributable to the Publisher as if it were its own. That commitment depends on no formality and applies as of today.

10.3. Before adding or replacing a sub-processor, the Publisher informs the Club by email at least 30 days in advance, stating its role, its location and the data concerned.

10.4. The Club may object to the change, in writing and on reasonable data protection grounds, within 30 days of being informed. The parties then seek a solution. Failing that, the Club may terminate the main contract at no cost, with a refund of the prepaid, unused portion of the subscription.

10.5. In an emergency affecting security or service continuity, the Publisher may immediately use a replacement sub-processor; it informs the Club as soon as possible and the right of objection is exercised after the fact.

10.6. What is not in the table, and why. In the configuration delivered to a Club, no analytics tool, no advertising pixel and no artificial intelligence service receives any member data — verified in the application actually served, not merely intended. The product contains the code for some of those integrations, but it stays inert as long as no key is configured.

10.7. If the Club itself enables an integration from its administration console — payments, analytics, social networks, a third-party management system — it does so as a controller: that provider becomes its sub-processor, not the Publisher’s. It is for the Club to govern it, record it in its own register and inform its members. The Publisher supplies the technical means of connection; it does not choose the provider and does not answer for it.

11. International transfers

11.1. The data is primarily hosted on the Publisher’s server. Some sub-processors listed in article 10 are established outside Indonesia and outside the European Union, mainly in the United States.

11.2. These transfers are limited to what each provider genuinely needs to process: archives entrusted to off-site storage are encrypted before they leave the server, and the DNS operator receives no personal data.

11.2 bis. One exception must be flagged, because it escapes the reasoning above: since the typefaces are loaded from Google, the member’s IP address travels straight from their browser to Google, without passing through the Publisher’s server — and therefore beyond the reach of any measure taken on that server. This is the point flagged in article 10; it is resolved by serving the typefaces from the Publisher’s own server.

11.3. Under the UU PDP (articles 56 and 57), the Publisher ensures that the destination country provides an adequate level of protection or, failing that, that appropriate contractual safeguards are in place, or else obtains the data subject’s consent.

11.4. Where the GDPR applies, transfers outside the European Economic Area must be covered by one of the mechanisms in Chapter V, in particular the European Commission’s standard contractual clauses.

11.5. The Publisher provides the Club, on request, with documentation on the safeguards applicable to each transfer.

12. Personal data breach

12.1. A breach is any security incident leading to the accidental or unlawful destruction, loss, alteration or unauthorised disclosure of data, or unauthorised access to it.

12.2. Deadline. The Publisher notifies the Club of any breach affecting its data without undue delay and at the latest within 24 hours of becoming aware of it.

Why 24 hours and not 72. It is the Club, as controller, that must notify the supervisory authority: the UU PDP allows it 3 x 24 hours, and that clock starts when it becomes aware of the breach. A 72-hour cap on the processor’s side would therefore consume the whole of the Club’s deadline before it learned anything at all: it would be mechanically out of time on the day it needed that time. The processor’s cap must be strictly shorter than the controller’s — that is arithmetic before it is drafting. Twenty-four hours leave the Club at least two full days to qualify the breach, decide and notify. The same reasoning applies against the 72 hours of GDPR article 33 where the GDPR applies.

12.3. Content of the notification. It states, as far as possible:

• the nature of the breach and when it occurred;
• the categories and approximate number of data records and people concerned;
• the likely consequences;
• the measures taken to address it and to limit its effects;
• a contact point for obtaining further information.

If all of that information is not immediately available, the Publisher notifies what it knows within the deadline and completes it progressively: an unfinished investigation does not justify delaying notification.

12.4. The Publisher documents every breach and makes that documentation available to the Club.

12.5. It is for the Club, as controller, to notify the competent supervisory authority and, where required, to inform the data subjects. The Publisher does not make those notifications in its place, unless asked in writing, but provides the assistance and material needed.

12.6. Notifications are sent to the Club’s contact email address recorded in the customer space. The Club keeps it up to date.

13. Assistance to the controller

13.1. Data subject rights

Members exercise their rights — access, rectification, erasure, objection, restriction, portability, withdrawal of consent — with the Club.

The administration console lets the Club view and correct a member’s record. It does not currently offer an export of all of a member’s data, nor deletion of an account by the Club: a member can delete their own account from the app (/delete-account), but the Club cannot do it on their behalf. For any request the console cannot satisfy, the Publisher carries it out on the Club’s instruction, within a reasonable time and, absent particular complexity, within 10 business days. This gap is known and documented rather than glossed over: the Club must know what its tool does and does not do before it commits to a deadline towards a member.

13.2. If a data subject contacts the Publisher directly, the Publisher does not answer in the Club’s place: it forwards the request to the Club promptly and tells the individual it has done so. It discloses, rectifies or erases no data without the Club’s instruction, unless legally required.

13.3. Other obligations. Taking into account the nature of the processing and the information available to it, the Publisher assists the Club with:

• the security of processing and the notification of breaches (articles 9 and 12);
• carrying out a data protection impact assessment, where the Club is required to do one, and prior consultation of the supervisory authority;
• demonstrating compliance with its obligations, in particular by providing what it needs to maintain its records of processing;
• responding to a supervisory authority’s enquiries about the processing.

13.4. This assistance is included in the subscription, except for requests of manifestly disproportionate scale or repeated requests, which may be subject to a prior accepted quotation.

13.5. If the Publisher receives a request from a public authority to disclose the Club’s data, it informs the Club promptly and discloses nothing beyond what is legally required, unless legally prohibited from informing it.

14. Data at the end of the contract

14.1. Return. At the end of the contract the Club has 30 days to obtain a complete copy of its data, in a structured, commonly used format. It may also export it itself, at any time during the contract, from its administration console.

14.2. Deletion. After that period, or immediately if the Club so requests in writing, the Publisher deletes the data: the dedicated database, the associated files and the Club’s space are destroyed.

14.3. Backups. Copies held in backups are not erased one by one — an encrypted backup cannot be selectively modified. They disappear through rotation within the periods set out in article 9.3, that is 14 days for local backups and 30 days for off-site copies. Until then they remain protected by the same measures and are used for no purpose other than restoration after an incident.

14.4. Statutory retention. The Publisher may retain certain data where the law requires it — in particular accounting and invoicing records. Such retention is limited to what is required, for the period imposed, and that data is no longer processed for any other purpose.

14.5. Certificate. The Publisher provides the Club, on written request, with a certificate of deletion.

14.6. The return obligation applies including where the contract is terminated for non-payment: the Publisher never holds the Club’s data as security for payment.

15. Audit

15.1. The Publisher makes available to the Club all information necessary to demonstrate compliance with its obligations, on written request.

15.2. The Club may have the processing audited, itself or through an independent auditor it appoints and which is not a competitor of the Publisher. It gives the Publisher reasonable notice of at least 30 days, save in the event of an established data breach, where that notice is shortened.

15.3. The audit takes place during business hours, without disproportionate disruption to operations, and in conditions preserving the confidentiality of other clubs’ data: the auditor accesses no other Club’s data under any circumstances. The auditor is bound by an obligation of confidentiality.

15.4. The costs of the audit are borne by the Club, unless the audit reveals a significant failing by the Publisher, in which case the Publisher bears them and remedies the failing at its own expense, within an agreed period.

15.5. The Publisher may respond to an audit request by supplying detailed documentation or a recent third-party audit report, provided those cover the scope requested.

15.6. Competent supervisory authorities have a direct right of access, which this article does not restrict.

16. Liability

16.1. Each party is liable for damage caused by processing that breaches its own obligations.

16.2. The Club indemnifies the Publisher against the consequences of unlawful collection, failure to inform data subjects, absence of a legal basis, or instructions contrary to applicable law.

16.3. The Publisher is liable for breaches of its obligations as processor, in particular processing carried out outside instructions or a failure to implement the measures in article 9.

16.4. The limitations of liability in the main contract do not restrict the rights data subjects hold under applicable law, nor the enforcement powers of supervisory authorities.

17. Miscellaneous

17.1. Where this agreement and the terms of sale conflict, this agreement prevails on personal data protection matters.

17.2. The Publisher may amend this agreement to reflect a change in the law or in its technical measures. Any substantial change is notified to the Club at least 30 days before it takes effect. No change may lower the level of protection afforded to data subjects.

17.3. If any provision is held invalid, the others remain in force.

17.4. This agreement is governed by Indonesian law, without prejudice to the mandatory provisions of the GDPR where it applies and to the jurisdiction of the supervisory authorities concerned. The competent court is the one designated in article 21 of the terms of sale.

17.5. Governing language. This agreement is drawn up in English, like the terms of sale. Any ambiguity bearing on the safeguards owed to data subjects is construed in the sense most protective of them.

17.6. For any question about this agreement: contact@firstgym.tech.