Data Processing Agreement

BailaYa — operated by Infinity Curve LLC · Version 2.0 · Effective 2026-09-05

If you run a studio on BailaYa, your students' personal data is yours. You decide what is collected and why; we hold it and act on your instructions. Every data protection law in this document draws that same line — they just use different words for the two sides of it. South Africa says responsible party and operator. Mexico says responsable and encargado. California says business and service provider. The GDPR says controller and processor. You are always the first one; we are always the second. Most of these laws also require the arrangement to be written down. This is that document.

1. Which laws this covers, and how to read it

BailaYa is used by studios across a lot of legal systems, and no one of those systems can stand in for the rest. So this document is built in two layers. Sections 2 to 13 are the substance and they apply to every studio whoever you are. Sections 14 to 21 are short annexes, one per legal regime, and each applies only if that regime applies to you.

• EU GDPR
• UK GDPR & DPA 2018
• Swiss FADP
• Georgian LPDP
• Turkish KVKK
• Mexican LFPDPPP
• South African POPIA
• California CCPA/CPRA

Three rules settle any conflict. An annex beats the body, for data governed by that annex's law. This agreement beats the Terms & Conditions, for anything to do with personal data. And the law beats both: nothing here narrows a right you or your students have, and where an applicable law demands more than we promise below, it is the law that we owe you.

More than one annex can apply at once — a studio in Zürich with students in London and Cape Town is in three regimes, and we apply the strictest requirement across all of them rather than making you sort out which record belongs where.

2. Who is who

The same two roles, in the vocabulary of each law:

Where this document says controller and processor, read the row that fits you. Nothing turns on the choice of word.

Two things are not covered by this agreement, and saying so is more useful than leaving it implied. Your own account data — your name, your billing details — is data we hold as controller, not as your processor; the Privacy Policy governs that. And where you connect your own payment gateway or meeting tool, that provider is yours, not ours: you contract with them directly and we simply act on your instruction to talk to them.

3. What we process, and why

Every regime in §1 wants this same description of the processing, under its own heading — it is Annex I of the Standard Contractual Clauses, and it is what the others ask for too. One table answers all of them. You do not need to fill anything in; if your regulator wants a completed annex on paper, ask us and we will produce one.

4. We act on your instructions

We process your students' data only to provide the service, and only as you direct — through the settings you choose and the actions you take in the app. Concretely, we commit that we do not and will not:

• sell it, or share it for cross-context behavioural advertising;
• use it for our own purposes, or for any commercial purpose outside our direct relationship with you;
• keep or disclose it outside that relationship, except where §5 requires;
• combine it with personal data we receive from anyone else, except where doing so is necessary to run the service for you;
• use it to train any model, ours or anyone else's;
• make automated decisions about your students that produce legal or similarly significant effects.

We understand these restrictions and we accept them as contractual obligations, not aspirations. (California requires a processor to say exactly that, in those words. It is true everywhere, so it lives here rather than in the Californian annex.)

The exception, stated plainly because every honest DPA has one: where a law we are subject to requires us to process or disclose something, we will comply. Where we are legally allowed to tell you first, we will.

If you tell us to do something unlawful, we will say so. If we think an instruction from you breaches a data protection law that applies to either of us, we will tell you and we may pause that instruction until it is resolved. And if we ever conclude we can no longer meet the obligations in this agreement, we will tell you promptly rather than quietly falling short — at which point you can instruct us to stop, and take the data elsewhere.

5. Confidentiality

Access to your students' data is limited to the people who need it to operate or support the service, and they are bound to keep it confidential by contract or by a duty imposed on them by law. That obligation survives the end of their engagement with us and the end of your subscription. In practice the group is a small number of people; production access is described in our security documentation.

6. Security

We keep appropriate technical and organisational measures. Concretely, and without claiming more than is true:

• All traffic is encrypted in transit with TLS.
• Passwords are stored only as bcrypt hashes — we cannot read them. Two-factor secrets and the OAuth client secrets we issue are encrypted at rest with AES-256-GCM.
• Production configuration and credentials are held encrypted and decrypted only at deploy time.
• Data is scoped per studio, so one studio cannot reach another's records.
• Access is role-based and enforced on the server for every request, not merely hidden in the interface.
• Backups are encrypted before they leave our servers and held off-site.
• Code is scanned for known-vulnerable dependencies and insecure patterns on every change.

