Умови обробника даних, додатки включено.

Ця Угода про обробку даних («DPA») є частиною Умов надання послуг або іншої письмової угоди («Угода») між Digital Socket LLC, товариство з обмеженою відповідальністю, зареєстроване в штаті Делавер, США, яке веде діяльність під торговою маркою Transglot («Transglot», «Процесор») та клієнтом («Клієнт», «Контролер») і застосовується скрізь, де ми обробляємо Персональні дані Клієнта від його імені під час надання Послуги. Вона включається до Угоди шляхом посилання і набирає чинності одночасно з Угодою; для того щоб вона була обов’язковою для нас, підпис не потрібен. Якщо Клієнт сам є процесором, який діє від імені стороннього контролера, Клієнт є експортером, і ця DPA застосовується так, ніби він є контролером, а Клієнт підтверджує, що має повноваження від свого власного контролера укладати її на таких умовах.

«Закон про захист даних» означає всі закони щодо обробки персональних даних, що застосовуються до сторони, включаючи Загальний регламент ЄС щодо захисту даних 2016/679 («GDPR»), британський GDPR і Закон про захист даних 2018 року, Швейцарський федеральний закон про захист даних, Каліфорнійський закон про конфіденційність споживачів із внесеними змінами («CCPA») та аналогічні закони штатів США про конфіденційність. «Персональні дані клієнта» означають персональні дані, що містяться в контенті клієнта або іншим чином обробляються нами від імені клієнта. «Стандартні договірні положення» або «SCC» означають положення, наведені у Виконавчому рішенні Комісії (ЄС) 2021/914. «Додаток для Великої Британії» означає Додаток до міжнародної передачі даних, виданий Уповноваженим з інформації Великої Британії відповідно до статті 119A Закону про захист даних 2018 року. «Субобробник» означає третю сторону, залучену нами для обробки персональних даних клієнта. Терміни «контролер», «обробник», «суб’єкт даних», «персональні дані», «обробка», «порушення безпеки персональних даних» та «наглядовий орган» мають значення, визначені в GDPR, а еквівалентні терміни в інших законах мають своє еквівалентне значення.

У разі виникнення суперечностей пріоритетність така: (a) Стандартні договірні положення та Додаток для Великої Британії, якщо вони застосовуються; (b) ця ДУОД; (c) будь-які інші умови щодо захисту даних у Формі замовлення; (d) решта Угоди. Жодне положення цієї ДУОД не має суперечити зобов’язанням сторони згідно із Законом про захист даних, і будь-який термін, який би це робив, тлумачиться в мінімально необхідному обсязі для усунення суперечності.

Ця ДУОД застосовується з моменту набрання чинності Угодою до моменту, коли ми більше не зберігаємо жодних персональних даних клієнта, що може статися після завершення Угоди через строки видалення, передбачені пунктом 13. Її зобов’язання залишаються чинними після припинення дії стільки часу, скільки ми зберігаємо будь-які персональні дані клієнта, а зобов’язання щодо конфіденційності залишаються чинними на невизначений термін у тій мірі, в якій цього вимагає Закон про захист даних.

Ми обробляємо персональні дані клієнта лише на основі документально зафіксованих інструкцій клієнта, включно з передачею до третьої країни, якщо інше не вимагається законом, якому ми підпорядковані; у такому випадку ми повідомимо клієнта про цю вимогу до початку обробки, якщо закон не забороняє це з важливих міркувань суспільного інтересу. Угода, ця ДУОД, Документація та конфігурація, налаштована клієнтом у продукті (проєкти, локалі, конектори, підписки на вебхуки, перемикачі збереження, перемикач пам’яті перекладів та доступні клієнту налаштування рушія та якості), разом становлять повний набір документально зафіксованих інструкцій клієнта. Ми повідомимо клієнта, якщо, на нашу думку, інструкція порушує Закон про захист даних, і ми можемо призупинити відповідну обробку до її скасування або зміни, а не виконувати її.

