Behandlerbetingelser, vedlegg inkludert.

Dette tillegget for databehandling («DPA») er en del av tjenestevilkårene eller en annen skriftlig avtale («avtalen») mellom Digital Socket LLC, et aksjeselskap stiftet i Delaware, USA, som driver virksomhet under navnet Transglot («Transglot», «databehandler») og kunden («kunde», «behandlingsansvarlig»), og gjelder der vi behandler kundens personopplysninger på kundens vegne i forbindelse med levering av tjenesten. Det inkorporeres ved henvisning i avtalen og trer i kraft samtidig med avtalen; ingen signatur kreves for at det skal binde oss. Dersom kunden selv er databehandler som handler på vegne av en tredjeparts behandlingsansvarlig, er kunden eksportør, og dette DPA gjelder som om kunden var den behandlingsansvarlige. Kunden bekrefter at den har fullmakt fra sin egen behandlingsansvarlige til å inngå dette på disse vilkårene.

«Databeskyttelseslovgivning» betyr all lovgivning om behandling av personopplysninger som gjelder for en part, inkludert EUs generelle personvernforordning 2016/679 («GDPR»), UK GDPR og Data Protection Act 2018, den sveitsiske føderale loven om databeskyttelse, California Consumer Privacy Act med endringer («CCPA») og sammenlignbare delstatslover om personvern i USA. «Kundens personopplysninger» betyr personopplysninger som finnes i kundeinnhold eller som på annen måte behandles av oss på kundens vegne. «Standard kontraktsvilkår» eller «SCC-er» betyr vilkårene som er vedlagt kommisjonens gjennomføringsbeslutning (EU) 2021/914. «UK Addendum» betyr tillegget for internasjonale dataoverføringer utstedt av UK Information Commissioner i henhold til section 119A i Data Protection Act 2018. «Underleverandør» betyr en tredjepart engasjert av oss for å behandle kundens personopplysninger. «Behandlingsansvarlig», «databehandler», «registrert», «personopplysninger», «behandling», «brudd på personopplysningssikkerheten» og «tilsynsmyndighet» har den betydningen som er angitt i GDPR, og tilsvarende begreper i annen lovgivning har tilsvarende betydning.

Ved motstrid er rangeringen som følger: (a) standard kontraktsvilkår og UK Addendum, der de gjelder; (b) dette DPA; (c) eventuelle andre vilkår for databeskyttelse i en bestillingsblankett; (d) resten av avtalen. Intet i dette DPA er ment å komme i konflikt med en parts forpliktelser i henhold til databeskyttelseslovgivningen, og ethvert vilkår som ville gjort det, tolkes ned til det minste omfanget som trengs for å fjerne konflikten.

Dette DPA gjelder fra avtalens ikrafttredelsesdato til vi ikke lenger innehar noen av kundens personopplysninger, noe som kan være etter at avtalen er avsluttet på grunn av slettingsfristene i klausul 13. Forpliktelsene overlever oppsigelsen så lenge vi innehar noen av kundens personopplysninger, og taushetsplikten overlever på ubestemt tid i den grad det kreves av databeskyttelseslovgivningen.

Vi behandler kundens personopplysninger kun i samsvar med kundens dokumenterte instruksjoner, inkludert for overføring til et tredjeland, med mindre vi er pålagt å gjøre det i henhold til lov som vi er underlagt. I så fall vil vi informere kunden om dette kravet før behandling, med mindre loven forbyr det av viktige hensyn til allmennhetens interesser. Avtalen, dette DPA, dokumentasjonen og konfigurasjonen kunden setter i produktet (prosjekter, språk, koblinger, webhook-abonnementer, innstillinger for lagring, bryteren for oversettelsesminne samt motor- og kvalitetsinnstillingene som er tilgjengelige for kunden) utgjør samlet sett kundens fullstendige dokumenterte instruksjoner. Vi vil informere kunden dersom vi etter vår mening mener at en instruksjon bryter med databeskyttelseslovgivningen, og vi kan suspendere den berørte behandlingen til instruksjonen trekkes tilbake eller endres, fremfor å utføre den.

