Data Processing Addendum

1. Scope and application

This Data Processing Addendum (the DPA) forms part of the Terms of Service between Telesuber (we, us, the Processor) and the customer that has created a workspace on Telesuber (the Customer, the Controller). Together the Terms and this DPA are the Agreement.

It applies whenever we process personal data on the Customer's behalf in providing Telesuber (the Service), and it applies automatically: no signature, countersignature or request is needed, and accepting the Terms accepts this DPA. A Customer who needs a separately signed copy, or whose own template must be used, can ask us using the details in section 21, but the protections below are in force either way.

This DPA does not cover personal data for which we are ourselves the controller — principally the account data of the people who sign in to Telesuber. That is described in our Privacy Policy, and our use of cookies on our own site is described in the Cookie Policy.

2. Definitions

Terms used but not defined here have the meaning given in the Terms or in Applicable Data Protection Law.

• Applicable Data Protection Law means all data protection and privacy laws applicable to a party's processing under this DPA, including the EU GDPR, the UK GDPR together with the Data Protection Act 2018, and, where relevant, the United States state privacy laws referred to in section 16.
• EU GDPR means Regulation (EU) 2016/679. UK GDPR means the EU GDPR as it forms part of the law of England and Wales, Scotland and Northern Ireland by virtue of the European Union (Withdrawal) Act 2018.
• controller, processor, data subject, personal data, processing, personal data breach and supervisory authority have the meanings given in the EU GDPR, and equivalent expressions in other laws are read accordingly.
• Customer Personal Data means personal data that we process on behalf of the Customer in providing the Service, as described in Annex 1.
• Subprocessor means a third party engaged by us to process Customer Personal Data.
• SCCs means the standard contractual clauses for the transfer of personal data to third countries approved by European Commission Implementing Decision (EU) 2021/914.
• UK Addendum means the International Data Transfer Addendum to the SCCs issued by the UK Information Commissioner under section 119A of the Data Protection Act 2018.

3. Roles of the parties

3.1 The Customer is the controller

The Customer — acting through the workspace owner, on behalf of the workspace — is the controller of the personal data it puts into the Service and of the personal data about its subscribers that the Service collects and handles on its behalf. The Customer decides what it sells, to whom, what it asks people for, what it imports, what messages it sends and what it keeps. We do not make those decisions.

3.2 We are the processor

Telesuber is the processor of that data and processes it only to provide the Service in accordance with section 5. We do not sell Customer Personal Data, do not use it for our own marketing, do not use it to build profiles of the Customer's subscribers for our own purposes, and do not use it to train artificial intelligence models.

3.3 Data for which we are the controller

We are the controller of the account data of the individuals who sign in to the Service — workspace owners and team members — including their sign-in credentials, sessions and the security records attached to them, and of our own billing records for what the Customer pays us. That processing is outside this DPA and is described in the Privacy Policy. Where the same individual appears both as an account holder and in workspace records, each role is treated separately.

3.4 Independent controllers

Some parties involved in the Customer's use of the Service are not our processors and do not act under this DPA. In particular, the payment provider the Customer connects to its own account, the artificial intelligence provider the Customer chooses if it switches on the AI support bot with its own key, and Telegram itself each act under the Customer's own relationship with them and under their own terms. Section 8.5 explains this further.

4. Details of the processing

The subject matter, duration, nature and purpose of the processing, the types of personal data and the categories of data subjects are set out in Annex 1, which forms part of this DPA and constitutes the Customer's instructions as to those matters for the purposes of Article 28(3) of the EU GDPR and UK GDPR.

The processing lasts for the term of the Agreement and for the retention and deletion periods described in section 14.

5. Processing on documented instructions

5.1 What counts as an instruction

We process Customer Personal Data only on the Customer's documented instructions, including for transfers to a third country, unless we are required to do so by a law to which we are subject. The Customer's documented instructions consist of:

• the Agreement, including this DPA and its annexes;
• the Customer's use and configuration of the Service — the plans and channels it creates, the messages and automations it sets up, the files it imports, the features it switches on, the payment provider it connects, the team members it invites and the data it chooses to store; and
• any further written instruction the parties agree, which may attract a reasonable charge where it requires work outside the ordinary operation of the Service.

5.2 Instructions that appear unlawful

