Data Processing Agreement
Last updated: April 2026
Need a countersignable copy?
This DPA is pre-signed by TheChatApp. Contact us to receive a PDF version for countersignature.
Request DPA CopyParties
Processor: TheChatApp, a company incorporated in Portugal. Data protection contact: privacy@thechatapp.chat.
Controller: The entity identified in the countersignature block at the end of this Agreement, or, where this DPA is incorporated by reference into a service agreement, the contracting entity named in that agreement.
Recitals
- A. The Controller has engaged the Processor to provide the TheChatApp enterprise communication platform and related services pursuant to a service agreement (the Service Agreement).
- B. In the course of providing those services the Processor will process Personal Data on behalf of the Controller, making the Processor a processor within the meaning of Article 4(8) GDPR and the Controller a controller within the meaning of Article 4(7) GDPR.
- C. Article 28(3) GDPR requires that processing by a processor be governed by a binding contract setting out the subject matter, duration, nature and purpose of the processing, the type of Personal Data and categories of Data Subjects, and the obligations and rights of the Controller. This Data Processing Agreement constitutes that contract.
- D. End-to-end encryption is a central architectural feature of the Platform. In the default cloud deployment model (Mode 2 — TenantControlled) the Processor holds no keys capable of decrypting message content, file content, meeting recordings, or AI-generated embeddings. The cryptographic characteristics of each deployment model are set out in Part II and Part III.
- E. This DPA is pre-signed by the Processor and is made available to all enterprise customers. The Controller may obtain a countersignable PDF version by contacting privacy@thechatapp.chat. Where the Controller electronically accepts the Service Agreement, this DPA is incorporated by reference and takes effect on the same date.
Definitions
In this Agreement, unless the context otherwise requires, the following terms have the meanings given below. Capitalised terms not defined here have the meanings given in the Service Agreement.
- GDPR means Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data, as implemented in Portuguese law by Lei n.º 58/2019 of 8 August 2019, and as amended or replaced from time to time.
- Personal Data has the meaning given in Article 4(1) GDPR.
- Processing has the meaning given in Article 4(2) GDPR.
- Data Subject has the meaning given in Article 4(1) GDPR.
- Sub-Processor means any processor engaged by the Processor who processes Personal Data in connection with the Services.
- SCCs means the Standard Contractual Clauses for the transfer of personal data to third countries adopted by the European Commission Decision 2021/914/EU of 4 June 2021.
- UK Addendum means the International Data Transfer Addendum to the European Commission's Standard Contractual Clauses issued by the UK Information Commissioner's Office under s.119A(1) of the Data Protection Act 2018.
- Supervisory Authority means the Comissão Nacional de Proteção de Dados (CNPD), the competent supervisory authority in Portugal.
- Mode 2 (TenantControlled) means the default cloud deployment model in which the tenant vault is sealed at rest, the Processor holds no plaintext decryption keys, and encrypted content is inaccessible to the Processor as further described in Section 12.
- Mode 1 (ServerManaged) means the legacy cloud deployment model in which the tenant vault key is wrapped on disk within the server container, giving the Processor a theoretical multi-step access path to encrypted content as further described in Section 13.
- E2E Encrypted Data means Personal Data that has been encrypted using end-to-end encryption before transmission and that can only be decrypted by intended recipients holding the relevant cryptographic keys.
- CHEF Format means the TheChatApp Hybrid Encrypted File format, a proprietary chunked file encryption format using AES-256-GCM with a per-file random key wrapped in the tenant vault key, used for all files stored on the Platform.
- Platform means the TheChatApp enterprise communication software and associated cloud infrastructure operated by the Processor.
- Security Incident means any confirmed or reasonably suspected accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Personal Data transmitted, stored or otherwise processed.
- Business Day means a day other than a Saturday, Sunday or public holiday in Portugal.
Part I — Article 28(3) Obligations
Section 1 — Subject Matter and Duration
1.1 The Processor shall process Personal Data on behalf of the Controller for the purpose of providing the Platform and related support services as described in Annex I to this Agreement and in any applicable order form or statement of work.
1.2 The processing shall commence on the effective date of the Service Agreement and shall continue for its duration, subject to early termination in accordance with Section 9.
1.3 The nature, purpose, subject matter, categories of Personal Data and categories of Data Subjects are as set out in Annex I.
Section 2 — Processing on Documented Instructions
2.1 The Processor shall process Personal Data only on documented instructions from the Controller, including with regard to transfers of Personal Data to a third country or an international organisation, unless required to do so by Union or Member State law to which the Processor is subject. In such a case, the Processor shall inform the Controller of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest.
2.2 The Service Agreement, any applicable order forms, statements of work, and the configuration settings made available to the Controller through the Platform administration interface constitute the Controller's documented instructions for the purposes of this Section.
2.3 If, in the Processor's reasonable opinion, an instruction from the Controller infringes the GDPR or other applicable Union or Member State data protection provisions, the Processor shall promptly inform the Controller of that view. The Processor may suspend processing pending clarification of the instruction but shall not be in breach of this Agreement by so doing.
2.4 The Processor shall promptly notify the Controller if it receives any request, demand, or order from a public authority seeking access to, disclosure of, or action in respect of Personal Data processed under this Agreement, to the extent permitted by applicable law.
Section 3 — Confidentiality
3.1 The Processor shall ensure that persons authorised to process Personal Data under this Agreement are subject to a statutory or contractual duty of confidentiality with respect to that Personal Data.
3.2 Authorised persons include employees, contractors, and sub-processors who access Personal Data in the course of providing the Services. Access is limited to those who need it to perform their functions.
3.3 The Processor acknowledges that under Lei n.º 58/2019, Articles 46 and 47, unlawful disclosure of personal data constitutes a criminal offence in Portugal, and that such obligations apply to its personnel independently of this Agreement.
3.4 The confidentiality obligations in this Section shall survive termination of this Agreement for a period of five years, except in respect of trade secrets or information subject to a longer statutory protection period.
Section 4 — Security
4.1 Taking into account the state of the art, the costs of implementation, and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the Processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, as required by Article 32 GDPR.
4.2 Those measures include, at minimum, the following:
- (a) End-to-end encryption of content: Messages, files, meeting recordings, AI-generated embeddings, and polls are encrypted using AES-256-GCM with per-object random keys. File objects additionally use the CHEF chunked format. Transport encryption uses ChaCha20-Poly1305 with ECDH key exchange.
- (b) Tenant isolation: Each cloud tenant runs in a dedicated Docker container with per-tenant LiteDB databases, vault keys, and storage volumes. Network segmentation prevents cross-tenant data flows at the infrastructure layer.
- (c) Pseudonymized operational logs: Server logs replace usernames and email addresses with HMAC-SHA256 pseudonyms keyed by a per-tenant secret, such that individual users cannot be identified from log data without access to the pseudonymization key.
- (d) Sanitized push notification payloads: Push notifications delivered via third-party gateways (FCM, APNs) contain only minimal routing metadata and do not include message content, sender identity, or channel names.
- (e) HMAC-based audit integrity: All audit log entries are chained using HMAC-SHA256 to detect tampering. The integrity chain survives configurable retention pruning via a retention boundary hash stored in the audit chain state record.
- (f) Password hashing: User passwords are hashed using Argon2id with per-user random salts prior to storage. Plaintext passwords are never persisted.
- (g) Rate limiting and replay protection: Authentication endpoints are rate-limited. Network messages include monotonic timestamps and nonce values to prevent replay attacks.
- (h) Configurable data retention: The Controller may configure retention periods for messages, files, and audit logs through the Platform administration interface. Data is deleted in accordance with the configured retention schedule.
4.3 A summary of current technical and organisational measures is set out in Annex II. The full TOM documentation is available to the Controller on request and will be provided within ten Business Days of a written request.
4.4 The Processor may update the measures in Annex II from time to time provided that the overall level of security is not materially reduced. The Processor shall notify the Controller of any material reduction in security measures at least 30 days in advance.
Section 5 — Sub-Processors
5.1 The Controller grants the Processor general written authorisation to engage Sub-Processors, subject to the conditions in this Section. The current list of Sub-Processors is maintained at thechatapp.chat/subprocessors and in Annex III to this Agreement.
5.2 The Processor shall notify the Controller of any intended changes to the Sub-Processor list (additions or replacements) at least 30 Business Days before the change takes effect, by updating the Sub-Processor list and, where the Controller has subscribed to notifications, by direct notice.
5.3 The Controller may object to a new or replacement Sub-Processor by written notice to the Processor within 30 Business Days of notification. If the parties cannot resolve the objection within a further 30 Business Days, either party may terminate the affected services on 30 days written notice, without penalty to either party.
5.4 Where the Processor engages a Sub-Processor, it shall impose data protection obligations on that Sub-Processor equivalent to those set out in this Agreement, by way of a written contract. Where a Sub-Processor fails to fulfil its data protection obligations, the Processor shall remain fully liable to the Controller for the performance of the Sub-Processor's obligations.
5.5 Self-hosted push gateway exception: In the self-hosted deployment model, the Controller operates its own push notification gateway and the Processor has no involvement in the delivery of push notifications. Sections 5.1–5.4 do not apply to third-party services selected and operated exclusively by the Controller.
Section 6 — Assistance with Data Subject Rights
6.1 Taking into account the nature of the processing, the Processor shall assist the Controller by appropriate technical and organisational measures, insofar as this is possible, for the fulfilment of the Controller's obligations to respond to requests for exercising Data Subject rights under Chapter III GDPR (Articles 15–22), including rights of access, rectification, erasure, restriction, portability and objection.
6.2 The Platform provides the following built-in tools to assist the Controller:
- (a) Per-user data export: The administration interface enables the Controller to generate a structured export of all Personal Data held for a specific user, including messages, files, channel memberships, and audit entries, in a machine-readable format. The export includes a
data-processing-info.jsonmanifest describing data categories, purposes, legal bases, and retention periods. - (b) Per-user data deletion: The administration interface enables the Controller to delete all Personal Data associated with a specific user account, including anonymization of audit log entries attributable to that user.
- (c) Full account deletion: The Controller may initiate full tenant deletion through the administration interface or by written request to the Processor, resulting in deletion of all tenant data as described in Section 9.
6.3 The Processor shall, upon request and within five Business Days, provide the Controller with written information about the categories of Personal Data processed, the purposes of processing, and any Sub-Processors involved, to assist the Controller in responding to a Data Subject's right-of-access request.
Section 7 — Breach Notification
7.1 The Processor shall notify the Controller without undue delay and, where feasible, within 48 hours of becoming aware of a Security Incident, in accordance with Article 33 GDPR.
7.2 The notification shall, at minimum, include the following information to the extent it is available at the time of notification:
- (a) A description of the nature of the Security Incident, including where possible the categories and approximate number of Data Subjects concerned and the categories and approximate number of personal data records concerned;
- (b) The name and contact details of the Processor's data protection contact point;
- (c) A description of the likely consequences of the Security Incident; and
- (d) A description of the measures taken or proposed to be taken by the Processor to address the Security Incident, including, where appropriate, measures to mitigate its possible adverse effects.
7.3 Where the Security Incident involves only E2E Encrypted Data processed under Mode 2, the Processor shall include in its notification a technical assessment as to whether the incident falls within the exemption in Article 34(3)(a) GDPR, namely that the personal data are unintelligible to any person who is not authorised to access them, citing the specific technical measures (AES-256-GCM content encryption, CHEF file format, sealed vault) that render the data inaccessible.
7.4 The Processor shall cooperate with and assist the Controller in connection with any data protection impact assessment (DPIA) under Article 35 GDPR or prior consultation under Article 36 GDPR that the Controller is required to carry out in relation to the processing activities under this Agreement.
Section 8 — International Transfers
8.1 Where the Processor transfers Personal Data to Sub-Processors located outside the European Economic Area, it shall ensure that such transfers are made only in accordance with Chapter V GDPR. The transfer mechanisms in use are:
- (a) EU-US Data Privacy Framework (DPF): Transfers to Google LLC (Firebase Cloud Messaging, Google Calendar API) and Microsoft Corporation (Microsoft Graph / Calendar API) are made on the basis of those entities' certification under the EU-US Data Privacy Framework adopted by European Commission Decision 2023/1795.
- (b) APEC CBPR: Transfers to Apple Inc. (Apple Push Notification Service) are made on the basis of Apple's certification under the APEC Cross-Border Privacy Rules system, which the European Commission has recognised as providing an adequate level of protection for the purposes of the SCCs supplementary safeguards assessment.
- (c) Intra-EEA: Primary server infrastructure is hosted with Hetzner Online GmbH in Germany. No personal data transfer outside the EEA occurs in connection with server hosting.
- (d) Standard Contractual Clauses: To the extent that DPF certification or CBPR certification is unavailable, revoked, or held invalid, transfers are covered by the SCCs (Module 2 — Controller to Processor; Module 3 — Processor to Processor) as referenced in Exhibit A.
8.2 In Mode 2, the end-to-end encryption described in Part III constitutes an effective supplementary measure within the meaning of EDPB Recommendations 01/2020 on measures that supplement transfer tools, such that even if a Sub-Processor is compelled to disclose data by a third-country authority, the data disclosed is cryptographically unintelligible.
8.3 This Agreement is governed by Portuguese law. For transfers subject to the SCCs, the governing law of the SCCs is the law of Portugal (an EU Member State), and the competent courts are the courts of Lisbon.
8.4 For transfers to the United Kingdom or involving UK Data Subjects, the UK Addendum (IDTA) is incorporated by reference in accordance with Exhibit A.
Section 9 — Data Return and Deletion
9.1 On termination or expiry of the Service Agreement for any reason, the Processor shall, at the Controller's choice, either return or delete all Personal Data processed under this Agreement, subject to the following:
- (a) Return window: The Controller may request an export of all tenant data within 30 days after the effective date of termination. The Processor shall make the export available within ten Business Days of a valid request.
- (b) Deletion timeline: Unless a return request is outstanding, the Processor shall securely delete all tenant Personal Data within 30 days after the end of the return window or, if no return window applies, within 30 days after termination.
- (c) Scope of deletion: Deletion covers the tenant server container and its volumes (including LiteDB databases, vault keys, and file storage), off-site encrypted backups attributable to the tenant, and all Portal and gateway records identifying or linked to the tenant, except as provided in sub-paragraph (d).
- (d) Billing records retention: Financial records, including invoices, payment history, and licence keys, are retained for ten years as required by Portuguese tax law (Código do IVA, Article 52; Lei Geral Tributária, Article 45), after which they are securely deleted. These records contain only company name, billing address, and masked payment information and do not include message content or user communications.
- (e) Secure deletion methods: Deletion of data at rest is performed by cryptographic erasure (deletion of encryption keys) where technically feasible, and by secure overwrite otherwise. Backup deletion is performed by deleting the encrypted backup object and its associated key material.
9.2 On completion of deletion, the Processor shall provide the Controller with written confirmation that the deletion has been carried out in accordance with this Section within five Business Days of completion.
9.3 Where a Controller exercises termination rights during a minimum contract term, a cooling-off period and/or an early termination fee may apply as set out in the Service Agreement. Exercise of those rights does not alter the Processor's obligations under this Section.
Section 10 — Audit Rights
10.1 The Processor shall make available to the Controller all information necessary to demonstrate compliance with Article 28 GDPR and shall allow for and contribute to audits, including inspections, conducted by the Controller or an auditor mandated by the Controller.
10.2 Any audit must be preceded by at least 30 days' written notice, carried out during normal business hours, conducted in a manner that minimises disruption to the Processor's operations, and limited to information and systems relevant to the processing activities covered by this Agreement.
10.3 The Controller shall bear all costs associated with the audit unless the audit reveals a material breach of this Agreement by the Processor, in which case the Processor shall bear the reasonable costs of the audit.
10.4 The Processor shall, on written request and within ten Business Days, provide the Controller with copies of or access to: the current Sub-Processor list; the current TOM summary (Annex II); any relevant third-party security certifications or audit reports held; and documentation of the data deletion process described in Section 9.
10.5 Where a mandated auditor is a competitor of the Processor, the Processor reserves the right to require that the auditor execute a non-disclosure agreement before commencing the audit. The Processor shall not unreasonably withhold consent to an auditor.
Part II — Deployment Models
Section 11 — Self-Hosted Deployment
11.1 In the self-hosted deployment model, the Controller installs and operates the Platform software on infrastructure under its own control. The Processor provides software licences and support services but does not operate any infrastructure that processes tenant Personal Data.
11.2 In this model, the Controller is both the data controller and the data processor with respect to all Personal Data processed by the Platform. This Agreement does not govern the processing of tenant Personal Data in the self-hosted model; instead, the Controller bears full responsibility for compliance with GDPR and applicable law in connection with its operation of the Platform.
11.3 Push notification gateway exception: Where the self-hosted Controller uses the Processor's optional push notification relay service, the Processor processes only the minimal push routing token and a notification counter increment required to forward the push notification. No message content, sender identity, or channel information is transmitted to or through the relay service. The Controller acknowledges that by using this optional service it is engaging the Processor as a sub-processor for the limited purpose described in this paragraph, and the relevant provisions of Part I apply to that limited processing only.
Section 12 — Cloud Mode 2 (TenantControlled)
12.1 Mode 2 is the default deployment model for cloud-hosted tenants. In this model, the tenant vault key is sealed at rest using a mechanism that requires the Controller's master passphrase or hardware token to unseal. The Processor does not hold, escrow, or have access to the unsealed vault key.
12.2 In Mode 2, the Processor cannot access the following categories of Personal Data without the Controller's vault key:
- Message content (all channels, including direct messages and meeting chats)
- Uploaded file content (stored in CHEF format, encrypted with per-file keys wrapped in the vault key)
- Meeting recordings and transcripts
- AI-generated message embeddings and search indexes
- Poll questions and responses
- Reactions associated with encrypted messages
12.3 In Mode 2, the Processor can access the following categories of Personal Data:
- Account identifiers (user IDs, usernames, email addresses, display names)
- Authentication data (Argon2id password hashes, public keys)
- Operational metadata (IP addresses, device identifiers, login timestamps)
- HMAC audit chain entries (pseudonymized, recording action type, timestamp, and pseudonymized user reference)
- Channel and role configuration (channel names, membership lists, permission assignments)
- Billing and licence data
12.4 The Processor processes the accessible categories described in Section 12.3 on the basis of the Controller's instructions and this Agreement. The Processor shall not use those categories of Personal Data for any purpose other than providing the Services.
Section 13 — Cloud Mode 1 (ServerManaged)
13.1 Mode 1 is a legacy deployment model in which the tenant vault key is wrapped by a key derived from a server-side secret stored as a Docker secret or environment variable within the tenant's container. In this model there exists a theoretical multi-step access path by which the Processor could, with deliberate effort, access encrypted content.
13.2 The multi-step access path requires: (i) access to the container's Docker secret or environment variable containing the wrapping key; (ii) decryption of the vault key; and (iii) use of the vault key to decrypt individual content objects. No automated or built-in tool exists for this purpose; execution of arbitrary commands within a running container is blocked by the container runtime configuration (EXEC=0).
13.3 The following safeguards reduce the risk of unauthorized access in Mode 1:
- (a) The wrapping key is stored exclusively as a Docker secret mounted at a path not accessible to external network requests; it is not passed as a plain environment variable in production deployments.
- (b) The container runtime is configured with EXEC=0, preventing execution of interactive shell commands within a running container.
- (c) Access to container infrastructure is restricted to a small number of named Processor personnel; all access is logged to the HMAC audit chain.
- (d) Data exports generated by the Platform are themselves encrypted using the tenant vault key before transmission.
13.4 Despite the safeguards in Section 13.3, the Processor treats all data categories described in Annex I as potentially accessible to the Processor in Mode 1, and accordingly applies the full obligations of Part I without qualification to Mode 1 deployments.
13.5 Mode 1 is being phased out. New cloud tenants are provisioned in Mode 2 by default. Existing Mode 1 tenants are notified of the migration timeline via the administration interface and by email to the billing contact.
Part III — End-to-End Encryption
Section 14 — End-to-End Encryption Clause
14.1 In Mode 2, the Processor represents and warrants that the following six conditions are met with respect to E2E Encrypted Data:
- (a) Content encryption uses AES-256-GCM with per-object random 256-bit keys. Message keys are derived from ECDH key exchange between sender and recipient devices. File keys are random 256-bit values wrapped in the tenant vault key using AES-256-GCM.
- (b) Files are stored exclusively in the CHEF format, in which the file content is encrypted in authenticated chunks, the per-file key is wrapped in the vault key, and the vault key is not accessible to the Processor.
- (c) Vault key slots are protected using LUKS-equivalent key derivation. The vault cannot be unsealed without the Controller's passphrase or hardware token.
- (d) The vault is sealed at rest. The unsealed vault key exists only in server process memory during an active session and is not written to disk, backup storage, or any log in unsealed form.
- (e) The Processor holds no copy of the Controller's vault passphrase or hardware token, and no escrow of the unsealed vault key is made on the Processor's infrastructure.
- (f) No technical bypass mechanism exists in the Platform software that would allow the Processor to access encrypted content without the vault key. The Processor undertakes not to introduce such a mechanism.
14.2 The encryption measures in Section 14.1 constitute a supplementary measure within the meaning of EDPB Recommendations 01/2020 on measures that supplement transfer tools to ensure compliance with the EU level of protection of personal data. Specifically, the measures satisfy the following six criteria identified in those Recommendations:
- (i) The data are encrypted before leaving the controller's or processor's infrastructure destined for a third-country sub-processor.
- (ii) The encryption algorithm and key length (AES-256-GCM) are considered state of the art and have withstood public scrutiny.
- (iii) The keys are managed exclusively by the controller or a trusted entity in a country providing adequate protection.
- (iv) The data are not made available in unencrypted form in the third country.
- (v) The sub-processor cannot access the encryption keys.
- (vi) There is no technical mechanism that would allow the sub-processor to compel access to the plaintext data.
14.3 In the event of a Security Incident involving exclusively E2E Encrypted Data processed in Mode 2, the Processor shall assess, and set out in its breach notification under Section 7, whether the incident falls within the exemption in Article 34(3)(a) GDPR on the basis that the data are unintelligible to any person not authorised to access them by virtue of the measures in Section 14.1.
14.4 Push notification payload limitation: Push notification payloads transmitted to third-party gateways (FCM, APNs) contain only: a routing token, a message count increment, and a notification sound identifier. No message content, channel name, sender name, or other Personal Data is included in the push payload. This limitation applies in both Mode 1 and Mode 2.
14.5 The representations in Section 14.1(d), (e) and (f) apply only to Mode 2. In Mode 1, the Processor's access path described in Section 13.1 means that Section 14.1(d), (e) and (f) cannot be warranted, and the supplementary measure assessment in Section 14.2 does not apply with respect to the vault key and content encrypted thereunder.
Part IV — General Provisions
Section 15 — Data Protection Officer
15.1 The Processor has assessed its obligations under Article 37 GDPR and has determined that appointment of a Data Protection Officer is not mandatory at the current time on the following basis: the Processor's core activities consist of operating a communication infrastructure platform; the Processor does not carry out large-scale, regular and systematic monitoring of individuals as a core activity; and the special categories of data within the meaning of Article 9 GDPR are not processed on a large scale as a core activity.
15.2 The Processor designates its privacy contact (privacy@thechatapp.chat) as the first point of contact for all data protection enquiries from the Controller, Data Subjects, and supervisory authorities. This contact point has access to the Processor's legal and technical teams and is authorised to respond on the Processor's behalf.
15.3 The Processor shall reassess its obligation to appoint a DPO at least annually and shall notify the Controller if that assessment changes.
Section 16 — Supervisory Authority
16.1 The Processor's lead supervisory authority is the Comissão Nacional de Proteção de Dados (CNPD), Av. D. Carlos I, 134 - 1.º, 1200-651 Lisboa, Portugal, telephone +351 213 928 400, email geral@cnpd.pt.
16.2 Nothing in this Agreement affects the Controller's right to lodge a complaint with any supervisory authority in any Member State where the Controller is established or where the alleged infringement occurred.
Section 17 — Governing Law and Jurisdiction
17.1 This Agreement is governed by Portuguese law, without regard to its conflict-of-law provisions, and the parties submit to the exclusive jurisdiction of the courts of Lisbon, Portugal, except where otherwise required by the SCCs or the UK Addendum.
17.2 Where a provision of this Agreement conflicts with a mandatory requirement of the GDPR or Lei n.º 58/2019, the mandatory requirement shall prevail to the extent of the conflict.
Section 18 — Liability
18.1 Each party's liability to the other in connection with this Agreement is subject to the limitations and exclusions set out in the Service Agreement, save that no limitation or exclusion of liability shall apply to the extent that it would prevent either party from fulfilling its mandatory obligations under the GDPR.
18.2 The Processor acknowledges that nothing in this Agreement limits the Controller's right to seek compensation from the Processor under Article 82 GDPR, or limits the Processor's exposure to administrative fines under Article 83 GDPR, to the extent such fines are imposed by a competent supervisory authority.
Section 19 — Term and Survival
19.1 This Agreement takes effect on the effective date of the Service Agreement and continues in force for the duration of that agreement, including any renewal periods.
19.2 Termination or expiry of this Agreement does not affect any rights or obligations that have already accrued.
19.3 The following Sections survive termination or expiry: Section 3 (Confidentiality), Section 9 (Data Return and Deletion), Section 10 (Audit Rights), and Section 14 (End-to-End Encryption Clause) to the extent relevant to post-termination obligations.
Section 20 — CCPA Service Provider Certification
20.1 To the extent the Controller processes the personal information of California residents subject to the California Consumer Privacy Act of 2018 as amended by the California Privacy Rights Act (CCPA/CPRA), the Processor certifies the following:
- (a) The Processor does not sell or share personal information received from the Controller within the meaning of Cal. Civ. Code § 1798.140(ad) and (ah), and shall not do so.
- (b) The Processor does not retain, use, or disclose personal information for any commercial purpose other than providing the Services specified in the Service Agreement or as otherwise permitted by the CCPA/CPRA.
- (c) The Processor does not combine personal information received from the Controller with personal information received from or collected in connection with another person's business, or collected from the Processor's own interactions with consumers, except as permitted by CCPA/CPRA regulations.
Section 21 — Amendments
21.1 Any amendment to this Agreement must be in writing and signed by authorised representatives of both parties, except as provided in Section 21.2.
21.2 The Processor may update the Sub-Processor list (Annex III) and the TOM summary (Annex II) without formal amendment to this Agreement, by providing the notice required under Section 5.2 and Section 4.4 respectively. Such updates take effect at the end of the applicable notice period unless the Controller objects in accordance with Section 5.3 or Section 4.4.
21.3 If any provision of this Agreement is held invalid, illegal, or unenforceable by a competent court or supervisory authority, the remaining provisions shall continue in full force and effect. The parties shall negotiate in good faith to replace the invalid provision with one that achieves the same legal and commercial purpose.
Annex I — Details of Processing
A. Parties
| Role | Entity | Contact |
|---|---|---|
| Controller | As identified in the Service Agreement or countersignature | As designated by Controller |
| Processor | TheChatApp, Portugal | privacy@thechatapp.chat |
B. Data Subjects
The processing covers Personal Data relating to the following categories of Data Subjects:
- 1. Employees and authorised users: Natural persons who are employees, contractors, or other individuals authorised by the Controller to use the Platform, including user accounts created by the Controller's administrators.
- 2. External parties via WebChat: Natural persons who interact with the Controller's team through the web-based guest interface (WebChat or embedded chat widget), without holding a registered account on the Platform.
C. Categories of Personal Data
1. Account Data
Elements: Username, email address, display name, organisation role, channel memberships, profile settings
Purpose: Service operation, user identification, access control, directory services
Mode 2 access: Readable by Processor
Mode 1 access: Readable by Processor
Retention: Account lifetime; anonymized within 30 days of account deletion
2. Authentication Data
Elements: Argon2id password hashes (with per-user random salt), ECDH public keys, active session tokens, TOTP secrets (encrypted)
Purpose: Authentication, multi-device support, session management
Mode 2 access: Readable (hashes and public keys only; plaintext passwords never stored)
Mode 1 access: Readable (same limitation)
Retention: Account lifetime for hashes and keys; session tokens expire within 7 days
3. Operational Metadata
Elements: IP addresses, device identifiers, login timestamps, message send timestamps, HMAC audit chain entries (pseudonymized)
Purpose: Service delivery, security monitoring, abuse prevention, compliance audit trail
Mode 2 access: Readable by Processor (pseudonymized; IP addresses in logs)
Mode 1 access: Readable by Processor
Retention: Configurable by Controller via administration interface (default: indefinite for audit chain)
4. Billing Data
Elements: Company name, billing address, masked payment method, licence keys, invoice history
Purpose: Licence management, invoicing, contract administration
Mode 2 access: Readable (Controller is primary controller for this category)
Mode 1 access: Readable
Retention: Account lifetime; invoices retained 10 years per Portuguese tax law
5. E2E Encrypted Content
Elements: Messages (all channels including direct messages and meeting chat), meeting recordings, AI-generated embeddings, poll questions and responses, message reactions
Purpose: Communication, collaboration, meeting management, search
Mode 2 access: Inaccessible to Processor (AES-256-GCM encryption; vault sealed)
Mode 1 access: Theoretically accessible via multi-step chain described in Section 13
Retention: Configurable by Controller (default: 30 days for messages)
6. E2E Encrypted Files
Elements: Uploaded files of all types, stored in CHEF chunked encrypted format with per-file AES-256-GCM keys wrapped in the tenant vault key
Purpose: File sharing, collaboration, document storage
Mode 2 access: Inaccessible to Processor (CHEF format; vault sealed)
Mode 1 access: Theoretically accessible via multi-step chain described in Section 13
Retention: Configurable by Controller; subject to storage quota
D. Purpose of Processing
The Processor processes Personal Data for the sole purpose of providing, maintaining, and improving the TheChatApp enterprise communication platform on behalf of the Controller. This includes authentication and access control, message delivery and storage, file upload and retrieval, meeting management, push notification delivery, calendar integration, AI search and embedding features, administration and audit logging, billing and licence management, and technical support. The Processor shall not process Personal Data for any purpose incompatible with the Controller's documented instructions or the Service Agreement.
E. Duration
Processing commences on the effective date of the Service Agreement and continues for its duration, including any automatic renewal periods, unless earlier terminated in accordance with Section 9. Post-termination obligations, including data deletion and retention of billing records, are as described in Section 9.
Annex II — Technical and Organizational Measures
The following table summarises the Processor's current technical and organisational security measures in accordance with Article 32 GDPR. Full TOM documentation is available on request within ten Business Days.
| Category | Measures |
|---|---|
| Pseudonymization | Operational logs pseudonymize usernames and email addresses using HMAC-SHA256 keyed by a per-tenant secret. Audit chain entries reference users via pseudonym only. |
| Transport Encryption | All client-server communication is encrypted using ChaCha20-Poly1305 with ECDH key exchange. TLS 1.3 is used for all HTTP/WebSocket connections. Self-signed certificates are rejected in enterprise mode. |
| Encryption at Rest | Message content encrypted AES-256-GCM. Files stored in CHEF format (AES-256-GCM chunked). LiteDB databases encrypted at database level. Vault keys sealed at rest in Mode 2. Docker secrets used for wrapping keys in Mode 1. |
| Key Management | Tenant vault with multi-slot LUKS-equivalent key derivation. Per-object random keys for messages and files. Argon2id for password hashing. ECDH key pairs per-device, per-user. Key escrow available to Controller only (not Processor) in Mode 2. |
| Confidentiality | Infrastructure access restricted to named Processor personnel on need-to-know basis. Contractor NDAs and statutory confidentiality obligations under Lei n.º 58/2019. EXEC=0 container policy prevents interactive shell access to running tenant containers. |
| Integrity | HMAC-SHA256 audit chain provides tamper-evident log integrity. GCM authentication tags on all encrypted objects detect tampering. Authenticated key exchange (Ed25519 server signing, ECDH ephemeral keys). Replay protection via monotonic timestamps and nonces. |
| Availability | Hosted on Hetzner Online GmbH infrastructure with 99.9% uptime SLA. Automated encrypted backups with configurable retention. Container-level health monitoring with automatic restart. Rate limiting prevents resource exhaustion attacks. |
| Incident Response | 48-hour breach notification to Controller (Section 7). Internal incident response procedure with designated privacy contact. Post-incident review and remediation documentation. Supervisory authority reporting where required by GDPR. |
| Data Deletion | Configurable retention periods per data category. Per-user deletion tool in administration interface. Cryptographic erasure (vault key deletion) for bulk tenant deletion. Secure overwrite for unencrypted residual data. 30-day post-termination return window and deletion timeline per Section 9. |
Annex III — Sub-Processors
The complete Sub-Processor register, including entity legal names, registration details, DPA status, transfer mechanisms, and change notification policy, is maintained at thechatapp.chat/subprocessors. The register is updated at least 30 Business Days before any new Sub-Processor begins processing Personal Data.
The following table lists current Sub-Processors at the date of this Agreement:
| Name | Location | Service | Transfer Basis |
|---|---|---|---|
| Hetzner Online GmbH | Germany (EU) | Server hosting and infrastructure | Intra-EEA (no transfer) |
| Google LLC (Firebase Cloud Messaging) | USA | Android push notification delivery | EU-US Data Privacy Framework + SCCs (fallback) |
| Google LLC (Google Calendar API) | USA | Calendar integration (optional feature) | EU-US Data Privacy Framework + SCCs (fallback) |
| Microsoft Corporation (Microsoft Graph) | USA | Microsoft 365 calendar integration (optional feature) | EU-US Data Privacy Framework + SCCs (fallback) |
| Apple Inc. (Apple Push Notification Service) | USA | iOS push notification delivery | APEC CBPR + SCCs (fallback) |
In accordance with Section 5.2 of this Agreement, the Controller will be notified at least 30 Business Days before any Sub-Processor is added or replaced, with a right to object as described in Section 5.3.
Exhibit A — Standard Contractual Clauses Reference
Where transfers of Personal Data to third countries are not covered by an adequacy decision or a recognised framework certification (Section 8.1), such transfers are made subject to the Standard Contractual Clauses for the transfer of personal data to third countries pursuant to Regulation (EU) 2016/679 (Commission Decision 2021/914/EU), as follows:
- Module 2 (Controller to Processor): Governs transfers where the Controller transfers Personal Data to the Processor (or a Sub-Processor) located in a third country without an adequacy decision. The Processor acts as the data importer under Module 2.
- Module 3 (Processor to Processor): Governs onward transfers from the Processor to Sub-Processors located in a third country without an adequacy decision.
The governing law for both Module 2 and Module 3 is the law of Portugal. The competent courts for disputes arising from the SCCs are the courts of Lisbon, Portugal.
Optional clauses selected: Clause 7 (docking clause) — not selected. Clause 9(a) (general written authorisation for sub-processors) — selected. Clause 11 (redress) — optional language not included.
UK International Data Transfer Addendum (IDTA): For transfers of personal data that fall within the scope of UK data protection law (UK GDPR as retained in UK law by the European Union (Withdrawal) Act 2018), the UK Addendum (version B1.0, issued by the ICO on 21 March 2022) is incorporated into and forms part of the SCCs as an addendum, in accordance with its terms. The Processor acts as the data importer under the UK Addendum. Table 1 of the UK Addendum is populated by reference to the parties and processing details in Annex I of this Agreement.
Countersignature
By signing below, the parties agree to be bound by the terms of this Data Processing Agreement as of the later of the two signature dates. Where the Controller has accepted the Service Agreement electronically, this DPA is incorporated by reference and the electronic acceptance constitutes the Controller's signature for the purposes of this block.
| Processor | Controller | |
|---|---|---|
| Entity | TheChatApp | _________________________ |
| Name | _________________________ | _________________________ |
| Title | _________________________ | _________________________ |
| Date | 2026-04-08 | _________________________ |
| Signature | _________________________ | _________________________ |
For questions about this DPA, contact privacy@thechatapp.chat.
Supervisory authority: Comissão Nacional de Proteção de Dados (CNPD), Av. D. Carlos I, 134 - 1.º, 1200-651 Lisboa, Portugal.