Data Processing Addendum

1. Scope and roles

1.1 What this is. This Data Processing Addendum (“DPA”) forms part of the Togo AI Terms of Service (the “Terms”) between you (“Customer”, “you”) and 77Sparx Studio, Inc. (“77Sparx”, “we”, “us”). It applies whenever we process personal data contained in Customer Data on your behalf. Capitalised terms we don’t define here have the meaning given in the Terms.

1.2 You don’t need to sign anything. This DPA is incorporated into the Terms by Terms §1.1 and takes effect when you accept them. If your organisation needs a counter-signed copy, email [email protected] and we’ll send one.

1.3 Roles. For personal data in Customer Data:

1.4 Where you are yourself a processor. If you process End User personal data on behalf of someone else, you are a processor and we are your subprocessor. You confirm you have that person’s authorisation to engage us and to agree this DPA, and references to your instructions mean instructions you are permitted to give.

1.5 What this DPA does not cover. It does not cover personal data we process as a controller for our own purposes — your account administrators’ and billing contacts’ details, website visitors, support correspondence itself, and Usage Data. Our Privacy Policy covers those. Customer Data you include in support correspondence stays Customer Personal Data and remains covered by this DPA. It also does not cover Aggregated Data, for the reasons in §5.

2. Definitions

• Applicable Data Protection Law — every privacy and data protection law that applies to either of us in respect of the processing, including the GDPR, the UK GDPR and the UK Data Protection Act 2018, the Swiss FADP, and US state privacy laws including the CCPA.
• Customer Personal Data — personal data within Customer Data that we process on your behalf under the Terms.
• Data Subject Request — a request from an individual to exercise a right under Applicable Data Protection Law.
• Personal Data Breach — a breach of our security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Customer Personal Data. It does not include an unsuccessful attempt that does not compromise Customer Personal Data — port scans, failed log-ins, denial-of-service attempts and the like.
• SCCs — the Standard Contractual Clauses annexed to Commission Implementing Decision (EU) 2021/914.
• Subprocessor — a third party we engage to process Customer Personal Data.
• UK Addendum — the International Data Transfer Addendum to the EU Commission Standard Contractual Clauses issued by the UK Information Commissioner, version B1.0.

“Controller”, “processor”, “personal data”, “processing”, “special category data”, “business”, “service provider”, “sell”, “share” and “deidentified” carry the meaning given in Applicable Data Protection Law.

3. What we process, and why

3.1 The details are in Annex I — the subject matter, duration, nature and purpose of processing, the categories of data subjects and personal data, and the retention periods.

3.2 Duration. We process Customer Personal Data for as long as the Terms are in force, and afterwards only as §15 allows. This DPA survives the Terms for as long as we hold Customer Personal Data.

4. Your instructions, and the limits on ours

4.1 We process on your instructions. We process Customer Personal Data only to provide, secure, support and improve the Service under the Terms, to comply with this DPA, and on your other documented, lawful instructions. The Terms, this DPA and your configuration of the Service — your Tracking Plan, retention settings, project structure, deletion requests and API calls — are your complete documented instructions at the outset.

4.2 The uses in Terms §4.5 to §4.7 are your instruction. You instruct us to process Customer Personal Data to derive the general diagnostic patterns described in Terms §4.5 and to compute the per-customer rollups that become Aggregated Data under Terms §4.6 and §4.7. This processing happens inside the Service and on your behalf. What it produces is governed by §5.

4.3 We will not sell or share it. We will not sell or share Customer Personal Data as those terms are defined in the CCPA, will not retain, use or disclose it outside the direct business relationship between us, and will not combine it with personal data we receive from another source except as the CCPA permits a service provider to do.

4.4 If an instruction looks unlawful. We will tell you if we believe an instruction infringes Applicable Data Protection Law, and may pause the affected processing until it is resolved. We are not obliged to give you legal advice and this is not a warranty that your instructions are lawful.

4.5 If the law compels us. If a law we are subject to requires us to process Customer Personal Data beyond your instructions, we will tell you before we do so unless that law prohibits it, and will disclose only what the request requires. Clause 15 of the SCCs governs where it applies.

4.6 Your obligations. You are responsible for the lawfulness of Customer Personal Data and of your instructions, for having a legal basis for collecting it and for the processing you instruct, for the notices and consents in Terms §4.2, and for the data-minimisation obligations in Terms §4.3 and §4.4.

