Data Processing Agreement.

• This agreement governs the personal data that Selr Group Pty Ltd processes on behalf of its customers: chiefly creators who host member data on Loup (community rosters, CSV member imports, course enrollments).
• For the marketplace itself (accounts, purchases, fraud screening, analytics), Loup is an independent controller and the Privacy policy governs, not this DPA. The split is set out in the role table in section 2.
• Headline commitments: processing on documented instructions only, the named sub-processor list in section 4 with advance notice and a 30-day objection window, breach notice to affected controllers within 48 hours of confirmation, and deletion or return of customer data at termination.

This Data Processing Agreement ("DPA") is entered into between Selr Group Pty Ltd (ABN 41 662 328 056), a company registered in Queensland, Australia ("Loup", "we", "us"), and the customer that accepts the Loup terms of service ("Customer", "you"). It forms part of the agreement between the parties and applies automatically, without signature, whenever we process personal data on your behalf.

In practice, this DPA applies to two groups:

• Creators, from the moment they use any feature that puts member data in our hands: importing a member CSV, running a community with a roster, enrolling people in a course, or binding a Telegram group whose messages bridge into their community.
• Business buyers who need processor terms for their own compliance file. The published terms below apply to them on the same basis; organisations that require a countersigned copy can request one by emailing support@selrgroup.com.au with the subject "DPA request" and their legal entity name.

Acceptance happens through the terms of service: no signature, exchange of PDFs, or purchase order is needed for these obligations to bind us. A countersigned copy adds evidence for a procurement file; it does not add rights beyond what is published here unless the parties negotiate different terms in writing.

This DPA is written to satisfy Article 28(3) of the GDPR and the equivalent requirements of the UK GDPR and the Australian Privacy Act 1988 (Cth). Where your own law requires additional terms, section 6 and section 7 explain how they slot in.

Term. This DPA takes effect when you first cause us to process personal data on your behalf, continues for as long as we do, and survives termination of the main agreement until the delete-or-return obligations in section 3 are complete. For US state privacy laws, this DPA is also the contract under which we act as your "service provider" or "processor": we do not sell Customer Data, do not share it for cross-context behavioural advertising, do not retain, use, or disclose it for purposes other than providing the services or as the law permits, and do not combine it with personal data we hold as controller except as those laws allow for service providers.

What this DPA is not. It is not a controller-to-controller data sharing agreement: the marketplace activities each party runs for itself are governed by each party’s own privacy notice. And it does not apply to the personal data we hold about you as our customer (your account email, your sales and payout records), for which we are the controller under our Privacy policy.

Everything else in this document depends on one question: for a given processing activity, who decides the purposes and means? The table below is the authoritative allocation. Where Loup is listed as an independent controller, the Privacy policy governs and this DPA does not apply to that activity.

One activity needs a note because it straddles the line. When a creator binds a Telegram group to their community, the bridged messages serve the creator’s community (creator as controller, Loup as processor for the hosting), but Loup also independently displays the bridged feed as part of the marketplace and moderates it for safety (Loup as controller for that display and moderation). Both this DPA and the Privacy policy therefore speak to bridged content, each within its lane.

The reasoning behind the controller rows: fraud screening, tax records, and platform analytics would run identically whether or not any individual creator instructed them. They are duties we owe to all users and to regulators, so we hold them in our own name rather than dressing them up as your instructions. The processor rows, by contrast, exist only because you brought the data and asked us to host it; you decide what goes in, what it is for, and when it leaves.

A concrete example. A creator imports a 2,000-row CSV of member emails to seed a community: the creator chose to collect those addresses, chose to bring them to Loup, and decides when they are deleted, so the creator is controller and we process. The same creator’s own payout record exists because tax law and our terms require it, whatever the creator might prefer, so for that record we are controller.

And one boundary case for completeness: buyer secrets (the encrypted credentials buyers store so their installs can run) sit in the marketplace column. We hold them under our direct service contract with each buyer, governed by the Privacy policy, and they are not Customer Data under this DPA.

