Как стать автором
Обновить

Почему не нужно всегда получать согласие на обработку персональных данных в рамках GDPR

Время на прочтение8 мин
Количество просмотров30K
Всего голосов 51: ↑51 и ↓0+51
Комментарии50

Комментарии 50

Есть сайт, пользователь вводит логин, пароль и своё имя, чтобы залогиниться. Я правильно понял из этой статьи, что галка про обработку персональных данных по закону не требуется? Имя нужно, чтобы знать, как к нему обращаться (техподдержка).

Вы не можете оказать техподдержку если не знаете имени пользователя?
Удалите имя, и у вас не будет персональных данных.

А это мысль. Спасибо)
Получается, что, если я прошу только email и пароль, то это уже будет не персональные данные? Как это можно было попроще объяснить пользователю? Заранее спасибо.

Именно так, email и пароль не являются персональными данными согласно GDPR.
Но есть одно исключение — email вида имя.фамилия@компания.com
Как исключить такую ситуация я не знаю.

Наверно тогда по любому придётся ставить галку "Я согласен с обработкой ПД". Видимо, здесь лучше будет перестараться.

Простите, но это не так. Если указаный email может каким либо образом меня идентифицировать, то это персональные данные. Например, у меня емайл вида abs@mail.com и я его испольую как свой основной емайл.
Может быть и так. Посмотрел еще раз, персональными данными считаются даже куки и данные которые зашифрованы, но позволяют повторно идентифицировать пользователя.
По-умолчанию e-mail является ПД, даже если это pinkpony@mail.ru — исключениями будут обезличенные служебные наподобии sales@company.tld какой-нибудь.
ФИО (как и любой другой ОДИН параметр, например просто адрес) в отрыве от других данных не является ПД. если логин не является e-mail-ом, то все ОК.
Да, я про ФЗ-152.
В рамках темы статьи российские ФЗ нерелевантны совершенно
Я бы начал с другого — какова природа технической поддержки. По общему правилу техподдержка подразумевает наличие некой услуги/сервиса, ее предварительное или последующее сопровождение.
До того, как пользователь залогинится, он должен еще и зарегистрироваться.
Стоит более комплексно оценить весь пусть, цели. И да, с точки зрения поставленного вопроса, само имя вообще не требуется.
2) полученных оператором в связи с заключением договора, стороной которого является субъект персональных данных, если персональные данные не распространяются, а также не предоставляются третьим лицам без согласия субъекта персональных данных и используются оператором исключительно для исполнения указанного договора и заключения договоров с субъектом персональных данных;

Вы в интернет — магазине приняли заказ, и передали его курьерской службе для доставки? ФИО и адрес кому доставить передали? ОК, значит этот пункт не про вас. И согласие нужно, и уведомление подавать. И согласие на передачу третьим лицам брать. А если курьер в штате — то да, вы правы, не нужно.

Про GDPR интересно, конечно. Не планируете более полного обзора?

Справедливое замечание, но если в приведенной цитате еще дополнительно выделить «без согласия», тогда пункт приобретает новое значение, в котором само уведомление, возможно, теряет смысл.
Не исключено, что к GDPR придется вернуться еще не раз.
согласие в данном случае не нужно…
явный случай legitimate interest — для выполнения контракта нужно передать данные…

я помню это момент нам юрист как пример приводил

IP-адрес и некий device-id анонимного посетителя сохраняются в базе. Это необходимо, чтобы деанонимизировать посетителя для владельца сайта в случае его обращения по какому-то вопросу.


  1. Являются ли эти данные персональными данными по GDPR? Предполагаю, что да.
  2. Можно ли их сбор обосновать публичной офертой, галочкой или иным юридическим способом?
Как насчет такого сценария — сохранять не IP и device-id, а их хеши (которые не позволяют простого обратного преобразования)?
Тогда с одной стороны есть возможность понять, что это тот же пользователь, а с другой у вас нет его персональных данных.

Иногда надо самому пользователю сказать, какой у него IP, чтобы понять что этот пользователь такой-то и такой-то из других анонимов. Технически можно вообще не хранить ничего, хэшировать, но я хочу понять, как эту проблему юридически решить и желательно без технических изменений.