4.7 What you must not send. Terms §4.3 prohibits special category data, government identifiers, financial account details, credentials and precise geolocation. The Service rejects or quarantines what validation can detect, but detection is not a guarantee: a declared string property can hold anything you put in it. If you send prohibited data anyway, we may delete it on notice to you, and you remain responsible for it having been sent.

5. The aggregation boundary — where this DPA stops

5.1 Two stages, and they are different processing. Terms §4.6 and §4.7 describe one pipeline with a boundary in the middle:

5.2 What crosses the boundary. Person, user, device, session and anonymous identifiers are removed before aggregation (Terms §4.8(2)). What crosses is project-level metric observations — counts, rates, distributions — not event rows and not individual records.

5.3 Aggregated Data is not Customer Personal Data, and this DPA does not apply to it. We publicly commit to maintain Aggregated Data in deidentified form: we will not attempt to reidentify any End User from it, we maintain technical and organisational measures designed to prevent inadvertent reidentification, and we contractually oblige any recipient to the same. Terms §4.8 states the suppression thresholds, per-contributor caps and disclosure limits that apply to it.

5.4 Erasure does not run backwards through the boundary. Deleting an End User under §10 or §11 removes them from Customer Data and from future rollups. It does not cause us to recompute or withdraw Aggregated Data already published or already incorporated into the Service, because that data is not personal data about them.

5.5 Contributor identity during computation. Producing a benchmark requires us to know which contributor is which, so that the per-contributor cap in Terms §4.8(3) and any contractual exclusion can be enforced. That linkage is working state: it is held only for the corpus build that uses it, is not accessible to the customer-facing Service, and is not present in the published distributions.

6. Confidentiality and personnel

6.1 We limit access to Customer Personal Data to personnel who need it to perform the Terms, bind them to written confidentiality obligations that survive their engagement, and train them on their data protection and security responsibilities at least annually.

6.2 Access is granted on the principle of least privilege, reviewed periodically, requires multi-factor authentication, and is revoked when an engagement ends.

7. Security

7.1 We implement and maintain the technical and organisational measures in Annex II, which are designed to protect Customer Personal Data against a Personal Data Breach and are appropriate to the risk given the state of the art, the cost of implementation, and the nature, scope, context and purposes of the processing.

7.2 We may change those measures, provided the change does not materially reduce the overall level of security.

7.3 You have obligations too. You are responsible for your use of the security features we provide — access controls, roles, API key hygiene, key rotation, spend caps, retention settings — and for the security of the systems, agents and AI clients you connect to the Service.

8. Subprocessors

8.1 General authorisation. You give us general written authorisation to engage Subprocessors. The current list is at togohq.ai/subprocessors. Our affiliates and our infrastructure, hosting and model-inference providers are authorised as of the date you accept this DPA.

8.2 Notice of changes. We will update the list and notify your account’s administrative contact at least 7 days before a new Subprocessor begins processing Customer Personal Data.

8.3 Objecting. You may object on reasonable data protection grounds within 7 days of that notice by emailing [email protected] with your reasons. We will work with you in good faith to make a change that avoids the objection. If we cannot within a reasonable time, you may terminate the affected part of the Service on written notice and receive a pro-rata refund of prepaid fees under Terms §10.4. That is your sole remedy for an objection.

8.4 Our contracts with them. We impose on each Subprocessor data protection obligations at least as protective as those in this DPA, and we remain liable to you for a Subprocessor’s acts and omissions as if they were our own.

8.5 Model providers. A third-party model provider whose models the Service uses to run an analysis for you is a Subprocessor, listed and governed under this Section like any other. Terms §4.10 states our commitment that no third party, including a model provider, trains its own models on Customer Data.

8.6 Emergency engagements. Where a Subprocessor must be engaged immediately to preserve the security or availability of the Service, we may do so and will notify you as soon as possible afterwards. Your objection right under §8.3 runs from that notice.

9. AI clients you connect

9.1 A client you connect is not our Subprocessor. Where you connect an AI client or agent through our MCP server or our APIs, that client acts on your behalf under the permissions you grant it. Customer Personal Data it receives leaves the Service at your direction. Its provider is your processor or your controller, not our Subprocessor, and the Subprocessor commitments in §8 do not reach it.

9.2 What that means practically. You are responsible for the client provider’s terms, including whether it trains on what it receives, for having a transfer mechanism for any international transfer it makes, and for including it in your own records of processing and subprocessor disclosures.