The parties do not intend to act as joint controllers for any activity. If a court or regulator nonetheless finds joint controllership somewhere, the allocation of responsibilities in this DPA stands as the arrangement between the parties to the extent the law permits.

Wherever the table in section 2 makes Loup a processor, we commit to the following with respect to the affected personal data ("Customer Data"):

• Instructions. We process Customer Data only on your documented instructions, including those embedded in your configuration of the platform (importing a list, opening a community, enrolling a member), unless processing is required by a law we are subject to, in which case we will tell you before processing unless that law forbids the telling. The terms of service, this DPA, and your feature configuration together form the complete set of standing instructions; instructions that would require changes to how the platform works can be agreed in writing. If we believe an instruction violates applicable data protection law, we will flag it rather than silently execute it.
• Purpose limitation. We do not use Customer Data to train models, to market to your members, or to build audiences for anyone. Processing is limited to providing the features you configured, plus the security processing needed to protect the platform they run on.
• Confidentiality. Every person we authorise to process Customer Data is bound by a contractual or statutory duty of confidentiality, and access is limited to what their role requires.
• Security. We maintain the technical and organisational measures in Annex B, and we may improve them over time provided the overall level of protection does not drop.
• Data subject requests. If a data subject contacts us directly about Customer Data (access, correction, deletion, objection, or any other right), we will not answer on your behalf; we will forward the request to you without undue delay and give you reasonable assistance in meeting it, including through the platform’s built-in export and deletion tooling.
• Breach notice. If we confirm a personal data breach affecting Customer Data, we will notify the affected controllers within 48 hours of confirmation, with a description of the breach, the categories and approximate volume of records involved, the likely consequences, and the measures taken or proposed. We set our deadline at 48 hours deliberately: where the GDPR applies to you as controller, your own clock for notifying a supervisory authority is 72 hours, and our notice is designed to land inside it with room to act. We will supplement the notice as facts develop rather than wait for a complete picture. A breach notice is information owed under this DPA, not an admission of fault or liability.
• Assistance. Taking into account the nature of the processing, we will give you reasonable assistance with your own obligations on security, breach notification, data protection impact assessments, and consultations with supervisory authorities.
• Legal demands. If a court, regulator, or law enforcement body demands access to Customer Data, we will redirect the demand to you where lawful, tell you before disclosing unless we are legally barred from doing so, and disclose no more than the demand validly requires.
• Records. We maintain the records of processing activities that Article 30(2) of the GDPR requires of processors, and we make them available to a supervisory authority on lawful request.
• Audit cooperation. We keep records of our processing activities and will make available the information reasonably necessary to demonstrate compliance with this DPA. We will allow and contribute to audits, including inspections, conducted by you or an auditor you mandate, subject to reasonable advance notice, confidentiality undertakings, no more than one audit per twelve-month period absent a confirmed breach or regulator requirement, and the requesting party bearing its own costs. Where a written security questionnaire would resolve your need faster than an inspection, we will answer one first.
• Delete-or-return at termination. When the services end, or earlier on your instruction, we will delete or return the Customer Data, at your choice, and delete remaining copies, except where a law we are subject to requires continued storage, in which case the data stays protected under this DPA and is processed for no other purpose. Residual copies in backups are purged on the backup cycle.

You authorise the engagement of the following sub-processors for Customer Data, which are the same providers named in the Privacy policy:

• Supabase (United States and Australia regions): database and authentication.
• Vercel (United States): application hosting and CDN.
• Stripe: payment processing and payouts. Cardholder data flows directly to Stripe and never reaches Loup.
• GitHub: skill pack source hosting and delivery.
• Telegram: message and identity exchange where a Telegram group or identity is linked.
• Resend: transactional email delivery.
• Sentry: error monitoring.
• PostHog (US cloud): product analytics.
• Anthropic: engaged only if the hosted runtime option is enabled. It is currently off, and no buyer prompts leave the platform today.

Scope note: not every sub-processor sees every datum. Customer Data lives in Supabase; Vercel carries the requests that read and write it; Resend touches it only when an email is actually sent to a member; Sentry sees fragments only when an error fires while Customer Data is in flight; PostHog receives product telemetry, not your member lists; and Stripe, GitHub, and Telegram are involved only where payments, pack delivery, or bridging actually occur.