Ми обробляємо персональні дані клієнта виключно для надання, забезпечення безпеки, підтримки та супроводу Сервісу для клієнта і не маємо жодної незалежної власної мети. Ми не продаємо персональні дані клієнта, не передаємо їх для поведінкової реклами в різних контекстах, не поєднуємо їх із персональними даними, отриманими з інших джерел, окрім випадків, дозволених Законом про захист даних для постачальника послуг, і не використовуємо їх для навчання, доналаштування чи оцінки будь-яких моделей машинного навчання. Наші субобробники ШІ обробляють їх лише для висновків (inference) на комерційних умовах, які забороняють навчання на цих даних. Ми можемо створювати та використовувати агреговану або деідентифіковану статистику, яка не ідентифікує ні клієнта, ні жодного суб’єкта даних, і не намагатимемося їх повторно ідентифікувати.

Ми гарантуємо, що кожна особа, уповноважена обробляти персональні дані клієнта, зобов’язана дотримуватися належної конфіденційності, чи то на підставі договору, чи закону, і ця зобов’язаність зберігається після завершення їхньої участі. Доступ надається на основі принципу найменших привілеїв, обмежується тим, що необхідно особі для виконання її ролі, періодично переглядається та оперативно скасовується при зміні ролі або звільненні. Персонал, який має доступ, проходить навчання з питань захисту даних та безпеки, відповідне до його ролі.

Ми впроваджуємо та підтримуємо технічні й організаційні заходи, викладені в Додатку II, беручи до уваги сучасний рівень розвитку технологій, витрати на впровадження, а також характер, обсяг, контекст і цілі обробки, а також ризики для суб’єктів даних. Ми можемо оновлювати ці заходи з часом, за умови, що загальний рівень захисту не буде суттєво знижено протягом періоду платної підписки. Додаток II свідомо містить як наші прогалини, так і наші засоби контролю: додаток до заходів, який перелічує лише сильні сторони, не є документом, на який рецензент може покладатися.

Клієнт надає загальний письмовий дозвіл нам залучати субобробників у категоріях, описаних у документі «Субобробники», і конкретно дозволяє тих, хто внесений до списку субобробників, наданого в Додатку III на дату набрання чинності. Ми накладаємо на кожного субобробника зобов’язання щодо захисту даних, які є не менш захищеними, ніж ті, що передбачені цією ДУОД, шляхом укладення письмового договору, і ми несемо повну відповідальність перед клієнтом за виконання субобробником своїх зобов’язань. Ми повідомимо клієнта щонайменше за тридцять днів електронною поштою Власникам облікового запису перед тим, як новий субобробник розпочне обробку персональних даних клієнта. Клієнт може заперечити на підставі обґрунтованих, документально підтверджених причин, пов’язаних із захистом даних, протягом цього періоду, і в такому разі ми сумлінно працюватимемо над тим, щоб запропонувати зміну конфігурації або альтернативу, яка уникає такої обробки; якщо ми не зможемо зробити це протягом розумного часу, клієнт може припинити дію відповідної підписки без штрафів і отримати пропорційне повернення попередньо оплачених невикористаних коштів.

З урахуванням характеру обробки ми надаємо Клієнту допомогу шляхом застосування відповідних технічних та організаційних заходів, наскільки це можливо, у виконанні зобов’язання Клієнта відповідати на запити суб’єкта даних щодо здійснення прав на доступ, виправлення, видалення, обмеження, перенесення або заперечення. Сам продукт є першою лінією такої допомоги: власники акаунтів та адміністратори робочих просторів можуть шукати, редагувати та видаляти вміст проєктів, керувати учасниками та ролями, а також отримувати вміст проєктів через кінцеву точку API для витягування даних, інтерфейс командного рядка, пакет доставки або конектор сховища на платному тарифі, а власники акаунтів можуть видаляти робочий простір. Якщо продукт не може відповісти на запит, ми надамо допомогу за запитом протягом розумного строку та безкоштовно для розумного обсягу запитів. Якщо суб’єкт даних звертається до нас безпосередньо щодо персональних даних Клієнта, ми не надаватимемо суттєвої відповіді самостійно; ми направимо його до Клієнта та, якщо це не заборонено, негайно повідомимо Клієнта.

