Законы ЕС о защите данных (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 (оценка воздействия на защиту данных) обязательна при высокой рисковости: KYC/биометрия, поведенческий мониторинг 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) Ретенция: как задать «умные» сроки

KYC/финансовые документы: 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, инцидент-план), снижает юридические и платёжные риски, ускоряет аудит и повышает доверие клиентов — а значит, выигрывает в долгую.