Security is a moving target, so these measures change as the threats do. They will not get weaker during your subscription. Each regime in §1 asks for a description of security measures under its own article number — the safeguards POPIA s21(1) and s19 require, the measures under KVKK Art. 12, the "reasonable security procedures" California expects of a service provider, Annex II of the Standard Contractual Clauses, and so on. This list serves as all of them. It is one list because it is one system; a separate annex per jurisdiction would be the same seven bullets with different footnotes.

We keep an internal record of the processing we carry out for you, which we will make available to you or to a regulator on request.

7. Sub-processors

You give us general authorisation to use sub-processors. Every one of them is named on our published list, with what they do and where they are, and each is bound by written terms no less protective than these — including the transfer safeguards in §13, passed down the chain.

We tell you before a new one starts. You get at least 30 days' notice by email — automatically, to the address we bill, with no need to subscribe to anything — and that gap is your window to object. If you object, reply before the effective date and we will work through the options with you; if we cannot resolve it, you may terminate.

We stay responsible to you for what our sub-processors do with your students' data, to the same extent as if we had done it ourselves.

8. Sensitive and special category data

You can build forms that ask for health information — an injury history, an accessibility need. Nearly every law in §1 treats that as a higher-risk category, so the platform makes you declare it: a form marked as collecting sensitive data requires an explicit, separate consent tick from the student before it can be submitted, recorded with a timestamp.

That is our half. The lawful basis is yours — you are the controller, and it is your form. What that basis has to look like differs more than most studios expect:

The consent tick the platform enforces will satisfy some of these and not others. It is a floor, not a compliance product.

9. Children

Dance studios teach children, so this is not a hypothetical. Where a student is a minor, it is you who must obtain and record consent from a parent or guardian where the applicable law requires it — the age at which a child can consent for themselves runs from 13 to 18 depending on where you are, and in South Africa the requirement is a "competent person" rather than an age test at all. The platform gives you guardian fields and the consent record; the judgement about who may consent is yours.

We do not knowingly process a child's data for any purpose beyond running your studio, and we never sell or share it.

10. Deletion, return, and what your students can ask for

Deleting a student deletes the person. Attendance, form submissions — including any health answers and the signature image — messages we sent them, booking notes and loyalty history all go with the record, in one transaction, enforced by the database rather than by code that can drift. Payment rows survive with the identity link severed, which tax law requires and which the erasure right in each of these regimes permits where another law compels retention.

Getting your data out. Reports, payments and payroll export to CSV from the dashboard, and the REST API at /api/v1 reads your students, classes and bookings with a studio API key. At the end of your subscription you can export everything through those routes; if you would rather we delete it, say so and see §12 below.

Individual rights. Any student can download everything we hold about them from their own account. That self-service export is a feature you have switched on as controller, so when it runs it is you answering, not us. If a student contacts us directly with a rights request, we will not answer it ourselves — we will pass it to you promptly and help you respond. The names and clocks differ:

Because you can act on all of these yourself in the app, you are almost never waiting on us. Where you do need us, we will help, and we will not charge you for it.

11. Helping you meet your own obligations

Beyond individual requests, we will give you what you reasonably need to run a data protection impact assessment, a POPIA impact assessment under Regulation 4, or the equivalent risk exercise your law calls for — and to consult your regulator where one is genuinely needed. Our published security documentation and sub-processor list answer most of what those exercises ask for; write to us for the rest.

12. Closing a studio

What closing does, precisely — because the honest answer is narrower than the usual DPA sentence. Closing anonymises the studio's own contact details and removes it from everyone's studio list, but it does not by itself erase your student records: the payment history that tax law obliges us to keep is attached to them. So if you want the student data gone, delete the students before you close, or ask us and we will do it within 30 days of the request.

Account deletions run on a 30-day delay you can cancel, and deletion reaches backups as they rotate rather than instantly, because a backup that can be edited is not a backup. Data still sitting in a backup is not used for anything; it ages out.

