Data Processing Agreement
Effective 20 October 2026 · Tolla, operated by Dmitrii Russu, 8006 Zürich, Switzerland
This Data Processing Agreement ("DPA") is part of the Terms of Service between the Customer and Dmitrii Russu, trading as Tolla, Stapferstrasse 3, 8006 Zürich, Switzerland ("Tolla"). It applies whenever Tolla processes personal data on the Customer's behalf, and takes effect when the Customer accepts the Terms. It meets the requirements of Article 28 of the EU and UK General Data Protection Regulation (GDPR) and Article 9 of the Swiss Federal Act on Data Protection (FADP).
If you need a signed copy, write to dmitrii@russu.net.
1. Roles
The Customer is the controller of the personal data it sends to Tolla ("Customer Personal Data"). Tolla is the processor. Annex 1 describes the processing: its subject matter, duration, nature and purpose, the types of personal data and the categories of people concerned.
Where the Customer is itself a processor for another company, Tolla acts as its sub-processor, and the Customer passes on the relevant instructions.
2. Instructions
Tolla processes Customer Personal Data only on the Customer's documented instructions, including for transfers abroad, unless the law requires otherwise; in that case Tolla tells the Customer before processing, unless the law forbids it. The Terms, this DPA and the Customer's settings and actions in the service are the Customer's instructions. Tolla tells the Customer without delay if it believes an instruction breaks data protection law.
Tolla does not sell Customer Personal Data, does not use it for its own purposes or for advertising, and does not combine it with data of other customers: identity signals and links are kept and computed separately for each workspace, and are never used to recognise people across customers. It may produce anonymous, aggregated statistics about the operation of the service.
3. The Customer's responsibilities
The Customer is responsible for the lawfulness of the data it sends and of its instructions, including:
- informing its users about the processing, and listing the browser snippet's cookie in its cookie notice;
- using the browser snippet only as intended: right after sign-up and sign-in, to recognise devices that create several accounts, never for analytics or marketing. Where the law requires consent for it, the Customer obtains it (the snippet can wait for it with
data-consent="wait"). The optional device fingerprint and automation checks need the visitor's consent in the EU; - not sending the data excluded in section 5 of the Terms;
- the decisions it takes about its users based on Tolla's results. Links between accounts are probabilities. Where a decision based on them significantly affects a person, the Customer ensures human review and the person's right to be heard, as Article 22 GDPR and Article 21 FADP may require.
4. Confidentiality
Tolla ensures that everyone it authorises to process Customer Personal Data is bound to confidentiality, by contract or by law.
5. Security
Tolla applies the technical and organisational measures described in Annex 2, appropriate to the risk. It may update them, as long as the overall level of protection does not decrease.
6. Subprocessors
As Article 28(2) GDPR and Article 9(3) FADP with Article 7 of the Data Protection Ordinance allow, the Customer gives a general authorisation for Tolla to use subprocessors. The current list is on the Subprocessors page.
Tolla informs the account owner by email at least 30 days before adding or replacing a subprocessor. The Customer can object in writing within that period on reasonable data protection grounds. If the parties cannot resolve the objection, the Customer can end the contract before the change takes effect.
Tolla imposes on each subprocessor data protection obligations that are at least as protective as this DPA, and remains responsible to the Customer for its subprocessors.
7. Transfers outside Switzerland and the EEA
Tolla stores Customer Personal Data in Frankfurt, Germany. Switzerland and the EU recognise each other as offering an adequate level of protection.
Where a subprocessor can access Customer Personal Data from a country without such recognition (currently the United States), the transfer is protected by the European Commission's Standard Contractual Clauses (Implementing Decision (EU) 2021/914), with the amendments required by the Swiss Federal Data Protection and Information Commissioner for transfers subject to the FADP and the UK Addendum for transfers subject to the UK GDPR, or by the subprocessor's certification under the EU-U.S. or Swiss-U.S. Data Privacy Framework.
8. Helping the Customer
Taking into account the nature of the processing, Tolla helps the Customer:
- respond to requests from people exercising their rights (access, correction, deletion, restriction, objection, portability). Tolla forwards any request it receives directly to the Customer and does not answer it itself;
- meet its obligations on security, breach notification, data protection impact assessments and prior consultation with authorities.
Because identity signals are stored as salted hashes, Tolla finds a person's data by the Customer's user id. The Customer can delete everything about one user at any time with DELETE /api/v1/users/{userId}, or ask Tolla by email, and can request an export of a user's data by email.
9. Personal data breaches
Tolla notifies the Customer without undue delay, and at the latest within 48 hours, after becoming aware of a breach of security affecting Customer Personal Data. The notice describes, as far as known, what happened, the data and people concerned, the likely consequences and the measures taken or proposed. Tolla then provides further information as it becomes available, so that the Customer can meet its own deadlines (72 hours under the GDPR, "as soon as possible" under the FADP).
10. Deletion at the end
When the contract ends, Tolla returns Customer Personal Data on request and deletes it within 30 days, unless the law requires it to be kept. Backups are overwritten in the normal rotation, at the latest within a further 30 days. During the contract the Customer can delete data at any time, and data is deleted according to the retention set in the workspace.
11. Information and audits
Tolla makes available all information needed to show compliance with this DPA and allows for and contributes to audits, including inspections, by the Customer or an auditor it appoints who is bound to confidentiality. Audits take place on 30 days' written notice, during business hours, at most once a year unless there has been a breach or an authority requires it, and at the Customer's cost. Tolla may first answer by providing documentation and written answers.
12. US state privacy laws
Where the California Consumer Privacy Act (CCPA) or a similar US state law applies, Tolla is the Customer's service provider or processor. It processes personal information only for the business purposes set out in the Terms and this DPA (providing the analyses described in Annex 1); does not sell or share it; does not retain, use or disclose it for any other purpose or outside the direct business relationship with the Customer; does not combine it with personal information from other sources except as the law allows; complies with the applicable law and gives the same level of protection it requires; and tells the Customer if it can no longer meet these obligations. The Customer may take reasonable and appropriate steps to check that Tolla uses the information as agreed, and to stop and remedy any unauthorised use.
13. Order of precedence
If this DPA conflicts with the Terms, this DPA prevails for the processing of Customer Personal Data. If the Standard Contractual Clauses apply, they prevail over both. The liability rules of the Terms apply to this DPA, as far as the law allows. This DPA is governed by the same law as the Terms, except where the Standard Contractual Clauses require otherwise.
Annex 1: Description of the processing
| Subject matter | Providing the Tolla service: analysing the costs, revenue and conversion of the Customer's free users, finding accounts that probably belong to the same person, and, for changes the Customer turns on, answering which free allowance applies to each user |
| Duration | For the term of the contract, plus the deletion period in section 10 |
| Nature of processing | Receiving, storing, hashing, combining, analysing, displaying and deleting data; reading Stripe data with a read-only key; for a change the Customer has turned on, answering the Customer's product, per user, what the rule the Customer approved says, and measuring the change against a control group |
| Purpose | Showing the Customer the economics of its free tier and likely duplicate accounts, so the Customer can decide how to design its free tier, and applying and measuring the free-tier changes the Customer approves |
| People concerned | The Customer's users and prospective users (people who sign up for or use the Customer's product), and the Customer's own staff who use Tolla |
| Types of personal data | User ids chosen by the Customer; sign-up date and source; plan; usage and cost of AI requests (model, tokens, cost, feature, time); product events the Customer chooses to send (for example "viewed pricing"); payments, subscriptions and refunds; identity signals stored only as salted hashes (email address, IP address and network, first-party device id, and, if the Customer turns them on, device fingerprint and automation signals); Stripe customer ids and card fingerprints (never card numbers); probabilistic links between accounts |
| Special categories | None. The Customer must not send them (Terms, section 5) |
| Retention | Identity session data as set in the workspace (30 to 730 days, 180 by default), deleted daily once older; the debugging event log for 30 days; other data for the term of the contract, or until the Customer deletes it |
Annex 2: Technical and organisational measures
- Encryption: all connections use TLS; the database is encrypted at rest; Stripe keys are encrypted with AES-256-GCM.
- Pseudonymisation: email addresses, IP addresses and device identifiers are hashed with a secret salt unique to each workspace before storage; the original values are not stored. The hashes remain personal data and are protected as such. Payment data is limited to card fingerprints.
- Separation: each workspace's data is separated by workspace id and checked on every request; automated tests verify that one workspace cannot read another's data.
- Access control: sign-in with a hashed password; workspace access only for members; secret API keys stored only as hashes, browser keys limited to allowed origins and to signed user ids; production access limited to the provider.
- Availability: hosting and a managed database in Frankfurt with the providers' redundancy and backups.
- Data minimisation: only the fields the service needs are accepted; the event log for debugging shows identity values masked.
- Deletion: retention enforced by a daily job; deletion of single users through the API; deletion on request and at the end of the contract (section 10).
- Supplier management: subprocessors are chosen for their security and bound by data processing agreements.
- Incident handling: breaches are assessed, documented (records kept for at least two years) and reported as set out in section 9.
Annex 3: Subprocessors
See the Subprocessors page, which is part of this DPA.