Changes. Before adding or replacing a sub-processor that touches Customer Data, we will give you advance notice through the platform or by email. You may object on reasonable, data-protection-related grounds within 30 days of the notice by emailing support@selrgroup.com.au. Reasonable grounds are data protection grounds: the newcomer’s location, security posture, or compliance record. A commercial preference for a different vendor is not one. If you object, we will work with you in good faith on an alternative: a configuration that avoids the new sub-processor, a delayed migration, or another reasonable accommodation. If no alternative is workable, you may terminate the affected services, and we will honour the delete-or-return commitment in section 3. Where a sub-processor must be replaced urgently for security or continuity reasons, we may act before the notice period ends and will notify you promptly afterwards; your objection and termination rights are unaffected.

Flow-down and liability. Every sub-processor handling Customer Data is bound by a written contract imposing data protection obligations materially equivalent to this DPA, including on security and confidentiality. We remain fully liable to you for the performance of each sub-processor’s obligations, as if the acts and omissions were our own.

A processor can only be as lawful as the instructions it receives. Where you are the controller, you agree that:

• Your instructions are lawful. You will instruct us to process Customer Data only in ways that comply with the data protection law applicable to you, and you are responsible for the accuracy, quality, and legality of the Customer Data and the means by which you acquired it.
• You have the rights you need, especially for imports. Before uploading a member CSV, syncing a roster, or enrolling people in a course, you must hold a lawful basis to give us that data: your members’ consent, a contract with them, or another basis valid under your law. Uploading a list you scraped, bought without rights, or exported in breach of another platform’s terms is a breach of this DPA.
• You give the notices. You are responsible for providing your members with any privacy notices required, including telling Telegram group members that the group is bound to your Loup community and that their messages will appear in the community feed.
• You handle your members’ rights requests. As controller, requests from your members are yours to answer. We assist as described in section 3.
• Marketing law is yours too. If you use member contact details to send messages through or alongside the platform, you are responsible for the spam and electronic marketing laws that apply to you (in Australia, the Spam Act 2003; elsewhere, the local equivalents), including consent and unsubscribe requirements.
• No special category data. The platform is not designed for health data, biometric data, or other special categories of personal data. Do not submit them as Customer Data unless we have agreed in writing to a specific arrangement.
• Assessments are yours where required. If your use of the platform triggers a data protection impact assessment or similar obligation under your law, conducting it is your responsibility; we provide the assistance described in section 3.
• Stay reachable. Keep your account email current. It is where sub-processor notices, breach notices, and forwarded data subject requests will go, and a notice sent there counts as given.

Loup is operated from Australia on infrastructure that includes United States providers, so Customer Data may be transferred to, and processed in, countries other than the one it originated in. Where a transfer of Customer Data is subject to the GDPR or UK GDPR and the destination lacks an adequacy decision, the European Commission’s Standard Contractual Clauses (controller-to-processor module, and processor-to-processor where relevant), together with the UK addendum or international data transfer agreement as applicable, are incorporated into this DPA by reference, with you as data exporter and Selr Group Pty Ltd as data importer, populated by the processing details in Annex A and the measures in Annex B. Where the destination benefits from an adequacy decision, the transfer rests on that decision and the Clauses are not engaged for it.

For disclosures governed by the Australian Privacy Act, we take the steps required by Australian Privacy Principle 8 before disclosing personal information to overseas recipients. If a transfer mechanism we rely on is invalidated or superseded, the parties will cooperate in good faith to adopt a lawful replacement without interrupting the services more than necessary.

If the Standard Contractual Clauses conflict with this DPA, the Clauses prevail for the transfers they govern; nothing in this DPA is to be read as varying them. Onward transfers from us to sub-processors are covered by the flow-down obligations in section 4, including transfer safeguards equivalent to the ones we owe you.

