Data Processing Addendum

Effective: 1 October 2026

This Data Processing Addendum ("DPA") is part of the Terms of Service between the Customer ("Controller") and UHRIK - IT & Event s. r. o., Bajzova 2417/13, 010 01 Žilina, Slovakia ("Processor", "Tandly"). It applies whenever Tandly processes personal data in Customer Data on the Customer's behalf through Tandly Cloud, and meets the requirements of Article 28 of the EU General Data Protection Regulation 2016/679 ("GDPR") and the UK GDPR. It does not apply to self-hosted editions.

The DPA applies automatically when you accept the Terms. If you need a countersigned copy, write to [email protected].

1. Definitions

Terms such as personal data, processing, controller, processor, data subject and personal data breach have the meaning given in the GDPR. "Customer Data" has the meaning given in the Terms. "Subprocessor" means a third party we engage to process Customer personal data.

2. Roles and instructions

1. The Customer is the controller (or a processor acting for its own controllers). Tandly is the processor.
2. We process Customer personal data only on the Customer's documented instructions. These are the Terms, this DPA, and the settings and actions that the Customer's owners and administrators choose in the service. The only exception is processing required by EU or Member State law. In that case we inform the Customer before processing, unless the law forbids it.
3. We tell the Customer promptly if we believe an instruction infringes data protection law.
4. The Customer is responsible for the lawfulness of the processing it instructs, including having a legal basis for the data that Users post and that directory sync imports, and for informing its Users.
5. This DPA covers everything inside the Customer's workspaces. It does not cover the personal data for which Tandly is itself the controller, as listed in section 1 of our Privacy Policy: our website and status page, the beta waiting list, billing and the customer relationship, support correspondence, security records that protect the service as a whole, the audit log of our own staff, and the service e-mails we send about our own service.

3. Details of the processing

The subject matter, duration, nature and purpose of the processing, and the types of personal data and categories of data subjects, are described in Annex 1.

4. Our obligations