З урахуванням характеру обробки та інформації, доступної нам, ми допомагаємо Клієнту виконувати його зобов’язання згідно зі статтями 32–36 GDPR та їх еквівалентами, включаючи оцінку впливу на захист даних та попередні консультації з наглядовим органом. На практиці це означає надання цього DPA, Додатка II, розкриття інформації в Центрі довіри, графіка зберігання даних у Політиці конфіденційності, нашої документації з безпеки та обґрунтованих письмових відповідей на анкету з питань безпеки чи конфіденційності. Ми можемо стягувати плату за допомогу, яка суттєво перевищує розумний обсяг, за нашими поточними ставками на професійні послуги, і повідомимо про це до початку роботи, а не після.

Ми повідомляємо Клієнта без необґрунтованої затримки, а в будь-якому разі протягом сімдесяти двох годин після того, як дізналися про порушення персональних даних, що стосується персональних даних Клієнта. Повідомлення описує, наскільки відомо на той момент, і оновлюється в міру отримання нової інформації: характер порушення, включаючи, де можливо, категорії та приблизну кількість відповідних суб’єктів даних і записів; ймовірні наслідки; заходи, вжиті або запропоновані для усунення порушення та пом’якшення його наслідків; а також контактну особу для отримання додаткової інформації. Ми співпрацюємо з Клієнтом і вживаємо кроків, яких розумно вимагає Клієнт, щоб допомогти йому у власному розслідуванні та повідомленні. Повідомлення не є і не тлумачиться як визнання провини чи відповідальності. Ми не будемо затримувати повідомлення, щоб спочатку завершити розслідування.

За вибором Клієнта ми видаляємо або повертаємо персональні дані Клієнта після завершення надання послуг і видаляємо наявні копії, якщо закон, якому ми підпорядковані, не вимагає їх зберігання. У продукті це працює так: скасування підписки переводить акаунт на безкоштовний тариф, який включає один робочий простір, а всі інші робочі простори стають доступними лише для читання та видаляються через 30 днів, або раніше для робочого простору, який нещодавно пройшов через ту саму процедуру, як описано в пункті 13 Умов надання послуг, якщо Клієнт не оновить тариф або не перемістить його beforehand; видалення робочого простору робить його доступним лише для читання протягом 30 днів, протягом яких власник акаунту може його відновити, а після цього періоду робочий простір очищається з активної бази даних, включаючи проєкти, переклади, історію версій, записи використання, записи доставки вебхуків, скріншоти та події аудиту; закриття акаунту видаляє всі робочі простори на ньому таким самим чином і зберігає рахунки-фактури акаунту протягом 7 років; видалення облікового запису користувача є миттєвим і незворотним. Вміст, який Клієнт отримує через API, інтерфейс командного рядка, пакет доставки або конектор сховища, виходить з-під нашого контролю з моменту його доставки. Зашифровані резервні копії не підпадають під очищення і мають термін дії згідно з графіками в Додатку II; поки вони існують, вони ізольовані, зашифровані та відновлюються лише для аварійного відновлення, ніколи для повернення очищеного робочого простору в роботу. Письмовий запит на повернення у структурованому форматі, зроблений перед видаленням, буде виконаний один раз, безкоштовно, протягом розумного строку.

Ми надаємо Клієнту інформацію, обґрунтовано необхідну для демонстрації відповідності цьому DPA та статті 28 GDPR, і дозволяємо проводити та сприяємо аудитам, включаючи перевірки, які проводяться Клієнтом або уповноваженим ним аудитором. Насамперед це зобов’язання виконується через цей DPA, Додаток II, Центр довіри, сторінку безпеки та наші заповнені відповіді на анкету з безпеки. Якщо цього дійсно недостатньо для виконання регуляторних зобов’язань Клієнта, Клієнт може провести аудит один раз протягом будь-якого дванадцятимісячного періоду, попередивши письмово щонайменше за тридцять днів, у робочий час, без необґрунтованого порушення наших операцій, за умови дотримання зобов’язань щодо конфіденційності, обмежуючись системами та записами, що стосуються власне даних Клієнта, і за рахунок Клієнта. Наглядовий орган, який здійснює статутні повноваження, не підпадає під ці обмеження. Аудитор не може бути нашим конкурентом, і ми можемо вимагати від нього окремого зобов’язання про конфіденційність.