Есть вариант маскировать последний знак, например: 10.0.10.1x. Если не ошибаюсь, так поступает yahoo.
>Иногда надо самому пользователю сказать, какой у него IP, чтобы понять что этот пользователь такой-то и такой-то из других анонимов
1) Юзер говорит вам свой IP
2) Считаете хэш
3) Сравниваете с хэшем в базе
В итоге и сравнить можно, и данные не хранятся

Вариант, но опять же теоретически можно докопаться, что хэш моих данных тоже мои данные, т.к. позволяет однозначно определить, что это я.


Технически здесь тыща вариантов, я пытаюсь понять, как это юридически натянуть.

Мы вот закончили обсуждать вопрос, включая обсуждение с французским юристом.
За все случаи не скажу, но в нашем случае по HardwareID (просто хэш) ответ такой: т.к. HardwareID не геренируется используя IP или Mac адрес, а использует только идентификаторы железа (CPU etc), то проблем нет.
1. GDPR трактует персональные данные крайне широко. По первому вопросу я бы ответил положительно. Для иллюстрации можно обратиться к п. 30 преамбулы — практически любые данные, которые прямо или косвенно (том числе в своем сочетании) могут определить субъекта.
2. Вам необходимо четко сформулировать цель — зачем вы собираете эти данные и подвести под один из базисов. Например, если вы сделаете обоснование, что необходимо для исключения мошенничества, то вполне вам законный интерес, который необходимо обосновать в политике (по цели, необходимости).

Кстати, в вашем примере это не будет анонимизацией, так как данные могут быть приведены к исходному формату.
А можно ли требования AML и KYC считать законным интересом?
В случае с AML и KYC я бы говорил о базисе (с) ст.6 (1), т.е. когда данные обрабатываются в связи с исполнением обязательств, вытекающих из закона.
В любом случае, ваша политика должна раскрывать какие данные и с какой целью обрабатываете, а также норма закона должна быть четко определена.
На сколько я понимаю у пользователя есть право запросить удаление его данных.
Если пользователь попросил удалить все данные о нем, что делать с бекапами базы данных в которых есть эти данные?
Право на удаление не всегда работает. GDPR содержит исключения, например вы вправе отказать, если данные требуются для защиты от претензий и исков, при наличии обязательств в силу закона и пр.
Прежде всего, необходимо изменить сам подход к обработке данных. В любом случае удалять, вопрос когда.
GDPR определяет, что данные должны обрабатываться в минимальном объеме, самый минимальный срок, обрабатываться в безопасной (защищенной) форме и пр.
Полагаю, что целесообразно (исходя из принципов ст. 5 ) определить правила работы с бэкапами, в которых, описать, в том числе:
  • обязательства по удалению данных в случае разворачивания
  • меры по беспечению безопасности (шифрование, псевдрнимизация, например)
  • сроки планового удаления бэкапов
  • определить условия, при которых данные не удаляются.

Говоря о сроках.
Ст. 12 устанавливает, что все запросы подлежат исполнению без задержек, но не более месяца (срок можно продлить в исключительных случаях).
Было бы хорошей практикой производить автоматическое удаление именно в этот срок (повторюсь, если нет основания для отказа).
Здравствуйте! Так как здесь вижу достаточно много знающих людей, может, если будет интересно, посмотрите следующий вариант политики конфиденциальности? Сайт — некоммерческий блог-сервис/форум стихов с комментариями. При регистрации требуется согласиться галкой с документом. Насколько юридически адекватно и не противоречит законодательству? Убираю в сполер:

Политика конфиденциальности
Политика конфиденциальности

Настоящий документ «Политика конфиденциальности» (далее по тексту – «Политика») представляет собой правила использования Администрацией сайта (далее – «Администрация») данных интернет-пользователей (далее «Пользователь»), собираемых с использованием сайта stiholov.ru (далее – «Сайт»).

1. Обрабатываемые данные

