Torrent Gear

Закони ЄС про захист даних (GDPR) та конфіденційність клієнтів

1) Коротко про головне

GDPR - базовий закон ЄС про захист персональних даних. Він застосовується до всіх, хто:

обробляє дані людей з ЄС/ЄЕЗ, навіть якщо оператор знаходиться поза ЄС;
пропонує їм послуги (в т.ч. онлайн-казино) або відстежує їх поведінку.

За порушення - штраф до 20 млн € або 4% глобального обороту (що більше), плюс заборони на обробку і репутаційні втрати.

2) Ключові принципи (ст. 5 GDPR)

1. Законність, справедливість, прозорість. Зрозумілі політики, чесні повідомлення.

2. Обмеження цілей. Використовувати дані тільки для заявлених завдань (KYC/AML, Responsible Gambling, виплати, підтримка, аналітика і т.д.).

3. Мінімізація. Збирати тільки те, що потрібно (наприклад, не зберігати «селфі з карткою», якщо вистачає 3-DS і банківської виписки).

4. Точність. Оновлювати адресу/документи, уникати дублікатів.

5. Обмеження зберігання. Чіткі терміни ретенції (зазвичай 5-7 років для фінансових документів; коротше - для телеметрії).

6. Цілісність і конфіденційність. Шифрування, контроль доступу, журналювання.

7. Підзвітність. Доводити відповідність (політики, DPIA, записи обробок).

3) Правові підстави обробки (ст. 6) - що підходить казино

Правовий обов'язок: KYC/AML/санкційний скринінг, фіскальна звітність, ведення журналів виплат.

Договір: створення та обслуговування ігрового аккаунта, поповнення/виведення, саппорт.

Законний інтерес: антифрод, безпека, базова аналітика продукту, Responsible Gambling-сигнали (якщо не суперечить місцевим нормам).

Згода: e-mail/SMS-маркетинг, cookies для реклами, нестандартні профілювання.

Життєво важливі інтереси/публічне завдання: рідко, точково.

💡 Спеціальні категорії (здоров'я, релігія тощо) в iGaming майже не потрібні - уникайте їх збору. Біометрія для liveness → використовуйте строго як ідентифікацію з DPIA і мінімізацією.

4) Ролі та межі відповідальності

Контролер (controller): оператор казино - визначає цілі/засоби.

Обробник (processor): KYC-провайдери, PSP, хмари, антифрод, ончейн-аналітика, маркетингові платформи.

Потрібні DPA (договори обробки) з чіткими інструкціями, субпроцесорами, заходами безпеки, аудит-правами та повідомленнями про порушення.

5) DPIA, DPO і записи обробок

DPIA (оцінка впливу на захист даних) обов'язкова при високій ризиковості: КУС/біометрія, поведінковий моніторинг RG, велика профілізація, транскордонні передачі.

Призначте DPO (офіцер із захисту даних), якщо масштаб обробки великий або є систематичний моніторинг.

Ведіть реєстр операцій обробки (RoPA): категорії даних, цілі, правові підстави, терміни зберігання, одержувачі, заходи безпеки.

6) Права суб'єкта даних і SLA відповідей

Гравець має право: доступу, виправлення, видалення («right to be forgotten»), обмеження, переносимості, заперечення, а також на пояснення при автоматизованих рішеннях/профілюванні (наприклад, антифрод-блок).

Термін відповіді - зазвичай до 1 місяця (можна продовжити ще на 2 при складності).

Потрібні процеси в саппорті/CRM, верифікація особистості запитуючого і WORM-журнали рішень.

7) Cookies, ePrivacy та онлайн-маркетинг

Банер згоди: явне opt-in для аналітики/реклами, окремі перемикачі, «рівні за значимістю» кнопки (прийняти/відхилити).

Строго необхідні cookies - без згоди, але з описом в політиці.

E-mail/SMS-маркетинг: тільки за згодою (або «м'який opt-in» для існуючих клієнтів в деяких країнах) + легкий opt-out.

Ремаркетинг і look-alike - тільки при валідній згоді; виключайте списки самовиключених і вразливих груп.

8) Міжнародні передачі даних (гл. V)

Передача поза ЄЕЗ можлива при:

Adequacy (країна визнана адекватною), або
SCCs (стандартні договірні положення) + TIA (оцінка впливу передачі), або
Binding Corporate Rules для груп компаній.
Перевірте хмари, anti-fraud, on-chain аналітику, helpdesk - де фізично зберігаються і обробляються дані.

9) Безпека (ст. 32) та інциденти (ст. 33/34)

Мінімум «залізобетону»:

Шифрування «в спокої» і «в транзиті», управління ключами.
RBAC/ABAC, MFA для адмінів, нульове розшарювання акаунтів.
Сегрегація середовищ, журнал дій (адмін/підтримка), моніторинг аномалій.
Tokenization/Pseudonymization для телеметрії та аналітики.
План реагування на інциденти, навчання, багбаунті.

Порушення безпеки: повідомити наглядовий орган протягом 72 годин, а суб'єктів - якщо високий ризик шкоди. Вести реєстр інцидентів.

10) Тонкі місця iGaming і як їх закрити

1. Біометрія та liveness. DPIA, локальне зберігання шаблонів (або їх відсутність після верифікації), прозорі терміни видалення.

2. Ончейн-дані. Крипто-адреса може стати персональними даними, якщо пов'язуємо з людиною - проводити TIA, не публікувати адреси гравця, зберігати звіти з мінімізацією.

3. Responsible Gambling і профілювання. Пояснювані моделі (XAI), «human-in-the-loop» для жорстких заходів, право на оскарження.

4. VIP и SoF/SoW. Збирати тільки необхідне, видаляти по терміну, захищати банківські виписки.

5. Афіліати і пікселі. Спільне контролерство? Закріпити в договорах, забезпечити синхронізований бан самовиключених, законний збір згоди.

6. Запити регуляторів/LEA. Документовані процедури розкриття, мінімізація, правова база (ст. 6 (1) (c )/( e)).

11) Ретенція: як задати «розумні» терміни

КУС/фінансові документи: 5-7 років (національні фіннорми).

Логи сесій/пристроїв: 12-24 міс (без ідентифікаторів - довше).

RG-сигнали та кейси: поки діє обмеження + аудитний термін.

Маркетингові дані: до відкликання згоди або 24 міс без активності.

Біометрія: видалити відразу після перевірки, якщо інше не потрібно законом.

12) Практичний чек-лист відповідності (коротко)

Правові основи та документація

Політика конфіденційності та cookies, простою мовою.
Реєстр обробок (RoPA), DPIA на KYC/біометрію/RG/ончейн.
DPO призначений/аутсорс, контакт опублікований.
DPA з усіма процесорами, список субпроцесорів.

Права суб'єктів

Процедури і SLA (≤1 міс), шаблони відповідей, верифікація особистості.
Легкі механізми opt-out/видалення/виправлення.

Технології та безпека

Шифрування, MFA, сегрегація, логи WORM.
Псевдонімізація аналітики, мінімізація експортів в BI.
План інцидентів, «72 години», навчання.

Маркетинг/ePrivacy

Банер згоди з окремими тумблерами; журнал consents.
Роздільні бази маркетингу та користувачів у самовиключенні.

Передачі даних

SCCs/BCR/TIA для всіх транскордонних потоків.
Карта даних по провайдерам (KYC, PSP, хмари, антифрод).

13) Часті помилки і як їх уникнути

Збирати «про запас». Зайві документи/скріншоти → ризик витоку. Рішення: мінімізація + білий список допустимих артефактів.

Cookie-банер з «темними патернами». Робіть рівнозначні кнопки «Прийняти/Відхилити».

Відсутність DPIA і DPA. Без них важко виправдати профілювання і передачу даних партнерам.

Єдиний доступ «суперадмін». Діліть ролі, підключайте JIT-доступ.

Ніяких TIA по хмарах/аналітиці. Оцініть розташування серверів і застосовність права третіх країн.

14) Міні-FAQ

Ми не в ЄС. На нас поширюється GDPR?

Так, якщо ви пропонуєте послуги людям з ЄС/ЄЕЗ або відстежуєте їх поведінку (cookies/аналітика).

Чи потрібна завжди згода для антифроду і RG?

Не завжди: зазвичай законний інтерес/правовий обов'язок. Але потрібно DPIA і прозорість + можливість заперечення, якщо застосовується.

Чи можна зберігати документи KYC безстроково?

Ні, ні. Фіксуйте обґрунтовані терміни і видаляйте/анонімізуйте після їх закінчення.

Автоматичний блок виведення - це «автоприйняття рішень»?

Так, потенційно. Забезпечте «human-in-the-loop», пояснення і право на перегляд.

Адреса гаманця - персональні дані?

Може стати таким, якщо пов'язаний з ідентифікованою людиною. Ставтеся як до PII при онбордингу.

15) Підсумок

GDPR вимагає не «паперової галочки», а системи управління даними: ясні цілі і правові підстави, мінімізацію, безпечну архітектуру, контроль вендорів і повагу прав гравців. Оператор, який будує privacy-by-design і веде підзвітність (RoPA, DPIA, DPA, DPO, інцидент-план), знижує юридичні та платіжні ризики, прискорює аудит і підвищує довіру клієнтів - а значить, виграє в довгу