GH GambleHub

Передача даних між країнами

1) Мета і область

Сформувати керовану і доведено безпечну модель транскордонних передач персональних даних (PII) і операційних наборів (KYC/AML, платежі, RG/SE, CRM/маркетинг, ігрова телеметрія, логи/АРМ, аналітика/DWH) з урахуванням вимог ліцензій iGaming і законів про захист даних різних юрисдикцій. Документ доповнює розділи: "Локалізація даних", "Видалення та анонімізація", "GDPR: згода", "DSAR".

2) Базові поняття та принципи

Транскордонна передача - будь-який доступ/репліка/обробка за межами «домашньої» юрисдикції суб'єкта/даних.
Адекватність/еквівалентність - рішення регулятора про достатність захисту країни-одержувача.
Договірні механізми - стандартні контрактні положення, місцеві аналоги, доп. угоди.
TIA (Transfer Impact Assessment) - оцінка правових/технічних ризиків конкретної передачі.
Суверенітет/резидентність - місце розташування зберігання і право місцевого контролю.

Принципи:

1. Local-first: по можливості обробляємо локально; назовні - мінімально і за правилами.

2. Мінімізація: «рівно стільки, скільки потрібно»; переважно агрегати/псевдоніми.

3. Криптографія та ізоляція: шифрування, ключі в регіоні, розділення control/data plane.

4. Доказовість: журнал кожної передачі, артефакти TIA і підстав.

5. Fail-closed: немає підстави або TIA - немає передачі.

3) Ролі та RACI

DPO/Head of Compliance (Owner) - політика, допуски, TIA, винятки. (A)

Legal - вибір механізму передачі, договори, локальні вимоги. (R)

Security/Infra - шифрування, KMS/HSM, мережеві периметри, аудит. (R)

Data Platform/Analytics - де-PII/анонімізація, федеративні/кохортні звіти. (R)

Engineering/SRE - маршрутизація, токенізація, контроль експортів. (R)

Vendor Manager - реєстр субпроцесорів, підтвердження, offboarding. (R)

Internal Audit - вибірки артефактів, CAPA. (C)

4) Карта потоків (Data Transfer Map)

Джерело → призначення (країна/хмара/вендор) → категорія даних → мета → правова основа → механізм передачі → захист (тех/орг) → терміни зберігання → відповідальність.
Графічно фіксується для: підтримка/CS, аналіз/звітність, фрод/ризик-швидкі, провайдери ігор і PSP, афіліати.

5) Правові механізми (каркас)

1. Рішення про адекватність (якщо застосовується): спрощений шлях, але все одно потрібні TIA-артефакти і договори з вендором.
2. Стандартні/типові контрактні положення та місцеві аналоги: включають обов'язкові додатки (категорії, цілі, заходи).
3. Binding/додаткові угоди: уточнюють обов'язки субпроцесорів, повідомлення про запити держорганів.
4. Винятки за законом: точкові і рідкісні (життєві інтереси, вимога договору) - не для системного експорту.
5. Внутрішньогрупові правила: для холдингів - корпоративні інструменти з контролем.

💡 Рішення механізму завжди супроводжується TIA і каталогом додаткових заходів.

6) Transfer Impact Assessment (TIA)

Привід: новий вендор/країна, нова мета, нові категорії (біометрія, RG/SE), зміна режиму ключів або маршрутів.

Зміст:
  • Опис передачі (дані/обсяг/частота/учасники).
  • Правове середовище країни-одержувача (ризики доступу держорганів, правові засоби захисту суб'єктів).
  • Технічні заходи: шифрування, ключі (BYOK/HYOK), псевдонімізація, split-processing.
  • Організаційні заходи: NDA, навчання, «need-to-know», журналювання, реакції на запити.
  • Залишковий ризик/рішення: дозволити/змінити/заборонити; термін перегляду.

Шаблон короткої форми TIA: див. § 15C.

7) Технічні та організаційні заходи

7. 1 Криптографія і ключі