1.1. Мы не осуществляем сбор ваших персональных данных с использованием Сайта и никаким образом не проверяем достоверность тех или иных данных, введенных в формы на сайте, принадлежность кому либо каких бы то не было сведений, псевдонимов, изображений.

1.2. Все данные, собираемые на Сайте, предоставляются и принимаются в обезличенной форме (далее – «Обезличенные данные»), в том числе не требуется подтверждения электронной почты, и любых других данных

1.3. Обезличенные данные и регистрации включают следующие сведения, которые не позволяют вас идентифицировать:

1.3.1. Информацию, которую вы предоставляете самостоятельно с использованием онлайн-форм и программных модулей Сайта:

— электронная почта не проверяемая и не подтверждаемая при регистрации;

— не проверяемый и не подтверждаемый при регистрации псевдоним;

— не проверяемый при регистрации пароль

1.3.2. Данные, которые передаются в обезличенном виде в автоматическом режиме в зависимости от настроек используемого вами программного обеспечения.

1.4. Администрация вправе устанавливать требования к составу Обезличенных данных Пользователя, которые собираются использованием Сайта.

1.5. Если определенная информация не помечена как обязательная, ее предоставление или раскрытие осуществляется Пользователем на свое усмотрение. Одновременно вы даете информированное согласие на доступ неограниченного круга лиц к таким данным. Указанные данные становится общедоступными с момента предоставления и/или раскрытия в иной форме.

1.6. Администрация не осуществляет проверку достоверности предоставляемых данных и наличия у Пользователя необходимого согласия на их обработку в соответствии с настоящей Политикой, полагая, что Пользователь действует на свое усмотрение.

1.7. Вы осознаете и принимаете возможность использования на Сайте программного обеспечения третьих лиц, в результате чего такие лица могут получать и передавать указанные в п.1.3 данные в обезличенном виде.

Пример: К указанному программному обеспечению третьих лиц относятся системы сбора статистики посещений Google Analytics и Яндекс.Метрика.

1.8. Состав и условия сбора обезличенных данных с использованием программного обеспечения третьих лиц определяются непосредственно их правообладателями и могут включать:

данные браузера (тип, версия, cookie);
данные устройства и место его положения;
данные операционной системы (тип, версия, разрешение экрана);
данные запроса (время, источник перехода, IP-адрес).

1.9. Администрация не несет ответственность за порядок использования Обезличенных данных Пользователя третьими лицами.

1.10. Администрация не несет ответственности за размещенные на ресурсе ссылки и материал и пользователи сайта осуществляют переходы по внешним ссылкам на свой страх и риск и соглашаются с ответственностью за свои действия при знакомстве с контентом сайта.

2. Цели обработки данных

2.1. Администрация использует данные в следующих целях:

2.1.1. Обработка поступающих запросов, авторизация пользователем на сайте, отправка сообщений на email, указанный при регистрации;

2.1.2. Информационное обслуживание, включая рассылку рекламно-информационных материалов с разрешения (подписки) пользователя;

2.1.3. Проведение маркетинговых, статистических и иных исследований;

2.1.4. Таргетирование рекламных материалов на Сайте.

3. Требования к защите данных

3.1. Администрация осуществляет хранение данных и обеспечивает их охрану от несанкционированного доступа и распространения в соответствии с внутренними правилами и регламентами.

3.2. В отношении полученных данных сохраняется конфиденциальность, за исключением случаев, когда они сделаны Пользователем общедоступными, а также когда используемые на Сайте технологии и программное обеспечение третьих лиц либо настройки используемого Пользователем программного обеспечения предусматривают открытый обмен с данными лицами и/или иными участниками и пользователями сети Интернет.

3.3. В целях повышения качества работы Администрация вправе хранить лог-файлы о действиях, совершенных Пользователем в рамках использования Сайта в течение 1 (Одного) года.

4. Передача данных

4.1. Администрация вправе передать данные третьим лицам в следующих случаях:

Пользователь выразил свое согласие на такие действия, включая случаи применения Пользователем настроек используемого программного обеспечения, не ограничивающих предоставление определенной информации;
Передача необходима в рамках использования Пользователем функциональных возможностей Сайта в том числе для авторизации через соцсети;
Передача требуется в соответствии с целями обработки данных;
В связи с передачей Сайта во владение, пользование или собственность такого третьего лица;
По запросу суда или иного уполномоченного государственного органа в рамках установленной законодательством процедуры;
Для защиты прав и законных интересов Администрации в связи с допущенными Пользователем нарушениями.

5. Изменение Политики конфиденциальности

5.1. Настоящая Политика может быть изменена или прекращена Администрацией в одностороннем порядке без предварительного уведомления Пользователя. Новая редакция Политики вступает в силу с момента ее размещения на Сайте, если иное не предусмотрено новой редакцией Политики.

5.2. Действующая редакция Политики находится на Сайте в сети Интернет по адресу

Действующая редакция Политики от 27 января 2018 г.


Большое спасибо заинтересовавшимся!
Достаточно противоречивая политика. Ее сложно отнести к соответствующей как GDPR, так и 152-ФЗ.
Если брать с первых положений, то контролер должен быть указан. Т.е. написать «Администрация сайта» не считается.
С одной стороны говорится об обезличенности, с другой стороны об использовании совокупности данных, которые определяют субъекта (IP, куки и пр.), право на директ-маркетинг.
На какие-то позиции возможно получение согласия, однако право на его отзыв не отражено, равно как и иные права субъекта.
Право на передачу иным лицам есть, однако такие лица не раскрыты.
В общем, требуется значительная доработка.

Ваш сайт по своей структуре не ориентирован на европейский рынок.
Если с позиции 152-ФЗ, то здесь подход к определению персональных данных иной.
Сам РКН рекомендует как cделать политику правильно.

Как раз начали разбираться с этой регулой, всё не можем понять, про нас это или нет.


У нас немного нетипичная ситуация: собираем различные данные с датчиков и обрабатываем их. Железяки находятся за пределами ЕС, софт и данные — на Европейском сервере. Пользователи заходят в наш софт через третью сторону (в нашем случае это Auth0), который производит аутентификацию и выдает токен. На своей стороне мы получаем id и fullName пользователя и показываем ему данные с его железяк.


Если не составит труда, подскажите:


  • данные с железяк (температура, влажность, итд) считаются ПД?
  • кто обрабатывает пользователя (username, password) — Auth0 или всё-таки мы? Должны ли мы оповестить пользователя, что мы получили его имя через токен? Или всё таки это ответственность сервиса?
1. Если железяки не собирают биометрию, то с ними все ок.
2. С аутентификацией тоже не сильно сложно.
Существует несколько потенциальных ваших статусов. Основные:
  • Контролер, т.е. лицо, которое определяет цели, средства обработки данных
  • Процессор, т.е лицо, производящее обработку по поручению контролера.
  • Третья сторона, т.е. сторона, которой данные раскрываются

В вашем случае надо определить роли в процессе.
По GDPR информация об обработке должна быть предоставлена в период первого сбора данных.
Если этот третий сервис обеспечивает регистрацию, может влиять на состояние полей, куда и как эти данные передать, то Контролером, полагаю, выступать будет она. Вы должны быть указаны в политике Контролера в числе лиц, которым данные передаются.
Из вопроса не следует, где находятся пользователи. Если вы не предлагаете услуги на территории Евросоюза, то расположение там сервера не создает обязанности по применению GDPR.
Всё бы хорошо, но почти всегда есть ситуации, когда договор заключаем с одним лицом (юридическим), а персональные данные получаем другого (пользователя, который может быть сотрудником юр. лица — контрагента, работать с ним по договору или быть просто знакомым, с которым поделились учётной записью; в общем случае приходится исходить из того, что природа отношений между контрагентом по договору и конкретным пользователем нам неизвестна).
Я правильно понимаю, что в этом случае все описанные лайфхаки неприменимы и идём по тернистому пути с согласиями, галочками и уведомлениями?
Вопрос, на самом деле, крайне обширный.
Повторюсь, но требуется определить какие данные, как и зачем вы собираете, установить базис.
Существует ли необходимость обработки данных работника, имея отношения с юр. лицом?
Можно смоделировать ситуацию, например, договор о предоставлении услуг отеля с юр. лицом. Отелю предоставляются данные работника, который будет проживать (мы говорим о ситуации на территории Евросоюза).
В GDPR определен порядок действий контролера в зависимости от того, получены ли данные от субъекта или иных источников — ст. 14.
Все прозрачно. Необходимо лишь каждому учитывать свою специфику.
Насколько я понимаю, статья именно про обработку. Для сбора данных во всех случаях нужно согласие?
Обработка включает в себя все этапы работы с данными. Статья как раз о том, что не всегда требуется согласие. Порой, достаточно ознакомить с политикой.
DenisPoison, а вы можете немного подробней описать ситуацию с CRM?

