Data processing agreement

Effective 23 September 2026. Version 1.0.

This data processing agreement ("DPA") forms part of the terms of service at chatguard.dev/terms (the "Terms") between Kirill Tolmachev pr Beograd (Belgrade, Serbia; "Chat Guard", "we") and the organization that uses Chat Guard (the "Customer", "you"). It applies automatically, on every plan and without a signature, whenever Chat Guard processes personal data on the Customer's behalf that is subject to Data Protection Law. A copy signed by Chat Guard is available on request to support@chatguard.dev.

1. Definitions

Terms defined in the GDPR (controller, processor, personal data, processing, data subject, personal data breach, supervisory authority) have the same meaning here.

• Data Protection Law: Regulation (EU) 2016/679 (the "GDPR"), the UK GDPR and the UK Data Protection Act 2018, the Swiss Federal Act on Data Protection (the "FADP"), and the national laws that implement or supplement them, each to the extent it applies to the processing.
• Customer Personal Data: personal data that the Customer, its servers or its players' clients send to the Service and that Chat Guard processes on the Customer's behalf, as described in Annex I.
• Service: the Chat Guard API, dashboard, Unity package and related services described in the Terms.
• SCCs: the standard contractual clauses annexed to Commission Implementing Decision (EU) 2021/914.
• UK Addendum: the International Data Transfer Addendum to the SCCs issued by the UK Information Commissioner under section 119A of the Data Protection Act 2018 (version B1.0), as amended.
• Sub-processor: another processor that Chat Guard engages to process Customer Personal Data.

2. Roles and scope

2.1 The Customer is the controller of Customer Personal Data and Chat Guard is its processor. If the Customer processes the data on behalf of another controller (for example a developer working for a publisher), the Customer is a processor, Chat Guard is its sub-processor, and the Customer passes on the instructions of its controller and the commitments of this DPA.

2.2 The personal data of the Customer's dashboard users (email address, display name, avatar URL) and of its billing contacts is processed by Chat Guard as a controller in order to run the Customer's account, as described in the privacy notice at chatguard.dev/privacy. It is not Customer Personal Data.

2.3 Annex I describes the subject matter, nature, purpose and duration of the processing, the types of personal data and the categories of data subjects.

3. Instructions

3.1 Chat Guard processes Customer Personal Data only on the Customer's documented instructions, including with regard to transfers to third countries, unless the law to which Chat Guard is subject requires otherwise. In that case Chat Guard tells the Customer of the legal requirement before processing, unless that law prohibits it on important grounds of public interest.

3.2 The Customer's instructions are: the Terms and this DPA; the requests that its servers and client builds send to the API; and the configuration it chooses in the dashboard or through the API, such as thresholds, rules, evidence logging and its retention, player erasure and the deletion of projects and organizations. Further instructions need the written agreement of both parties.

3.3 Chat Guard tells the Customer promptly if, in its opinion, an instruction infringes Data Protection Law.

3.4 Chat Guard does not sell Customer Personal Data, does not use it to train or fine-tune machine-learning models, and does not process it for its own purposes. The improvement of the local word lists allowed by section 8 of the Terms uses only aggregate statistics that identify no player, never stored message text or player identifiers.

4. The Customer's obligations

4.1 The Customer is responsible for the lawfulness of the processing it instructs: it has a lawful basis to send player messages to Chat Guard, and it tells its players in its privacy notice that chat is moderated automatically by a processor and that messages are analyzed by a model provider in the United States (Annex III).

4.2 As the author identifier, and as the author labels of thread context lines, the Customer uses opaque values that it can map to players, never a name, email address, platform account name or other direct identifier, and it does not send personal data that moderation does not need.

4.3 Decisions about players based on verdicts, such as hiding a message, muting or banning, are the Customer's. Where such a decision produces legal or similarly significant effects for a player, the Customer provides the safeguards that Data Protection Law requires, including human review on request.

4.4 The Customer enables evidence logging only when it needs message text for review and chooses a retention no longer than it needs.

5. Confidentiality

Chat Guard is operated by its owner. Any other person Chat Guard authorizes to access Customer Personal Data, such as an employee or contractor, is bound by a written or statutory duty of confidentiality and accesses the data only as far as needed to provide the Service, to support the Customer or to comply with the law.

6. Security

6.1 Chat Guard implements the technical and organizational measures in Annex II, which take into account the state of the art, the costs of implementation, the nature, scope, context and purposes of the processing, and the risks to players (Art. 32 GDPR).