Vi behandler kundens personopplysninger utelukkende for å levere, sikre, støtte og vedlikeholde tjenesten for kunden, og ikke for noen uavhengig formål fra vår side. Vi selger ikke kundens personopplysninger, vi deler dem ikke for atferdsbasert annonsering på tvers av kontekster, vi kombinerer dem ikke med personopplysninger vi mottar fra andre kilder, bortsett fra slik det er tillatt i henhold til databeskyttelseslovgivningen for en tjenesteleverandør, og vi bruker dem ikke til å trene, finjustere eller evaluere noen maskinlæringsmodell. Våre AI-underleverandører behandler dem kun for inferens, under kommersielle vilkår som forbyr trening på dem. Vi kan lage og bruke aggregerte eller anonymiserte statistikker som ikke identifiserer hverken kunden eller noen registrert, og vi vil ikke forsøke å re-identifisere dem.

Vi sikrer at enhver person som er autorisert til å behandle kundens personopplysninger, er underlagt en passende taushetsplikt, enten kontraktuell eller lovbestemt, som overlever slutten på deres engasjement. Tilgang gis på prinsippet om minst mulig privilegier, begrenset til det en person trenger for å utføre sin rolle, gjennomgås periodisk og trekkes tilbake promptly ved rolleendring eller fratreden. Personell med tilgang mottar opplæring i databeskyttelse og sikkerhet som er tilpasset deres rolle.

Vi implementerer og opprettholder de tekniske og organisatoriske tiltakene som er angitt i vedlegg II, med tanke på det nyeste innen teknologi, implementeringskostnadene og arten, omfanget, konteksten og formålene med behandlingen, samt risikoen for de registrerte. Vi kan oppdatere disse tiltakene over tid, forutsatt at det samlede beskyttelsesnivået ikke reduseres vesentlig i løpet av en betalt abonnementsperiode. Vedlegg II angir bevisst både våre mangler og våre kontroller: et vedlegg for tiltak som kun lister opp styrker, er ikke et dokument en reviewer kan stole på.

Kunden gir en generell skriftlig autorisasjon for at vi skal engasjere underleverandører, i kategoriene beskrevet i dokumentet om underleverandører, og autoriserer spesifikt de som er oppført i underleverandørlisten fremlagt under vedlegg III per ikrafttredelsesdatoen. Vi pålegger hver underleverandør databeskyttelsesforpliktelser som er minst like beskyttende som de i dette DPA, gjennom en skriftlig kontrakt, og vi forblir fullt ansvarlige overfor kunden for en underleverandørs oppfyllelse av sine forpliktelser. Vi vil gi kunden minst tretti dagers varsel, via e-post til kontoeierne, før en ny underleverandør begynner å behandle kundens personopplysninger. Kunden kan gjøre innsigelse på rimelige, dokumenterte databeskyttelsesgrunner innen denne perioden, i hvilket tilfelle vi vil arbeide i god tro for å tilby en endring i konfigurasjon eller et alternativ som unngår behandlingen; dersom vi ikke klarer dette innen rimelig tid, kan kunden si opp det berørte abonnementet uten straff og motta en forholdsmessig refusjon av forhåndsbetalte, ubrukte avgifter.