10. Data Subject Requests

10.1 They come to you. You are responsible for responding to Data Subject Requests from your End Users. If we receive one directly, we will not respond to it on the merits, and will tell you without undue delay with what we know about who sent it.

10.2 Self-service first. We provide functionality in the Service that lets you access, export, correct, restrict and delete a person’s data yourself, which is how requests should normally be handled. Terms §4.3 requires identifying traits to be declared as person properties precisely so that a deletion is a targeted operation.

10.3 Where the tooling doesn’t reach. Where a request cannot be satisfied through the Service, we will provide reasonable assistance, taking account of the nature of the processing and the information available to us. We may charge for assistance that is not reasonably attributable to a failure of our own tooling, on notice to you and at our then-current rates.

11. Deletion, erasure and retention

11.1 Retention during the Term. We retain Customer Personal Data for the retention period applicable to your plan and then delete it on a rolling basis. You can set a shorter period.

11.2 Deletion on request. When you delete a person, a project or an account through the Service, we delete the corresponding Customer Personal Data from active systems without undue delay.

11.3 When deletion is complete. Our analytical store is an append-only table format that retains prior snapshots so that queries in flight remain consistent. A deleted record is unreadable through the Service immediately, and ceases to exist in earlier snapshots and in encrypted backups as those expire on their normal cycles.

11.4 Quarantine. Events and properties that fail contract validation are held briefly in a diagnostic quarantine so you can fix your instrumentation (Terms §2.3). Quarantined data is never queryable as analytics, is not included in Aggregated Data, and is deleted on the cycle stated in Annex I.

11.5 What we keep anyway. We may retain Customer Personal Data where a law requires it. If we do, we will tell you, retain only what the law requires, retain it for no longer than required, and continue to apply this DPA to it for as long as we hold it.

12. Personal Data Breaches

12.1 Notice. We will notify you of a Personal Data Breach affecting Customer Personal Data without undue delay after becoming aware of it, at the email address of your account administrator — so keep it current.

12.2 What the notice contains, to the extent known at the time: the nature of the breach, the data affected, the likely consequences, the measures taken, and a contact point. We will supplement it as the investigation develops.

12.3 What we do. We investigate, take reasonable steps to contain and mitigate, and cooperate with you and provide reasonable assistance with your own notification obligations to regulators and data subjects.

12.4 What a notice is not. A notice under §12.1 is not an acknowledgement of fault or liability.

13. Impact assessments and prior consultation

We will provide reasonable assistance with your data protection impact assessments and any prior consultation with a supervisory authority, taking account of the nature of the processing and the information available to us. Our security documentation and this DPA are intended to answer most of it without a bespoke exercise.

14. Audits and compliance verification

14.1 Documentation first. On written request, and no more than once in any 12-month period, we will provide our then-current security documentation and third-party audit reports or certifications where we hold them, and will respond to a reasonable security questionnaire.

14.2 Certifications discharge the obligation. Where we hold a current third-party audit report or certification covering the Service, providing it satisfies our obligation to make available the information necessary to demonstrate compliance with this DPA, unless you identify a specific matter it does not address.

14.3 An audit where that isn’t enough. Where the material in §14.1 does not reasonably allow you to verify our compliance with this DPA, or where you are required to audit by a supervisory authority, you may audit us — on 30 days’ written notice, no more than once in any 12-month period except after a Personal Data Breach affecting your Customer Personal Data or where a supervisory authority directs it, during business hours, without unreasonably disrupting the Service, and at your cost. Any auditor must be independent of our competitors and bound by confidentiality at least as protective as Terms §8.

14.4 What an audit does not reach. Our Subprocessors’ facilities, other customers’ data, and anything that would breach a duty of confidentiality we owe someone else. For Subprocessors, we will provide what our own contracts and their published documentation let us provide.

15. Return and deletion at the end

15.1 For 30 days after the Terms end, you can export Customer Data through our export tools (Terms §10.5).

15.2 We then delete Customer Personal Data within 60 days after the end of that period, subject to the snapshot and backup timelines in §11.3 and any retention §11.5 requires.

15.3 On written request made within the retrieval period, we will confirm the deletion in writing.

15.4 Aggregated Data and patterns derived before termination are retained under Terms §4.5 to §4.7 and §5 of this DPA.

16. International transfers