6.2 Chat Guard may change the measures as technology and threats change, provided the overall level of protection does not decrease.

7. Sub-processors

7.1 The Customer gives Chat Guard general written authorization to engage Sub-processors. The current Sub-processors are listed in Annex III and on the privacy page.

7.2 Chat Guard gives at least 30 days' notice before it adds or replaces a Sub-processor, by email to the owners of each organization and on the privacy page. If a Sub-processor must be replaced urgently, for security reasons or because it stops providing its service, Chat Guard may make the change with shorter notice and tells the Customer as soon as possible.

7.3 The Customer may object to a change on reasonable data-protection grounds by writing to support@chatguard.dev within the notice period, or within 30 days of an urgent change. The parties then discuss the objection in good faith. If they cannot resolve it, the Customer may end the Terms by asking Chat Guard to delete its organization, and Chat Guard refunds any fees paid in advance for the period after the deletion.

7.4 Chat Guard imposes on each Sub-processor, by written contract, data-protection obligations that provide the same level of protection as this DPA, in particular sufficient guarantees of appropriate technical and organizational measures, as far as they apply to the service that Sub-processor provides. Chat Guard remains fully liable to the Customer for the performance of each Sub-processor's obligations.

8. Requests from players

8.1 Chat Guard provides tools with which the Customer can answer players exercising their rights:

• Erasure. DELETE /v1/evidence/{projectId}/{authorOpaqueId} (with a server key of the project) and "Erase a player" in the project settings (owners and admins) hard-delete the player's evidence rows in that project and remove the author identifier from its verdict rows, at once and on every plan.
• Access and portability. "Export a player" in the project settings (owners and admins) downloads everything the project stores for an author identifier (verdicts and evidence) as JSON, on every plan.
• Restriction and objection. The Customer stops sending the player's messages to the Service.

8.2 Email support is not designed to receive Customer Personal Data. The Customer uses the tools above for players' requests and, when a support request concerns a specific record, refers to it by its verdict or request id rather than by player data.

8.3 If a player contacts Chat Guard directly, Chat Guard does not answer the request itself. It forwards the request to the Customer without undue delay where it can tell which Customer the player belongs to, and otherwise tells the player to contact the game's operator.

8.4 Beyond these tools, Chat Guard assists the Customer with appropriate technical and organizational measures, as far as possible, taking into account the nature of the processing.

9. Assistance with security, impact assessments and consultations

Chat Guard assists the Customer in meeting its obligations under Articles 32 to 36 GDPR, taking into account the nature of the processing and the information available to Chat Guard, by providing this DPA, the privacy page and the documentation, and by answering reasonable questions about the Service, for example for a data protection impact assessment.

10. Personal data breaches

10.1 Chat Guard notifies the Customer without undue delay, and in any case within 48 hours, after becoming aware of a personal data breach affecting Customer Personal Data. The notice goes by email to the owners of the organization.

10.2 The notice describes, as far as then known: the nature of the breach, including the categories and approximate number of players and records concerned; its likely consequences; the measures taken or proposed to address it and to mitigate its possible adverse effects; and a contact point for more information. Chat Guard supplements the notice as more information becomes available.

10.3 Chat Guard takes reasonable steps to contain and investigate the breach and documents it. Notifying supervisory authorities and players is the Customer's decision; Chat Guard does so on the Customer's behalf only if the Customer asks and the law allows.

10.4 A notice under this section is not an acknowledgement of fault or liability.

11. International transfers

11.1 Customer Personal Data is stored in the European Union (Annex III). Chat Guard is established in Serbia, which is not covered by an adequacy decision under Article 45 GDPR, and model inference takes place in the United States.

11.2 Where the Customer's transfer of Customer Personal Data to Chat Guard is a transfer to a third country under the GDPR, the SCCs are incorporated into this DPA as follows:

• Module Two (controller to processor) applies where the Customer is a controller, and Module Three (processor to processor) where the Customer is a processor;
• the Customer is the data exporter and Chat Guard the data importer;
• Clause 7 (docking clause) applies;
• in Clause 9, Option 2 (general written authorization) applies, with the notice period of section 7.2;
• in Clause 11, the optional wording does not apply;
• in Clause 13, the competent supervisory authority is the one set out in Annex I.C;
• in Clause 17, Option 1 applies, and the law is that of Ireland;
• in Clause 18, disputes are resolved by the courts of Ireland;
• Annexes I, II and III of the SCCs are completed by Annexes I, II and III of this DPA.