If we are required by law to process Customer Personal Data other than on the Customer's instructions, we will tell the Customer before processing unless that law forbids it on important grounds of public interest. If we form the view that an instruction infringes Applicable Data Protection Law, we will inform the Customer, and we may suspend the affected processing until the instruction is withdrawn, amended or confirmed. We are not obliged to carry out an instruction we reasonably believe to be unlawful.

5.3 Support

We access Customer Personal Data to support the Customer at its request, to maintain and secure the Service, and to investigate faults. Staff access is limited as described in Annex 2, and administrative access to a workspace is recorded in an append-only audit log.

6. Confidentiality

We ensure that the personnel authorised to process Customer Personal Data are bound by an appropriate duty of confidentiality, whether by contract or by a statutory obligation, and that the duty survives the end of their engagement. Access is limited to those who need it to provide, secure and support the Service, and is removed when it is no longer needed.

7. Security of processing

Taking account of the state of the art, the costs of implementation and the nature, scope, context and purposes of the processing, as well as the risks to individuals, we implement appropriate technical and organisational measures to ensure a level of security appropriate to that risk. The measures in force are described in Annex 2.

We may change those measures as the Service develops, provided the change does not materially reduce the overall level of security. Annex 2 is kept up to date with what is actually in place; it describes measures rather than certifications, and we do not claim any third-party security certification or audit report.

The Customer is responsible for the parts of security that sit with it: keeping sign-in credentials secret, switching on two-step verification, managing who is invited to the workspace and removing people who should no longer have access, and configuring the Service appropriately for the data it chooses to put in it.

8. Subprocessors

8.1 General authorisation

The Customer gives a general authorisation for us to engage Subprocessors to process Customer Personal Data. The current list is published at /subprocessors and forms Annex 3 to this DPA.

8.2 Our obligations towards them

We engage each Subprocessor under a written contract that imposes data protection obligations materially no less protective than those in this DPA, so far as applicable to the service it provides. We remain fully responsible to the Customer for the performance of each Subprocessor's obligations.

8.3 Notice of changes

We give notice before adding a Subprocessor or replacing one. Notice is given by updating the page at /subprocessors and by emailing Customers who have asked to be notified of changes, at least 15 days before the change takes effect where that is practicable. Where a change has to be made sooner — for example to replace a provider that has failed or to respond to a security problem — we give notice as soon as we can.

8.4 Objection

The Customer may object to a new Subprocessor on reasonable data protection grounds by writing to us within the notice period. We will work with the Customer in good faith to address the objection, for example by explaining the safeguards in place or by offering a different arrangement where one is available. If we cannot address it within a reasonable time, the Customer may terminate the part of the Service that requires that Subprocessor, and, where that is the Service as a whole, the Agreement, by written notice. That is the Customer's sole remedy for an objection.

8.5 Parties that are not our Subprocessors

Three relationships are the Customer's own rather than ours, and we do not engage them as Subprocessors:

• The Customer's payment provider. Subscriber payments are taken through the payment account the Customer connects itself. We never receive or hold that money and we are not a party to the Customer's contract with the provider; the provider processes the payment data under its own terms with the Customer.
• The Customer's AI provider. Where the Customer switches on the AI support bot using its own API key, the messages sent for answering go to the provider the Customer has chosen, under the Customer's own account and terms with that provider.
• Telegram. The Service works by operating the Customer's own Telegram bot. Messages, invite links and channel membership changes are delivered through Telegram under Telegram's terms, and the Customer's relationship with Telegram — including its bot token and the channels it administers — is its own.

We remain responsible for the Subprocessors we do engage, which are listed at /subprocessors.

9. Data subject requests

9.1 Assistance

Taking into account the nature of the processing, we assist the Customer by appropriate technical and organisational measures, so far as possible, in fulfilling its obligation to respond to requests to exercise data subject rights — access, rectification, erasure, restriction, portability and objection.

In practice most of that assistance is the Service itself: the dashboard lets the Customer find a subscriber, read and correct the record, see what they bought and what was sent to them, and delete them. Where a request needs something the dashboard does not yet do — a full export for one individual, or deletion of records the interface does not expose — the Customer can ask us and we will help, without charge for requests of ordinary volume and complexity.

9.2 Requests made to us directly

If a subscriber or other data subject contacts us directly about Customer Personal Data, we will not respond to the substance of the request ourselves, except to confirm that they should direct it to the Customer. We will refer them to the Customer, and will tell the Customer about the request promptly where we can identify the workspace it concerns.

