Роли в рамках GDPR

1) Базовые определения и принципы

Controller (Контролер): самостоятельно определяет цели и способы обработки персональных данных (PD). Несет основную ответственность за законность, прозрачность, права субъектов, security-TOMs, выбор и контроль процессоров.
Processor (Процессор): обрабатывает PD только по документированным указаниям контролера, обеспечивает TOMs, помогает с правами субъектов и инцидентами, ведет записи и допускает аудиты.
Joint Controllers (Совместные контролеры): два+ лица совместно определяют цели и способы; требуется прозрачное распределение обязанностей и точка контакта для субъектов.
Sub-Processor (Субпроцессор): привлеченный процессором поставщик; допускается только с предварительным письменным разрешением контролера и эквивалентными обязательствами.

Золотое правило: кто решает зачем и как обрабатывать — тот контролер; кто лишь «выполняет по инструкции» — процессор.

2) Как определить роль на практике (дерево решений)

1. Кто задает бизнес-цели обработки?

→ Вы? Скорее контролер.

2. Можете ли вы повторно использовать данные для своих целей (аналитика, маркетинг)?

→ Да → контролер (или совместное контролерство, если цели общие).

3. Указывают ли вам точные средства/ограничения другой стороной, а ваши цели производны?

→ Да → процессор.

4. Есть общий продукт/совместная платформа с определением целей обеими сторонами?

→ Да → joint controllers (нужен art. 26 arrangement).

5. Вы привлекаете облако/вендора по вашему заданию?

→ Вендор — субпроцессор; вы — контролер; ваш основной процессор обязан получить ваше разрешение на него.

3) Роли в экосистеме iGaming — матрица примеров

4) Обязанности по ролям (RACI высокого уровня)

5) Документы и соглашения

DPA (Data Processing Agreement): обязательный для схемы контролер → процессор.
Минимум: предмет/категории PD, цели/инструкции, TOMs, конфиденциальность, помощь с DSAR/DPIA, уведомления об инцидентах, удаление/возврат данных, аудит, субпроцессоры (список/механизм согласия).
Art. 26 Arrangement (Joint Controllers): прозрачное распределение обязанностей (информирование, DSAR, контактная точка), суть ролей в публичной политике.
SCCs/UK IDTA + DTIA: обязательны при передачах вне ЕЭЗ/UK при отсутствии адекватности.
RoPA: реестр операций обработки у контролера и у процессора (своего набора).
Условия маркетинга/SDK: запрет вторичного использования, ясные роли и цели.

6) Критические зоны и типовые ошибки

1. Смешение ролей: «процессор» использует данные для собственных целей → на самом деле это контролер / совместный контролер.
2. Субпроцессоры без разрешения: процессор добавляет поставщика без вашего согласия.
3. «Пустой» DPA: нет четких инструкций по retention/удалению/инцидентам/аудиту.
4. Непрозрачное совместное контролерство: нет art. 26 — жалобы и штрафные риски.
5. Маркетинговые SDK: провайдеры тянут PD для себя — вы отвечаете за раскрытие и законность.
6. PSP/Банки: считать их процессорами — ошибка; чаще это отдельные контролеры.

7) Мини-шаблон DPA (фрагменты формулировок)

Цели и характер обработки: «Процессор обрабатывает PD исключительно для KYC-верификации по указаниям Контролера».
Инструкции: «Любое изменение целей требует письменного согласия Контролера».
Субпроцессоры: «Процессор не привлекает субпроцессоров без предварительного письменного разрешения; ведет и публикует актуальный реестр».
Безопасность: «Процессор поддерживает TOMs (шифрование, псевдонимизация, контроль доступа, журналирование), не ниже описанного в Приложении А».
Инциденты: «Процессор уведомляет Контролера без неоправданной задержки и предоставляет всю информацию для уведомлений регулятора и субъектов».
Удаление/возврат: «По окончании услуги процессор удаляет/возвращает PD и удаляет копии в бэкапах по графику».
Аудит: «Контролер вправе проводить аудит/опросники/внешние отчеты (SOC2/ISO), с разумным уведомлением».

8) DPIA/DTIA и трансграничность

DPIA: контролер запускает; процессор предоставляет сведения о системах, рисках, TOMs.
DTIA: при SCCs/IDTA — оценка правоприменительной среды получателя, дополнительные меры (E2EE, клиентские ключи, квазианонимизация, хранение ключей в ЕС/UK).

9) Работа с правами субъектов (DSAR) в распределенных ролях

Контролер: принимает запрос, верифицирует личность, координирует сбор, отвечает в срок (обычно ≤30 дней).
Процессор: оперативно предоставляет выгрузки/удаляет по указанию, не отвечает субъекту напрямую (если иное не предписано).
Совместные контролеры: в соглашении указать «точку контакта» и обмен данными для ответа.

10) Security и инциденты: кто что делает

Контролер: политика инцидентов, план уведомлений DPA/пользователей, управление CAPA.
Процессор: немедленное оповещение контролера, техническая форензика, containment, журналы, помощь с уведомлениями.
Совместные контролеры: согласованная матрица уведомлений; единая линия коммуникации.

11) Ретеншн, удаление, тестовые данные

Контролер: устанавливает сроки хранения по целям/законам (AML, бухучет), публикует в политике.
Процессор: реализует удаление/анонимизацию по расписанию, отдельно — очистка бэкапов; запрет использовать PD в тестовой среде без маскировки/синтетики.

12) Операционная интеграция (практика)

CAB/Change: любая смена ролей/субпроцессоров/территорий — через CAB и правки DPA/SCCs.
Data Map & RoPA: живая карта потоков; у контролера — цели и получатели, у процессора — категории и операции.
Вендор-менеджмент: due diligence перед онбордингом (ISO/SOC2, пентест, политика инцидентов, география данных).
Аудиты: чек-листы, опросники, выборочные журналы доступа к PII, логика удаления.

13) Чек-лист «Определяем роль»

• Кто задает цели и ключевые параметры обработки?
• Можно ли повторно использовать PD для своих целей?
• Есть ли самостоятельные правовые основания у второй стороны?
• Кто несет ответственность перед субъектом (DSAR)?
• Нужны ли DPA (art. 28) или arrangement (art. 26)?
• Есть ли субпроцессоры и механизм согласования?
• Будут ли трансграничные передачи и какой механизм (SCCs/IDTA)?

14) Часто задаваемые вопросы (FAQ)

PSP — процессор или контролер?
Обычно отдельный контролер: собственные цели (платежное обслуживание, предотвращение мошенничества, нормативная отчетность).

Провайдер KYC может хранить фото для обучения моделей?
Только при статусе контролера (с отдельным основанием и раскрытием) или при вашем явном согласии и корректном правовом основании. Иначе — запрещено.

Аффилиат, который привел игрока, — процессор?
Чаще отдельный контролер: он собирает PD у себя для своих целей. Совместные кампании требуют явного распределения ролей.

Сервер-логирование облака — чьи данные?
Обработка логов — обязанность процессора для обеспечения безопасности; повторное использование для своих целей требует отдельного основания (иначе нельзя).

15) Мини-политика ролей (фрагмент для внутреннего стандарта)

1. По умолчанию оператор выступает контролером по всем потокам PD игроков/партнеров.
2. Любой вендор с доступом к PD — оформляется как процессор (DPA) либо как отдельный контролер (при собственных целях).
3. Добавление субпроцессора требует письменного согласия и обновления реестра.
4. Любая смена ролей/территорий/целей — через CAB, DPO и Legal.
5. DSAR и инциденты — координируются контролером, процессоры отвечают в SLA.

16) Дорожная карта внедрения

Недели 1–2: инвентаризация потоков данных и ролей; черновик матрицы «кто есть кто»; обновление RoPA.
Недели 3–4: заключение/обновление DPA, art. 26 (где нужно), реестр субпроцессоров; подготовка опросников аудита.
Месяц 2: DTIA/SCCs/IDTA, обновление публичной политики, обучение команд.
Месяц 3+: регулярные аудиты вендоров, тест DSAR, tabletop по инцидентам, ревизия ролей при изменениях продукта/маркетинга.

17) Короткий шаблон «Матрица ролей» (пример)

TL;DR

Определяем роль через цели и способы обработки: решаешь «зачем/как» — контролер; выполняешь по указанию — процессор; вместе решаете — joint controllers. Формализуем это в DPA/art. 26, ведем RoPA, контролируем субпроцессоров, обеспечиваем DPIA/DTIA, права субъектов и безопасность. Четкая матрица ролей = меньше регуляторных рисков, меньше спорных зон и быстрее аудиты.