1. Confidentiality. Everyone we authorise to process Customer personal data is bound by confidentiality, and only staff who need it have access.
2. Security. We implement the technical and organisational measures in Annex 2, appropriate to the risk under Article 32 GDPR. We may improve them over time, but will not reduce the overall level of protection.
3. Support access. Staff access Customer Data only to provide support that the Customer requested, to keep the service secure and working, or as required by law. They work through an operator console, not directly in the database, except when operating or restoring the service or handling an incident. Every action, whether it reads or changes something (for example viewing a workspace or a member's account, editing a profile, ending sessions, unlocking an account or changing the plan), needs a written reason and is recorded with the staff member and the reason in our operator audit log. A reason given for viewing a workspace or an account covers that staff member's views of it for 30 minutes, and each such period is recorded once. Only finding a workspace or person in the console's lists and search (names and e-mail addresses) needs no reason. Every change and every such viewing is also shown to the Customer's administrators in the Support access log, as an action by "Tandly Support" with what was done and when; that log shows neither the individual staff member nor the reason, and we tell the Customer both on request. The console gives no access to the content of messages or files.
4. Assistance with data subject requests. Taking into account the nature of the processing, we help the Customer respond to requests from data subjects. The service gives the Customer tools to do this itself: editing and deactivating accounts, deleting messages and files, account deletion by the User, read-confirmation and audit exports, and, on plans that include it, workspace data export. For anything the tools don't cover, such as a copy of one person's data or a full export on another plan, we assist on request, in a machine-readable format (JSON). If a data subject contacts us directly about Customer Data, we forward the request to the Customer without responding ourselves, unless the Customer authorises us to.
5. Other assistance. We help the Customer meet its obligations under Articles 32 to 36 GDPR (security, breach notification, data protection impact assessments and prior consultation), taking into account the information available to us.

5. Personal data breaches

We notify the Customer without undue delay, and in any case within 48 hours, after becoming aware of a personal data breach affecting Customer personal data. We notify the e-mail addresses of all owners of each affected workspace. As far as we know them at the time, the notice describes the nature of the breach, the categories and approximate number of data subjects and records affected, the likely consequences, and the measures taken or proposed. We add further information as it becomes available. Notifying the Customer is not an admission of fault.

6. Subprocessors

1. The Customer gives general authorisation for us to engage Subprocessors. The current list is on our subprocessors page.
2. We announce new or replacement Subprocessors on that page, and by e-mail to workspace owners who have subscribed to updates, at least 30 days before they start processing Customer personal data.
3. The Customer may object on reasonable data protection grounds within that period. We will then discuss it in good faith. If we can't resolve the objection, the Customer may terminate the affected service and receive a refund of prepaid fees for the remaining period.
4. We impose data protection obligations on each Subprocessor that are no less protective than this DPA, and we remain responsible for their performance.

7. International transfers

Customer personal data is stored in the European Union: Germany, the Netherlands and Belgium (see the subprocessors page). Traffic to and from the service passes through Cloudflare's network, which may handle it in a data centre outside the EU/EEA while it is in transit. Push notifications and e-mails are delivered by providers in the United States. We transfer Customer personal data outside the EU/EEA only if the transfer is covered by Chapter V GDPR: an adequacy decision (including the EU–US Data Privacy Framework for certified recipients) or the Standard Contractual Clauses adopted by Commission Implementing Decision (EU) 2021/914. Where we rely on the Standard Contractual Clauses with a Subprocessor, we use Module 3 (processor to processor), and we carry out transfer impact assessments.

For personal data subject to the UK GDPR, transfers are covered by the UK Information Commissioner's International Data Transfer Addendum to the EU Standard Contractual Clauses. For personal data subject to the Swiss Federal Act on Data Protection (FADP), the Standard Contractual Clauses apply with the adaptations the Swiss Federal Data Protection and Information Commissioner requires: references to the GDPR include the FADP, and the Swiss Commissioner is a competent supervisory authority.

8. Deletion and return

1. The Customer can delete Customer Data at any time using the service.
2. When the agreement ends, the Customer can retrieve Customer Data during the data retrieval period of at least 30 days described in the Terms, and we return it as described there. After that period, and within a further 30 days, we delete Customer personal data from the live systems. Backups are deleted within 14 days after that. The only exception is data we must keep by law, which we continue to protect under this DPA.
3. When a workspace is deleted, it can be restored for up to 30 days and is then erased. The accounts of people who belonged to no other workspace are anonymised at the same time, as if they had deleted their accounts themselves.
4. On request, we confirm the deletion in writing.

9. Audits

1. We make available the information needed to demonstrate compliance with Article 28 GDPR, including this DPA, the description of our security measures and, where available, third-party audit reports or certifications.
2. If that information is not sufficient, or a supervisory authority requires it, the Customer (or an independent auditor bound by confidentiality) may carry out an audit, no more than once a year, with at least 30 days' notice, during business hours and without disrupting other customers. Each party bears its own costs, unless the audit reveals a material breach by us.

10. Liability and precedence

The liability provisions of the Terms apply to this DPA, except where the GDPR provides otherwise. If this DPA conflicts with the Terms, this DPA prevails regarding the processing of personal data. If the Standard Contractual Clauses apply, they prevail over both.

Annex 1: Details of the processing

Annex 2: Technical and organisational measures

Encryption and transport

• All connections to the service use TLS (HTTPS with HSTS). Unencrypted HTTP is redirected to HTTPS.
• Databases and caches are reachable only on a private network (on Google Cloud: Cloud SQL with a private address only and TLS required, and Memorystore). File storage accepts only requests signed by the application; download links expire after 5 minutes. Public traffic reaches the service only through the TLS proxy: Cloudflare, in front of Google's load balancer, which accepts traffic from Cloudflare only; and, on the server we are migrating away from, a Caddy proxy.
• Encryption at rest: Secrets we must be able to read back — two-factor seeds, connected-app tokens, directory-sync service account keys, SAML signing keys and the signing secrets of slash commands and automation webhooks — are additionally encrypted with AES-256-GCM before they are written, under a key kept in the server's secret configuration, never in the database. Messages and uploaded files are not separately encrypted by the application. On Google Cloud and Cloudflare R2 they are encrypted at rest by the provider's standard storage encryption; on our netcup servers they are not, and are protected by the provider's physical security and the access controls described in this annex. We will say so here when that changes.

Access control for Users

• Sign-in through Google (OpenID Connect), Sign in with Apple, SAML single sign-on against the Customer's own identity provider, or e-mail and password. Passwords are stored only as argon2id hashes, never in a form anybody here can read. Two-factor authentication (TOTP, with recovery codes) is available, and a workspace can require it for every e-mail-and-password sign-in; Google, Apple and single sign-on sign-ins rely on that provider's own second factor.
• New sign-ins from an unknown browser or device are announced to the User by e-mail. Five failed password sign-ins from one IP address block further attempts for that account from that address for 15 minutes.
• Server-side sessions: random tokens stored only as SHA-256 hashes, in HttpOnly, Secure, SameSite cookies, expiring after at most 30 days. Users can see their sessions and sign out of any of them. Deactivation ends all sessions.
• Every state-changing request needs an anti-CSRF header. WebSocket connections check their origin.
• Role-based permissions (owner, admin, member) and checks on every channel. Private channels and direct messages are visible only to their members.
• Files are delivered only after an access check, through signed links that expire after 5 minutes.

Access control for our staff

• A dedicated operator console with role-based staff permissions (viewer, support, billing, admin), a staff e-mail domain allowlist and optional IP allowlisting.
• Looking at a workspace or a person's account, and every change, requires a written reason, is rate-limited and is recorded in the operator audit log. A reason for looking is valid for 30 minutes, for that staff member and that workspace or account only. Finding a workspace or person in the console's lists and search (names and e-mail addresses) needs no reason; opening one does.
• Support actions are shown to the Customer's administrators in the Support access log. The console has no view of message or file content.
• Least-privilege access to servers, with personal accounts and SSH keys. Access is removed when staff leave.

Application security

• Link previews, preview images, external profile pictures and outgoing integration calls are fetched by our servers, which block private, loopback and link-local addresses (SSRF protection). Users' browsers don't contact those sites just to show a preview or a picture.
• Webhooks and the bot API are rate-limited. Tokens and signing secrets are shown only once. Tokens are stored only as hashes; the signing secrets we must read back to sign outgoing requests (slash commands, automation webhooks) are stored encrypted.
• Uploaded files are private by default. Image files are verified before others can see them.
• Secret guard warns before credentials are posted in messages.
• Dependencies are kept up to date, and code changes go through automated tests.

Availability and resilience

• Automatic restart of services and health checks.
• Daily database backups, kept for 14 days and then deleted, stored apart from the production database: on Google Cloud in Google's EU multi-region, with point-in-time recovery for up to 14 days; on the server we are migrating away from, together with the uploaded files, with a copy outside that server that is deleted on the same schedule.
• On the server we are migrating away from, also a database backup before every upgrade, deleted on the same schedule.
• We test restoring a backup at least once a quarter.

Organisation

• Confidentiality obligations for everyone with access to personal data, and data protection training.
• A written incident response procedure, with breach notification as set out in section 5 and a register of breaches.
• Records of processing activities, and review of these measures at least once a year.

Annex 3: Subprocessors

See the current list on the subprocessors page.