Processor terms, annexes included.

This Data Processing Addendum ("DPA") forms part of the Terms of Service or other written agreement (the "Agreement") between the Transglot entity named on your order form or invoice ("Transglot", "Processor") and the customer ("Customer", "Controller"), and applies wherever we process Customer Personal Data on the Customer’s behalf in providing the Service. It is incorporated by reference into the Agreement and takes effect when the Agreement does; no signature is required for it to bind us. Where the Customer is itself a processor acting for a third party controller, the Customer is the exporter and this DPA applies as though it were the controller, and the Customer confirms it has authority from its own controller to enter into it on those terms.

"Data Protection Law" means all laws about the processing of personal data applicable to a party, including the EU General Data Protection Regulation 2016/679 ("GDPR"), the UK GDPR and Data Protection Act 2018, the Swiss Federal Act on Data Protection, the California Consumer Privacy Act as amended ("CCPA") and comparable United States state privacy laws. "Customer Personal Data" means personal data contained in Customer Content or otherwise processed by us on the Customer’s behalf. "Standard Contractual Clauses" or "SCCs" means the clauses annexed to Commission Implementing Decision (EU) 2021/914. "UK Addendum" means the International Data Transfer Addendum issued by the UK Information Commissioner under section 119A of the Data Protection Act 2018. "Subprocessor" means a third party engaged by us to process Customer Personal Data. "Controller", "processor", "data subject", "personal data", "processing", "personal data breach" and "supervisory authority" have the meanings given in the GDPR, and equivalent terms in other laws have their equivalent meaning.

In the event of a conflict, the order of precedence is: (a) the Standard Contractual Clauses and the UK Addendum, where they apply; (b) this DPA; (c) any other data protection terms in an Order Form; (d) the rest of the Agreement. Nothing in this DPA is intended to conflict with a party’s obligations under Data Protection Law, and any term that would do so is read down to the minimum extent needed to remove the conflict.

This DPA applies from the effective date of the Agreement until we no longer hold any Customer Personal Data, which may be after the Agreement ends because of the deletion timelines in clause 13. Its obligations survive termination for as long as we hold any Customer Personal Data, and the confidentiality obligations survive indefinitely to the extent required by Data Protection Law.

We process Customer Personal Data only on the Customer’s documented instructions, including for a transfer to a third country, unless required to do so by a law to which we are subject, in which case we will tell the Customer of that requirement before processing unless the law prohibits it on important grounds of public interest. The Agreement, this DPA, the Documentation and the configuration the Customer sets in the product (projects, locales, connectors, webhook subscriptions, retention switches, the translation memory switch and the engine and quality settings available to the Customer) together constitute the Customer’s complete documented instructions. We will tell the Customer if, in our opinion, an instruction infringes Data Protection Law, and we may suspend the affected processing until it is withdrawn or amended rather than carry it out.

We process Customer Personal Data solely to provide, secure, support and maintain the Service for the Customer, and for no independent purpose of our own. We do not sell Customer Personal Data, we do not share it for cross-context behavioural advertising, we do not combine it with personal data we receive from other sources except as permitted by Data Protection Law for a service provider, and we do not use it to train, fine-tune or evaluate any machine learning model. Our AI subprocessors process it for inference only, under commercial terms that prohibit training on it. We may create and use aggregated or de-identified statistics that identify neither the Customer nor any data subject, and we will not attempt to re-identify them.

We ensure that every person authorised to process Customer Personal Data is subject to an appropriate obligation of confidentiality, whether contractual or statutory, that survives the end of their engagement. Access is granted on a least privilege basis, limited to what a person needs to perform their role, reviewed periodically and revoked promptly on role change or departure. Personnel with access receive data protection and security training appropriate to their role.

We implement and maintain the technical and organisational measures set out in Annex II, 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 to data subjects. We may update those measures over time provided the overall level of protection is not materially reduced during a paid subscription period. Annex II states our gaps as well as our controls, deliberately: a measures annex that only lists strengths is not a document a reviewer can rely on.