10. Personal data breaches

We notify the Customer without undue delay after becoming aware of a personal data breach affecting Customer Personal Data, and in any event within 72 hours of becoming aware of it. Notice is given to the workspace's registered contact address.

The notice will describe, so far as the information is available to us at the time: the nature of the breach, including where possible the categories and approximate number of data subjects and records concerned; the likely consequences; the measures taken or proposed to address it and to mitigate its effects; and a contact point for further information. Where we cannot provide everything at once, we provide it in phases as it becomes available rather than delaying the first notice.

We assist the Customer in meeting its own obligations to notify supervisory authorities and data subjects, taking into account the nature of the processing and the information available to us. Our notification of a breach is not an admission of fault or liability.

11. Impact assessments and prior consultation

We provide reasonable assistance to the Customer with data protection impact assessments and with prior consultation of a supervisory authority, where the Customer is required to carry these out in relation to its use of the Service. That assistance is given to the extent that is reasonable and that the necessary information is available to us, and it takes into account the nature of the processing and the information we hold. Annex 2 and the page at /subprocessors are intended to answer most of what such an assessment needs.

12. Information and audits

12.1 Information

We make available to the Customer the information necessary to demonstrate compliance with the obligations in Article 28 of the EU GDPR and UK GDPR. In the ordinary case this means this DPA, Annex 2, the subprocessor list, and written answers to a reasonable security or data protection questionnaire.

12.2 How often

We will answer such a questionnaire no more than once in any twelve-month period, unless a supervisory authority requires otherwise or there has been a personal data breach affecting the Customer's data, in which case the Customer may ask again.

12.3 On-site audits

We allow for and contribute to audits and inspections conducted by the Customer or an auditor it mandates, where they are required by Applicable Data Protection Law. Any such audit is at the Customer's cost, on at least 30 days' written notice, during business hours, no more than once a year except where a supervisory authority requires otherwise or following a breach, conducted so as not to disrupt the Service or the security or confidentiality of other customers' data, by an auditor who is not a competitor of ours and who is bound by confidentiality. The findings are the confidential information of both parties.

13. International transfers

Customer Personal Data may be processed outside the European Economic Area and the United Kingdom, including in the United States, by us or by a Subprocessor. The column headed "Where" at /subprocessors says where each Subprocessor processes data.

Where such a transfer is subject to the EU GDPR or UK GDPR and the destination is not covered by an adequacy decision, the transfer is made under an appropriate safeguard:

• the SCCs, which are incorporated into this DPA by reference — Module Two (controller to processor) where the Customer is a controller and we act as its processor, and Module Three (processor to processor) where the Customer is itself a processor for a third-party controller;
• for transfers subject to the UK GDPR, the SCCs as amended by the UK Addendum, also incorporated by reference; and
• for transfers subject to Swiss law, the SCCs with the amendments the Swiss Federal Data Protection and Information Commissioner recognises.

For the purposes of the SCCs: the Customer is the data exporter and we are the data importer; the optional docking clause applies; in Clause 9 option 2 (general written authorisation) applies with the notice period in section 8.3; in Clause 11 the optional independent dispute resolution language does not apply; in Clause 17 the governing law and in Clause 18 the forum are those of the Republic of Ireland — which the SCCs require to be those of an EU member state, so they are not the same choice as the law governing the rest of the agreement — unless the parties agree in writing on another member state, or the SCCs require otherwise; Annexes I, II and III of the SCCs are populated by Annex 1, Annex 2 and Annex 3 of this DPA together with the parties' details in the Agreement. For the UK Addendum, Tables 1 to 3 are populated in the same way, Table 4 is completed as "neither party", and the start date is the date of the Agreement.

Where the parties are required to put a different transfer mechanism in place, or a mechanism relied on here is invalidated, the parties will work in good faith to agree a replacement, and we may substitute an alternative lawful mechanism without reducing the protection given to data subjects.

14. Return and deletion of data

14.1 During the term

Customer Personal Data is retained for the term of the Agreement so that the Service can work. The Customer can delete individual records itself in the dashboard at any time.

14.2 At the end

