Контролер от слова «контроль»: как управлять цепочкой процессоров по GDPR?
- 12 декабря, 2025
- Data Protection Officer, GDPR, Защита данных
Автор: Анастасия Пархимович, CIPP/E, GDPR DPP, консультант Data Privacy Office.
Когда компания выходит на европейский рынок или начинает работать с персональными данными более структурировано, возникает логичный вопрос: какие документы для защите персональных данных по GDPR действительно нужны и зачем тратить на них время? В этой статье мы разберём, какие документы являются критически важными, какие дополняют систему защиты персональных данных, и как создавать их так, чтобы они работали в реальности. Если вы начинающий специалист по приватности или стартап, который хочет избежать ошибок, — этот материал поможет расставить приоритеты.
Содержание
«Большой Брат Контролер следит за тобой!»
Когда контролер инициирует обработку персональных данных, он определяет два ее главных элемента: «для чего?» (цель обработки) и «как?» (средства обработки). При этом само по себе решение о привлечении процессора, а также выбор конкретного процессора рассматриваются как определение средства обработки (то самое «как?»). Следовательно, именно контролер говорит решающее «да» или «нет» на привлечение любого дополнительного процессора любого уровня (суб-процессора, суб-суб-процессора и так далее).
За счет чего он осуществляет такую возможность? Согласно ст. 28(2) GDPR, процессор (с которым у контролера уже есть договорные отношения) не должен привлекать другого процессора без предварительного специального или общего письменного разрешения контролера.
Статья: Контролер и процессор
Объясняем простым языком, кто является контролером, а кто — процессором по GDPR.
Читать
EDPB уточняет, что процессором по смыслу ст. 4(8) GDPR является не только процессор первого уровня, привлеченный непосредственно контролером, но и процессор процессора и т.д. на всей протяжении цепочки обработки данных. То есть, обязанности контролера, связанные с проверкой процессора при присоединении его к цепочке обработки данных, относятся к абсолютно всем процессорам независимо от их уровня. (Мнение 22/2024 об определенных обязанностях, следующих из привлечения процессора(ов) и суб-процессора(ов), принятое EDPB 7 октября 2024 г., пар. 17 и 39.)
Пример: Компания А, испанский интернет-гипермаркет, обращается в местное маркетинговое агентство В для увеличения продаж с помощью маркетинговой рассылки. Предполагается, что компания B получит данные о текущих клиентах интернет-гипермаркета и их покупках за последние два года, проанализирует эти данные, разделит покупателей на сегменты и отправит всем покупателям рекламные сообщения по электронной почте. Они будут отличаться в зависимости от того, к какому сегменту был отнесен покупатель. Среди передаваемых компании B данных: адрес электронной почты покупателя и все заказы, оформленные на этот адрес электронной почты за последние два года.
Компания А является контролером персональных данных.
Маркетинговое агентство В является процессором персональных данных.
В соответствии с Data Processing Agreement, который был заключен между компаниями А и Б, компания Б обязана запрашивать предварительное специальное разрешение контролера на привлечение любого процессора, кроме тех, которые уже включены в Data Processing Agreement.
На момент заключения Data Processing Agreement в нем указаны два процессора, которым агентство В имеет право передавать персональные данные: платформа электронной рассылки С и ее хостинг-провайдер D. И платформа электронной рассылки C, и ее хостинг-провайдер D расположены за пределами ЕЭЗ, в Израиле. Израиль является юрисдикцией с адекватным уровнем защиты персональных данных в соответствии с решением Еврокомиссии.
Разрешение контролера (общее письменное или предварительное специальное) — это инструмент, который позволяет контролеру выбирать способ обработки персональных данных: какой именно процессор будет привлечен, будут ли персональные данные передаваться за пределы Европейское Экономической Зоны (ЕЭЗ), какие именно защитные меры будут использоваться и т.д. В зависимости от договоренностей между сторонами контролер добавляет очередного участника к обработке данных либо своим прямым «да» (предварительное специальное разрешение), либо отсутствием прямого «нет» (общее письменное разрешение). Важно отметить: в рамках обоих вариантов у процессора есть обязанность заблаговременно известить контролера о намерении привлечь к обработке данных еще одного участника, а у контролера — право запретить процессору привлекать соответствующего участника к обработке (при этом процессор обязан такому решению подчиниться). На практике это означает, что:
📎 какого бы уровня процессор ни собирался привлечь суб-процессора, одобрение придется получать именно от контролера, то есть, передавать информацию по цепочке до «локомотива» обработки. Согласно ст. 28(4) GDPR, первоначальный процессор обязан не только сам следовать процедуре запроса согласия, но и передавать ее по цепочке договоров до самого последнего звена. Таким образом, даже договор с процессором последнего (например, 5-го) уровня должен содержать такую обязанность;
80 000 евро за доставку документов
Клиент ING Bank в Испании отправил в банк комплект бумажных документов (анкета, копия DNI, подписи и др.) для оформления себя как совладельца счета партнера.
Отправка шла через курьерскую цепочку: ING Bank (контролер) заключил DPA с курьером DYNAMIC (процессор), DYNAMIC привлек SENDING как суб-процессора, а SENDING, в свою очередь, задействовал еще одну курьерскую компанию — AUTORADIO. Именно сотрудник AUTORADIO забрал конверт у клиента, но документы были утрачены (ING Bank так и не получил пакет). Клиент банка подал жалобу в надзорный орган.
Было установлено, что SENDING выступала как суб-процессор ING Bank и должна была соблюдать требования ст. 28 GDPR. Договор между ING Bank и компанией DYNAMIC (процессор первого уровня) предусматривал строгое (специфическое) одобрение всех суб-процессоров. Эта обязанность была передана компанией DYNAMIC дальше по цепочке, то есть, SENDING, желая привлечь AUTORADIO к обработке данных, должна была запросить согласие ING Bank. Однако SENDING, нарушив и договор с DYNAMIC, и положения ст. 28(2) GDPR, не запросила разрешение на привлечение суб-процессора. Более того, договор между SENDING и AUTORADIO не соответствовал требованиям ст. 28(4) GDPR: в нем не был идентифицирован контролер ING Bank, роли были описаны некорректно, а условия обработки и меры безопасности не соответствовали стандарту обязательств по договору между ING Bank и DYNAMIC.
📎 контролер всегда рассматривает конкретную кандидатуру (суб-)процессора. То есть, процессор обязан собрать досье на каждого потенциального участника обработки, и ждать решения контролера. Запросить «добро» на категорию процессоров (например, «курьерские организации» или «операторы email-рассылки») не получится;
📎 обязанность контролера — рассмотреть кандидатуру, предложенную процессором, и принять решение. Это следует из обязанности контролера «…использовать услуги только таких процессоров, которые обеспечивают достаточные гарантии по осуществлению соответствующих технических и организационных мер таким образом, чтобы обработка отвечала требованиям GDPR и обеспечивала защиту прав субъекта данных». Даже если, по мнению контролера, обработка представляет минимальный риск для прав и свобод субъекта, это никак не может быть основанием для неисполнения такой обязанности (хотя и влияет на степень проверки кандидата);
📎 договор между контролером и процессором (а также между процессорами последующих уровней) не может включать условие о том, что контролер дает процессору общее согласие на привлечение любых (суб-)процессоров последующих уровней по выбору процессора (без необходимости представлять кандидатуры на рассмотрение контролера). Даже если такое условие будет включено в договор, оно будет недействительным с самого начала: договору не под силу изменить правовую норму ст. 28(2) GDPR.
Это означает, что идентификационная информация (имя/наименование, адрес, контактное лицо и описание действий с данными) обо всех процессорах всех уровней всегда должна быть доступна для контролера, поскольку именно последний несет ответственность за действия каждого процессора в цепочке.
⚡️Хотите научиться грамотно оформлять отношения между контролером и процессором?
Пройдите наш фундаментальный курс GDPR Data Privacy Professional. На нем участники изучают основные аспекты GDPR и учатся применять их на практике.
Я контролер. Зачем мне знать каждого участника цепочки?
GDPR возлагает на контролера ряд обязанностей, исполнить которые без информации о каждом участнике цепочки обработки данных невозможно:
1) согласно ст. 13(1)(е) и 14(1)(е) GDPR контролер обязан включить в политику обработки персональных данных сведения о получателях (или категориях получателей) данных. При этом он должен стараться предоставить максимально конкретные сведения. В соответствии с пар. 37 Руководства о принципе прозрачности, по общему правилу, максимально конкретные сведения — это поименное перечисление получателей данных. (Руководство Рабочей группы по 29 статье о прозрачности, как она закреплена в Регламенте 2016/679, принятое 29 ноября 2017 г., дополненное и принятое в новой редакции 11 апреля 2018 г.) Если контролер выбирает указывать не наименование получателя, а его категорию, следует обязательно уточнить сферу деятельности и место нахождения такого получателя;
Пример: В соответствии с Data Processing Agreement к цепочке обработки персональных данных контролер — интернет-магазин А — присоединил процессоров — маркетинговое агентство B, платформу электронной рассылки C и ее хостинг-провайдера D. Платформа и ее хостинг-провайдер зарегистрированы и физически расположены в Израиле. В политике обработки персональных данных контролер указывает либо конкретные сведения о получателях персональных данных (название компании, ее адрес, ссылка на сайт в интернете), либо их категории, например: «маркетинговое агентство, занимающееся анализом покупательских предпочтений», «платформа для направления рассылки по электронной почте», «хостинг-провайдер».
2) как предусмотрено ст. 13(1)(f) и 14(1)(f) GDPR, контролер указывает в политике обработки персональных данных также сведения о трансграничной передаче данных, включая сведения о государстве назначения и применимых гарантиях. Для того, чтобы знать, в какие именно страны отправятся персональные данные, контролеру важно иметь доступ к информации обо всех получателях данных (независимо от того, как далеко они стоят от контролера в цепочке обработки);
Пример: платформа электронной рассылки С и ее хостинг-провайдер D зарегистрированы и физически расположены в Израиле. В политике обработки персональных данных интернет-магазин А указывает, что персональные данные покупателей будут переданы платформе электронной рассылки и хостинг-провайдеру, находящимся в Израиле. Израиль является юрисдикцией с адекватным уровнем защиты персональных данных в соответствии с решением Еврокомиссии.
3) в соответствии со ст. 15 GDPR (право на доступ к персональным данным) субъект имеет право получить от контролера информацию о получателях или категориях получателей персональных данных. Суд ЕС уточнил, что это положение обязывает контролера предоставить сведения о конкретных получателях (то есть, субъект должен получить перечень лиц, которым передавались именно его персональные данные) (Решение Европейского суда от 12 января 2023 г. по делу RW v Österreichische Post AG, C‑154/21, пар. 51.);
Пример: один из покупателей интернет-магазина А обратился к контролеру с запросом на доступ к его персональным данным, в том числе к сведениям о получателях его данных. В ответе субъекту интернет-магазин А указал конкретных получателей персональных данных:
📎 маркетинговое агентство B, зарегистрированное в Испании;
📎 платформа электронной рассылки C, зарегистрированная в Израиле;
📎 хостинг-провайдер D, зарегистрированный в Израиле.
4) ст. 19 GDPR предусматривает, что контролер обязан сообщить о запросе на удаление или исправление персональных данных всем получателям, которым были переданы соответствующие данные.
⚠️ Важно: все эти обязанности относятся не только к первоначальному процессору, отношения с которым строит непосредственно контролер, но и ко всем остальным процессорам (и получателям данных) в цепочке обработки данных (суб-процессорам, суб-суб-процессорам и т.д.). Так что даже если трансграничная передача происходит между процессором и суб-процессором (или даже между процессорами 4 и 5 уровней), задача контролера ‒ отследить эту передачу и включить ее в собственную политику обработки персональных данных.
Что делать?
Вопрос вполне закономерный — и ответ на него есть. Предлагаем план действий для контролера:
1) Если вы намерены привлечь к обработке процессора, соберите информацию:
📎 оцените риски конкретной обработки данных. Так, например, риски выше, если вы обрабатываете специальные категории данных, например, данные о здоровье или участии в профсоюзе. Хотя, если именно эти категории данных не будут передаваться процессору, риск будет не так высок. Продумайте, какие именно защитные меры помогут минимизировать риски;
📎 подберите потенциальных кандидатов в процессоры. На этом этапе контролер просматривает общедоступную информацию, например, политику обработки персональных данных, сведения о сертификациях или кодексах поведения, которым следует процессор. Нелишним будет проверить историю потенциального процессора с точки зрения утечек данных или привлечения к ответственности за нарушение законодательства о персональных данных;
📎 свяжитесь с лучшими из кандидатов и уточните, какие организационные и технические меры защиты данных они принимают. Получив информацию, оцените, насколько эти организационные и технические меры помогают минимизировать риски соответствующей обработки персональных данных;
350 000 евро за попытку переложить ответственность
Польская компания A (контролер) поручила компании X (процессор / IT-подрядчик) миграцию и обслуживание веб-сайта.
В процессе запуска нового веб-сайта (переходе на новый сервис) сотрудники X скопировали файлы с резервными копиями баз данных старого сайта в новую папку, которая должна была быть скрыта, но оказалась предоставленной в общем доступе. В результате конфигурация сервера позволила поисковым роботам индексировать этот каталог и персональные данные около 21 000 человек (ФИО, адреса, e-mail, телефоны, даты рождения, PESEL и др.) стали доступны для просмотра и скачивания через поисковую систему.
После выявления инцидента контролер уведомил надзорный орган. Он, в свою очередь, провел проверку и привлек к ответственности и контролера, и процессора за непринятие надлежащих технический и организационных мер защиты и нарушение принципа подотчетности. Так, до заключения договора с процессором контролер не провел надлежащий анализ рисков и оценку влияния. DPA носил общий характер, не закреплял конкретные требования к безопасности, мониторингу и аудиту (безопасность данных была фактически делегирована процессору). В свою очередь, принятые процессором меры безопасности были несоразмерны рискам: процессор не проводил проверку конфигурации, тестирование среды, не осуществлял адекватный контроль доступа и шифрования.
📎 узнайте, прибегают ли потенциальные процессоры к услугам суб-процессоров. Если да, стоит уточнить, находятся ли такие суб-процессоры внутри ЕЭЗ или за ее пределами. В отношении суб-процессоров, которые находятся за пределами ЕЭЗ, важно также проверить статус юрисдикции назначения (наличие решения Еврокомиссии об адекватности) и применимые гарантии в соответствии с Главой V GDPR;
2) выберите лучшего кандидата среди потенциальных процессоров и заключите с ним DPA в соответствии со ст. 28 GDPR:
📎 определите тип разрешения на привлечение новых процессоров (общее письменное или предварительное специальное). Если вы выбрали общее письменное разрешение, предусмотрите в договоре, как именно процессор должен представлять вам кандидатуры на рассмотрение. Иногда процессор публикует информацию о потенциальном суб-процессоре на отдельной странице сайта, к которой имеют доступ все контролеры; иногда данные о потенциальном суб-процессоре направляются через уведомления в электронном кабинете контролера на платформе процессора или по электронной почте. Также предусмотрите, сколько времени у вас будет на принятие решения. Полезно также включить в договор критерии подбора суб-процессора, например, только компании с сертификацией ISO 27701 или компании, находящиеся в ЕЭЗ: они будут ориентиром для процессора, а значит, при соблюдении критериев шансы на одобрение со стороны контролера будут выше;
Пример: маркетинговое агентство B провело сегментацию покупателей интернет-магазина А для последующего направления им электронной рассылки. Однако в ходе оказания услуг интернет-магазину А потребовался дополнительный анализ покупателей. К сожалению, специалисты маркетингового агентства B не имели большого опыта в проведении такого анализа. Однако их коллеги из маркетингового агентства Е давно занимались таким анализом и могли бы его провести.
Поскольку Data Processing Agreement предусматривал обязанность компании B получать специальное предварительное разрешение на привлечение других процессоров, агентство обратилось к контролеру, представив сведения о практиках обработки и защиты персональных данных в компании Е. Эти сведения маркетинговое агентство B получило, заранее направив агентству E опросник для уточнения того, какие именно меры принимает эта компания для защиты персональных данных. Интернет-магазин А рассмотрел сведения о практиках обработки персональных данных в компании Е, посчитал применимые меры защиты достаточными и разумными и предоставил маркетинговому агентству В разрешение на привлечение субподрядчика.
В связи с привлечением субподрядчика контролеру необходимо внести изменения в политику обработки персональных данных.
Поскольку маркетинговое агентство Е находится в Испании, сведения о трансграничной передаче персональных данных дополнять не нужно.
Если первоначальная версия политики обработки персональных данных предусматривала перечень конкретных получателей данных, интернет-магазину А необходимо внести маркетинговое агентство Е в этот список. Если же изначально политика содержала лишь категории получателей персональных данных, дополнять политику не нужно, поскольку компания Е, так же, как и компания В, относится к «маркетинговым агентствам, занимающимся анализом покупательских предпочтений».
📎 в зависимости от степени риска для прав и свобод субъектов данных определите глубину проверки процессора в ходе исполнения договора. Закрепленная в ст. 28(1) GDPR обязанность контролера не исчерпывается преддоговорным этапом: в течение всего срока сотрудничества контролер обязан регулярно проверять, принимают ли процессоры, участвующие в обработки, необходимые меры защиты данных. Так, если DPO процессора ежегодно публикует отчет о состоянии защиты персональных данных, контролер может настоять на том, чтобы копия этого отчета предоставлялась и ему. Способом проверки может также быть направление процессору ежегодного опросника;
📎 каждый раз, когда процессор желает привлечь к обработке данных суб-процессора, ознакомьтесь с полученным «досье». Контролер не вправе переложить на процессора обязанность привлекать к обработке данных только надежных контрагентов. Следовательно, решающее слово за контролером. Насколько надежным выглядит потенциальный суб-процессор? В какой юрисдикции он находится? Какие меры защиты данных принимает? Достаточны ли такие меры для минимизации рисков именно вашей обработки?
3) Своевременно вносите сведения о получателях данных и трансграничной передаче данных в политику обработки персональных данных. Помните: как контролер, вы обязаны описать все случаи трансграничной передачи данных на всей протяженности цепочки обработки.
4) Ведите каталог получателей данных для каждой конкретной обработки. Согласно ст. 30(1)(d) GDPR, в реестре обработок допускается указывать лишь категории получателей. Но для того, чтобы исполнить свои обязанности (а также в соответствии с принципом подотчетности) контролеру необходимо держать сведения о получателях данных под рукой.
Команда Data Privacy Office всегда готова помочь вам организовать обработку персональных данных с участием процессора. Мы:
📎 проверим уровень соблюдения потенциальным (или актуальным) процессором законодательства о защите персональных данных, а также наличие информации о привлекаемых суб-процессорах;
📎 составим DPA, в котором будут учтены ваши интересы как контролера персональных данных;
📎 дополним сведения в реестре обработок персональных данных и политике обработки персональных данных о получателях персональных данных и юрисдикциях назначения, если персональные данные передаются за пределы ЕЭЗ;
📎 соберем в единую базу информацию обо всех участниках цепочки обработки персональных данных.
