Tigby Data Processing Agreement (DPA)

Effective date: 2026-08-29

This Data Processing Agreement ("DPA") is part of the Tigby Terms of Service between neuraforce GmbH, Dora-Koch-Stetter-Weg 22, 18055 Rostock, Germany ("Processor", "Tigby") and the customer ("Controller"). It governs all processing of personal data contained in Customer Content under Art. 28 GDPR and is accepted at signup.

1. Subject matter, duration, nature and purpose

Subject matter / purpose: operation of the Tigby agent-identity service — hosting of agent mailboxes (send, receive, store), operation of Tunnels (transport of traffic to the customer's agent), Connectors to third-party platforms (Bluesky, Mastodon), the Vault (encrypted secret storage), and associated APIs, webhooks, and exports.
Duration: the term of the service contract (§10 applies at the end).
Nature of processing: storage, transmission, retrieval, spam/malware filtering, deletion; no use for Tigby's own purposes.

2. Data types and data-subject categories

Data types: email content and metadata; messages and profile data exchanged via Connectors; traffic transported through Tunnels; secrets and credentials stored in the Vault; webhook payloads.
Data-subject categories: the Controller's staff and agents' operators; third parties who communicate with the Controller's agents (email correspondents, social-platform users); persons whose data appears in Customer Content.

3. Documented instructions (Art. 28(3)(a))

Tigby processes Customer Content only on the Controller's documented instructions. The service configuration effected through the Tigby console, API, CLI, and SDKs constitutes those instructions. Tigby informs the Controller if, in its opinion, an instruction infringes the GDPR. If EU or member-state law requires processing beyond the instructions, Tigby informs the Controller before processing, unless that law prohibits it.

4. Confidentiality (Art. 28(3)(b))

Persons authorized to process Customer Content are bound to confidentiality (contractually and, as mail-service personnel, under § 3 TDDDG telecommunications secrecy).

5. Security (Art. 28(3)(c), Art. 32)

Tigby implements the technical and organizational measures described in Annex 1 (TOMs), including EU/EEA-only infrastructure, TLS in transit, encryption at rest, and application-layer envelope encryption for Vault secrets and OAuth tokens. The TOMs may be updated as the state of the art evolves, provided the security level does not fall below the level agreed here.

6. Sub-processors (Art. 28(2), (3)(d))

The Controller grants general authorization for the sub-processors listed at Sub-processors, all located in the EU/EEA. Tigby will announce intended additions or replacements at least 30 days in advance via the sub-processor page and email to account holders. The Controller may object on reasonable data-protection grounds within that period; if no resolution is found, the Controller may terminate the affected service. Tigby imposes the obligations of this DPA on every sub-processor by contract and remains fully liable for their performance.

7. Data-subject rights (Art. 28(3)(e))

Tigby assists the Controller with requests under Art. 12–23 GDPR through the service's built-in export (account data as JSON, mailboxes as mbox/EML + JSON) and deletion functions (account and per-Identity). Requests received directly from data subjects are forwarded to the Controller without undue delay and not answered on the merits by Tigby.

8. Breach notification and assistance (Art. 28(3)(f))

Tigby notifies the Controller without undue delay after becoming aware of a personal-data breach affecting Customer Content, with the information required by Art. 33(3) GDPR as it becomes available, and assists the Controller with its obligations under Art. 32–36 GDPR (security, breach notification, DPIA, prior consultation), taking the nature of the processing into account.

9. Audits (Art. 28(3)(h))

Tigby makes available all information necessary to demonstrate compliance with Art. 28 — primarily this DPA, the TOMs, and the Art. 30(2) record. Audits and inspections, including by a mandated third party, are permitted with reasonable prior notice (at least 14 days, at most once per year absent concrete cause), during business hours, without disrupting operations, and at the Controller's expense.

10. Deletion and return (Art. 28(3)(g))

At the end of the service contract — or earlier via the deletion functions — Tigby deletes all Customer Content within 30 days, unless EU or member-state law requires storage. The Controller may export Customer Content before deletion. Residual copies in encrypted backups expire automatically within 90 days and are not restored except for disaster recovery, in which case deleted data is re-deleted.

Two things survive an erasure by design and are not covered by those two periods. The Handle of an erased Identity stays reserved indefinitely, so that mail still addressed to a deleted agent cannot be delivered to a stranger. And one erasure record per erasure — Identity ids, Handles and timestamps, no addresses and no Customer Content — is kept indefinitely, because it is what a restored backup is re-deleted from. Neither is Customer Content; Tigby processes both as controller on Art. 6(1)(f) GDPR rather than on the Controller's instruction, as stated in the privacy policy.

11. International transfers

Tigby's own processing takes place exclusively in the EU/EEA. Tigby does not transfer Customer Content to third countries on its own account, and engages no sub-processors outside the EU/EEA. Any future change is subject to §6.

Transmissions the Controller instructs are a different matter and are not covered by that sentence. Where the Controller has Tigby post to or read from a connected platform (§1), carry traffic through a Tunnel to an endpoint the Controller operates, deliver an event to a webhook endpoint the Controller registers, or send mail to a recipient the Controller addresses, Tigby transmits Customer Content to a destination the Controller chose. Those destinations are independent third parties, not sub-processors of Tigby, and each of them may sit outside the EEA: a *.bsky.social account is served by a US company, a Mastodon instance is wherever its operator runs it, and a Tunnel or webhook endpoint is wherever the Controller runs it. Tigby applies no geographic restriction to them, because the Controller brings the account and the endpoint. Tigby is therefore not the transferring party for these transmissions; the Controller is, and the assessment under Chapter V GDPR for them is the Controller's own.

12. Miscellaneous

German law applies. In case of conflict between this DPA and the Terms of Service, this DPA prevails for data-protection matters. The German version (AVV) and this version are intended to be identical in substance.

Annex 1: Technical and Organizational Measures (TOMs)
Annex 2: Sub-processor list

Annex 1 – Technical and Organizational Measures (TOMs)

Art. 32 GDPR measures of neuraforce GmbH for the Tigby service.
Last reviewed: 2026-08-27.

1. Infrastructure and physical security

All processing on infrastructure in the EU/EEA operated by EU-owned providers: two dedicated servers (OVH, Limburg an der Lahn, Germany, ISO 27001-certified datacenters, separate buildings), a witness/monitoring VM (OVH, Limburg an der Lahn, Germany), backup storage (OVH, Germany) with a monthly encrypted copy at Scaleway (France).
Physical security, power, and network redundancy per the datacenter operator's certifications; no Tigby hardware outside these facilities.

2. Encryption

In transit: TLS for all external connections — web console, API, Tunnel endpoints, mail transport (STARTTLS/TLS; MTA-STS and TLS-RPT published), IMAP. Internal replication and node-interconnect traffic over a private network.
At rest: database and mail stores are encrypted with ZFS native encryption (AES-256-GCM) on the two dedicated nodes; the per-node key is sealed to that node's TPM 2.0 and released only on that machine, so an unattended reboot re-enters service without operator interaction. Swap is encrypted with a key regenerated at every boot; operational logs, which carry mail traffic data, reside on an encrypted dataset as well. This protects data on disks that leave the facility — returned, replaced, or disposed of; it does not protect a running machine, whose keys are necessarily in memory. Nor does it protect against a different operating system booted on the same machine: the key is bound to the TPM but not to a PCR policy, and Secure Boot is off, so the TPM releases it to whatever boots on that motherboard — the provider's rescue mode included. Control of the provider console is therefore part of the boundary of the seal, and is protected by the two-factor authentication required in §3. That is the price of a reboot that needs no operator, and it is stated here rather than left to be inferred. The witness/monitoring VM is not encrypted; what may reach it is bounded instead — no mailbox content, and traffic data only in the pseudonymized form described in §4.
Application layer: Vault secrets and Connector OAuth tokens are envelope-encrypted (AES-256-GCM, per-organization data keys wrapped by a host key held as a rootless-container secret); database access alone does not reveal them.
Backups: pgBackRest backups encrypted; the offsite monthly copy is encrypted before leaving the primary provider. The host key is escrowed offline (single sealed copy).

3. Access control

Administrative access restricted to named administrators (currently: the managing director) via SSH public-key authentication only; no password login; administrative access is logged.
Provider consoles (OVH, Scaleway, Mollie) protected with strong unique credentials and two-factor authentication.
Application access via API keys (admin- or identity-scoped), stored only as hashes, shown once at creation; console sessions are server-side with magic-link login.
One bounded exception to "only as hashes": an Identity's first API key and its mailbox password are held in the database in the clear from the moment provisioning mints them until the customer confirms receipt, and at most for a configured window (15 minutes at launch) after which a sweeper deletes them whether or not anyone confirmed. Nothing else is ever held in the clear, and neither value can be re-read once it is gone. Two calls bound that window and neither is the status resource: GET /api/identities/{handle}/identity-key hands the pair over, and POST /api/identities/{handle}/identity-key/ack is the confirmation of receipt that deletes them. The status resource a client polls while provisioning runs carries neither, so no credential reaches a caller that did not ask for one.
Services run as rootless containers under distinct unprivileged users; least privilege between components (the public tunnel listener runs outside the process that can decrypt the Vault).

4. Separation and pseudonymization

Logical tenant separation by organization ID at the application and database layer; per-organization encryption keys for secrets.
Two separate databases (application vs. mail store) in one cluster.
Operational logs reference internal IDs rather than content; mail content is never copied into logs.
The witness/monitoring VM holds cluster-quorum state, operational metrics referenced by internal ID, the log lines shipped from all three hosts (MTA lines included, retained 90 days) and application error reports. No mailbox content and no message bodies are stored on it, and no unredacted traffic data: mail addresses and client IP addresses are replaced by a salted HMAC on the sending host, before the line leaves it, so the collector never receives the value itself. The raw line stays on the sending host's encrypted dataset and is expired there after 30 days.
Log retention is therefore tiered at the redaction, not at "access" versus "security": unredacted log lines 30 days (the node journal, the only place an address is in the clear), redacted operational and security logs 90 days (the witness's stores). The short clock sits on the identifying data, which is the storage-limitation argument under Art. 5(1)(e); the reasoning is recorded in the architecture decision on the observation layer. ops/verify.sh asserts both numbers against what the machines are configured with.
That replacement is pseudonymization, not anonymization: the same value yields the same token, and the log store is therefore recorded as personal data in the Art. 30 records, not as anonymous operational data. It is a security measure under Art. 32(1)(a), and the measures that carry it are checked rather than promised — the infrastructure check asserts that the redaction key exists, is readable by root alone and is not exposed through the service environment, and a continuous-integration test runs the redaction rules against sample log lines including real MTA lines.

5. Integrity and availability

Two-node warm active-standby cluster with automatic failover (Patroni + witness quorum); synchronous database replication (RPO 0 in normal operation).
Point-in-time-recovery backups: WAL archiving, daily differential, weekly full; retention 30 days, offsite monthly copies retained 90 days; recurring documented restore tests.
Monitoring, alerting and external probing run on a third host that is not part of the failover pair (witness VM), so each node is observed from outside itself, and every host watches the others — a stalled alerting pipeline raises an alert of its own rather than reading as silence. All three machines are at the same location, so a site-wide outage is learned from the provider rather than from Tigby's own alerting; alerts are dispatched over paths that do not depend on the Tigby mail service. On-call: managing director.

Rate limiting and verification-coupled send limits against abuse; spam and malware filtering on inbound mail.

6. Data-protection procedures

Deletion concept: self-serve deletion (account and per-Identity) purges live data within 30 days; backup copies expire within 90 days; documented in the privacy policy and DPA.
Export: self-serve account (JSON) and mailbox (mbox/EML + JSON) export.
Breach response per the incident runbook (Art. 33: 72 hours to the authority; processor notice to customers without undue delay).
Records of processing maintained per Art. 30 (ropa).
Sub-processors bound by Art. 28 contracts; list published with 30-day change notice.
Personnel (future hires) bound to confidentiality and § 3 TDDDG telecommunications secrecy before access; onboarding/offboarding checklist with access revocation.
Software supply chain: dependencies pinned; deployments from version-controlled configuration via manual, logged CI scripts over SSH.

7. Review

These measures are reviewed at least annually and on every significant architecture change; the DPA permits evolution that does not lower the security level.