GH GambleHub

Передача данных между странами

1) Цель и область

Сформировать управляемую и доказуемо безопасную модель трансграничных передач персональных данных (PII) и операционных наборов (KYC/AML, платежи, RG/SE, CRM/маркетинг, игровая телеметрия, логи/APM, аналитика/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 логи/APM и server-side tagging с обнулением идентификаторов без согласия.

7.3 Изоляция плоскостей

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

7.4 Запросы госорганов

Контур реакции: проверка законности, оспаривание, минимизация объема, уведомление (если разрешено), запись в реестр запросов.

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

КатегорияМожно за рубеж?Условия
KYC/биометрияОграниченноПсевдонимизация/вердикты «pass/fail», ключи в регионе, запрет «сырого» образа
Платежные токены/PSPДа/условноДоговор/PCI-скоуп, токенизация, запрет PAN
Игровые сырые событияОграниченноПсевдонимы → агрегаты в глобальный DWH
RG/SE статусыНетРазрешены только анонимные флаги в глобальные системы
CRM/маркетингУсловноСогласие/LI, suppression, CMP/TCF, локальные канальные правила
Логи/APMТолько PII-freeМаскирование на агенте, локальные синки

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

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

10) Бэкапы, логи и аналитика

Бэкапы: в том же регионе; экспорт за рубеж — только в зашифрованном виде + HYOK; при достижении срока — crypto-shred.
Логи/APM: 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 логи/APM.
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).

Нажимая кнопку, вы соглашаетесь на обработку данных.