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

1) Що вважається транскордонною передачею і чому це важливо

• хостинг/реплікація в іншому регіоні,
• віддалений доступ третьої сторони (включаючи саппорт/адміндоступ),
• маршрутизація через глобальні хмарні сервіси, CDN, діагностичні/аналітичні SDK.

У iGaming/фінтехе транскордонність впливає на ліцензування, партнерства з PSP/банками і ризик-профіль інцидентів.

2) Правові основи (узагальнена модель)

1. Законність обробки у джерела: мета, підстава (договір/обов'язок/легітимний інтерес/згода), мінімізація і ретеншн.

• рішення про адекватність (якщо одержувач в юрисдикції з «достатнім захистом»);
• договірні інструменти: стандартні положення/застереження, корпоративні правила (BCR), міжгрупові угоди;
• інші підстави (необхідність за договором, явна згода, захист життя і т. п. - вузькі і контекстні).

3. Додаткові заходи захисту: тих/орг заходи, що підтверджують, що ризики доступу третіх сторін і держорганів знижені до прийнятного рівня.

3) DTIA: оцінка переносу (Data Transfer Impact Assessment)

DTIA відповідає на питання: "Куди передаємо? Хто отримує? Які закони/ризики доступу до даних? Чи достатні наші заходи?"

1. Операція і контекст (категорії ПД/суб'єктів, цілі, обсяги, частота).

2. Одержувачі і ланцюжок сабпроцесорів (локації, ролі, субобробники).

3. Правовий аналіз країни-одержувача (ризики держдоступу, процедури запиту даних, засоби правового захисту).

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

5. Залишковий ризик і рішення: «передавати/посилити заходи/не передавати».

6. План моніторингу: перегляди за подіями (зміна провайдера/гео/закону).

4) Типові механізми передачі (за аналогією з GDPR і еквівалентами)

Адекватність: можна передавати без додаткових договірних інструментів, але з базовими заходами (мінімізація, шифрування, ретеншн).
Стандартні договірні положення (SCC/аналог): контрактні гарантії + DTIA + допмери.
Корпоративні правила (BCR): для транснаціональних груп; вимагають схвалення регулятора і зрілої внутрішньої програми приватності.
Інші підстави: явна згода, необхідність для договору з суб'єктом, важливі суспільні інтереси - вузькі і поганосимі в операційку.

5) Технічні та організаційні заходи (конструктор)

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

Шифрування in transit і at rest; мінімально TLS 1. 2+/AES-256.
Split-key / envelope encryption: ключі залишаються в країні походження (KMS/HSM «вдома»), в країні-одержувачі - тільки обгорткові ключі.
Клієнтське шифрування для особливо чутливих наборів.

Де-ідентифікація

Псевдонімізація до передачі: стабільні токени замість PII; заборонений прямий джойн з PII в стороні одержувача.
Анонімізація/агрегація для аналітики та звітності (де можливо); диференціальна приватність для публікацій.

Доступ та експлуатація

JIT-доступи, RBAC/ABAC, контроль експортів (DLP), WORM-логи.
Заборона прод-ПД в dev/stage; синтетика або маскування.
Гео-обмеження та IP allowlist для адміндоступів.

Контроль вендорів

DPA/договір із забороною вторинних цілей і onward transfer без згоди.
Реєстр субпроцесорів з географією; SLA повідомлень про інциденти.
Щорічні рев'ю/аудити; моніторинг змін юрисдикцій/хостингу.

6) Архітектурні патерни «data/key residency»

• «EU-only »/« BR-only »/« IN-only» кластери; синхронізація анонімних агрегатів у «всесвітній» DWH.
• Гео-шардинг з маршрутизацією за походженням користувача і місцем ліцензії.

• Дані можуть зберігатися глобально в шифрованому вигляді, а ключі - тільки в країні походження (split-key, remote KMS).
• Запити на дешифрацію проходять через авторизований «ключовий проксі» з аудитом і квотами.

• Server-side analytics і серверні постбеки (афіліати/атрибуція) замість «жирних» браузерних SDK.
• Edge-шар з редагуванням подій (видалення PII) до потрапляння в глобальні пайплайни.

7) Регіональні особливості (високорівнево)

Європейський підхід (GDPR): розділ про передачу + DTIA; особливу увагу до доступу держорганів і засобів правового захисту.
США (штатні режими конфіденційності): акцент на «продажу/спільному використанні» та договірних обмеженнях у третіх осіб; окремі сигнали (наприклад, GPC) для рекламних сценаріїв.
Бразилія (LGPD): допускає передачу при адекватності/договірних гарантіях/сертифікації/згоди; практики схожі з європейськими (RIPD для ризикованих обробок).
Індія, Азія та ін.: можливі локальні вимоги до зберігання копій, реєстрація/повідомлення регуляторам, обмеження щодо «чутливих» наборів - перевіряйте галузеві норми та умови ліцензій/платіжних партнерів.