16.1 Where processing happens. Customer Personal Data is processed in the locations stated on the subprocessor list, which is the single source for where each Subprocessor processes and which we may update under §8. Our data plane runs on a global edge network, so an event may be received and validated in the region closest to your End User before being stored. We do not commit to a storage region under this DPA — see §16.7.

16.2 Transfer mechanism. Where Applicable Data Protection Law restricts the transfer, the following apply, in this order, to the extent each is a valid mechanism at the relevant time:

(a) any adequacy decision, certification or framework we have certified to and that covers the transfer, as stated on the subprocessor list; then

(b) the SCCs, the UK Addendum and the Swiss adaptations, as completed by §16.3 to §16.5.

16.3 The SCCs, incorporated by reference and completed as follows:

• Module Two (controller to processor) applies where you are a controller. Module Three (processor to processor) applies where you are a processor under §1.4.
• You are the data exporter; 77Sparx Studio, Inc. is the data importer.
• Clause 7 (docking clause) does not apply.
• Clause 9: Option 2, general written authorisation, with the 14-day notice period in §8.2.
• Clause 11: the optional independent dispute resolution body does not apply.
• Clause 17: the SCCs are governed by the law of Ireland.
• Clause 18(b): disputes are resolved before the courts of Ireland.
• Annex I, II and III to the SCCs are Annexes I, II and III to this DPA. The competent supervisory authority for Clause 13 is the one stated in Annex I.

16.4 UK transfers. The UK Addendum applies to transfers subject to the UK GDPR, with the SCCs as completed in §16.3 as its Approved EU SCCs. Tables 1 to 3 are populated from the Annexes to this DPA, and in Table 4 the Importer may end the Addendum as set out in Section 19 of it.

16.5 Swiss transfers. The SCCs apply with these adaptations: the competent authority is the Federal Data Protection and Information Commissioner; references to the GDPR are read as references to the FADP; “member state” does not prevent a data subject in Switzerland from suing in Switzerland; and until the revised FADP is in force, the SCCs also protect the data of legal entities.

16.6 Conflict. If the SCCs or the UK Addendum conflict with this DPA or the Terms, the SCCs or the UK Addendum control for the transfer they govern.

16.7 No data residency commitment today. We do not currently offer a region-restricted deployment. If you need one, say so before you build on the Service; we will tell you where that stands rather than imply a commitment we cannot keep.

17. US state privacy laws

17.1 Service provider. We are your Service Provider under the CCPA and your processor under other US state privacy laws. We process Customer Personal Data only for the business purposes described in the Terms and Annex I, and §4.3 states the restrictions.

17.2 Deidentified information. Where we hold deidentified information — including Aggregated Data under §5 — we will maintain it in deidentified form, will not attempt to reidentify it except as permitted to test the effectiveness of our deidentification, and will contractually oblige recipients to the same.

17.3 Your rights over us. You may take reasonable and appropriate steps to ensure we use Customer Personal Data consistently with your obligations, and to stop and remediate our unauthorised use. §14 is how those steps are exercised. We will tell you if we determine we can no longer meet our obligations as a Service Provider.

17.4 Certification. We certify that we understand the restrictions in §4.3 and §17.1 and will comply with them.

18. Children’s data

Terms §4.4 places the whole of the children’s-data obligation on you: comply with COPPA and equivalent laws, obtain any parental consent required, and send no personal information from or about a child. We do not classify your apps as child-directed and hold no such flag.

19. General

19.1 Liability. Each party’s liability under this DPA is subject to the exclusions and the limitation of liability in Terms §9.6, and a reference there to a party’s liability means its total aggregate liability under the Terms and this DPA together. Nothing in this section limits a data subject’s rights under the SCCs.

19.2 Conflicts. If this DPA conflicts with the Terms, this DPA controls for the processing of Customer Personal Data. If it conflicts with the SCCs or the UK Addendum, §16.6 applies. An Order Form controls over this DPA only where it says so expressly and by reference to the section it varies.

19.3 Changes. We may update this DPA in line with Terms §12.2, and will give advance notice of a material change. A change will not reduce the protections in this DPA or in the SCCs below what Applicable Data Protection Law requires. Where a mechanism in §16 stops being valid, we will adopt a valid alternative without needing your agreement.

19.4 Severance and survival. An unenforceable provision is limited to the minimum extent necessary and the rest stands. §§5, 11.5, 15, 16 and 19.1 survive termination.

