Краткий ответ: В соответствии с 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].
Часто задаваемые вопросы
В: Является ли компания SaaS всегда процессором? Компания SaaS является процессором только тогда, когда она обрабатывает персональные данные строго от имени своих клиентов и без независимой цели. Если она использует данные клиентов для своей аналитики, улучшения продукта или маркетинга, она становится контроллером для этих действий.
В: Нужно ли процессору регистрироваться в надзорном органе? Требования к регистрации различаются в зависимости от государства-члена ЕС. Однако процессоры должны вести внутренние Записи Деятельности по Обработке (RoPA) в соответствии со статьей 30 GDPR, если они нанимают 250 или более человек или если обработка, вероятно, приведет к риску для субъектов данных.
В: Может ли процессор отказаться от указания контроллера? Да, если выполнение указания потребует от процессора нарушения GDPR. В таких случаях процессор должен уведомить контроллера и, если указание не будет исправлено, может потребоваться прекратить отношения.
В: Что такое соглашение о совместном контроллере? Совместные контроллеры существуют, когда две или более сущности совместно определяют цели и средства обработки. Они должны документировать свои соответствующие обязанности в прозрачном соглашении и сделать суть этого соглашения доступной для субъектов данных [1].
В: Как долго DPA должно оставаться в силе? DPA должно оставаться в силе на протяжении всей обработки. По окончании оно регулирует обязательства процессора по удалению или возврату всех персональных данных.
В: Несут ли процессоры ответственность за штрафы, наложенные на контроллеров? Нет. Штрафы налагаются на лицо, совершившее нарушение. Однако процессоры могут столкнуться с отдельными штрафами за свои собственные нарушения и могут столкнуться с исками о возмещении убытков от контроллеров в соответствии с DPA.
В: Применяется ли GDPR к процессорам, расположенным за пределами ЕС? Да. GDPR применяется к процессорам за пределами ЕС, когда они обрабатывают персональные данные резидентов ЕС от имени контроллеров, расположенных в ЕС, или когда они иным образом подпадают под территориальную сферу действия GDPR в соответствии со статьей 3.
В: Какова разница между 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