Швидка відповідь: Відповідно до GDPR, контролер даних визначає, чому і як обробляються персональні дані, тоді як процесор даних обробляє дані виключно за інструкціями контролера. Відповідальність суттєво відрізняється: контролери несуть найширшу відповідальність, тоді як процесори стикаються з прямою відповідальністю лише тоді, коли діють поза межами законних інструкцій або порушують зобов'язання GDPR, які безпосередньо стосуються їх.
Основні висновки
- Контролер даних визначає цілі та засоби обробки; процесор даних діє від імені контролера.
- Контролери несуть основну відповідальність за GDPR; процесори стикаються з прямою відповідальністю відповідно до статті 82 лише в специфічних обставинах.
- Обидві ролі можуть існувати одночасно в одній організації, компанія може бути контролером для своїх власних клієнтів і процесором для іншого бізнесу.
- Юридично обов'язковий Договір на обробку даних (DPA) є обов'язковим щоразу, коли контролер залучає процесора.
- Підпроцесори потребують попереднього письмового дозволу від контролера; основний процесор залишається повністю відповідальним за дії підпроцесора.
- Неправильна класифікація вашої ролі є ризиком відповідності, який може піддати вашу організацію регуляторним штрафам.
- Процесори, які використовують персональні дані для своїх власних цілей, автоматично стають контролерами для цієї діяльності.
- Закон Великої Британії про дані (використання та доступ) 2026 року вводить подальші зміни, які організації, що працюють відповідно до GDPR Великої Британії, повинні терміново переглянути.
Яка Різниця Між Контролером Даних та Процесором Даних Відповідно до GDPR?
Контролер даних — це будь-яка особа або організація, яка визначає цілі та засоби обробки персональних даних. Процесор даних — це будь-яка особа або організація, яка обробляє персональні дані від імені контролера, строго дотримуючись інструкцій контролера [1].
Різниця полягає в повноваженнях прийняття рішень. Якщо ваша організація вирішує, чому дані збираються і як вони будуть використовуватися, ви є контролером. Якщо ваша організація лише обробляє дані, оскільки інша особа дала вам вказівку, і ви не маєте незалежного слова щодо мети, ви є процесором.
Практичні приклади:
| Сценарій | Роль |
|---|---|
| Інтернет-магазин, що збирає дані про покупки клієнтів | Контролер |
| Провайдер хостингу в хмарі, що зберігає базу даних цього роздрібного продавця | Процесор |
| Платформа SaaS для обробки даних працівників для роботодавця | Процесор |
| Маркетингова агенція, що формує власний список потенційних клієнтів | Контролер |
| Постачальник CRM, що отримує дані клієнтів для надання підтримки | Процесор |
ICO підкреслює, що позначка в контракті не визначає роль, а фактична поведінка — так [1]. Постачальник, якого називають "процесором" у контракті, але який приймає незалежні рішення щодо використання даних, юридично є контролером, незалежно від того, що говорить угода.
Які Основні Обов'язки Контролера Даних Відповідно до GDPR?
Контролери несуть найбільше навантаження відповідності відповідно до GDPR. Вони відповідають за весь життєвий цикл даних і повинні забезпечити, щоб будь-який процесор, якого вони залучають, відповідав стандартам GDPR [3].
Основні обов'язки контролера включають:
- Встановлення та документування законної основи для кожної діяльності з обробки
- Надання прозорих повідомлень про конфіденційність суб'єктам даних
- Сприяння правам суб'єктів даних, доступу, виправленню, видаленню, портативності та запереченню
- Проведення оцінок впливу на захист даних (DPIA) для обробки з високим ризиком
- Призначення Офіцера з захисту даних (DPO) за потреби
- Проведення належної перевірки перед залученням процесорів і моніторинг їхньої подальшої відповідності
- Виконання письмового Договору на обробку даних з кожним залученим процесором [3]
Контролери не можуть делегувати відповідальність. Навіть коли процесор спричиняє порушення, контролер залишається відповідальним перед наглядовими органами за свій вибір процесора та адекватність контрактних гарантій.
Які Основні Обов'язки Процесора Даних Відповідно до GDPR?
Процесори мають прямі зобов'язання відповідно до GDPR, а не лише контрактні, і не можуть вважати відповідність проблемою контролера [3].
Прямі зобов'язання процесора відповідно до GDPR включають:
- Обробка даних лише за документованими інструкціями контролера
- Впровадження відповідних технічних та організаційних заходів безпеки
- Ведення записів про всі діяльності з обробки, що виконуються від імені контролерів
- Повідомлення контролера про будь-яке порушення даних без затримки
- Допомога контролеру у виконанні запитів прав суб'єктів даних
- Видалення або повернення всіх персональних даних після закінчення контракту
- Залучення підпроцесорів лише з попереднім письмовим дозволом від контролера [3]
"Процесори мають прямі зобов'язання відповідно до GDPR, а не лише контрактні обов'язки, і стикаються з регуляторними ризиками, якщо діють поза межами законних інструкцій контролера."
Хто Відповідає У Разі Порушення Даних: Контролер Чи Процесор?
Обидва можуть нести відповідальність, але обсяг відрізняється. Відповідно до статті 82 GDPR, будь-яка особа, яка зазнала шкоди внаслідок порушення GDPR, має право вимагати компенсацію від контролера або процесора, відповідального за це [2].
Контролери несуть відповідальність за збитки, завдані будь-якою обробкою, яка порушує GDPR. Процесори несуть відповідальність лише тоді, коли вони не виконали зобов'язання GDPR, які безпосередньо стосуються процесорів, або коли вони діяли поза межами або всупереч законним інструкціям контролера [2].
Розподіл відповідальності на практиці:
- Якщо процесор зазнає порушення через те, що контролер дав недостатні інструкції щодо безпеки, контролер, ймовірно, несе основну відповідальність.
- Якщо процесор проігнорував вимоги контролера щодо безпеки, процесор несе пряму відповідальність.
- Обидва можуть бути солідарно відповідальними, що означає, що суб'єкт даних може вимагати відшкодування від будь-якої зі сторін за всю суму збитків, залишаючи їм розподіл відповідальності між собою пізніше.
Процесор може уникнути відповідальності, довівши, що він не винен у події, що спричинила шкоду [2]. Це високий бар'єр: процесор повинен продемонструвати повну відповідність своїм зобов'язанням за GDPR.
Чи Може Компанія Бути І Контролером, І Процесором Одночасно?
Так. Організація може одночасно діяти як контролер для деяких діяльностей з обробки та як процесор для інших, навіть у межах одних і тих же бізнес-відносин [1].
Наприклад, цифрова маркетингова агенція може діяти як контролер, коли вона управляє даними HR своїх власних працівників, і як процесор, коли вона проводить рекламні кампанії, використовуючи дані клієнтів. Роль визначається діяльністю, а не компанією.
Чи Може Процесор Стати Контролером, Якщо Він Використовує Дані Для Своїх Власних Цілей?
Процесор автоматично стає контролером в момент, коли він використовує персональні дані для цілей, що виходять за межі інструкцій контролера [1]. Це одна з найзначніших неправильних класифікацій на практиці.
Якщо постачальник аналітики в хмарі починає видобувати дані клієнтів для навчання своїх власних моделей ШІ без дозволу, він виходить за межі ролі процесора і набуває статусу контролера для цієї діяльності, з усіма супутніми зобов'язаннями та ризиками відповідальності за GDPR. Жоден пункт угоди не може запобігти цій перекласифікації; це питання факту, а не угоди.
Як Договори на Обробку Даних Захищають Процесорів Від Відповідальності?
Договір на обробку даних (DPA) є обов'язковим юридичним документом відповідно до GDPR щоразу, коли контролер залучає процесора [3]. Для процесорів добре складений DPA є основним механізмом для обмеження ризику відповідальності.
Відповідний DPA повинен вказувати:
- Предмет, тривалість, природу та мету обробки
- Тип персональних даних та категорії суб'єктів даних, що беруть участь
- Зобов'язання та права контролера
- Вимоги щодо конфіденційності для уповноваженого персоналу
- Заходи безпеки, які потрібно впровадити
- Умови для залучення підпроцесорів
- Процедури повернення або видалення даних після закінчення контракту [3]
Коли процесор діє строго в межах DPA, відповідальність за будь-яку шкоду, що виникає, переходить переважно на контролера. Навпаки, якщо процесор перевищує ці інструкції, DPA стає доказом відхилення, а не щитом.
Що Відбувається, Якщо Процесор Порушує Правила GDPR?
Процесори, які порушують GDPR, стикаються як з регуляторними штрафами, так і з цивільною відповідальністю за збитки. Наглядові органи можуть накладати адміністративні штрафи безпосередньо на процесорів, до 20 мільйонів євро або 4% від світового річного обороту за найсерйозніші порушення, що більше [2].
Окрім штрафів, процесори стикаються з позовами відповідно до статті 82 від суб'єктів даних, які зазнали шкоди. Вони також можуть стикатися з контрактною відповідальністю перед контролером відповідно до DPA, включаючи зобов'язання щодо відшкодування.
Чи Потрібен Процесорам Власний Офіцер з Захисту Даних?
Процесори підлягають тим самим порогам призначення DPO, що й контролери. Процесор повинен призначити DPO, якщо він проводить масштабний, систематичний моніторинг осіб або обробляє спеціальні категорії даних або дані про кримінальні засудження в масштабах [1].
Бути процесором не звільняє організацію від вимоги щодо DPO. Багато великих постачальників хмарних послуг та платформ SaaS, які діють як процесори, зобов'язані підтримувати DPO саме через обсяг та чутливість даних, які вони обробляють.
Яка Різниця У Штрафах GDPR Між Контролерами та Процесорами?
Двохрівнева структура штрафів GDPR застосовується однаково до контролерів і процесорів. Перший рівень охоплює менш серйозні порушення (до 10 мільйонів євро або 2% від світового обороту); другий рівень охоплює найсерйозніші порушення, включаючи незаконну обробку та невиконання прав суб'єктів даних (до 20 мільйонів євро або 4% від світового обороту) [2].
Не існує законодавчої знижки для процесорів. Однак на практиці наглядові органи оцінюють провину, співпрацю та характер порушення при визначенні розміру штрафів, фактори, які можуть призвести до різних результатів для контролерів і процесорів у одному й тому ж інциденті.
Чи Має Підпроцесор Іншу Відповідальність, Ніж Основний Процесор?
Підпроцесори несуть ті ж зобов'язання за GDPR, що й основні процесори, але зобов'язані контрактом перед основним процесором, а не безпосередньо перед контролером. Критичне відмінність: основний процесор залишається повністю відповідальним перед контролером за виконання підпроцесора [3].
Якщо підпроцесор спричиняє порушення, юридичний захист контролера спрямований проти основного процесора. Основний процесор повинен тоді окремо переслідувати підпроцесора. Підпроцесори також можуть стикатися з прямими регуляторними діями з боку наглядових органів за свої власні порушення GDPR.
Правила для підпроцесорів на один погляд:
- Потрібен попередній письмовий дозвіл від контролера перед залученням будь-якого підпроцесора
- Основний процесор повинен накласти еквівалентні зобов'язання щодо захисту даних на підпроцесора
- Основний процесор не може уникнути відповідальності, вказуючи на провину підпроцесора
Як Визначити, Чи Є Ви Контролером Чи Процесором Для Вашого Бізнесу?
Визначення залежить від одного питання: чи ваша організація самостійно вирішує, чому обробляються персональні дані? Якщо так, ви є контролером. Якщо ви лише обробляєте дані, оскільки інша особа дала вам вказівку, і у вас немає незалежної мети, ви є процесором [1].
Практичний контрольний список для прийняття рішення:
- Хто вирішив зібрати ці дані в першу чергу?
- Хто визначив, для чого будуть використовуватися дані?
- Чи має ваша організація свободу дій щодо того, як обробляються дані, чи ви дотримуєтеся специфікацій іншої сторони?
- Чи зупинилася б обробка, якщо інша сторона відкликала свої інструкції?
- Чи використовуєте ви дані для будь-якої мети, яка приносить користь вашій організації незалежно?
Якщо ваші відповіді вказують у різні напрямки на ці питання, ви можете бути спільним контролером, ситуація, що вимагає окремої угоди про прозорість з іншою стороною [1].
Які Поширені Помилки Роблять Компанії З Ролями Контролера І Процесора?
Неправильна класифікація є найпоширенішою помилкою, і вона має реальні наслідки для відповідності. Організації часто вважають, що назва "постачальник" або "сервісний провайдер" у контракті робить їх процесорами, тоді як їх фактична поведінка кваліфікує їх як контролерів.
Інші часті помилки:
- Пропуск DPA: Контролери, які залучають процесорів без письмового DPA, порушують GDPR, незалежно від того, наскільки безпечні системи процесора.
- Невиконання перевірки підпроцесорів: Контролери часто не помічають, що їх процесор залучив підпроцесорів без дозволу або еквівалентних контрактних захистів.
- Припущення, що процесори обробляють запити прав суб'єктів даних: Контролери залишаються відповідальними за реагування на запити суб'єктів даних; процесори лише допомагають.
- Ігнорування ризику перекласифікації: Процесори, які розширюють свої послуги і починають використовувати дані клієнтів для аналітики, навчання моделей або бенчмаркінгу, можуть ненавмисно стати контролерами, не усвідомлюючи зміни.
Для організацій, які керують згодою та потоками даних через веб-сайти та цифрові ресурси, платформа управління згодою, така як Biscotti CMP, може допомогти контролерам документувати законні підстави та управляти записами згоди, що є основним елементом відповідальності контролера відповідно до GDPR.
Як Малому Бізнесу Слід Вирішувати Відповідальність Контролера І Процесора?
Малі підприємства не звільняються від рамок контролера-процесора GDPR. Якщо малий бізнес збирає дані клієнтів, навіть просто електронні адреси для розсилки новин, він є контролером і повинен дотримуватися всіх обов'язків контролера.
Практичні кроки для малих підприємств:
- Складіть карту кожного інструменту або постачальника, який обробляє персональні дані від вашого імені (платформи електронної пошти, аналітичні інструменти, платіжні процесори, CRM).
- Підтвердіть, чи існує підписаний DPA з кожним постачальником.
- Перевірте, чи відповідає DPA кожного постачальника мінімальним вимогам GDPR.
- Опублікуйте відповідне повідомлення про конфіденційність, яке точно описує вашу діяльність з обробки.
- Встановіть процес для реагування на запити суб'єктів даних протягом 30-денного законодавчого терміну.
Закон Великої Британії про дані (використання та доступ) 2026 року, який отримав королівську санкцію 19 червня 2026 року, вводить подальші зміни до законодавства про захист даних, які малі підприємства, що базуються у Великій Британії, повинні терміново переглянути з юридичним радником, щоб забезпечити актуальність своїх обов'язків контролера [1].
Часто Задавані Питання
Q: Чи завжди компанія SaaS є процесором? Компанія SaaS є процесором лише тоді, коли вона обробляє персональні дані виключно від імені своїх клієнтів і без незалежної мети. Якщо вона використовує дані клієнтів для власної аналітики, покращення продукту або маркетингу, вона стає контролером для цих діяльностей.
Q: Чи потрібно процесору реєструватися у наглядового органу? Вимоги до реєстрації варіюються в залежності від держави-члена ЄС. Однак процесори повинні вести внутрішні записи про діяльність з обробки (RoPA) відповідно до статті 30 GDPR, якщо вони мають 250 або більше працівників або якщо обробка, ймовірно, призведе до ризику для суб'єктів даних.
Q: Чи може процесор відмовитися від інструкції контролера? Так, якщо виконання інструкції вимагатиме від процесора порушення GDPR. У таких випадках процесор повинен повідомити контролера, і, якщо інструкція не буде виправлена, може знадобитися припинити відносини.
Q: Що таке угода спільного контролера? Спільні контролери існують, коли дві або більше особи спільно визначають цілі та засоби обробки. Вони повинні документувати свої відповідні обов'язки в прозорій угоді та зробити суть цієї угоди доступною для суб'єктів даних [1].
Q: Як довго DPA повинна залишатися в силі? DPA повинна залишатися в силі протягом усього терміну відносин з обробки. Після закінчення вона регулює зобов'язання процесора щодо видалення або повернення всіх персональних даних.
Q: Чи несуть процесори відповідальність за штрафи, накладені на контролерів? Ні. Штрафи накладаються на особу, яка вчинила порушення. Однак процесори можуть стикатися з окремими штрафами за свої власні порушення і можуть стикатися з позовами про відшкодування від контролерів відповідно до DPA.
Q: Чи застосовується GDPR до процесорів, розташованих за межами ЄС? Так. GDPR застосовується до процесорів за межами ЄС, коли вони обробляють персональні дані резидентів ЄС від імені контролерів, що базуються в ЄС, або коли вони інакше підлягають територіальному обсягу GDPR відповідно до статті 3.
Q: Яка різниця між DPA та Стандартними Контрактними Положеннями? DPA регулює відносини контролера і процесора на внутрішньому рівні. Стандартні Контрактні Положення (SCC) є специфічними контрактними механізмами для передачі персональних даних до третіх країн за межами ЄС/ЄЕП, які не мають рішення про адекватність.
Висновок
Контролер проти Процесора: Розуміння Вашої Відповідальності Відповідно до GDPR не є абстрактною юридичною вправою, вона визначає, хто стикається з регуляторними штрафами, хто компенсує суб'єктам даних і хто відповідає перед наглядовими органами, коли щось йде не так. Різниця базується на фактичному питанні про повноваження прийняття рішень, а не на позначках у контракті.
Дії, які потрібно вжити:
- Проведіть вправу з картографування даних, щоб визначити кожну діяльність з обробки та роль вашої організації в кожній.
- Аудитуйте існуючі контракти з постачальниками, щоб підтвердити, що з кожним процесором, якого ви залучаєте, укладено відповідний DPA.
- Перегляньте угоди з підпроцесорами, щоб забезпечити наявність попереднього дозволу та накладення еквівалентних зобов'язань.
- Якщо ви дієте як контролер і процесор у різних діяльностях, документуйте кожну роль окремо.
- Для організацій у Великій Британії перегляньте наслідки Закону про дані (використання та доступ) 2026 року з кваліфікованим юридичним радником.
- Впровадьте рішення для управління згодою, таке як Biscotti CMP, щоб підтримувати аудиторські записи згоди та підтримувати свої обов'язки контролера.
Неправильна класифікація не є технічною деталлю, це прогалина у відповідності з прямими фінансовими та репутаційними наслідками. Правильне визначення ролей з самого початку є найбільш економічно вигідною інвестицією в GDPR, яку може зробити будь-яка організація.
Посилання
[1] Що таке контролери та процесори - https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/controllers-and-processors/controllers-and-processors/what-are-controllers-and-processors/?utm_source=openai
[2] Стаття 82 GDPR - https://gdpr-info.eu/art-82-gdpr/?utm_source=openai
[3] Відносини контролера та процесора - https://dataprotection.ie/en/organisations/know-your-obligations/controller-and-processor-relationships?utm_source=openai