(Розділ навмисно узагальнений: перед запуском обов'язково актуалізуйте локальне право і вимоги ваших ліцензій і PSP.)

8) Що документувати (артефакти)

Реєстр передач: країни/провайдери/механізм (адекватність/SCC/BCR/інше )/категорії ПД/підстави/терміни.
DTIA по кожній передачі (і оновлення при змінах).
DPA/контракти з процесорами/сабпроцесорами; список субпроцесорів по регіонах.
Політика key residency і схеми KMS/HSM.
Процедури інцидентів з урахуванням географії та термінів повідомлень.
Data map/lineage для каскадів та експортів.

9) Інциденти та повідомлення при транскордонній передачі

Швидко визначити обсяг і географію порушених ПД, застосовні регулятори/терміни повідомлень.
Скоординувати дії з провайдерами/сабпроцесорами; отримати технічні артефакти (логи, тимчасові вікна, ключі доступу).
Комунікації - «мінімально достатні», без розкриття зайвого; для порушених суб'єктів - зрозумілі рекомендації (зміна паролів, контроль транзакцій тощо).
Пост-морем: оновлення DTIA, посилення заходів, коригування договорів.

10) Метрики та контроль якості

DTIA Coverage - частка передач з актуальними оцінками впливу.
Key Residency Enforcement -% дешифрацій, що пройшли через регіональний KMS.
Vendor Geo Accuracy - збіг обіцяної і фактичної географії обробки.
Export Violations - спроби/факти несанкціонованих експортів.
Incident MTTD/MTTR по транскордонних кейсах.
RoPA/Transfer Registry Completeness - повнота реєстрів.
Retention Adherence для даних, переданих за кордон.

11) Чек-листи (операційні)

Перед стартом передачі

• Мета/підстава/мінімізація визначені, внесено в RoPA.
• Обрано механізм: адекватність/SCC (або аналог )/BCR/інше.
• Проведено DTIA, прийняті допмери (шифрування, split-keys, псевдонімізація).
• DPA/контракти з обмеженнями onward transfer, право аудиту.
• Налаштовані логування доступів, DLP, алерти експортів.

В експлуатації

• Моніторинг географії (провайдери/репліки/CDN/SDK).
• Щорічний/подієвий перегляд DTIA і списків сабпроцесорів.
• Тести відновлення/санітизації при DR-сценаріях.

При змінах

• Re-DTIA при зміні країни/провайдера/правового режиму.
• Оновлення реєстрів і повідомлення DPO/юристів.
• Перевірка «key residency» і маршрутів дешифрації.

12) Матриця «категорія даних → міра захисту → чи можна передавати»

13) Шаблони для вашої wiki/репозиторію

DTIA-Template. md (розділи 1-6 + чек-лист допмер).
Transfer-Registry. xlsx/MD (операція → країна → провайдер → механізм → заходи).
Key-Residency-Policy. md (архітектура KMS/HSM, ролі, аудит).
Vendor-DPA-Checklist. md (обмеження, сабпроцесори, локації, повідомлення).
DR-Sanitization-Runbook. md (як чистити відновлені оточення).
Geo-Monitoring SOP (як контролювати фактичну географію).

14) Дорожня карта впровадження (6 кроків)

1. Інвентаризація передач: джерела ПД, одержувачі, маршрути, SDK/теги.
2. Юридичний контур: вибір механізмів (адекватність/SCC/BCR), підготовка DPA, запуск реєстру.
3. DTIA і допмери: крипто-архітектура (split-keys, key residency), псевдонімізація, DLP/аудит.
4. Архітектура «data residency»: гео-кластери, правила маршрутизації, server-side analytics.
5. Операції та моніторинг: гео-моніторинг провайдерів/сабпроцесорів, DR-санітизація, метрики.
6. Аудити/навчання: щорічний перегляд DTIA/реєстрів, тренування інцидентів, звіти для керівництва.

Підсумок

Управління транскордонною передачею - це не «галочка в договорі», а комбінація юридичних механізмів, крипто-архітектури та операційної дисципліни. Чіткий DTIA, договірні обмеження, «data/key residency», псевдонімізація і контроль вендорів дозволяють безпечно масштабувати продукт по регіонах, не втрачаючи швидкість і відповідність вимогам регуляторів і платіжних партнерів.