At the end of the Agreement, and at any time on the Customer's written request, we delete or return Customer Personal Data at the Customer's choice. Deletion is carried out within 30 days of the request or of the end of the Agreement, except where storage is required by a law to which we are subject, in which case we keep only what that law requires and only for as long as it requires.

There is no self-service export or deletion feature yet. Requests are made by email or in the help chat, using the details in section 21, and we act on them within the period above.

14.3 Backups

Deleted data persists in encrypted backups until those backups age out. Backups are taken nightly and fourteen are kept, so a deletion works its way out of the backup set within that rotation. Backups are not used to restore individual records that have been deleted, and a restore of a whole system would be followed by re-applying deletions we are aware of.

14.4 Records we keep

Three categories are kept beyond the above, each deliberately narrow:

• The audit log. It records account, security and administrative actions — including when our staff view a workspace — and it is append-only by design: it cannot be edited or deleted, which is the property that makes it worth having. It holds limited identifiers rather than the content of anybody's data, and is kept for security, accountability and legal purposes.
• Records we must keep by law, such as the accounting records for what the Customer has paid us.
• The do-not-email list. An address that asked us not to write to it stays on it, because it is what stops us writing to that address again.

14.5 Automatic pruning

Some technical records are deleted automatically without anybody asking: the event payloads sent to us by payment providers are pruned between 30 and 180 days after receipt depending on whether they were processed, rejected or failed, and the counters recording AI usage are pruned after 30 days.

15. The Customer's own obligations

The Customer warrants and undertakes that:

• it has a lawful basis for the processing it instructs, and has given the subscribers and other individuals concerned the information they are entitled to about it, including about the involvement of processors such as us;
• where it sends marketing or promotional messages through the Service — broadcasts and automated messages in particular — it has the consent or other lawful basis required for those messages under the applicable direct-marketing and electronic communications rules, and honours opt-outs;
• its instructions, including its configuration of the Service, are accurate, lawful and within its authority, and it will keep the personal data it holds accurate and up to date;
• it will not upload or otherwise put into the Service any personal data that is unlawful, or any special-category data within the meaning of Article 9 of the EU GDPR or UK GDPR, or data about criminal convictions and offences, unless it has a lawful basis and the data is genuinely necessary — the Service does not require any such data and is not designed for it;
• where it imports subscribers from another tool or from its own files, it has the right to hold that data, to import it, and to contact the people in it through the Service; and
• it will handle data subject requests and complaints from its own subscribers, as the controller of their data, with our assistance under section 9.

16. United States state privacy laws

Where the Customer is subject to the California Consumer Privacy Act as amended by the California Privacy Rights Act, or to a comparable United States state privacy law, we act as a "service provider" (or the equivalent, such as a "processor" or "contracted service provider") in respect of the personal information we process on the Customer's behalf. In that capacity:

• we do not sell that personal information and do not share it for cross-context behavioural advertising;
• we do not retain, use or disclose it for any purpose other than performing the Service specified in the Agreement, or as otherwise permitted by the applicable statute — and not outside the direct business relationship between us and the Customer;
• we do not combine it with personal information we receive from, or on behalf of, another person, or collect ourselves, except as the applicable statute permits;
• we comply with the obligations applicable to service providers under those laws and provide the same level of protection they require; and
• we will tell the Customer if we determine that we can no longer meet those obligations, and the Customer may take reasonable steps to stop and remediate unauthorised use.

The Customer may take reasonable and appropriate steps to confirm that we use the personal information consistently with its obligations, which section 12 is intended to satisfy.

17. Liability

Each party's liability under or in connection with this DPA is subject to the exclusions and limitations of liability set out in the Terms of Service, and the parties' total liability is aggregated across the Agreement rather than counted separately for this DPA. Nothing in this DPA limits any liability that cannot be limited under Applicable Data Protection Law, or affects the rights of data subjects under that law or under the SCCs.

18. Term of this addendum

This DPA takes effect when the Customer accepts the Terms, or on the date the Service is first used if that is earlier, and continues for as long as we process Customer Personal Data. The obligations that by their nature should survive — in particular confidentiality, security, deletion and the transfer safeguards — continue until the data has been returned or deleted in accordance with section 14.

19. Order of precedence

Where there is a conflict, the order is:

• the SCCs and the UK Addendum prevail, where they apply, over the rest of this DPA;
• this DPA prevails over the Terms of Service on matters of data protection; and
• the Terms of Service govern everything else.