Med hensyn til arten av behandlingen bistår vi kunden med passende tekniske og organisatoriske tiltak, så langt dette er mulig, for å oppfylle kundens plikt til å svare på en registrert som utøver rettigheter til innsyn, retting, sletting, begrensning, portabilitet eller innsigelse. Produktet selv er den første linjen i denne bistanden: Konto-eiere og arbeidsområde-administratorer kan søke, redigere og slette prosjektinnhold, administrere medlemmer og roller, og hente prosjektinnhold gjennom API-endepunktet for pulling, kommandolinjegrensesnittet, leveringspakken eller en lagringskobling på en betalt plan, og konto-eierne kan slette arbeidsområdet. Der produktet ikke kan besvare en forespørsel, vil vi hjelpe på forespørsel innen rimelig tid og uten kostnad for et rimelig volum av forespørsler. Hvis en registrert kontakter oss direkte om kunde-personopplysninger, vil vi ikke svare substantielt selv; vi vil be dem kontakte kunden og, med mindre det er forbudt, informere kunden umiddelbart.

Med hensyn til arten av behandlingen og informasjonen som er tilgjengelig for oss, bistår vi kunden i å oppfylle sine forpliktelser etter artiklene 32 til 36 i GDPR og deres ekvivalenter, inkludert konsekvensvurderinger for personvern og forhåndskonsultasjon med en tilsynsmyndighet. I praksis betyr det å tilby denne databehandleravtalen, Vedlegg II, Trust Center-opplysningene, oppbevaringsplanen i personvernerklæringen, vår sikkerhetsdokumentasjon og rimelige skriftlige svar på et sikkerhets- eller personvernspørreskjema. Vi kan ta betalt for bistand som går vesentlig utover et rimelig volum, til våre gjeldende priser for profesjonelle tjenester, og vi vil si ifra om dette før arbeidet utføres, ikke etterpå.

Vi varsler kunden uten unødig forsinkelse, og under alle omstendigheter innen sytti-to timer, etter at vi blir kjent med et personvernbrudd som påvirker kunde-personopplysninger. Varselet beskriver, i den utstrekning det er kjent på tidspunktet og oppdatert etter hvert som vi lærer mer: arten av bruddet, inkludert der det er mulig kategoriene og det omtrentlige antallet berørte registrerte og poster; de sannsynlige konsekvensene; tiltakene som er tatt eller foreslått for å håndtere det og dempe effektene; og et kontaktpunkt for ytterligere informasjon. Vi samarbeider med kunden og tar de trinnene kunden rimelig ber om for å bistå i deres egen etterforskning og varsling. Et varsel er ikke, og skal ikke tolkes som, en innrømmelse av feil eller ansvar. Vi vil ikke forsinke et varsel for å fullføre en etterforskning først.

Etter kundens valg sletter eller returnerer vi kunde-personopplysninger ved avslutningen av tjenesteleveransen, og sletter eksisterende kopier, med mindre en lov vi er underlagt krever lagring. I produktet fungerer det slik: kansellering av et abonnement flytter kontoen til Gratis-planen, som inkluderer ett arbeidsområde, og alle andre arbeidsområder blir skrivebeskyttet og slettes 30 dager senere, eller tidligere for et arbeidsområde som nylig har gått gjennom det samme som klausul 13 i tjenestevilkårene beskriver, med mindre kunden oppgraderer eller flytter det først; sletting av et arbeidsområde gjør det skrivebeskyttet i 30 dager, hvor en konto-eier kan gjenopprette det, og etter den perioden renses arbeidsområdet fra live-databasen, inkludert prosjekter, oversettelser, versjonshistorikk, brukslogger, webhook-leveringslogger, skjermbilder og revisjonshendelser; stenging av kontoen sletter alle arbeidsområder på den på samme måte og beholder kontoens fakturaer i 7 år; sletting av en brukers innlogging er umiddelbar og irreversibel. Innhold kunden henter gjennom API-et, kommandolinjegrensesnittet, leveringspakken eller en lagringskobling er ute av våre hender fra øyeblikket vi leverer det. Krypterte sikkerhetskopier nås ikke av rensingen og utløper etter tidsplanene i Vedlegg II; mens de eksisterer er de isolerte, krypterte og gjenopprettes kun for katastrofegjenoppretting, aldri for å returnere et renset arbeidsområde til tjeneste. En skriftlig forespørsel om returnering i et strukturert format gjort før sletting vil bli honorert én gang, uten kostnad, innen rimelig tid.