At rest: AES-256-GCM; in transit: TLS 1. 2+/mTLS; PFS.
KMS: BYOK (ключі у нас), переважно HYOK (ключі залишаються в регіоні); сегментація по ринках/тенантах; незмінний аудит операцій з ключами.
Crypto-shredding: для бекапів і архівів при термінах.

7. 2 Мінімізація та де-ідентифікація

Псевдонімізація перед експортом (token gateway), зберігання маппінгу окремо в регіоні.
Агрегати, k-анонімність/бінінг дат і гео, придушення рідкісних категорій.
PII-free логи/АРМ і server-side tagging з обнуленням ідентифікаторів без згоди.

7. 3 Ізоляція площин

Глобальний control-plane без PII; data-plane з PII локально.
Доступ до PII через проксі-шар з обґрунтуванням запиту і журналом.

7. 4 Запити держорганів

Контур реакції: перевірка законності, оспорювання, мінімізація обсягу, повідомлення (якщо дозволено), запис до реєстру запитів.

8) Категорії даних і правила передачі

КатегоріяМожна за кордон? Умови
КУС/біометріяОбмежено
Платіжні токени/PSPТак/умовно
Ігрові сирі подіїОбмежено
RG/SE статусиНі, ні
CRM/маркетингУмовно
Логи/АРМТільки PII-free

9) Вендори і субпроцесори

Реєстр: юр. особа, країни DC, субпроцесори, сертифікації, механізми передачі, режим ключів.
Контракти: DPA + SCC/аналоги, повідомлення про зміну локацій/субпроцесорів ≥30 днів, право аудиту/опитувальника, зобов'язання з локалізації бекапів, SLA інцидентів і DSAR.
Онбординг/рев'ю: TIA, пентест/атестації, тест «sample transfer».
Offboarding: експорт/видалення/crypto-shred + підтвердження (evidence).

10) Бекапи, логи та аналітика

Бекапи: в тому ж регіоні; експорт за кордон - тільки в зашифрованому вигляді + HYOK; при досягненні терміну - crypto-shred.
Логи/АРМ: PII-free за замовчуванням; якщо ні - локальне сховище, коротка ретенція.
Аналітика/DWH: глобальні звіти тільки агрегати/кохорти; заборона сирих ідентифікаторів за межі регіону.

11) Процеси і події

Наскрізний процес: запит передачі → перевірка профілю ринку → вибір механізму → TIA → узгодження → техмери → запуск → моніторинг → артефакти/аудит.

Події (мінімум):
  • `xborder_transfer_requested/approved/denied`
  • 'transfer _ executed'( обсяг/час/вендор)
  • `key_accessed_for_transfer` (KMS audit)
  • `gov_request_received/responded`
  • `vendor_location_changed`
  • `transfer_review_due`

12) Дані та артефакти (модель)


transfer_record {
id, market_from, market_to, vendor, purpose, lawful_basis,
mechanism{adequacy    scc    local_clause    exception}, tia_id,
data_classes[], pii{yes/no}, deidentification{pseudo    anon    none},
encryption{at_rest, in_transit, keys{scope: BYOK    HYOK, kms_region}},
executed_at_utc, volume{rows, mb}, retention_days, backups{region, crypto_shred:true},
approvals{legal, dpo, security}, status, evidence_uri(WORM)
}

tia {
id, date, countries_involved[], legal_risk_summary, gov_access_risk,
technical_measures[], organizational_measures[], residual_risk{low    med    high},
decision{allow    modify    deny}, review_at
}

13) KPI/KRI і дашборд

X-Border Transfer Rate (по цілям/вендорам/країнам).
TIA Coverage (% передач з актуальним TIA).
BYOK/HYOK Coverage (частка передач з регіональними ключами).
Anonymized Export Share (% експортів в агрегатах/псевдонімах).
Vendor Location Drift (інциденти зміни локацій).
Gov Request Count і середній час відповіді.
Auditability Score (% записів з повним пакетом артефактів).

14) Чек-листи