13. If something goes wrong

If we become aware of a personal data breach affecting your students, we will tell you without undue delay, and in any event within 48 hours of confirming that a breach has occurred. We will give you what you need to meet your own duty: what happened, which data and roughly how many people are affected, the likely consequences, and what we have done about it.

We will send you what we know when we know it rather than waiting until the picture is complete, because your clock is running too. Those clocks are not the same everywhere:

14. Audits and monitoring

We will make available the information needed to show we are meeting these obligations. In the ordinary case that means our published security documentation and answers to your questions in writing.

You may also take reasonable and appropriate steps to satisfy yourself that we are using your students' data consistently with this agreement — including sending us a questionnaire, reviewing our documentation, or asking us to demonstrate a control. If you find unauthorised use, tell us and we will stop it and remediate it. Where written answers genuinely are not enough for your regulator, we will accommodate an audit, on reasonable notice, once a year, at your cost, and without disrupting other studios.

15. Where the data goes

Your students' records are stored on our servers in the European Union.

Infinity Curve LLC is established in Georgia — and operates the platform from there, so your data is also processed in Georgia. Georgia is a third country for every regime in §1 that restricts exports, so a transfer mechanism is needed in each case. This is what we rely on:

Where a transfer impact assessment is expected of you, ask us — we will give you what we know about Georgian law enforcement access, our record of government requests, and the technical measures in §6.

Some of our sub-processors are outside the EU as well; the list says where each one is, and the same mechanisms flow down to them. Traffic to the site passes through Bunny, which decrypts each request at whichever of its data centres is nearest the visitor — so traffic is not confined to the EU even though storage is. Under Swiss law in particular, remote access from outside the country counts as a disclosure abroad, which is why we mention it here rather than burying it.

Because we are established in Georgia, our own onward transfers out of Georgia are additionally governed by the Georgian Law on Personal Data Protection, and we meet its grounds for international transfer independently of anything you do.

16. Representatives and registrations

Several of these laws require a company that processes their residents' data from abroad to appoint a local representative or to register. Where that obligation falls on us as processor, we meet it, and the current appointments are available from data@infinitycurve.com on request.

Where it falls on you as controller, it is yours: a UK or EU studio outside its own market may need an Art. 27 representative, a Turkish studio must register with VERBIS, and a studio that itself operates servers or other technical equipment in Georgia may need a special representative registered there, unless it is established in the EU or another country Georgia treats as having equivalent standards. We flag it because studios are regularly surprised by it, not because we can do it for you.

17. Annex — United Kingdom

Applies if the UK GDPR governs your processing.

Read every reference in this agreement to the GDPR as a reference to the UK GDPR and the Data Protection Act 2018, every reference to a supervisory authority as the Information Commissioner, and every reference to Member State law as the law of England and Wales, Scotland or Northern Ireland as applicable.

For transfers, the Standard Contractual Clauses in §15 apply as amended by the ICO's International Data Transfer Addendum (version B1.0), which is incorporated here by reference. Table 1 is populated by §2 and the details in §3; Tables 2 and 3 by §15 and the annex references in §3 and §6; and in Table 4, neither party may end the Addendum when the ICO revises it. If you would rather use the standalone IDTA than the Addendum, write to us.

18. Annex — Switzerland

Applies if the Swiss FADP governs your processing.

The Standard Contractual Clauses in §15 apply with the amendments the FDPIC recognises. In practice: read references to the GDPR as references to the FADP; the competent authority is the FDPIC; "Member State" is Switzerland, and nothing in the Clauses prevents a person in Switzerland from bringing a claim in Switzerland.

Two Swiss specifics worth naming. Switzerland's list of sensitive personal data is wider than the GDPR's, as §8 notes. And Swiss law treats remote access from outside Switzerland as a disclosure abroad, so the Bunny point in §15 matters more here than elsewhere.

19. Annex — Türkiye

Applies if the KVKK (Law No. 6698) governs your processing.

