Лайфхак по 152-ФЗ
Для начала небольшое, но важное отступление.
Недавно знакомый из торговой компании попросил посмотреть их договор с веб-студией. Те собирались дорабатывать сайт магазина. Первым делом я открыл техзадание и увидел, что ребята планируют зарегистрировать владельца сайта в Роскомнадзоре как оператора персональных данных. Я подумал: «Они это серьезно?» И сам же ответил: «К сожалению, да».
Такой же совет будет в семи из десяти статей-инструкций по соблюдению закона «О персональных данных» (152-ФЗ). Советчики говорят: «Первым делом подайте заявление о включении в реестр операторов персональных данных». И многие этой рекомендации следуют.
А теперь внимание! Статья 22 того же закона определяет, что если обработка данных необходима для исполнения договора, то уведомлять Роскомнадзор не нужно.
Вы продаёте товары/услуги через интернет? Отлично! Если не используете данные ни для чего больше, то и уведомление в Роскомнадзор подавать не надо. Вот такой простой рецепт.
Ну а теперь к теме.
О GDPR и почве для ошибок
25 мая в силу вступает европейский аналог нашего 152-ФЗ — GDPR (General Data Protection Regulation). Документ касается всех, кто продает на территории Евросоюза товары и услуги. Мы в ISPsystem делаем ПО для хостинга и дата-центров, которое покупают по всему миру, в том числе в Евросоюзе. Поэтому для нас тема очень актуальна.
Разобраться в GDPR сложно, а за нарушение грозят штрафы до 20 000 000 евро или 4% от годовой общемировой выручки. Поэтому о нем говорят много, и как в истории со 152-ФЗ дают якобы универсальный совет: «получайте согласие на обработку персональных данных».
Европейский интернет пестрит такими заявлениями (вырвано из контекста):
«You should always get consent for the data you wish to collect. Not only will that meet the requirement of a legal basis to collect, but it’s also a general requirement under the GDPR».Если перевести совсем вольно, то выходит: «вы должны всегда получать согласие».
После таких статей хочется сделать 100500 «галочек о согласии». Но действительно ли всегда нужно согласие на обработку персональных данных? Нет, не нужно! Как минимум — не всегда.
«Попытайся понять главное. Ложки не существует» ((С) фильм «Матрица»).
Мы привыкли воспринимать согласие пользователя как единственно возможное основание для обработки данных. Но это неверно. Надо воспринимать его как отдельный правовой базис, как одно из оснований. Согласие как зеленка: помогает, но не от всего.
Основания для работы с персональными данными
Обработка персональных данных законна, только если она производится в соответствии с принципами ст. 5 и на основании одного из шести правовых базисов ст. 6 GDPR.
Несмотря на то что слово «согласие» встречается в тексте GDPR 72 раза, это всего лишь одно из оснований обработки, и не более.
Согласно п. 7 ст. 14 нашего 152-ФЗ, оператор (в терминологии GDPR «контролер», лицо, которое определяет цели и средства обработки) тоже должен определить правовые основания и цели обработки персональных данных. Но для этого нужно изучить много нормативов и сослаться на конкретные положения законов. В GDPR проще: закон требует определить только правовой базис.
С позиции ст. 6(1) GDPR к таким базисам относятся:
- a) согласие субъекта данных на обработку персональных данных для одной или нескольких конкретных целей;
- b) обработка для исполнения договора, в котором субъект данных является одной из сторон, а равно и в отношении шагов, предшествующих заключению договора;
- c) обработка необходима для соблюдения законных обязанностей, субъектом которых является контролёр;
- d) обработка для защиты жизненных интересов субъекта данных, либо иного физического лица;
- e) обработка в общественных интересах или при осуществлении официальных полномочий, возложенных на контролера;
- f) обработка для целей обеспечения законных интересов контролёра или третьего лица.
Согласие субъекта данных нужно, только если никакой другой базис не подходит. Везде и всегда его получать не надо. Тем более что по GDPR у субъекта данных должна быть возможность легко изменить свое решение: как поставить галочку, так и снять ее.
Поэтому до начала верстки формы с «галочками» определите, какие данные и зачем вы собираете, установите применимый базис. Откажитесь от сбора информации, которую вы собираете на всякий случай. Не исключено, что после этого вам вообще не потребуется получать согласие на обработку. Об этом и расскажу подробнее.
Персональные данные и договор: обрабатываем и не спрашиваем
Базис по своему содержанию аналогичен российскому законодательству (вспомним историю из введения).
Согласно подп. (b) ст. 6(1) GDPR, если обработка данных необходима для исполнения договора, вы можете без труда — и, главное, без согласия — ее производить. Даже до заключения договора, но при условии, что действия были запрошены самим субъектом данных (например, он отправил заявку).
Здесь стоит сделать ремарку: данные должны обрабатываться только в том объеме, который необходим для исполнения договора. Если информация нужна для заполнения полей CRM, то она остается вне этого базиса.
Простой пример. Компания продает товары через интернет. При оформлении покупки клиент предоставляет персональные данные, магазин обрабатывает их в связи с исполнением договора. Надо получать согласие? Нет, если данные не избыточны и не будут использоваться иным способом.
Необходимо только сообщить пользователю, что данные все-таки обрабатываются, а также рассказать о способах обработки, мерах по защите и ознакомить с иной информацией в соответствии с GDPR (ст. 5, ст. 13, 14).
В форму заказа магазину надо добавить только уведомление об ознакомлении с политикой. Требовать поставить пресловутую галочку о согласии, создавать технические условия с целью возможности подтверждения получения согласия (п. 42 преамбулы) не нужно. Отмечу, что хорошо бы иметь галочку об ознакомлении с политикой.
Однако, если компания хочет использовать персональные данные, например, для точечных рекламных рассылок, то это уже не подпадает под договорный базис. В этом случае обработка имеет две цели, вторая из которых должна строиться на основании согласия или на основании законного интереса (о нем ниже).
Законный интерес или базис без согласия
Вторым наиболее пластичным базисом является «законный интерес» (legitimate interest).
Законный интерес не является новым для сферы защиты данных. Отличия в деталях.
Пункт 47 преамбулы GDPR раскрывает смысл базиса. Думаю, полезно привести его полное содержание. По тексту под «законным интересом» понимается именно сам базис.
«(47) Законные интересы контролёра <…> или третьей стороны могут создать правовые основания для обработки, при условии, что они не имеют преимущественной силы над интересами или основными правами и свободами субъекта данных, с учётом разумных ожиданий субъектов данных, основанных на взаимоотношении с контролёром. Такой законный интерес может иметь место, например, если между субъектом данных и контролёром существуют соответствующие отношения в ситуациях, когда субъект данных является клиентом или является работником. В любом случае наличие законного интереса нуждается в тщательной оценке, в том числе относительно того, может ли субъект данных при сборе персональных данных разумно ожидать, что обработка будет осуществляться для указанной цели <…> Обработка персональных данных, необходимая в целях предотвращения мошенничества, также является законным интересом соответствующего контролёра данных. Обработка персональных данных в целях директ-маркетинга может рассматриваться в качестве обработки, служащей законному интересу».
Выделим основные критерии для применения данного базиса:
- Вы преследуете законную цель.
- Обработка необходима, то есть цели нельзя достигнуть иным способом.
- Обработка сбалансирована, а потенциальный вред не является существенным.
- Обработка очевидна для субъекта данных.
Базис многогранный и непростой. Возможные ситуации его применения: предотвращение мошенничества, правовая защита, директ-маркетинг. В случае с директ-маркетингом следует обратиться также к ст. 21 GDPR и актам регулирования электронной коммерции, например, European Directive 2002/58/EC.
Для иллюстрации основания законного интереса расскажу про абсурдный случай из российской судебной практики. Суть в двух словах: компания из сферы ЖКХ передала юрфирме данные о неплательщиках, чтобы та подготовила исковое заявление в суд. В свою очередь, один из должников добился привлечения компании к административной ответственности по ст. 13.11 КоАП РФ, так как согласия на передачу своих данных не давал. Абсурд! Фактически 152-ФЗ ущемил права участников гражданского оборота и привел к возможности злоупотребления со стороны должника. Этого бы не случилось, если в законе применялся базис законного интереса. В GDPR он создает вполне законную почву для такой передачи данных.
Базис законного интереса на практике
Предположим, компания-разработчик предоставляет доступ к веб-сервису по лицензии. Персональные данные использует для заключения договора и сбора статистики (не обезличенной). Налицо две цели обработки данных: исполнение договора и улучшение продукта, решение технических проблем.
Первая цель относится к договорному базису (подп. (b) ст. 6(1)) и не требует согласия.
Вторая цель может реализовываться на основании:
а) согласия (подп. (b) ст. 6(1)),
б) базиса законного интереса (подп. (f) ст. 6(1)).
Если компания решит применять базис согласия, ей придется добавить в форму заказа не отмеченный заранее чекбокс. Много ли пользователей согласится предоставлять данные для сбора статистики? Вряд ли.
При применении базиса законного интереса компания только рассказывает о правах, не требуя активных действий (ст. 21 (4) GDPR). Более того, если преобладающий интерес над правами субъекта данных обоснован, компания вправе обрабатывать данные независимо от отказа.
Сможет ли компания ответить на вопросы для применения базиса законного интереса? Проверим:
| Цель использования | Повышение стабильности продукта для соблюдения интересов лицензиата. |
| Необходимость | Иным способом получить статистику в совокупности необходимых параметров невозможно. |
| Баланс интересов | Обработка сбалансирована, а потенциальный вред не является существенным. |
| Открытость | Обработка данных открытая и очевидная для субъекта данных. |
Как видим, у компании есть все основания не получать согласия. Но следует помнить об ограничениях:
- До сбора персональных данных субъекту должно быть сообщено о целях и законном интересе обработки (пункт (d) ст. 13 (1), пункт (b) ст. 14(2) GDPR). То есть применение должно быть публично мотивировано и документировано.
- Субъекту данных должно быть предоставлено право на возражение против обработки (ст. 21), право на удаление и ограничение.
С другой стороны, при сборе статистики просто соблюсти закон можно другим способом: обезличить данные. Обработка анонимизированных данных не регламентируется GDPR.
Выводы
- Не спешите получать согласие на обработку персональных данных. Сначала ответьте на вопросы: чьи и какие данные вы собираете, с какой целью, какие меры защиты применяете, кому эти данные раскрываете, какой из базисов будет наиболее применим.
- Если вы поняли, что собираете избыточные данные, откажитесь от их сбора. Основания для сбора остальных, меры по их защите и потенциальные каналы передачи зафиксируйте в политике обработки персональных данных. Более того, обработку и передачу необходимо документировать. Information Commissioner's Office рассказывает, как это сделать и рекомендует форму учетного документа.
- Если вы собираете данные только для оказания услуг и продажи товаров, то вам не нужно получать согласие (но все еще надо оформить политику и выполнять иные формальности).
- Если вы собираете данные еще и для анализа, защиты от мошенничества, нелегальной активности, определите, подпадает ли этот сбор под базис законного интереса, если да, напишите об этом в политике. Или анонимизируйте данные, или, если вам так проще, получайте согласие на обработку.
- Получая согласие на обработку, предусмотрите возможность отзыва этого согласия.
- Каждое ваше решение должно быть обосновано исходя из специфики вашей деятельности, собираемых данных, а также детально документировано.
GDPR – это крайне обширная тема, детали которой охватить в одной статье невозможно.
Здесь я не коснулся вопросов обработки специальных категорий данных, а также тонкостей и особенностей применения проиллюстрированных базисов, прав и обязанностей сторон, вовлеченных в обработку, вопросы трансграничной передачи и множество иных связанных с GDPR проблем.
GDPR подчеркивает, что персональные данные принадлежат не вам, а субъекту данных. Именно он должен иметь над ними полный контроль — от получения информации, редактирования до права ограничения обработки или удаления.
Комментарии (47)
elobachev
18.04.2018 14:352) полученных оператором в связи с заключением договора, стороной которого является субъект персональных данных, если персональные данные не распространяются, а также не предоставляются третьим лицам без согласия субъекта персональных данных и используются оператором исключительно для исполнения указанного договора и заключения договоров с субъектом персональных данных;
Вы в интернет — магазине приняли заказ, и передали его курьерской службе для доставки? ФИО и адрес кому доставить передали? ОК, значит этот пункт не про вас. И согласие нужно, и уведомление подавать. И согласие на передачу третьим лицам брать. А если курьер в штате — то да, вы правы, не нужно.
Про GDPR интересно, конечно. Не планируете более полного обзора?
DenisPoison Автор
18.04.2018 16:31Справедливое замечание, но если в приведенной цитате еще дополнительно выделить «без согласия», тогда пункт приобретает новое значение, в котором само уведомление, возможно, теряет смысл.
Не исключено, что к GDPR придется вернуться еще не раз.
moachi
18.04.2018 16:42согласие в данном случае не нужно…
явный случай legitimate interest — для выполнения контракта нужно передать данные…
я помню это момент нам юрист как пример приводил
garex
18.04.2018 15:45IP-адрес и некий device-id анонимного посетителя сохраняются в базе. Это необходимо, чтобы деанонимизировать посетителя для владельца сайта в случае его обращения по какому-то вопросу.
- Являются ли эти данные персональными данными по GDPR? Предполагаю, что да.
- Можно ли их сбор обосновать публичной офертой, галочкой или иным юридическим способом?
marenkov
18.04.2018 15:54Как насчет такого сценария — сохранять не IP и device-id, а их хеши (которые не позволяют простого обратного преобразования)?
Тогда с одной стороны есть возможность понять, что это тот же пользователь, а с другой у вас нет его персональных данных.garex
18.04.2018 16:02Иногда надо самому пользователю сказать, какой у него IP, чтобы понять что этот пользователь такой-то и такой-то из других анонимов. Технически можно вообще не хранить ничего, хэшировать, но я хочу понять, как эту проблему юридически решить и желательно без технических изменений.
theo
18.04.2018 17:25Есть вариант маскировать последний знак, например: 10.0.10.1x. Если не ошибаюсь, так поступает yahoo.
MaximChistov
19.04.2018 13:17>Иногда надо самому пользователю сказать, какой у него IP, чтобы понять что этот пользователь такой-то и такой-то из других анонимов
1) Юзер говорит вам свой IP
2) Считаете хэш
3) Сравниваете с хэшем в базе
В итоге и сравнить можно, и данные не хранятсяgarex
19.04.2018 13:35Вариант, но опять же теоретически можно докопаться, что хэш моих данных тоже мои данные, т.к. позволяет однозначно определить, что это я.
Технически здесь тыща вариантов, я пытаюсь понять, как это юридически натянуть.
abyss
20.04.2018 18:35Мы вот закончили обсуждать вопрос, включая обсуждение с французским юристом.
За все случаи не скажу, но в нашем случае по HardwareID (просто хэш) ответ такой: т.к. HardwareID не геренируется используя IP или Mac адрес, а использует только идентификаторы железа (CPU etc), то проблем нет.
DenisPoison Автор
18.04.2018 16:521. GDPR трактует персональные данные крайне широко. По первому вопросу я бы ответил положительно. Для иллюстрации можно обратиться к п. 30 преамбулы — практически любые данные, которые прямо или косвенно (том числе в своем сочетании) могут определить субъекта.
2. Вам необходимо четко сформулировать цель — зачем вы собираете эти данные и подвести под один из базисов. Например, если вы сделаете обоснование, что необходимо для исключения мошенничества, то вполне вам законный интерес, который необходимо обосновать в политике (по цели, необходимости).
Кстати, в вашем примере это не будет анонимизацией, так как данные могут быть приведены к исходному формату.
gto
18.04.2018 16:28А можно ли требования AML и KYC считать законным интересом?
DenisPoison Автор
18.04.2018 17:02+1В случае с AML и KYC я бы говорил о базисе (с) ст.6 (1), т.е. когда данные обрабатываются в связи с исполнением обязательств, вытекающих из закона.
В любом случае, ваша политика должна раскрывать какие данные и с какой целью обрабатываете, а также норма закона должна быть четко определена.
rakhinskiy
18.04.2018 19:29На сколько я понимаю у пользователя есть право запросить удаление его данных.
Если пользователь попросил удалить все данные о нем, что делать с бекапами базы данных в которых есть эти данные?DenisPoison Автор
18.04.2018 19:39Право на удаление не всегда работает. GDPR содержит исключения, например вы вправе отказать, если данные требуются для защиты от претензий и исков, при наличии обязательств в силу закона и пр.
Прежде всего, необходимо изменить сам подход к обработке данных. В любом случае удалять, вопрос когда.
GDPR определяет, что данные должны обрабатываться в минимальном объеме, самый минимальный срок, обрабатываться в безопасной (защищенной) форме и пр.
Полагаю, что целесообразно (исходя из принципов ст. 5 ) определить правила работы с бэкапами, в которых, описать, в том числе:
- обязательства по удалению данных в случае разворачивания
- меры по беспечению безопасности (шифрование, псевдрнимизация, например)
- сроки планового удаления бэкапов
- определить условия, при которых данные не удаляются.
Говоря о сроках.
Ст. 12 устанавливает, что все запросы подлежат исполнению без задержек, но не более месяца (срок можно продлить в исключительных случаях).
Было бы хорошей практикой производить автоматическое удаление именно в этот срок (повторюсь, если нет основания для отказа).
SeoTron
18.04.2018 23:09Здравствуйте! Так как здесь вижу достаточно много знающих людей, может, если будет интересно, посмотрите следующий вариант политики конфиденциальности? Сайт — некоммерческий блог-сервис/форум стихов с комментариями. При регистрации требуется согласиться галкой с документом. Насколько юридически адекватно и не противоречит законодательству? Убираю в сполер:
Политика конфиденциальностиПолитика конфиденциальности
Настоящий документ «Политика конфиденциальности» (далее по тексту – «Политика») представляет собой правила использования Администрацией сайта (далее – «Администрация») данных интернет-пользователей (далее «Пользователь»), собираемых с использованием сайта 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 г.
DenisPoison Автор
19.04.2018 08:36Достаточно противоречивая политика. Ее сложно отнести к соответствующей как GDPR, так и 152-ФЗ.
Если брать с первых положений, то контролер должен быть указан. Т.е. написать «Администрация сайта» не считается.
С одной стороны говорится об обезличенности, с другой стороны об использовании совокупности данных, которые определяют субъекта (IP, куки и пр.), право на директ-маркетинг.
На какие-то позиции возможно получение согласия, однако право на его отзыв не отражено, равно как и иные права субъекта.
Право на передачу иным лицам есть, однако такие лица не раскрыты.
В общем, требуется значительная доработка.
Ваш сайт по своей структуре не ориентирован на европейский рынок.
Если с позиции 152-ФЗ, то здесь подход к определению персональных данных иной.
Сам РКН рекомендует как cделать политику правильно.
Vitaljok
19.04.2018 04:39Как раз начали разбираться с этой регулой, всё не можем понять, про нас это или нет.
У нас немного нетипичная ситуация: собираем различные данные с датчиков и обрабатываем их. Железяки находятся за пределами ЕС, софт и данные — на Европейском сервере. Пользователи заходят в наш софт через третью сторону (в нашем случае это Auth0), который производит аутентификацию и выдает токен. На своей стороне мы получаем id и fullName пользователя и показываем ему данные с его железяк.
Если не составит труда, подскажите:
- данные с железяк (температура, влажность, итд) считаются ПД?
- кто обрабатывает пользователя (username, password) — Auth0 или всё-таки мы? Должны ли мы оповестить пользователя, что мы получили его имя через токен? Или всё таки это ответственность сервиса?
DenisPoison Автор
19.04.2018 04:451. Если железяки не собирают биометрию, то с ними все ок.
2. С аутентификацией тоже не сильно сложно.
Существует несколько потенциальных ваших статусов. Основные:
- Контролер, т.е. лицо, которое определяет цели, средства обработки данных
- Процессор, т.е лицо, производящее обработку по поручению контролера.
- Третья сторона, т.е. сторона, которой данные раскрываются
В вашем случае надо определить роли в процессе.
По GDPR информация об обработке должна быть предоставлена в период первого сбора данных.
Если этот третий сервис обеспечивает регистрацию, может влиять на состояние полей, куда и как эти данные передать, то Контролером, полагаю, выступать будет она. Вы должны быть указаны в политике Контролера в числе лиц, которым данные передаются.
Из вопроса не следует, где находятся пользователи. Если вы не предлагаете услуги на территории Евросоюза, то расположение там сервера не создает обязанности по применению GDPR.
aborouhin
19.04.2018 05:16Всё бы хорошо, но почти всегда есть ситуации, когда договор заключаем с одним лицом (юридическим), а персональные данные получаем другого (пользователя, который может быть сотрудником юр. лица — контрагента, работать с ним по договору или быть просто знакомым, с которым поделились учётной записью; в общем случае приходится исходить из того, что природа отношений между контрагентом по договору и конкретным пользователем нам неизвестна).
Я правильно понимаю, что в этом случае все описанные лайфхаки неприменимы и идём по тернистому пути с согласиями, галочками и уведомлениями?DenisPoison Автор
19.04.2018 05:18Вопрос, на самом деле, крайне обширный.
Повторюсь, но требуется определить какие данные, как и зачем вы собираете, установить базис.
Существует ли необходимость обработки данных работника, имея отношения с юр. лицом?
Можно смоделировать ситуацию, например, договор о предоставлении услуг отеля с юр. лицом. Отелю предоставляются данные работника, который будет проживать (мы говорим о ситуации на территории Евросоюза).
В GDPR определен порядок действий контролера в зависимости от того, получены ли данные от субъекта или иных источников — ст. 14.
Все прозрачно. Необходимо лишь каждому учитывать свою специфику.
AndreyKas
19.04.2018 05:23Насколько я понимаю, статья именно про обработку. Для сбора данных во всех случаях нужно согласие?
DenisPoison Автор
19.04.2018 05:23Обработка включает в себя все этапы работы с данными. Статья как раз о том, что не всегда требуется согласие. Порой, достаточно ознакомить с политикой.
myemuk
19.04.2018 10:17DenisPoison, а вы можете немного подробней описать ситуацию с CRM?
Для примера возьмем продавца, который пользуется CRM. В ней наш пользователь хранит контактные данные своих реальных и потенциальных клиентов. Так вот, какие есть способы избежать разрешения/запрета на использование персональных данных со стороны этих клиентов?DenisPoison Автор
20.04.2018 04:16На стороне CRM, думаю, должны быть реализованы универсальные настройки.
Со стороны поставщика схемы индивидуальны, равно как и объем данных. Например, продавец может формировать бессрочный договор (оферту) и данные хранить уже согласно определенной им политике.
В части предполагаемых клиентов имеется хороший пример от Information Commissioner's Office. Лучше смотреть оригинал.
Суть в 2-х словах: при сборе данных (в примере — из визитных карточек) допустимо опираться на legitimate interest, так имеется обоснованная бизнес цель, недостижимая иным образом, риском для субъекта минимален, а последующая обработка данных очевидна. При этом помнить про порядок обоснования в политике, уведомлении о права и обработке.
Стоит не забывать, что согласие/уведомление лишь малая часть того, что необходимо соблюдать по GDPR.
S0krat
19.04.2018 16:01Очень хороший текст. Могу придраться только к отсутствию акцента на том, что «Откажитесь от сбора информации, которую вы собираете на всякий случай.» — это не просто рекомендация, а базовое требование GDPR, абсолютно обязательное к исполнению.
DenisPoison Автор
20.04.2018 06:19Спасибо. Избыточность уже и по национальному законодательству давно не приветствуется.
jaredhared
19.04.2018 16:21Теперь можно надеяться, что эти галки согласия появятся в том или ином виде в Billmanager? До сих пор поддержка предлагала делать самодельные костыли для этих целей.
Upd: И что с правом на забвение? Сейчас по таким запросам приходится менять все данные пользователя.DenisPoison Автор
20.04.2018 06:17Мы готовимся к вступлению в силу GDPR и к 25 мая все наши панели будут ему соответствовать. Что касается «права на забвение», в BILLmanager уже есть возможность удаления пользователя, но применять ее нужно с осторожностью (с учетом потенциальной востребованности данных в целях защиты от претензий и исков, исполнения запросов правоохранительных органов и пр.)
AlexeyKovyazin
19.04.2018 23:46Хорошая статья, спасибо! Скажите, а не разбирались ли вы с вопросом о шифровании данных — в каких случаях оно нужно, в каких настоятельно рекомендуется?
DenisPoison Автор
20.04.2018 18:56GDPR не предопределяет меры технической защиты, которые необходимо применять. Требованием является применение способов защиты, которые приемлемы исходя из рисков, возникающих из характера обработки.
Вообще GDPR смотрит в сторону риск-ориентированного подхода.
Безопасность не относится только к вопросам псевдонимизации и шифрования — должны быть обеспечены подходящие организационные и технические меры (в т.ч. находящиеся в сфере off-line).
В части шифрования у ICO имеется отдельный блок рекомендаций, который, фактический, можно свети к одной позиции – шифруйте, если это применимо.
Все основные существующие позиции по информационной безопасности относятся к предшествующему документу (Data Protection Act). Например, «Руководство по облачным вычислениям», «IT-безопасность», «Защита в онлайн сервисах».
explorer2018
20.04.2018 17:47Автор статьи написал:
«А теперь внимание! Статья 22 того же закона определяет, что если обработка данных необходима для исполнения договора, то уведомлять Роскомнадзор не нужно».
А теперь внимание автору, в ст. 22 указано, что оператор вправе осуществлять без уведомления уполномоченного органа по защите прав субъектов персональных данных обработку персональных данных, полученных оператором в связи с заключением договора, стороной которого является субъект персональных данных, если персональные данные не распространяются, а также не предоставляются третьим лицам без согласия субъекта персональных данных и используются оператором исключительно для исполнения указанного договора и заключения договоров с субъектом персональных данных.
Т.е. только если сторона договора физ. лицо. А если это юридическое лицо, тогда нужно.
Об этом уже написали в комментах до меня, ну и плюс другие ограничения, установленные этим пунктом статьи.
Так что не нужно людей в заблуждение вводить.
DenisPoison Автор
20.04.2018 18:01Не соглашусь с вашим заявлением и обосную почему.
Сразу разберемся в понятиях – мы говорим о 152-ФЗ, об уведомлении.
Оператор – физические и юридические лица (в любых сочетаниях и комбинациях).
Персональные данные – информация, относящаяся к определённому или определяемому физическому лицу (субъекту персональных данных).
Оператор вправе осуществлять без уведомления уполномоченного органа по защите прав субъектов персональных данных обработку персональных данных: полученных оператором в связи с заключением договора, стороной которого является субъект персональных данных, если персональные данные не распространяются, а также не предоставляются третьим лицам без согласия субъекта персональных данных и используются оператором исключительно для исполнения указанного договора и заключения договоров с субъектом персональных данных (подп. 2 п. 2 ст. 22).
Если кратко — данные только для договора и не передаются, а если передаются, то с согласия.
В силу приведенной ситуации договор, попадающий под п. 2 ст. 22 может быть заключен: между оператором (физическим или юридическим лицом) и субъектом данных (физическим лицом).
Договор между оператором и юридическим лицом выпадает из отношений, так как это юридическое лицо не субъект персональных данных.
Усилю свою позицию судебной практикой, при которой суды подтверждают позицию об отсутствии необходимости – дело А19-17054/2017 (см. стр. 7 решения), или Постановление Верховного Суда РФ от 05.08.2011 N 20-АД11-3.
Судебной практики, увы (или к счастью), не так много, так как статья достаточно очевидна в своем применении.explorer2018
20.04.2018 21:19Договор между оператором и юридическим лицом выпадает из отношений, так как это юридическое лицо не субъект персональных данных.
Это юр. лицо не субъект персональных данных, но при заключении передаются перс. данные представителя этого юр. лица, например, ФИО подписанта договора — представителя юр. лица. Таким образом, оператор ПД, будучи юр. лицом, получает от другого юр. лица персональные данные физ. лица и именно поэтому он должен направить уведомление в Роскомнадзор.
А вначале статьи это почему-то не учитывается и делаются неправильный обобщающий вывод:
А теперь внимание! Статья 22 того же закона определяет, что если обработка данных необходима для исполнения договора, то уведомлять Роскомнадзор не нужно.
Этот вывод неправильный и вводящий в заблуждение еще потому, что второй стороной по договору должен быть не только сам субъект ПД, но и еще пару параметров:
-если персональные данные не распространяются,
— а также не предоставляются третьим лицам без согласия субъекта персональных данных и используются оператором исключительно для исполнения указанного договора и заключения договоров с субъектом персональных данных.
sindzicat
Есть сайт, пользователь вводит логин, пароль и своё имя, чтобы залогиниться. Я правильно понял из этой статьи, что галка про обработку персональных данных по закону не требуется? Имя нужно, чтобы знать, как к нему обращаться (техподдержка).
marenkov
Вы не можете оказать техподдержку если не знаете имени пользователя?
Удалите имя, и у вас не будет персональных данных.
sindzicat
А это мысль. Спасибо)
Получается, что, если я прошу только email и пароль, то это уже будет не персональные данные? Как это можно было попроще объяснить пользователю? Заранее спасибо.
marenkov
Именно так, email и пароль не являются персональными данными согласно GDPR.
Но есть одно исключение — email вида имя.фамилия@компания.com
Как исключить такую ситуация я не знаю.
sindzicat
Наверно тогда по любому придётся ставить галку "Я согласен с обработкой ПД". Видимо, здесь лучше будет перестараться.
theo
Простите, но это не так. Если указаный email может каким либо образом меня идентифицировать, то это персональные данные. Например, у меня емайл вида abs@mail.com и я его испольую как свой основной емайл.
marenkov
Может быть и так. Посмотрел еще раз, персональными данными считаются даже куки и данные которые зашифрованы, но позволяют повторно идентифицировать пользователя.
S0krat
По-умолчанию e-mail является ПД, даже если это pinkpony@mail.ru — исключениями будут обезличенные служебные наподобии sales@company.tld какой-нибудь.
dmitryredkin
ФИО в отрыве от других данных не является ПД. если логин не является e-mail-ом, то все ОК.
ledascho
ПД — по российскому закону? А то ведь:
For the purposes of this Regulation:
(1) 'personal data' means any information relating to an identified or identifiable natural person ('data subject'); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;
dmitryredkin
Да, я про ФЗ-152.
ledascho
В рамках темы статьи российские ФЗ нерелевантны совершенно
DenisPoison Автор
Я бы начал с другого — какова природа технической поддержки. По общему правилу техподдержка подразумевает наличие некой услуги/сервиса, ее предварительное или последующее сопровождение.
До того, как пользователь залогинится, он должен еще и зарегистрироваться.
Стоит более комплексно оценить весь пусть, цели. И да, с точки зрения поставленного вопроса, само имя вообще не требуется.