Якщо наша обробка Персональних даних Клієнта передбачає передачу з Європейської економічної зони до країни, на яку не поширюється рішення про адекватність, Стандартні договірні положення включаються до цієї Угоди про обробку даних (DPA) і є її невід’ємною частиною та застосовуються таким чином. Модуль два (від контролера до процесора) застосовується, якщо Клієнт є контролером. Модуль три (від процесора до процесора) застосовується, якщо Клієнт сам є процесором. Застосовується положення 7 (положення про приєднання). У положенні 9 обрано Варіант 2 (загальний письмовий дозвіл) із періодом повідомлення, зазначеним у положенні 09 вище. У положенні 11 додаткова мова про незалежне вирішення спорів не обрана. Положення 17 регулюється законодавством Республіки Ірландія, якщо сторони не домовляться про законодавство іншої держави-члена ЄС у Формі замовлення. Відповідно до положення 18(b), спори вирішуються судами Республіки Ірландія на тій самій підставі. Додаток I(A) містить інформацію про сторони, Додаток I(B) — опис передачі, Додаток I(C) — компетентний наглядовий орган, Додаток II — технічні та організаційні заходи, а Додаток III — список субпроцесорів, як зазначено нижче.

Для передачі, що підпадає під дію UK GDPR, Додаток Великої Британії включається та заповнюється таким чином: Таблиця 1 заповнюється на основі Додатка I(A); Таблиці 2 і 3 заповнюються на основі положення 15 та Додатків I і II цієї Угоди про обробку даних (DPA), де як версія, на яку посилаються, використовуються Затверджені стандартні договірні положення ЄС; а в Таблиці 4 жодна зі сторін не може припинити дію Додатка у разі змін до Затвердженого додатка. Для передачі, що підпадає під дію швейцарського законодавства, посилання в Стандартних договірних положеннях на GDPR читаються як посилання на Федеральний закон Швейцарії про захист даних, компетентним органом є Федеральний уповноважений із захисту даних та інформації, посилання на державу-член не позбавляють суб’єкта даних у Швейцарії права подавати позов за місцем свого звичайного проживання, а Стандартні договірні положення захищають дані юридичних осіб, доки швейцарське законодавство більше цього не вимагає.

Якщо ми отримуємо юридично обов’язковий запит від державного органу щодо Персональних даних Клієнта, ми: перевіряємо його на дійсність та обсяг і оскаржуємо його, якщо є розумні підстави вважати його незаконним; розголошуємо лише мінімальний обсяг даних, необхідний для виконання запиту; та негайно повідомляємо Клієнта, надаючи достатньо деталей для відповіді, якщо це не заборонено законом, у такому випадку ми докладаємо розумних зусиль для отримання скасування заборони та вжиття тимчасових заходів, що дозволяють розголошення. Ми ведемо облік отриманих запитів і наданих відповідей та надаємо їх Клієнту та наглядовому органу за запитом у межах, дозволених законом. Ми не отримували урядових запитів, які вимагали б від нас створення або збереження загального механізму доступу до Персональних даних Клієнта, і не будемо створювати такий механізм добровільно.

Щодо персональної інформації, на яку поширюється дія CCPA, Клієнт є бізнесом, а ми є постачальником послуг. Нам заборонено, і ми не будемо продавати або передавати цю персональну інформацію; зберігати, використовувати або розголошувати її для будь-яких цілей, інших ніж бізнес-цілі, зазначені в Угоді, або як інше дозволено CCPA; зберігати, використовувати або розголошувати її поза прямими бізнес-відносинами між сторонами; або поєднувати її з персональною інформацією, отриманою з іншого джерела, за винятком випадків, коли CCPA дозволяє це постачальнику послуг. Ми засвідчуємо, що розуміємо та будемо дотримуватися цих обмежень. Ми повідомимо Клієнта, якщо визначимо, що більше не можемо їх дотримуватися. Клієнт може вживати розумних і відповідних заходів для припинення та усунення несанкціонованого використання, використовуючи права на аудит, передбачені в положенні 14. Ми забезпечуємо такий самий рівень захисту конфіденційності, якого CCPA вимагає від бізнесу.

Якщо застосовується комплексний закон штату про конфіденційність, який вимагає договору з процесором із визначеними умовами, ця Угода про обробку даних (DPA) є таким договором: вона визначає характер і мету обробки, тип даних, тривалість, права та обов’язки обох сторін, наш обов’язок щодо конфіденційності, наше залучення субпроцесорів на еквівалентних письмових умовах, нашу допомогу у виконанні запитів споживачів щодо їхніх прав та у виконанні зобов’язань щодо безпеки, наш обов’язок видалити або повернути дані після завершення послуг, а також наш обов’язок надавати інформацію, необхідну для демонстрації відповідності та проведення обґрунтованої оцінки. Ми діємо як процесор або постачальник послуг згідно з цими законами і ніколи як контролер Персональних даних Клієнта.