Vi gjør informasjon som er rimelig nødvendig for å demonstrere overholdelse av denne DPA-en og artikkel 28 i GDPR, tilgjengelig for Kunden, og vi legger til rette for og bidrar til revisjoner, inkludert inspeksjoner, som utføres av Kunden eller en revisor Kunden har utpekt. Denne forpliktelsen oppfylles i første omgang gjennom denne DPA-en, vedlegg II, Trust Center, sikkerhetssiden og våre utfylte svar på sikkerhetsundersøkelser. Dersom disse virkelig er utilstrekkelige for Kundens regulatoriske forpliktelser, kan Kunden gjennomføre én revisjon i løpet av enhver tolv måneders periode, med minst tretti dagers skriftlig varsel, i arbeidstiden, uten urimelig forstyrrelse av vår drift, underlagt taushetsplikter, begrenset til systemer og registre knyttet til Kundens egne data, og for Kundens regning. Et tilsynsorgan som utøver en lovfestet myndighet, er ikke underlagt noen av disse begrensningene. En revisor kan ikke være en konkurrent av oss, og vi kan kreve en separat taushetserklæring fra dem.

Dersom vår behandling av Kundens personopplysninger innebærer en overføring fra Det europeiske økonomiske samarbeidsområdet til et land som ikke er dekket av en adekvansbeslutning, er standard kontraktsvilkår innlemmet i og utgjør en del av denne DPA-en og gjelder som følger. Modul to (behandlingsansvarlig til databehandler) gjelder der Kunden er behandlingsansvarlig. Modul tre (databehandler til databehandler) gjelder der Kunden selv er databehandler. Klausul 7 (tilkoblingsklausulen) gjelder. I klausul 9 er alternativ 2 (generell skriftlig autorisasjon) valgt, med varslingsfristen angitt i klausul 09 ovenfor. I klausul 11 er den valgfrie språkformen for uavhengig tvisteløsning ikke valgt. I klausul 17 styres vilkårene av lovgivningen i Republikken Irland, med mindre partene avtaler lovgivningen i en annen EU-medlemsstat i en bestillingsformular. I klausul 18(b) løses tvister for domstolene i Republikken Irland på samme grunnlag. Vedlegg I(A) omfatter partene, vedlegg I(B) beskriver overføringen, vedlegg I(C) angir det kompetente tilsynsorganet, vedlegg II omhandler tekniske og organisatoriske tiltak, og vedlegg III er listen over underdatabehandlere, hver som angitt nedenfor.

For en overføring som er underlagt UK GDPR, er UK-tillegget innlemmet og utfylt som følger: Tabell 1 utfylles av vedlegg I(A); tabell 2 og 3 utfylles av klausul 15 og vedlegg I og II i denne DPA-en, med de godkjente EU-standardkontraktsvilkårene som den versjonen det støttes på; og i tabell 4 kan ingen av partene si opp tillegget når det godkjente tillegget endres. For en overføring som er underlagt sveitsisk lov, leses henvisninger i standardkontraktsvilkårene til GDPR som henvisninger til den sveitsiske føderale loven om databeskyttelse, den kompetente myndigheten er den føderale kommissæren for databeskyttelse og informasjon, henvisninger til en medlemsstat fratar ikke en registrert i Sveits retten til å saksøke på sitt vanlige bosted, og standardkontraktsvilkårene beskytter dataene til juridiske enheter inntil sveitsisk lov ikke lenger krever det.