Nothing in the annexes is intended to vary the body of this DPA; where it appears to, the body governs.

20. Governing law

This DPA is governed by the same law, and subject to the same jurisdiction, as the Terms of Service, except where Applicable Data Protection Law or the SCCs require otherwise — in which case that requirement prevails for the matters it covers.

21. Contact

Data protection questions, deletion and export requests, subprocessor notification requests, questionnaires and breach correspondence go to Telesuber:

• Email: no-reply@telesuber.com
• The help chat inside your dashboard, which reaches the same people

We have not appointed a data protection officer. Requests sent to the addresses above reach the people who can act on them.

Annex 1 — Description of the processing

This annex populates Annex I of the SCCs and the corresponding tables of the UK Addendum. The data exporter is the Customer; the data importer is Telesuber. The competent supervisory authority is the one determined by the Customer's own establishment or representative.

Annex 2 — Technical and organisational measures

These are the measures in force, and they populate Annex II of the SCCs. They are a description of what the Service does, not a claim of certification: we hold no third-party security certification and publish no third-party audit report.

Encryption in transit

• All traffic to the Service is carried over TLS (HTTPS), with HTTP Strict Transport Security set so that browsers refuse to fall back to an unencrypted connection.

Encryption and hashing at rest

• Account passwords are hashed with Argon2id. They are never stored in a form that can be reversed.
• Credentials belonging to a workspace — Telegram bot tokens, payment provider API keys, webhook signing secrets, AI provider keys, SMTP passwords and two-step verification secrets — are encrypted with AES-256-GCM envelope encryption, each value cryptographically bound to the record it belongs to so that a ciphertext cannot be moved to another record.
• Session, password-reset, invitation, checkout and sign-up tokens are stored only as SHA-256 hashes, so the stored value cannot be used to impersonate anyone.

Separation of each workspace's data

• PostgreSQL row-level security is enforced on workspace tables, so a query made for one workspace can return only that workspace's rows.
• The web application connects to the database as a role that does not have the right to bypass row-level security, so the separation is enforced by the database rather than only by application code.

Application security

• A strict content security policy on every page. It permits no third-party script anywhere but on one page: the card step where a workspace pays us for its own plan by card, which allows Stripe’s script — so that the card number is typed into Stripe’s own fields and goes straight to Stripe, never to us — and nothing else. Every other page allows only scripts served from our own site, and most of the public pages none at all.
• Cross-site request forgery protection on form submissions, and cross-origin request checks that refuse a submission that did not come from our own pages.
• Rate limiting on sign-in, sign-up, checkout and token endpoints.
• Account lockout after repeated failed sign-in attempts.
• Optional two-step verification using time-based one-time passwords, with recovery codes.

Integrity of incoming events

• Payment-provider webhooks are verified by signature, or by asking the provider to confirm the event, before they are processed.
• Telegram webhooks are verified using a secret header, so updates that did not come from Telegram are rejected.

Accountability and staff access

• An append-only audit log records account, security and administrative actions, including when our staff view a workspace. It cannot be edited or deleted.
• Staff access to a workspace is limited to the summaries needed for support and billing. There is no feature that lets staff sign in as a customer, and no administrative view of a workspace's subscriber list or of the contents of its conversations.
• Personnel with access are bound by confidentiality, as set out in section 6.

Infrastructure

• The Service runs on a single application server with a hardened service configuration.
• The application listens only on the local interface, behind a reverse proxy that terminates HTTPS, so it is not reachable directly from the internet.

Backups and restoration

• The database is backed up nightly. Each backup is encrypted with AES-256 and is test-decrypted and read before it is kept, so a truncated or unreadable backup is not counted as one.
• Fourteen backups are retained on the rotation described in section 14.3.

Measures the Customer controls

• Who is invited to the workspace and what they can do; whether two-step verification is switched on; the strength and secrecy of sign-in credentials; and what data is put into the Service in the first place.

Annex 3 — Subprocessors

The list of Subprocessors authorised under section 8 is published, and kept current, at /subprocessors. That page states, for each one, what it does, the data involved, where it processes data, and whether it is used always or only when a particular feature is switched on. It is incorporated into this DPA by reference and populates Annex III of the SCCs.

To be notified by email when the list changes, ask us using the details in section 21. The notice period and the right to object are in sections 8.3 and 8.4.