11.3 Where the transfer is subject to the UK GDPR, the UK Addendum is incorporated: Table 1 is completed with the parties in Annex I.A, Table 2 with the modules and clauses selected in section 11.2, and Table 3 with the annexes of this DPA; in Table 4, neither party may end the UK Addendum under its Section 19.

11.4 Where the transfer is subject to the FADP, the SCCs apply with these changes: the Swiss Federal Data Protection and Information Commissioner is the competent supervisory authority for such transfers; references to the GDPR include the corresponding provisions of the FADP; and the term "Member State" does not prevent data subjects in Switzerland from bringing claims in their place of habitual residence under Clause 18(c).

11.5 Chat Guard transfers Customer Personal Data to Sub-processors outside the European Economic Area only under a transfer mechanism recognized by Data Protection Law, as listed in Annex III.

11.6 If a public authority sends Chat Guard a legally binding request for Customer Personal Data, Chat Guard notifies the Customer unless the law prohibits it, challenges the request where there are reasonable grounds to consider it unlawful, and discloses no more than the request requires.

12. Audits

12.1 Chat Guard makes available to the Customer the information necessary to demonstrate compliance with Article 28 GDPR and this DPA: this DPA, the privacy page and Annex II; written answers to a reasonable security questionnaire, once in any 12 months; and, where the provider permits, the audit reports and certifications its Sub-processors make available.

12.2 If that information is not sufficient, or a supervisory authority requires it, or after a personal data breach, the Customer may audit Chat Guard itself or through an independent auditor bound by confidentiality. Audits take place at most once in any 12 months (except when a supervisory authority requires it or after a breach), with at least 30 days' written notice, during business hours in Belgrade, without disrupting the Service or giving access to other customers' data. Each party bears its own costs. The data centers of Sub-processors are covered by their own audit reports.

13. Deletion and return

13.1 While the Service runs, Customer Personal Data is deleted according to the retention periods in Annex I and the Customer's configuration.

13.2 Owners and admins can delete a project in the dashboard at any time. Its verdicts, evidence and feedback are hard-deleted at once, together with its keys and rules.

13.3 The Customer can ask Chat Guard to delete its organization by email to support@chatguard.dev (section 10 of the Terms). When the organization is deleted or the Terms otherwise end, Chat Guard deletes all remaining Customer Personal Data within 30 days. Before that, the Customer can export players' data with the tools in section 8, and Studio and Enterprise organizations a project's evidence.

13.4 Deleted data remains in the database provider's restore history for up to 7 days and in its encrypted backups for the period that provider keeps them. It is not accessed there except to restore the database after an incident, and then expires.

13.5 On request, Chat Guard confirms the deletion in writing.

14. Liability

Each party's liability arising out of or in connection with this DPA is subject to the limitations in section 9 of the Terms, to the extent Data Protection Law and the SCCs allow. This does not limit either party's liability to data subjects, including under Article 82 GDPR and the third-party beneficiary rights of the SCCs.

15. Precedence, duration, changes and law

15.1 For the processing of Customer Personal Data, the SCCs (where they apply) prevail over this DPA, and this DPA prevails over the Terms. Nothing in this DPA modifies the SCCs.

15.2 This DPA applies for as long as Chat Guard processes Customer Personal Data.

15.3 Chat Guard may change this DPA in the same way as the Terms (section 11 of the Terms). It does not reduce the protection of Customer Personal Data, except as Data Protection Law or a supervisory authority requires. The current version is always at chatguard.dev/dpa.

15.4 This DPA is governed by the law named in section 12 of the Terms, except the SCCs and the UK Addendum, which are governed as set out in sections 11.2 to 11.4.

15.5 If a provision of this DPA is invalid, the rest remains in force.

Annex I. Details of processing

A. Parties

Data exporter (controller, or processor under section 2.1): the Customer, identified by its organization in the Chat Guard dashboard. Contact: the organization owners' email addresses. Activity: moderation of chat in its games using the Service. Signature and date: acceptance of the Terms.

Data importer (processor): Kirill Tolmachev pr Beograd, Belgrade, Serbia. Contact: support@chatguard.dev. Activity: providing the Service. Signature and date: acceptance of the Terms by the Customer, and publication of this DPA by Chat Guard.

B. Description of the processing

Categories of data subjects. Players of the Customer's games whose chat messages the Customer sends to the Service, and other people named or quoted in those messages.