Hvis vi mottar en juridisk bindende forespørsel fra en offentlig myndighet om Kundens personopplysninger, vil vi: gjennomgå den for gyldighet og omfang, og bestride den dersom det er rimelig grunn til å anse den som ulovlig; kun utlevere det minimum som forespørselen krever; og varsle Kunden raskt med nok detaljer til å kunne svare, med mindre det er juridisk forbudt, i hvilket tilfelle vi vil bruke rimelige anstrengelser for å oppnå unntak fra forbudet og søke om en midlertidig tillatelse som muliggjør utlevering. Vi fører oversikt over forespørslene vi mottar og svarene vi gir, og vi gjør denne tilgjengelig for Kunden og for et tilsynsorgan på forespørsel i den grad loven tillater det. Vi har ikke mottatt noen regjeringsforespørsel som krevde at vi bygde eller opprettholdt en generell tilgangsmekanisme til Kundens personopplysninger, og vi vil ikke bygge en slik frivillig.

For personopplysninger som er underlagt CCPA, er Kunden virksomheten og vi er en tjenesteleverandør. Vi er forhindret fra, og vil ikke, selge eller dele disse personopplysningene; beholde, bruke eller utlevere dem for noe annet formål enn forretningsformålene spesifisert i avtalen eller som ellers tillatt av CCPA; beholde, bruke eller utlevere dem utenfor det direkte forretningsforholdet mellom partene; eller kombinere dem med personopplysninger mottatt fra en annen kilde, unntatt der CCPA tillater en tjenesteleverandør å gjøre dette. Vi bekrefter at vi forstår og vil overholde disse begrensningene. Vi vil varsle Kunden dersom vi fastslår at vi ikke lenger kan overholde dem. Kunden kan ta rimelige og hensiktsmessige skritt for å stoppe og utbedre uautorisert bruk, ved å bruke revisjonsrettighetene i klausul 14. Vi tilbyr samme nivå av personvernbeskyttelse som CCPA krever av virksomheten.

Der en omfattende delstatslov om personvern gjelder og krever en databehandleravtale med spesifiserte vilkår, er denne DPA-en den avtalen: den angir arten og formålet med behandlingen, typen data, varigheten, rettighetene og forpliktelsene til begge parter, vår taushetsplikt, vår engasjering av underdatabehandlere under tilsvarende skriftlige vilkår, vår bistand med forespørsler om forbrukerrettigheter og med sikkerhetsforpliktelser, vår plikt til sletting eller returnering ved avslutning av tjenestene, og vår forpliktelse til å gjøre informasjonen som trengs for å demonstrere overholdelse, tilgjengelig og tillate en rimelig vurdering. Vi handler som databehandler eller tjenesteleverandør under disse lovene og aldri som behandlingsansvarlig for Kundens personopplysninger.

Hver parts ansvar som oppstår ut av eller er relatert til denne DPA-en, enten i kontrakt, erstatningsrett eller annen teori, er underlagt begrensningene og unntakene fra ansvar i avtalen, og enhver henvisning i disse begrensningene til en parts ansvar betyr den samlede ansvarsbegrensningen for den parten under både avtalen og denne DPA-en. Ingenting i denne klausulen begrenser en registrerts rettigheter under standard kontraktsvilkår eller under databeskyttelseslovgivningen, og ingenting begrenser et ansvar som ikke lovlig kan begrenses.

Vi kan oppdatere denne DPA-en der det er nødvendig for å gjenspeile en endring i databeskyttelseslovgivningen, en ny eller endret overføringsmekanisme, en avgjørelse fra et tilsynsorgan eller en domstol, eller en vesentlig endring i hvordan tjenesten behandler Kundens personopplysninger, forutsatt at oppdateringen ikke reduserer beskyttelsen gitt til Kundens personopplysninger vesentlig. Vi gir minst tretti dagers varsel om en vesentlig oppdatering, via e-post og på denne siden, og vi endrer ikrafttredelsesdatoen øverst. Vi holder den erstattede versjonen tilgjengelig på forespørsel.