The Customer gives a general written authorisation for us to engage Subprocessors, in the categories described in the Subprocessors document, and specifically authorises those in the subprocessor list furnished under Annex III as at the effective date. We impose on each Subprocessor data protection obligations no less protective than those in this DPA by way of a written contract, and we remain fully liable to the Customer for a Subprocessor’s performance of its obligations. We will give the Customer at least thirty days notice, by email to the notice contact, before a new Subprocessor begins processing Customer Personal Data. The Customer may object on reasonable, documented data protection grounds within that period, in which case we will work in good faith to offer a change in configuration or an alternative that avoids the processing; if we cannot within a reasonable time, the Customer may terminate the affected subscription without penalty and receive a pro-rata refund of prepaid unused fees.

Taking into account the nature of the processing, we assist the Customer by appropriate technical and organisational measures, insofar as this is possible, in fulfilling the Customer’s obligation to respond to a data subject exercising rights of access, rectification, erasure, restriction, portability or objection. The product itself is the first line of that assistance: an organization owner or admin can search, edit and delete project content, manage members and roles, delete the workspace, and retrieve project content through the API pull endpoint, the command line interface, the delivery bundle or a storage connector on a paid plan. Where the product cannot answer a request, we will help on request within a reasonable period and at no charge for a reasonable volume of requests. If a data subject contacts us directly about Customer Personal Data, we will not respond substantively ourselves; we will tell them to contact the Customer and, unless prohibited, tell the Customer promptly.

Taking into account the nature of processing and the information available to us, we assist the Customer in meeting its obligations under Articles 32 to 36 of the GDPR and their equivalents, including data protection impact assessments and prior consultation with a supervisory authority. In practice that means providing this DPA, Annex II, the Trust Center disclosures, the retention schedule in the Privacy Policy, our security documentation and reasonable written answers to a security or privacy questionnaire. We may charge for assistance that goes materially beyond a reasonable volume, at our then-current professional services rates, and we will say so before doing the work rather than afterwards.

We notify the Customer without undue delay, and in any event within seventy-two hours, after becoming aware of a personal data breach affecting Customer Personal Data. The notice describes, to the extent known at the time and updated as we learn more: the nature of the breach including where possible the categories and approximate number of data subjects and records concerned; the likely consequences; the measures taken or proposed to address it and to mitigate its effects; and a contact point for further information. We cooperate with the Customer and take the steps the Customer reasonably requests to assist in its own investigation and notification. A notice is not, and will not be construed as, an admission of fault or liability. We will not delay a notice in order to complete an investigation first.

At the Customer’s choice, we delete or return Customer Personal Data at the end of the provision of services, and delete existing copies, unless a law to which we are subject requires storage. In the product that works as follows: cancelling a subscription moves the workspace to the Free plan and deletes nothing; deleting a workspace starts a thirty day grace period during which it is read only and can be restored by an owner, and after that period the workspace is purged from the live database, including projects, translations, version history, usage records, webhook delivery records, screenshots and audit events; deleting a user account is immediate and irreversible. Content the Customer retrieves through the API, the command line interface, the delivery bundle or a storage connector is out of our hands from the moment we deliver it. Encrypted backups are not reached by the purge and expire on the schedules in Annex II; while they exist they are isolated, encrypted and restored only for disaster recovery, never to return a purged workspace to service. A written request for return in a structured format made before deletion will be honoured once, at no charge, within a reasonable period.

We make available to the Customer the information reasonably necessary to demonstrate compliance with this DPA and with Article 28 of the GDPR, and allow for and contribute to audits, including inspections, conducted by the Customer or an auditor it mandates. In the first instance that obligation is met by this DPA, Annex II, the Trust Center, the security page and our completed security questionnaire responses. Where those are genuinely insufficient for the Customer’s regulatory obligation, the Customer may audit once in any twelve month period, on at least thirty days written notice, during business hours, without unreasonably disrupting our operations, subject to confidentiality obligations, limited to systems and records relating to the Customer’s own data, and at the Customer’s cost. A supervisory authority exercising a statutory power is subject to none of those limits. An auditor may not be a competitor of ours, and we may require a separate confidentiality undertaking from them.