Categories of personal data.

Verdict and evidence records pass through a queue in Redis on their way to the database and are removed from it once written, normally within seconds.

Special categories of data. The Service is not designed to process special categories of personal data or data about criminal convictions, and the Customer does not send them on purpose. Player messages may contain them incidentally (for example a remark about someone's health or beliefs). The Service classifies messages for abuse categories and does not infer or record special categories. Safeguards: message text is not stored unless an owner or admin enables evidence logging for the project; stored text is visible only to members of the Customer's organization; retention limits with hard deletion.

Frequency. Continuous, for each message the Customer sends.

Nature of the processing. Receipt over HTTPS, normalization, local dictionary filtering, classification by the model provider, storage of verdict metadata, optional storage of message text as evidence, display in the dashboard, erasure and deletion.

Purpose. Moderating chat in the Customer's games according to the Customer's configuration, and operating, securing and metering the Service. Metering counts verdicts; it does not use message content or player identifiers.

Duration. For the term of the Terms, followed by deletion under section 13.

Transfers to Sub-processors. As listed in Annex III, for the purposes and duration stated there.

C. Competent supervisory authority

• If the Customer is established in an EU Member State: the supervisory authority of that Member State.
• If the Customer is not established in the EU but the GDPR applies to it under Article 3(2) and it has appointed a representative under Article 27(1): the supervisory authority of the Member State where the representative is established.
• If the Customer is not established in the EU and is not required to appoint a representative: the Data Protection Commission (Ireland).
• For transfers subject to the UK GDPR: the Information Commissioner's Office. For transfers subject to the FADP: the Swiss Federal Data Protection and Information Commissioner.

Annex II. Technical and organizational measures

Data minimization

• Message text is stored only when the Customer enables evidence logging for a project; by default the Service keeps a hash of the normalized message and the verdict.
• Players are known only by opaque identifiers chosen by the Customer. The identifier is not sent to the model provider.
• Application logs contain no message text. No third-party analytics, error-tracking or tracing service receives data from the Service.
• Player IP addresses are used in memory for rate limiting and are not logged or stored.

Access control for Customers

• Dashboard sign-in only through Google or GitHub with a verified email address; no passwords.
• Access tokens expire after 15 minutes. Refresh tokens are stored only as SHA-256 hashes, rotated on every use, kept in HttpOnly cookies and expire after 30 days.
• Each organization has owner, admin and member roles. Only members see the organization's data; only owners and admins can enable evidence logging, change its retention, export evidence or a player's data, erase players, manage API keys or delete projects.
• API keys are random secrets shown once and stored only as SHA-256 hashes. They can be revoked in the dashboard at any time; revocation takes effect within a minute. Publishable keys for client builds can only moderate and read the quota.

Access control for the operator

• Only the operator has access to production systems, through the providers' consoles and command-line tools. Every administrative account (hosting, database, cache, source code, DNS, email and billing) uses two-factor authentication.
• Secrets are kept in the hosting provider's secret store, never in source code. Deploy tokens are scoped to one application and expire.
• Production is deployed only from the main branch, by continuous integration, after the automated tests pass. Containers run as non-root users.

Encryption

• In transit: HTTPS is enforced for the API and the dashboard; connections from the application to the database, the cache and the model provider use TLS.
• At rest: the database is encrypted at rest (AES-256) by its provider. The cache holds only the short-lived data described in Annex I and is not encrypted at rest. The application servers store no Customer Personal Data on disk.

Availability and resilience

• The API runs on at least two instances. If the model provider is unreachable, the API answers from a local filter and marks the answer as degraded.
• Rate limits per IP address, API key, player and model budget, and size limits on every input.
• The database provider keeps a restore history of up to 7 days and daily encrypted backups.
• The public endpoints are probed every five minutes, and an outage alerts the operator.

Retention and deletion

• An hourly job hard-deletes evidence past its retention, and verdict rows older than 90 days once no retained evidence refers to them.
• Erasure and export by author identifier, on every plan.
• Deleting a project deletes its verdicts, evidence and feedback at once.
• Queue entries in Redis are removed once written to the database.

Sub-processors

• Sub-processors are chosen for their security practices and bound by data processing agreements; data is stored in EU regions (Annex III).

Incidents

• Suspected breaches are assessed, contained and investigated as a priority, documented in a breach register, and notified to affected Customers under section 10.

Annex III. Sub-processors

TypeSafe keeps request data for as long as necessary to provide its service and does not train its models on it.