Denne DPA-en binder oss uten signatur, så Kunden trenger ikke én for å være beskyttet. Hvis prosessen din krever en undertegnet motpart for dine arkiver, eller hvis du ønsker å fremme en merket versjon, skriv til privacy@transglot.ai med navn på juridisk enhet, registrert adresse, kontakt for varsling og signatar, og vi vil returnere en signert kopi. Vi svarer på spørreskjemaer om sikkerhet og personvern fra samme adresse, og Trust Center inneholder pakken de fleste anmeldere trenger før de skriver til noen.

Data exporter: the Customer, being the person or company that holds the Account, as named on 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 Owners' email addresses 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: Digital Socket LLC, et aksjeselskap stiftet i Delaware, USA, som driver virksomhet under navnet Transglot, 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 a login (Account Owners and Billing Members, and workspace admins, developers, reviewers and translators); 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, login identifier, Account, workspace 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 Account, workspace and project, and a cross-tenant identifier answers 404 rather than 403 so that the existence of another tenant’s record never leaks. The two Account roles (Owner and Billing), the four workspace roles (admin, developer, reviewer and 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 Account Owner can require a second factor for an entire workspace, enforced at the workspace 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 a workspace 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’s login 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 workspace 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, SCIM provisioning events, workspace rename and deletion requests. Plan, billing and spend cap changes, changes to the Account’s members and the closing of the Account are written to the Account’s own audit trail in the same way. Each record carries the workspace or the Account, 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; on the Account’s trail the IP address is removed after 395 days. On the Enterprise plan the whole trail, the Account’s included, can be exported as CSV. 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 3 hour window, password reset links expire after 60 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 a workspace 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, federated login correlation records at their own expiry, signup integrity signals 90 days after the Account was created or the pair was last seen, sign-up refusal records at 90 days, welcome words velocity records at 30 days for a domain and 24 hours for a network, sign-up allowlist entries at the expiry an operator set, never more than 365 days, Accounts never verified and holding no workspace at 30 days, welcome words, trial and card fingerprint records at 1,095 days, and the IP address on an Account’s audit trail at 395 days. Deletion runs in bounded batches rather than as one unbounded operation. Workspace deletion is a 30 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.

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.

Den autoritative, oppdaterte listen over underbehandlere vedlikeholdes av oss og gjøres tilgjengelig for Kunden på forespørsel under en taushetserklæring, ved å skrive til privacy@transglot.ai. Kategoriene, formålet, regionen og vilkårene som hver enkelt engasjeres under, publiseres i Trust Center og oppsummeres i dokumentet om underbehandlere, som er inkorporert i dette vedlegget gjennom henvisning. Den holdes på ett sted fremfor å bli duplisert inn i denne siden med hensikt: en liste som skrives inn på nytt i et juridisk dokument, er en liste som blir utdatert den dagen en leverandør endres, og et foreldet vedlegg er verre enn en lenke. Per ikrafttredelsesdatoen er kategoriene følgende: AI-oversettelse, automatisk kvalitetskontroll, ordlisteuttrekk og kontekstbaserte visuelle forslag, behandlet i USA og engasjert når en AI-funksjon brukes; tekstinnbygginger for semantisk oversettelsesminne, behandlet i USA og engasjert kun når et prosjekt slår på denne funksjonen, som er deaktivert som standard; en valgfri alternativ oversettelsesmotor nås via en API-ruter i USA og hostet i Singapore, engasjert kun når en operatør ruter et nivå til den, noe som er deaktivert som standard; skyhosting, databasen og objektlagring, i regionen fastlagt ved utrulling og alltid engasjert; betalingsbehandling, i USA og Den europeiske union, engasjert kun for betalte abonnementer; levering av transaksjons-e-post, alltid engasjert; og støtte-meldinger i produktet, engasjert kun når støttemeldingsfunksjonen er aktivert. Der en kunde oppgir sine egne legitimasjoner for en valgfri maskinoversettelses-reserve, er kunden behandlingsansvarlig for den overføringen, og leverandøren er ikke vår underbehandler.