Для примера возьмем продавца, который пользуется CRM. В ней наш пользователь хранит контактные данные своих реальных и потенциальных клиентов. Так вот, какие есть способы избежать разрешения/запрета на использование персональных данных со стороны этих клиентов?
На стороне CRM, думаю, должны быть реализованы универсальные настройки.
Со стороны поставщика схемы индивидуальны, равно как и объем данных. Например, продавец может формировать бессрочный договор (оферту) и данные хранить уже согласно определенной им политике.
В части предполагаемых клиентов имеется хороший пример от Information Commissioner's Office. Лучше смотреть оригинал.
Суть в 2-х словах: при сборе данных (в примере — из визитных карточек) допустимо опираться на legitimate interest, так имеется обоснованная бизнес цель, недостижимая иным образом, риском для субъекта минимален, а последующая обработка данных очевидна. При этом помнить про порядок обоснования в политике, уведомлении о права и обработке.
Стоит не забывать, что согласие/уведомление лишь малая часть того, что необходимо соблюдать по GDPR.
Очень хороший текст. Могу придраться только к отсутствию акцента на том, что «Откажитесь от сбора информации, которую вы собираете на всякий случай.» — это не просто рекомендация, а базовое требование GDPR, абсолютно обязательное к исполнению.
Спасибо. Избыточность уже и по национальному законодательству давно не приветствуется.
Теперь можно надеяться, что эти галки согласия появятся в том или ином виде в Billmanager? До сих пор поддержка предлагала делать самодельные костыли для этих целей.

Upd: И что с правом на забвение? Сейчас по таким запросам приходится менять все данные пользователя.
Мы готовимся к вступлению в силу GDPR и к 25 мая все наши панели будут ему соответствовать. Что касается «права на забвение», в BILLmanager уже есть возможность удаления пользователя, но применять ее нужно с осторожностью (с учетом потенциальной востребованности данных в целях защиты от претензий и исков, исполнения запросов правоохранительных органов и пр.)
Хорошая статья, спасибо! Скажите, а не разбирались ли вы с вопросом о шифровании данных — в каких случаях оно нужно, в каких настоятельно рекомендуется?
GDPR не предопределяет меры технической защиты, которые необходимо применять. Требованием является применение способов защиты, которые приемлемы исходя из рисков, возникающих из характера обработки.
Вообще GDPR смотрит в сторону риск-ориентированного подхода.
Безопасность не относится только к вопросам псевдонимизации и шифрования — должны быть обеспечены подходящие организационные и технические меры (в т.ч. находящиеся в сфере off-line).
В части шифрования у ICO имеется отдельный блок рекомендаций, который, фактический, можно свети к одной позиции – шифруйте, если это применимо.
Все основные существующие позиции по информационной безопасности относятся к предшествующему документу (Data Protection Act). Например, «Руководство по облачным вычислениям», «IT-безопасность», «Защита в онлайн сервисах».
Автор статьи написал:
«А теперь внимание! Статья 22 того же закона определяет, что если обработка данных необходима для исполнения договора, то уведомлять Роскомнадзор не нужно».

А теперь внимание автору, в ст. 22 указано, что оператор вправе осуществлять без уведомления уполномоченного органа по защите прав субъектов персональных данных обработку персональных данных, полученных оператором в связи с заключением договора, стороной которого является субъект персональных данных, если персональные данные не распространяются, а также не предоставляются третьим лицам без согласия субъекта персональных данных и используются оператором исключительно для исполнения указанного договора и заключения договоров с субъектом персональных данных.

