Ролі в рамках 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, клієнтські ключі, квазіанонімізація, зберігання ключів в EC/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, права суб'єктів і безпеку. Чітка матриця ролей = менше регуляторних ризиків, менше спірних зон і швидше аудити.