19.5 Notices. [email protected], or 77Sparx Studio, Inc., 2010 El Camino Real #2390, Santa Clara, CA 95050.

Annex I — Details of processing

A. List of parties

B. Description of transfer

Categories of data subjects. Customer’s End Users — the people who use Customer’s websites, applications and services and whose activity Customer instruments. Customer’s own Users where they appear in Customer Data.

Categories of personal data.

Client error data, specifically. Stack traces and error messages are generated by Customer’s own code and are the one category the Service cannot meaningfully validate in advance, because an exception message can contain anything the application put in it. Customer is responsible for scrubbing error payloads before they leave the SDK, and the SDK provides hooks for that.

Sensitive data. None. Terms §4.3 prohibits special category data, government identifiers, dates of birth, payment card and bank details, credentials and precise geolocation. No additional safeguards for sensitive data are agreed, because none is permitted to be transferred.

Frequency. Continuous, for the duration of the Terms.

Nature and purpose of the processing. Receiving, validating, enriching, sessionizing, storing and querying product analytics event data; identity resolution; experiment analysis; error aggregation; monitoring and alerting; AI-assisted analysis performed by the Service; computing per-customer rollups under §4.2 and §5.1; support and troubleshooting; security, abuse prevention and billing.

Retention.

Subprocessors. As listed at togohq.ai/subprocessors, processing for the duration of their engagement, for the purposes stated there.

Processing locations. As stated on the subprocessor list, per Subprocessor. This DPA does not fix a storage region — see §16.1 and §16.7.

C. Competent supervisory authority

The supervisory authority of the EEA member state in which the data exporter is established; where the exporter is not established in the EEA but has designated a representative under Article 27, the authority of that member state; otherwise the authority of a member state in which the data subjects whose personal data is transferred are located. Where none of those resolves, the Irish Data Protection Commission.

Annex II — Technical and organisational measures

Measures we implement and maintain, described as required by Clause 8.5 of the SCCs. §7.2 permits changes that do not materially reduce the overall level of security.

Pseudonymisation and data minimisation

• Declared-only ingestion: an event or property that is not in Customer’s Tracking Plan or our canonical taxonomy is rejected or quarantined at the edge rather than silently accepted.
• Event property values are primitives, with no nested structures, which constrains what an event row can carry.
• Identifying traits are held apart from event rows, so that erasure is a targeted delete rather than a rewrite of historical files.
• The tenant identifier is resolved from the write key and governs every write; it is never read from a request body.

Encryption

• In transit: TLS on every external interface.
• At rest: industry-standard encryption for the analytical store, the control-plane database, backups and object storage.
• Secrets and credentials are held in a managed secret store rather than in configuration or source.

Confidentiality, integrity, availability and resilience

• Tenant isolation at every layer: the tenant identifier is the first partition field on every tenant-scoped table, and queries are scoped by the session’s project rather than by a client-supplied field.
• Analytical queries are generated from a validated specification against a semantic layer rather than from free-form SQL.
• Managed infrastructure with provider-level redundancy, and regular encrypted backups.

Access control

• Least privilege, role-based, reviewed periodically.
• Multi-factor authentication on administrative systems.
• Unique named accounts, no shared credentials, and deprovisioning when an engagement ends.
• Administrative access to production is logged, and access to Customer Personal Data is limited to what support and operation of the Service require.
• Benchmark computation runs under a service account separate from customer query credentials and without access to organisation names, billing records, API keys or identity mappings.

Testing, monitoring and incident handling

• Automated dependency and vulnerability scanning in continuous integration.
• Platform-level monitoring and alerting on availability, error rates and anomalous access.
• Application, access and audit logging.
• Documented incident response with defined severities and post-incident review.

Data deletion

• Tenant deletion is a partition-level operation rather than a row-level rewrite.

Subprocessor governance

• Security and privacy review before engagement, contractual terms at least as protective as this DPA, and the public list and notice process in §8.

Organisational measures

• Confidentiality obligations on all personnel, and periodic security and privacy training.
• A named owner for privacy and security requests at [email protected].
• Change management with separation between development and production.

Annex III — Subprocessors

The current list is published at togohq.ai/subprocessors and is incorporated here. It states each Subprocessor’s name, role and processing location. The categories of Customer Personal Data are in Annex I and are not restated per Subprocessor. §8 governs changes to the list.

↑ Back to top