On any matter concerning the processing of personal data, this DPA prevails over the terms of service and any other agreement between the parties, to the extent of the conflict. On all other matters, the terms of service govern, including their limitations of liability, which apply to claims under this DPA except where the applicable data protection law does not permit them to be limited. Nothing in this DPA reduces a protection or right that applicable data protection law grants and does not allow the parties to vary.

If any provision of this DPA is held invalid, the remainder stays in force and the parties will replace the invalid provision with a valid one that comes closest to the original intent. This DPA is governed by the law that governs the terms of service, except where applicable data protection law mandates otherwise for a particular protection.

• "Personal data", "processing", "controller", "processor", "data subject", "personal data breach", "supervisory authority" carry the meanings given by the GDPR, and equivalent terms under other applicable data protection law (for Australia, "personal information" and the related concepts of the Privacy Act 1988) are read accordingly.
• "Customer Data" means personal data that Loup processes on the Customer’s behalf in the activities marked "Processor" in the table in section 2: community rosters, CSV member imports, course enrollments, and the hosting of bridged community content for the Customer.
• "Sub-processor" means a third party engaged by Loup to process Customer Data on Loup’s behalf.
• "Member" means a data subject whose personal data the Customer brings to the platform: a community member, a person named in an imported list, a course enrollee, or a participant in a Telegram group the Customer has bound to a community.
• "Applicable data protection law" means the data protection and privacy laws that apply to the processing of Customer Data under this DPA, including the GDPR, the UK GDPR, the Australian Privacy Act 1988 (Cth), and applicable US state privacy laws.
• "Standard Contractual Clauses" means the standard contractual clauses for international transfers adopted by the European Commission under Article 46(2)(c) of the GDPR, as amended or replaced from time to time, together with the UK transfer tools where the UK GDPR applies.
• "Services" means the Loup platform features through which the Customer Data is processed.

• Subject matter: hosting and processing of member, community, and enrollment data that the Customer brings to the Loup platform.
• Duration: the term of the Customer’s use of the relevant services, plus the period needed to complete deletion or return under section 3, including the purge of backups on cycle.
• Nature and purpose: storage, organisation, display, transmission, and deletion of Customer Data as needed to provide the community, import, enrollment, and bridging features the Customer configures.
• Categories of data subjects: the Customer’s community members and prospective members, people named in member lists the Customer imports, course enrollees, and participants in Telegram groups the Customer binds to a community.
• Categories of personal data: identifiers and contact details (names, email addresses, Telegram user IDs and display names), membership and enrollment records, and community content (posts, comments, bridged messages).
• Special categories: none intended; the Customer must not submit special category data (see section 5).
• Frequency: continuous, for as long as the relevant features are in use.
• Deletion mechanics: deletion on documented instruction during the term; delete-or-return under section 3 at termination; purge of residual backup copies on the backup cycle thereafter.
• Processing locations: Australia and the United States, through the sub-processors listed in section 4 and subject to the transfer terms in section 6.

The technical and organisational measures maintained for Customer Data, written to be read alongside GDPR Article 32: the aim is confidentiality, integrity, availability, and resilience proportionate to the risk of the processing described in Annex A.

• Encryption in transit: TLS 1.2 or higher on all connections to and within the platform’s public surfaces.
• Encryption at rest for secrets: stored credentials are encrypted with AES-256 (AES-256-GCM), with key rotation capability.
• Access control: multi-factor authentication on infrastructure accounts, least-privilege access scoped to role, and row-level security policies in the database so tenant data is isolated at the query layer.
• Abuse resistance: rate limiting and anomaly monitoring on public endpoints.
• Auditability: audit logging of sensitive operations, including administrative access to stored secrets. Stored credentials are not written to logs in plaintext.
• Resilience: scheduled backups, with deleted data purged from backups on the backup cycle, so that a deletion instruction reaches every copy within a bounded period rather than lingering indefinitely.
• Personnel: confidentiality obligations on everyone with production access, and access reviews aligned to least privilege.
• Incident response: a defined process for detecting, assessing, containing, and notifying personal data breaches, feeding the 48-hour controller notice in section 3.

We may update these measures as technology and threats evolve, provided the changes do not materially reduce the overall level of protection for Customer Data during the term.