Where our processing of Customer Personal Data involves a transfer from the European Economic Area to a country not covered by an adequacy decision, the Standard Contractual Clauses are incorporated into and form part of this DPA and apply as follows. Module Two (controller to processor) applies where the Customer is a controller. Module Three (processor to processor) applies where the Customer is itself a processor. Clause 7 (the docking clause) applies. In Clause 9, Option 2 (general written authorisation) is selected, with the notice period stated in clause 09 above. In Clause 11, the optional independent dispute resolution language is not selected. In Clause 17, the Clauses are governed by the law of the Republic of Ireland unless the parties agree another EU member state law in an Order Form. In Clause 18(b), disputes are resolved before the courts of the Republic of Ireland on the same basis. Annex I(A) is the parties, Annex I(B) is the description of the transfer, Annex I(C) is the competent supervisory authority, Annex II is the technical and organisational measures, and Annex III is the list of subprocessors, each as set out below.

For a transfer subject to the UK GDPR, the UK Addendum is incorporated and completed as follows: Table 1 is completed by Annex I(A); Tables 2 and 3 are completed by clause 15 and Annexes I and II of this DPA, with the Approved EU SCCs as the version relied on; and in Table 4, neither party may end the Addendum when the Approved Addendum changes. For a transfer subject to Swiss law, references in the SCCs to the GDPR are read as references to the Swiss Federal Act on Data Protection, the competent authority is the Federal Data Protection and Information Commissioner, references to a member state do not deprive a data subject in Switzerland of the right to sue in their place of habitual residence, and the SCCs protect the data of legal entities until Swiss law no longer requires it.

If we receive a legally binding request from a public authority for Customer Personal Data, we will: review it for validity and scope and challenge it where there are reasonable grounds to consider it unlawful; disclose only the minimum the request requires; and notify the Customer promptly with enough detail to respond, unless legally prohibited, in which case we will use reasonable efforts to obtain a waiver of the prohibition and to seek an interim measure allowing disclosure. We keep a record of the requests we receive and the responses we give, and we make it available to the Customer and to a supervisory authority on request to the extent the law allows. We have not received a government request that required us to build or preserve a general access mechanism to Customer Personal Data, and we will not build one voluntarily.

For personal information subject to the CCPA, the Customer is the business and we are a service provider. We are prohibited from, and will not, sell or share that personal information; retain, use or disclose it for any purpose other than the business purposes specified in the Agreement or as otherwise permitted by the CCPA; retain, use or disclose it outside the direct business relationship between the parties; or combine it with personal information received from another source, except as the CCPA permits a service provider to do. We certify that we understand and will comply with these restrictions. We will notify the Customer if we determine that we can no longer meet them. The Customer may take reasonable and appropriate steps to stop and remediate unauthorised use, using the audit rights in clause 14. We provide the same level of privacy protection as the CCPA requires of the business.

Where a comprehensive state privacy law applies and requires a processor contract with specified terms, this DPA is that contract: it sets out the nature and purpose of processing, the type of data, the duration, the rights and obligations of both parties, our duty of confidentiality, our engagement of subprocessors under equivalent written terms, our assistance with consumer rights requests and with security obligations, our deletion or return duty at the end of the services, and our obligation to make available the information needed to demonstrate compliance and to permit a reasonable assessment. We act as a processor or service provider under those laws and never as a controller of Customer Personal Data.

Each party’s liability arising out of or related to this DPA, whether in contract, tort or any other theory, is subject to the limitations and exclusions of liability in the Agreement, and any reference in those limitations to the liability of a party means the aggregate liability of that party under the Agreement and this DPA together. Nothing in this clause limits a data subject’s rights under the Standard Contractual Clauses or under Data Protection Law, and nothing limits a liability that cannot lawfully be limited.

We may update this DPA where required to reflect a change in Data Protection Law, a new or amended transfer mechanism, a decision of a supervisory authority or a court, or a material change in how the Service processes Customer Personal Data, provided the update does not materially reduce the protection given to Customer Personal Data. We give at least thirty days notice of a material update, by email and on this page, and we change the effective date at the top. We keep the superseded version available on request.

This DPA binds us without a signature, so the Customer does not need one to be protected. If your process requires an executed counterpart for your records, or if you want to raise a redline, write to privacy@transglot.ai with the legal entity name, the registered address, the notice contact and the signatory, and we will return a signed copy. We answer security and privacy questionnaires from the same address, and the Trust Center carries the pack most reviewers need before they write to anybody.

Data exporter: the Customer, being the organization named in the account or on the Order Form, acting as controller (or as processor where clause 01 applies) in respect of Customer Personal Data processed through the Service. Contact details: the account owner’s email address and the notice contact given on the Order Form. Activities relevant to the transfer: use of a cloud localization platform to store, translate, review, deliver and manage software and content strings. Signature and date: as recorded by acceptance of the Agreement, or as executed under clause 22. Data importer: the Transglot entity named on your order form or invoice, acting as processor. Contact details: privacy@transglot.ai. Activities relevant to the transfer: provision of the Service described in the Agreement. Role: processor.

Categories of data subjects: the Customer’s personnel and contractors who hold an account (owners, admins, developers, translators, reviewers); the Customer’s own end users, customers and other individuals to the extent their personal data appears inside source strings, translations, glossary entries, comments, screenshots or imported files; and the Customer’s billing and notice contacts. Categories of personal data: identity and contact data (name, email address, account identifier, organization and role); authentication data (hashed password, second factor enrolment, federated identity subject identifiers, API token digests); usage and technical data (IP address, user agent, pages and endpoints accessed, request and run identifiers, timings, outcomes, error traces, audit records); billing data (billing contact, billing address, tax identifiers, payment method token and card metadata held by the payment processor); content data (whatever personal data the Customer chooses to place in project content, which is under the Customer’s control and which the Acceptable Use Policy asks the Customer to keep free of payment card data, government identifiers, credentials and special category data). Sensitive data: none is requested or required, and none should be submitted; where the Customer nonetheless submits it, the restrictions and safeguards are those in Annex II applied to all Customer Content, and the Customer remains responsible for its lawful basis. Frequency: continuous, for the duration of the Agreement, on the Customer’s instruction. Nature and purpose: hosting, storage, indexing, machine translation, quality checking, translation memory matching, glossary enforcement, review workflow, delivery and transmission through the API, webhooks, connectors and the delivery bundle, together with support, security and billing. Duration of processing: the term of the Agreement plus the retention periods stated in the Privacy Policy and clause 13 of this DPA. Subprocessor processing: for the purposes, and for the durations, set out in Annex III and in the Trust Center.

Where the SCCs apply on the basis of Article 3(1) of the GDPR, the competent supervisory authority is the one in the member state in which the data exporter is established. Where they apply because the exporter is not established in the European Economic Area but is caught by Article 3(2), the competent authority is the one in the member state in which the exporter’s Article 27 representative is established. Where they apply on the basis of Article 3(2) and no representative is appointed, the competent authority is the one in the member state in which the data subjects whose personal data is transferred are located. For UK transfers the competent authority is the Information Commissioner’s Office; for Swiss transfers, the Federal Data Protection and Information Commissioner.

Data in transit is protected with TLS 1.2 or better at the edge, and connections below that are refused. Passwords are hashed with bcrypt at a cost factor of 12 and are never stored or logged in plaintext. API tokens and delivery keys are stored as SHA-256 digests, are displayed once at creation and cannot be recovered afterwards; publishable in-context keys are deliberately public identifiers bound to an origin allowlist rather than secrets, and are documented as such. Third party credentials, connector tokens, SSO configuration secrets and webhook signing secrets are held in encrypted columns using authenticated application-level encryption. Database backups are encrypted with AES-256 by the backup tool itself, independently of any provider-side encryption, and file backups are held in a password-encrypted repository. Two honest gaps: the live database and application volumes are not disk-encrypted, and server-side encryption of the object store is not asserted in our own configuration. We state both here rather than letting a reviewer discover them in diligence.

Every query in the application is scoped by organization and project, and a cross-tenant identifier answers 404 rather than 403 so that the existence of another tenant’s record never leaks. Four organization roles (owner, admin, developer, translator), eighteen project abilities and per-project and per-language grants are available on every plan including Free, so least privilege is never a paid upgrade. Two-factor authentication with time-based one-time codes and recovery codes, and passkeys, are available on every plan, and an owner can require a second factor for the entire organization, enforced at the organization boundary so that federated and single sign-on doors cannot bypass it. SAML 2.0 single sign-on with just-in-time provisioning, generic OpenID Connect, SCIM 2.0 provisioning and de-provisioning, and the ability to switch off password login for an organization are available on the Enterprise plan. API access uses scoped tokens with optional expiry. Internal administrative access is least privilege, and operator impersonation of a customer account is time-limited to thirty minutes and writes an audit record when it starts and when it ends.

Security-relevant events are written to an append-only audit trail: sign-in and single sign-on events, second factor and organization MFA policy changes, member invitations, joins, role changes and removals, custom role changes, token and key creation and revocation, integration and connector connection and disconnection, review policy changes, branding changes, plan and spend limit changes, SCIM provisioning events, workspace rename and deletion requests. Each record carries the organization, the actor, the action, the target, structured metadata, the source IP address and the time, and the model layer refuses updates and deletes, so a record cannot be edited after the fact. Owners and admins on the Enterprise plan can export the whole trail as CSV. The honest limit: append-only is enforced in the application layer and there is no cryptographic hash chain or signature over the log, so we do not describe it as tamper-evident. Application errors are collected by an error tracker we host ourselves, configured not to send personally identifying information and not to capture request bodies, which is the setting that actually keeps customer strings out of a stack trace. Operational metrics are retained for thirty days.

Public endpoints are rate limited: the REST API at sixty requests a minute per token, the delivery endpoint at three hundred a minute per key and address, sign-in at five a minute per email and address, and registration at five a minute and twenty an hour per network block, with separate buckets for the other public doors. Outbound webhooks are signed HMAC-SHA256 over the timestamp and the raw body, sent as an explicit signature header and a timestamp header, and compared in constant time; the timestamp is published so the receiver can enforce its own replay window, and we are explicit that no server-side tolerance is enforced on our side. Inbound forge webhooks are verified by signature, with the delivery identifier as the replay guard. Cross site request forgery protection is applied to every state-changing browser request, sessions expire after 120 minutes of inactivity, sensitive actions require password re-confirmation within a three hour window, password reset links expire after sixty minutes, and destructive actions require typing the workspace name or re-entering a password. A frame-ancestors content security policy is applied; we do not claim a broad content security policy, because we do not yet ship one.

Usage metering records counts of words and tokens, never the body of a request. The shared exact-match translation memory pool stores the linguistic pair keyed by a hash of the source, together with plural forms and reuse counters, and stores no user column and no team column at all, so an entry cannot be traced to a person; the key name, file path, screenshots, comments and every other piece of surrounding context are stripped. Human-reviewed memory entries carry an organization identifier, which functions as a hard tenant fence on the near-match query rather than as attribution, and that is why a reviewed entry is never returned to another workspace. Any project can leave the pool entirely with a per-project switch on every plan, which stops it both contributing and drawing. In-context screenshots are held on a private store with no public path and are served only through short-lived signed URLs.

The database is backed up continuously with write-ahead log archiving and periodic full and differential backups, retaining two full backups and seven differentials, encrypted with AES-256 by the backup tool. Application file storage is snapshotted nightly into a password-encrypted repository retaining thirty daily, twelve weekly and twelve monthly snapshots, with an integrity verification pass on each run. Restore procedures are documented and exercised. Backups are isolated from the production credentials that could delete them, and they are restored for disaster recovery only, never to return a purged workspace to service. Deployment images are retained for the last several releases so that a rollback is a minute rather than a rebuild.

Changes are made through version control with peer review, an automated test suite, static analysis and dependency scanning, and container image vulnerability scanning in the build pipeline, and a failing gate blocks the release rather than warning about it. Test environments do not use production customer data. Secrets are held encrypted at rest in the deployment repository and injected at runtime rather than committed. Several product claims are themselves enforced by tests: a translation engine that becomes reachable without a subprocessor disclosure row fails the build, and the advertised overage rate is pinned to the rate the system charges. Third party components are tracked and patched, and a build is refused when a scanner reports a vulnerability above threshold.

Access to production is limited to the personnel who need it, granted individually, and removed on role change or departure. Personnel are bound by confidentiality obligations that survive their engagement, and receive security and data protection guidance appropriate to their role. We operate a documented incident response process with defined severities, an on-call rotation, alerting on service health and background job health, and post-incident review. We publish a vulnerability disclosure policy with a safe harbour for good faith research and a security address that is monitored. We hold no third party security certification today: a SOC 2 Type II audit is in progress and an AI management system standard is being pursued, and the compliance status published on our site is rendered from a configuration value that cannot show a certificate we do not hold.

Scheduled jobs enforce the retention windows published in the Privacy Policy rather than leaving them as intentions: translation version history at 180 days with a floor of the newest 20 per string, notifications at 90 days, resolved comment threads at 365 days from resolution, the activity feed at 180 days, assistant conversations at 90 days, in-context screenshots at 90 days with the stored object deleted alongside the record, connector sync records at 90 days keeping the latest per connection, referral click records at 90 days, unreviewed and unused translation memory entries at 90 days, failed background jobs at 7 days, expired API tokens 24 hours after they lapse, and federated login correlation records at their own expiry. Deletion runs in bounded batches rather than as one unbounded operation. Workspace deletion is a thirty day reversible grace period followed by a cascading purge of the live database. Webhook delivery records have no time-based prune today and are removed with their endpoint or their workspace, which is stated plainly here because a retention annex that omits the one uncapped table is worse than no annex.

For transfers to subprocessors we rely on the contractual measures in clause 15 together with these supplementary measures: transport encryption on every hop; contractual prohibitions on training, on onward transfer without equivalent protection, and on processing outside our instructions; a published and code-enforced disclosure list so that no undisclosed vendor can be routed customer text; the ability for a customer to disable the optional features that engage a conditional subprocessor, including the semantic translation memory feature and the per-project translation memory switch; retention windows enforced by scheduled jobs so that transferred data does not accumulate indefinitely; and the government access commitments in clause 17, including challenge, minimisation, notification and record keeping.

The authoritative, current list of subprocessors is maintained by us and furnished to the Customer on request under a non-disclosure agreement, by writing to privacy@transglot.ai. The categories, the purpose, the region and the condition under which each is engaged are published in the Trust Center and summarised in the Subprocessors document, which is incorporated into this Annex by reference. It is held in one place rather than duplicated into this page on purpose: a list retyped into a legal document is a list that goes out of date the day a vendor changes, and a stale annex is worse than a link. As at the effective date the categories are: AI translation, automated quality checking, glossary extraction and in-context vision suggestions, processed in the United States and engaged whenever an AI feature is used; text embeddings for semantic translation memory, processed in the United States and engaged only when a project turns that feature on, which is off by default; an optional alternative translation engine reached through an API router in the United States and hosted in Singapore, engaged only when an operator routes a tier to it, which is off by default; cloud hosting, the database and object storage, in the region fixed at deployment and engaged always; payment processing, in the United States and the European Union, engaged only for paid plans; transactional email delivery, engaged always; and in-product support messaging, engaged only when the support messenger is enabled. Where a customer supplies their own credentials for an optional machine translation fallback, the customer is the controller of that transfer and the vendor is not our subprocessor.