1. Subject matter and duration
This agreement governs Tindorah's processing of personal data on the customer's behalf while providing the Tindorah authentication and account services described in the underlying service agreement. It supplements that agreement and does not replace it.
It applies for as long as the underlying service agreement is in force, and continues to bind the processor for any personal data retained after termination, under clause 6(g), until that data is deleted or returned.
2. Nature and purpose of processing
The processor authenticates the customer's users, issues and rotates access and refresh tokens, stores account and workspace records, and operates the security controls — multi-factor authentication, password recovery, session and security logging — needed to run those services.
Processing is carried out by automated means, on the processor's own infrastructure, strictly to deliver the services the customer has configured — never for the processor's own separate purposes.
3. Type of personal data
Names, email addresses, phone numbers where provided, login identifiers, authentication secrets and their hashes, multi-factor authentication enrolment data, IP addresses and user-agent strings captured for security logging, and any workspace or account metadata the customer's users enter.
The processor does not require special categories of data under Art. 9 GDPR to provide the service, and the customer should not submit any through fields not designed to hold them.
4. Categories of data subjects
The customer's employees, contractors, and any other individuals the customer registers as users of its workspace, plus prospective users the customer invites.
The processor does not itself determine who these individuals are — that is the customer's decision, exercised each time it invites, provisions, or removes a user.
5. Rights and obligations of the controller
The customer instructs the processor solely through its configuration of the services and through this agreement; any additional instruction must be given in writing and is not binding until the processor has confirmed it can be carried out within the services as built.
The customer remains responsible for the lawfulness of the personal data it submits, for the legal basis it relies on toward its own users, and for responding to data subject requests it has not delegated to the processor under clause 6(e).
6. Obligations of the processor. Under Art. 28(3) GDPR, the processor:
- (a) Documented instructions. Processes personal data only on the customer's documented instructions, including with regard to transfers to a third country, unless required to do otherwise by a law to which the processor is subject — in which case the processor informs the customer of that legal requirement before processing, unless the law prohibits this on important grounds of public interest.
- (b) Confidentiality. Ensures that persons authorised to process the personal data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality.
- (c) Security of processing. Implements the technical and organisational measures required by Art. 32 GDPR, described in Annex 2, and reviews them as the service and its risk profile change.
- (d) Sub-processors. Engages another processor only under the general written authorisation set out in clause 7, imposes the same data protection obligations on that sub-processor by way of a contract, and remains fully liable to the customer for the sub-processor's performance.
- (e) Assistance with data subject rights. Assists the customer, by appropriate technical and organisational measures, in fulfilling its obligation to respond to requests to exercise a data subject's rights under Chapter III GDPR, taking into account the nature of the processing.
- (f) Assistance with Articles 32 to 36. Assists the customer in ensuring compliance with its obligations under Art. 32 to 36 GDPR — security of processing, breach notification, and data protection impact assessments — taking into account the nature of processing and the information available to the processor.
- (g) Deletion or return of data. At the customer's choice, deletes or returns all personal data to the customer after the end of the provision of services, and deletes existing copies unless German or Union law requires storage of the personal data.
- (h) Audits and information. Makes available to the customer all information necessary to demonstrate compliance with the obligations in Art. 28 GDPR, and allows for and contributes to audits, including inspections, conducted by the customer or an auditor mandated by the customer, subject to reasonable notice and confidentiality.
8. Liability
Each party is liable for damage caused by its own processing that infringes the GDPR, in line with Art. 82 GDPR. Nothing in this agreement limits liability for infringement of the GDPR itself.
A party's liability toward the other under this agreement is otherwise governed by the underlying service agreement.
9. Governing law and language
This agreement is governed by the law of the Federal Republic of Germany.
It is issued in German and English. Where the two versions conflict for a customer domiciled in Germany, the German version governs.
Annex 1 — Sub-processors
The sub-processors currently authorised under clause 7 are the ones published in the sub-processor register below — the same register, not a copy of it, so the two can never drift apart.
| Sub-processor | Purpose | Data categories | Processing location |
|---|---|---|---|
| Hetzner Online GmbH | Infrastructure hosting for every application and database workload | All personal data the platform stores or processes | Nuremberg, Germany (EU) |
| Cloudflare, Inc. | DNS, and the DNS-01 challenge used to issue Let's Encrypt certificates | None — DNS resolution only, no application data | Global anycast network (Standard Contractual Clauses) |
| Google LLC (Google Calendar API) | Creates and manages calendar events and video-call links for demo bookings | Name and email address of the person booking a demo | United States (Standard Contractual Clauses) |
Annex 2 — Technical and organisational measures
Art. 32 GDPR asks what is actually implemented. The measures below are the technical and organisational measures in place for the processing described in this agreement. They are updated as the controls change; a measure stated here that stops matching what the platform runs is a defect in this document, not a description of the platform.
- Encryption in transit
- All traffic to Tindorah services is served over TLS, terminated at the edge with certificates issued by Let's Encrypt.
- Authentication and access control
- Every account requires a hashed, salted password. Refresh tokens rotate on use, detect reuse, and expire on a bounded family lifetime. Every authentication and token endpoint is rate-limited.
- Multi-factor authentication
- Multi-factor authentication is available, using one-time codes delivered by email.
- Federated authentication (SSO)
- Enterprise single sign-on over OIDC is available and is configured per client application: a customer can delegate authentication to its own identity provider, with just-in-time user provisioning disabled unless the customer enables it, and an optional policy that refuses password sign-in on every credential path once federation is enforced. A federated sign-in does not exempt a user from the customer's multi-factor policy — that control still applies after the identity provider has authenticated them.
- Token signing and key management
- Access and refresh tokens are signed with an asymmetric key pair. The signing key is never shared with client applications, which verify tokens against the public key only.
- Backups
- The database is backed up regularly.
- Administrative action attribution
- Administrative actions across the platform's admin surfaces are attributed to the individual who performed them.