A) Перед початком передачі

  • Призначення і законна мета підтверджені.
  • Обраний механізм (адекватність/договір/аналог), TIA виконана.
  • Псевдонімізація/анонімізація налаштовані; обсяг мінімізований.
  • KMS/ключі: BYOK/HYOK, журнал включений.
  • Контракт з вендором: DPA + SCC/аналог, повідомлення про зміну DC/субпроцесорів.
  • Резидентність бекапів і crypto-shred в плані.

B) В операціях

  • Моніторинг'vendor _ location _ changed'і алерти.
  • Періодичний перегляд TIA і механізмів.
  • DSAR/видалення коректно застосовуються в периметрі одержувача (або через анонімізацію).
  • Логи передач і KMS-аудит доступні аудиту.

C) Аудит/поліпшення

  • Квартальні вибірки'transfer _ record'на повноту.
  • CAPA щодо інцидентів/скарг/регуляторних знахідок.
  • Тест «revoke access» у вендора + підтвердження видалення.

15) Шаблони (швидкі вставки)

A) Клауза «транскордонна передача»

💡 Субпроцесор зберігає/обробляє дані тільки в заявлених юрисдикціях. Будь-яка передача в іншу юрисдикцію допустима при діючих правових підставах (SCC/локальний аналог) і письмовій згоді. Зміна локації/субпроцесора - повідомлення ≥30 днів. Ключі шифрування - BYOK/HYOK; логи доступів надаються за запитом.

B) Повідомлення про запит держоргану

💡 Постачальник негайно повідомляє (якщо дозволено) про будь-яку вимогу доступу, мінімізує обсяг, оскаржує надмірні запити і документує розкриття. Копії повідомлень/відповідей - до нашого WORM-реєстру.

C) Короткий TIA (one-pager)

💡 Суть: {мета, дані, обсяг, країни}
Правові ризики: {підсумок}
Техмери: {шифрування, ключі, псевдонімізація, split-processing}
Оргмери: {NDA, need-to-know, аудит}
Рішення: {allow/modify/deny}, перегляд {дата}

16) 30-денний план впровадження

Тиждень 1

1. Затвердити політику транскордонних передач, RACI і шаблони TIA/DPA.
2. Побудувати карту поточних потоків і реєстр вендорів/локацій/ключів.
3. Налаштувати KMS по ринках (BYOK/HYOK), включити незмінний аудит ключів.

Тиждень 2

4) Включити псевдонімізацію перед експортом і PII-free логи/АРМ.
5) Запустити реєстр'transfer _ record '/' tia'( WORM-артефакти).
6) Оновити договори з критичними вендорами: локації, повідомлення, offboarding-процедури.

Тиждень 3

7) Пілот 2-3 потоків (CS, звіти DWH): виміряти Anonymized Export Share, BYOK Coverage.
8) Навчити Product/CS/BI/Legal за процедурами запитів держорганів і ескалацій.
9) Підключити алерти'vendor _ location _ changed'.

Тиждень 4

10) Повний реліз; дашборд KPI/KRI і щоквартальні TIA-рев'ю.
11) CAPA за знахідками; план v1. 1 - федеративна аналітика/дифф. приватність у звітах.
12) Тест offboarding одного вендора: видалення/crypto-shred, підтвердження.

17) Взаємопов'язані розділи

Локалізація даних по юрисдикціях

Видалення та анонімізація даних/Графіки зберігання та видалення

GDPR: управління згодою/Політика cookies і CMP

Privacy by Design / DSAR

Шифрування At Rest/In Transit, KMS/BYOK/HYOK

Дашборд комплаєнсу та моніторинг/Внутрішній та зовнішній аудит

Contact

Зв’яжіться з нами

Звертайтеся з будь-яких питань або за підтримкою.Ми завжди готові допомогти!

Розпочати інтеграцію

Email — обов’язковий. Telegram або WhatsApp — за бажанням.

Ваше ім’я необов’язково
Email необов’язково
Тема необов’язково
Повідомлення необов’язково
Telegram необов’язково
@
Якщо ви вкажете Telegram — ми відповімо й там, додатково до Email.
WhatsApp необов’язково
Формат: +код країни та номер (наприклад, +380XXXXXXXXX).

Натискаючи кнопку, ви погоджуєтесь на обробку даних.