Різниця між Контролером і Процесором у DPA 2026 для ТОВ/ФОП: Контролер (ст. 4(7) GDPR / ст. 1 ЗУ № 2297-VI «володілець») визначає мету і засоби обробки персональних даних і несе primary відповідальність перед суб'єктами. Процесор (ст. 4(8) GDPR / ст. 1 ЗУ № 2297-VI «розпорядник») обробляє дані від імені Контролера за документованими інструкціями. ТОВ-Контролер визначає, ЯКІ дані обробляти і ЧОМУ; SaaS/cloud-Процесор — ЯК технічно зберігати/передавати. Joint controllership (ст. 26 GDPR) — особлива форма, коли дві або більше сторін спільно визначають мету (наприклад, marketing campaign з partner brand).
Ключова різниця у одному реченні
Контролер вирішує WHAT and WHY. Процесор робить HOW.
Перевірка ролі — діагностичний тест
| Питання | Контролер | Процесор |
|---|---|---|
| Хто вирішує, які дані збирати? | ✅ | ❌ |
| Хто вирішує, ЧОМУ дані обробляються (purpose)? | ✅ | ❌ |
| Хто визначає, скільки часу зберігати? | ✅ | ❌ |
| Хто вибирає sub-процесорів? | ✅ (з notice) | (лише з дозволу Контролера) |
| Хто відповідає на DSAR (data subject access request)? | ✅ primarily | (assists Контролер) |
| Хто визначає міру безпеки? | ✅ (instructs Процесор) | (implements за інструкціями + ст. 32) |
| Хто платить штраф у випадку breach? | primarily ✅ | proportionally (для своїх failures) |
Покроково: алгоритм визначення ролі
- Identify purpose. Хто визначає, ЧОМУ дані обробляються — той Контролер. Якщо обидві сторони — joint controllers (ст. 26 GDPR).
- Identify means. Хто визначає essential means (категорії даних, retention, sub-процесори) — Контролер. Хто визначає technical means (storage location, encryption methods) — може бути Процесор за інструкціями.
- Document role. У DPA explicit clause: "X — Контролер, Y — Процесор". Документація — основа accountability (ст. 5(2) GDPR).
- Assess sub-relationships. Чи Y має sub-процесорів? Кожен sub-процесор Y — sub-Процесор для X. Chain DPA.
- Edge cases — review annually. Якщо Процесор починає processing for own purposes — стає Independent Controller (ст. 28(10)). Annual review для уникнення.
Ситуації — хто Контролер, хто Процесор
Кейс 1: ТОВ використовує AWS для зберігання customer data
- ТОВ — Контролер (визначає, що data зберігається + чому).
- AWS — Процесор (надає infrastructure).
- DPA — між ТОВ і AWS.
Кейс 2: ТОВ найняло маркетингову агенцію для email campaign
- ТОВ — Контролер (визначає список + content).
- Агенція — Процесор (розсилає від імені).
- Mailchimp (sub-процесор агенції) — sub-процесор Процесора.
- DPA — між ТОВ і Агенцією + back-to-back DPA Агенція + Mailchimp.
Кейс 3: ТОВ + Stripe для платежів
- Stripe — частково Independent Controller (визначає fraud detection, AML — для своїх purposes).
- Stripe — частково Процесор (для transaction processing від імені ТОВ).
- Stripe DPA — позиціонує Stripe як dual role (Independent Controller + Processor).
- Practice: прийняти Stripe DPA як ETL — нестандарт, але industry-accepted.
Кейс 4: ТОВ + партнерська ТОВ для co-marketing campaign
- Обидві ТОВ — joint controllers (спільно визначають мету і засоби).
- DPA — joint controllership agreement за ст. 26 GDPR.
- Allocation of responsibilities — хто notification суб'єктам, хто DSAR.
Кейс 5: ТОВ + Apollo для lead enrichment
- Apollo — Independent Controller (для своєї database) + Процесор (для enrichment service).
- Тут DPA + Apollo Privacy Policy (independent controller part).
Joint controllers — особливості
Joint controllership (ст. 26 GDPR) — рідкісна форма, коли:
- Спільне визначення мети — обидві сторони мають shared purpose.
- Спільне визначення засобів — agree on methods, technologies, partners.
Examples:
- Co-branded campaign з partner ТОВ → joint marketing controller.
- Educational platform + Universities → joint controllers для student data.
- Industry consortium з shared customer database.
Правовий обов'язок: transparent arrangement (Joint Controller Agreement), що:
- Визначає responsibilities кожної сторони (хто notification, хто DSAR).
- Доступний суб'єктам (essence of arrangement).
- Allocates liability.
Subject's rights: suspect can exercise rights проти будь-якої з joint controllers (ст. 26(3)).
DPA структура різна для controller vs processor
Якщо ви Контролер (типовий сценарій ТОВ + SaaS)
DPA містить:
- Ваші instructions Процесору.
- Sub-процесорі rules.
- Audit rights (ваші).
- Breach SLA (Процесор → ви).
- Termination data handling (ваш вибір return/erasure).
- Indemnification (Процесор compensates вам за свої порушення).
Якщо ви Процесор (наприклад, ТОВ-агенція або ТОВ-SaaS)
DPA містить:
- Інструкції від Контролера ваших клієнтів.
- Ваше зобов'язання процесити only за instructions.
- Audit rights (your client's).
- Sub-процесорі notification (ваше зобов'язання).
- Breach SLA (ви → Контролер).
- Indemnification (ви відповідаєте за свої failures).
Часті помилки у визначенні ролі
1. Mailchimp як Independent Controller. Mailchimp positioned як Processor у standard DPA. Не позиціонуйте як Independent Controller. Recipe: sign Mailchimp DPA as-is (Processor role).
2. SaaS як Joint Controller. Standard SaaS — Processor, не Joint Controller. Joint controllership — для партнерських relationships з shared purpose. Recipe: не категоризувати SaaS як Joint Controller.
3. ТОВ-Процесор без DPA з sub-процесорами. ТОВ-агенція — Процесор для клієнтів; має back-to-back DPA з усіма sub-процесорами (Mailchimp, AWS). Recipe: chain DPA: Client → Агенція → Mailchimp → AWS.
4. Без notification суб'єкту joint controller arrangement. Якщо joint, суб'єкт має знати identity обох + arrangement essence. Recipe: Privacy Notice secciya "Joint Controllers".
5. Стрибання rolami між контрактами. ТОВ Контролер з одного клієнта стає Процесором іншого — потрібні два різні DPA. Recipe: clear contract templates per role.
Правові підстави для кожної ролі
Контролер
- ст. 6 GDPR підстави (consent / contract / legal obligation / vital interests / public task / legitimate interests).
- ст. 13/14 GDPR — інформування суб'єктів.
- ст. 28 GDPR — выбір Процесора з достатніми гарантіями.
- ст. 30 GDPR — Records of processing activities.
- ст. 35 GDPR — DPIA для high-risk обробки.
Процесор
- ст. 28(3) GDPR — DPA terms.
- ст. 30(2) GDPR — Records of processing activities (procesor side).
- ст. 32 GDPR — security measures.
- ст. 33(2) GDPR — breach notification до Контролера.
Ukraine: ст. 1 ЗУ № 2297-VI термінологія
- Володілець персональних даних = Контролер (GDPR).
- Розпорядник персональних даних = Процесор (GDPR).
- Третя особа = third party (не суб'єкт, не Контролер, не Процесор).
- Обробка = processing.
ЗУ № 2297-VI broadly compatible з GDPR ролями, але термінологія різна. У DPA — використовуйте обидві (parallel definitions).
FAQ
Чи може одна сторона бути одночасно Контролером і Процесором? Так, dual role можливий — але для різних purposes обробки. Stripe — Independent Controller для fraud detection + Процесор для transaction processing.
Хто несе primary відповідальність перед суб'єктом — Контролер чи Процесор? Контролер. Суб'єкт зазвичай не знає Процесора (він "behind the scenes"). Скарга суб'єкта — до Контролера. Контролер тоді rеcourse до Процесора через indemnification.
Що якщо я не впевнений у ролі — Контролер чи Процесор? Apply діагностичний тест (хто вирішує what/why). Якщо unclear — consultation з DPO або юристом. Документуйте reasoning для accountability.
Чи може Процесор стати Контролером без зміни DPA? Так, якщо Процесор починає processing for own purposes (e.g., own marketing). Це breach original DPA. Recipe: clearly limit purposes у DPA.
AGENTIS — інформаційний інструмент. Не замінює адвоката і не є юридичною консультацією.
Готовий шаблон DPA з clear role definition — згенеруйте чернетку DPA через AGENTIS.
Пов'язані матеріали:
- Pillar: Договір про обробку персональних даних
- QA: GDPR ст. 28 — обов'язки процесора
- GDPR ст. 28 — повний огляд
Зовнішні джерела: GDPR Art. 4 на gdpr-info.eu · GDPR Art. 26 (Joint Controllers) · Закон 2297-VI ст. 1