Відповідальність кожної зі сторін, що випливає з цієї Угоди про обробку даних (DPA) або пов’язана з нею, чи то за договором, деліктом або за будь-якою іншою теорією, підлягає обмеженням і виключенням відповідальності, передбаченим в Угоді, і будь-яке посилання в цих обмеженнях на відповідальність сторони означає сукупну відповідальність цієї сторони за Угодою та цією DPA разом. Ніщо в цьому положенні не обмежує права суб’єкта даних згідно зі Стандартними договірними положеннями або Законом про захист даних, і ніщо не обмежує відповідальність, яка не може бути законно обмежена.

Ми можемо оновлювати цю Угоду про обробку даних (DPA), якщо це необхідно для відображення змін у Законі про захист даних, нового або зміненого механізму передачі, рішення наглядового органу або суду, або суттєвої зміни в тому, як Сервіс обробляє Персональні дані Клієнта, за умови, що оновлення не знижує суттєво рівень захисту Персональних даних Клієнта. Ми повідомляємо про суттєве оновлення щонайменше за тридцять днів електронною поштою та на цій сторінці, а також змінюємо дату набрання чинності вгорі. Ми зберігаємо попередню версію та надаємо її за запитом.

Ця Угода про обробку даних (DPA) є обов’язковою для нас без підпису, тому Клієнту не потрібен підпис для захисту своїх інтересів. Якщо ваш процес вимагає підписаного примірника для ваших записів або якщо ви хочете запропонувати редакцію зі змінами, напишіть на адресу privacy@transglot.ai, вказавши назву юридичної особи, зареєстровану адресу, контактну особу для повідомлень та особу, яка підписує документ, і ми надішлемо підписану копію. Ми відповідаємо на анкети з питань безпеки та конфіденційності з тієї ж адреси, а Центр довіри містить пакет документів, який потрібен більшості рецензентів перед тим, як вони звертаються до кого-небудь.

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, товариство з обмеженою відповідальністю, зареєстроване в штаті Делавер, США, яке веде діяльність під торговою маркою 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.

Авторитетний і актуальний перелік субобробників ми підтримуємо самостійно та надаємо Клієнту за запитом відповідно до угоди про нерозголошення, надіславши листа на адресу privacy@transglot.ai. Категорії, мета, регіон та умови залучення кожного з них опубліковано в Центрі довіри та узагальнено в документі «Субобробники», який є невід’ємною частиною цього Додатку шляхом посилання. Ми навмисно зберігаємо його в одному місці, а не дублюємо на цій сторінці: список, переписаний у юридичний документ, стає застарілим того ж дня, коли змінюється постачальник, а застарілий додаток гірший за посилання. Станом на дату набрання чинності категорії такі: AI-переклад, автоматизована перевірка якості, вилучення термінів із глосарію та контекстні візуальні підказки — обробляються в Сполучених Штатах Америки та залучаються щоразу, коли використовується функція AI; текстові ембеддинги для семантичної пам’яті перекладів — обробляються в Сполучених Штатах Америки та залучаються лише тоді, коли в проєкті вмикається ця функція (за замовчуванням вона вимкнена); альтернативний рушій перекладу, доступний через API-маршрутизатор у Сполучених Штатах Америки та розміщений у Сінгапурі, — залучається лише тоді, коли оператор маршрутизує на нього рівень (за замовчуванням вимкнено); хмарний хостинг, база даних та об’єктне сховище — у регіоні, визначеному під час розгортання, залучаються завжди; обробка платежів — у Сполучених Штатах Америки та Європейському Союзі, залучається лише для платних планів; доставка транзакційних електронних листів — залучається завжди; внутрішньопродуктова підтримка через месенджер — залучається лише тоді, коли увімкнено месенджер підтримки. Якщо клієнт надає власні облікові дані для резервного машинного перекладу, клієнт є контролером такої передачі, а постачальник не є нашим субобробником.