Otherwise: read controller as veri sorumlusu and processor as veri işleyen; the security obligations in §6 are our Art. 12 obligations, for which Turkish law holds us jointly liable with you; and the breach clock in §13 is 72 hours to the Board.

20. Annex — Mexico

Applies if the LFPDPPP governs your processing.

This agreement is the arrangement between a responsable and its encargado. Because we act only on your instructions, sending student data to us is a remisión, not a transferencia, so it does not require separate consent from your students and does not need to be listed as a transfer in your aviso de privacidad. Our sub-processors are engaged on the same basis, under the general authorisation in §7.

Two things stay yours. The aviso de privacidad is a controller document and the centre of Mexican compliance — you must have one, it must reach your students before or at collection, and it must say what §8 requires if you collect sensitive data. And ARCO requests come to you; §10 sets out the deadlines.

Since 21 March 2025 the supervisory authority is the Secretaría Anticorrupción y Buen Gobierno, following the dissolution of INAI. If your own privacy notice still names INAI, it needs updating.

21. Annex — South Africa

Applies if POPIA governs your processing.

We are your operator. We process student information only with your knowledge and authorisation, treat it as confidential, and maintain the security safeguards in §6 as s21(1) requires. Where we have reasonable grounds to believe student information has been accessed or acquired by an unauthorised person, we will notify you immediately — see §13.

This agreement is the binding agreement under s72(1)(a). We undertake that we are bound, in respect of student information you send us, to principles for reasonable processing substantially similar to POPIA's eight conditions for lawful processing, and that we will not transfer that information onward to a third party in another country except on terms substantially similar to s72 itself. That undertaking flows down to every sub-processor in §7. South Africa has published no adequacy list, so this contractual route is the practical one.

Note also that POPIA's definition of personal information reaches identifiable juristic persons, not only individuals. Where your student records include information about a company — a corporate account paying for classes — it is protected here on the same terms as an individual's.

Two filings remain yours. Section 57 requires prior authorisation from the Information Regulator before special personal information or children's information is transferred to a country without adequate protection — which, given §15, describes health intake forms and minors' records on BailaYa. And the s22 notification to the Regulator and to affected people is a responsible party's duty. We will support both.

22. Annex — California

Applies if the CCPA as amended by the CPRA governs your processing.

We are a service provider, and we receive your students' personal information solely for the limited and specified business purpose of providing the BailaYa studio-management service as described in §3. The prohibitions in §4 — no selling, no sharing for cross-context behavioural advertising, no use outside our direct business relationship with you, no combining with other people's data, no model training — are the CCPA restrictions, and we certify that we understand and will comply with them.

We will provide the same level of privacy protection the CCPA requires of you. §14 is your right to monitor us. §4 covers our duty to tell you if we can no longer comply. §7 flows these terms down to every sub-processor, each of which is engaged as a service provider on the same basis.

Health information collected through a form under §8 is sensitive personal information; we use it only to run your studio, which is within the permitted purposes, and never to infer characteristics.

The other US state privacy laws — Virginia, Colorado, Connecticut, Utah, Texas, Oregon, Montana and the rest of that family — impose materially the same processor contract terms. Read this annex as satisfying those too, with "service provider" read as "processor" and "business" as "controller".

23. Changes, liability, and what this is worth

We may update these terms as the service or the law changes. Anything that materially affects your rights gets the same 30 days' notice as a new sub-processor. The version and date at the top tell you which text you are looking at, and superseded versions stay available on request.

Liability under this agreement is governed by the Terms & Conditions, except where a law in §1 fixes a party's liability directly — in which case the law governs, and no cap in the Terms limits what a data subject can recover from either of us under it. The Standard Contractual Clauses carry their own liability and third-party beneficiary provisions, which stand as written.

This agreement survives the end of your subscription for as long as we hold any of your students' data.

Language. This agreement is published in several languages so you can read it in your own. The translations are provided for convenience and we intend them to be accurate; where one of them and the English differ, the English text governs. That is not a way of disowning the translation — if you find one that says something the English does not, tell us and we will fix it.

Infinity Curve LLC · Data Processing Agreement · Version 2.0 · Effective 2026-09-05 · Data protection contact: data@infinitycurve.com