Т.е. только если сторона договора физ. лицо. А если это юридическое лицо, тогда нужно.
Об этом уже написали в комментах до меня, ну и плюс другие ограничения, установленные этим пунктом статьи.
Так что не нужно людей в заблуждение вводить.

Не соглашусь с вашим заявлением и обосную почему.
Сразу разберемся в понятиях – мы говорим о 152-ФЗ, об уведомлении.
Оператор – физические и юридические лица (в любых сочетаниях и комбинациях).
Персональные данные – информация, относящаяся к определённому или определяемому физическому лицу (субъекту персональных данных).
Оператор вправе осуществлять без уведомления уполномоченного органа по защите прав субъектов персональных данных обработку персональных данных: полученных оператором в связи с заключением договора, стороной которого является субъект персональных данных, если персональные данные не распространяются, а также не предоставляются третьим лицам без согласия субъекта персональных данных и используются оператором исключительно для исполнения указанного договора и заключения договоров с субъектом персональных данных (подп. 2 п. 2 ст. 22).
Если кратко — данные только для договора и не передаются, а если передаются, то с согласия.
В силу приведенной ситуации договор, попадающий под п. 2 ст. 22 может быть заключен: между оператором (физическим или юридическим лицом) и субъектом данных (физическим лицом).
Договор между оператором и юридическим лицом выпадает из отношений, так как это юридическое лицо не субъект персональных данных.
Усилю свою позицию судебной практикой, при которой суды подтверждают позицию об отсутствии необходимости – дело А19-17054/2017 (см. стр. 7 решения), или Постановление Верховного Суда РФ от 05.08.2011 N 20-АД11-3.
Судебной практики, увы (или к счастью), не так много, так как статья достаточно очевидна в своем применении.
Договор между оператором и юридическим лицом выпадает из отношений, так как это юридическое лицо не субъект персональных данных.

Это юр. лицо не субъект персональных данных, но при заключении передаются перс. данные представителя этого юр. лица, например, ФИО подписанта договора — представителя юр. лица. Таким образом, оператор ПД, будучи юр. лицом, получает от другого юр. лица персональные данные физ. лица и именно поэтому он должен направить уведомление в Роскомнадзор.

А вначале статьи это почему-то не учитывается и делаются неправильный обобщающий вывод:
А теперь внимание! Статья 22 того же закона определяет, что если обработка данных необходима для исполнения договора, то уведомлять Роскомнадзор не нужно.


Этот вывод неправильный и вводящий в заблуждение еще потому, что второй стороной по договору должен быть не только сам субъект ПД, но и еще пару параметров:
-если персональные данные не распространяются,
— а также не предоставляются третьим лицам без согласия субъекта персональных данных и используются оператором исключительно для исполнения указанного договора и заключения договоров с субъектом персональных данных.
НЛО прилетело и опубликовало эту надпись здесь
Позволю себе тоже комментарий по поводу 22 статьи ФЗ-152 =)
В Вашем выводе ключевой тезис «если Вы обрабатываете ПДн клиентов в рамках договора, то уведомление в РКН подавать не надо», это может ввести в заблуждение неопытного читателя, которые разбирается в ФЗ-152, потому что помимо клиентов есть еще работники, с которыми может быть отдельная песня. То есть нельзя только на основании этого тезиса принимать решение об уведомлении, необходимо рассмотреть под лупой всех субъектов ПДн, от кого получаются ПДн, и всех действующих лиц, которые в этой обработке участвуют, и лишь потом принимать решение об уведомлении РКН.
Автор, спасибо за отличную статью.
Скажите, а если сайт не собирает никаких данных. Но на сайте стоит analytics/adsense/pixel и т.п. — нужно что-то дополнительно делать или нет?
На западных форумах читал как мнения, что нужно прописывать информацию о том, что собирается, так и мнения, что ничего не нужно дополнительно делать. Что Вы думаете по этому поводу?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий