Новые правила закона о защите персональных данных в Интернете в Европе

25 мая 2018 года вступают в силу правила нового Закона о защите персональных данных в Интернете для пользователей, которые находятся на территории Европейской экономической зоны. Новые правила обозначаются аббревиатурой GDPR (The General Data Protection Regulation, Общие правила защиты данных) и распространяются на всех игроков Интернета, которые участвуют в сборе, хранении или обработке персональных данных. Хотя закон принят для защиты европейских данных, глобальный характер Интернета означает, что GDPR устанавливает стандарт конфиденциальности данных во всем мире. Практически все крупные интернет-компании, включая Google, Facebook и Twitter, подпадают соблюдению требований GDPR.

 

GDPR – это давно назревший набор передовых методов обеспечения конфиденциальности в бизнесе, и особенно в Интернете. Он учит нас относиться к данным наших пользователей с такой же тщательностью и уважением, с какой мы относимся к своим собственным.

GDPR призван обеспечивать большую защиту персональных данных человека, включая, но не ограничиваясь, его религиозными или политическими убеждениями. Штрафы за несоблюдение правил довольно большие: до 20 млн. евро, или 4% от общего оборота (в расчет берется большая сумма) за нарушение. Кроме того, GDPR дает пользователям право на компенсацию любого материального и/или нематериального нарушения GDPR.

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

 

 

К кому применяются правила GDPR?

GDPR применяется к данным, которые собираются, обрабатываются и/или хранятся в Европе независимо от того, где собраны данные. Если у вас есть интернет-магазин с информационной рассылкой, и хотя бы один подписчик из ЕС подписался на нее, тогда вас касаются правила GDPR.

Одним из значительных условий GDPR является то, что теперь запрещена передача данных за пределы ЕС в любую страну, которую ЕС не считает соответствующую законам о защите персональных данных. Если вы передаете личные данные за пределы ЕС для обработки или хранения, то вы должны получить явное согласие на это от пользователя, которому принадлежат данные.

Учитывая многоуровневый характер юрисдикций Интернета и такие технологии, как CDN, разумно предположить, что в определенный момент данные, которые вы собираете и храните, будут передаваться за пределы ЕС и одобренных стран. Поэтому, независимо от того, какие другие разрешения вы запрашиваете у своих пользователей, желательно всегда получать разрешение на хранение данных за пределами ЕС.

 

 

Какие данные должны быть защищены?

Существует два основных типа данных, которые по GDPR должны быть защищены: личные и деликатные.

• Личные данные – это любые данные, которые идентифицируют человека. Ваше имя, адрес электронной почты, местоположение, биометрические данные, логин (другие онлайн-идентификаторы) – все это является личными данными.
• Деликатные данные – это то, что, по мнению ЕС, более личное, чем имя. Этническое происхождение, религиозные убеждения, сексуальные предпочтения, политические взгляды, криминальная история – все это можно отнести к деликатным данным. Новые правила призваны уделять больше внимания защите и деликатных данных.

Хотя может возникнуть коллизия в случаях, когда личные данные становятся деликатными. Например, адрес электронной почты – это личные данные, но если адрес электронной почты типа «fanat-trampa-2018@…», из которого можно сделать вывод о политических предпочтениях пользователя, тогда эти данные уже относятся к деликатным. Подобные случаи, скорее всего, будут рассматриваться регулирующими органами в каждом конкретном случае.

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

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

 

 

Права пользователя по требованиям GDPR

В любой ситуации, когда вы запрашиваете данные пользователя, сначала спросите себя: как это повлияет на права владельца этих данных?

GDPR определяет следующие официальные права, которыми обладают владельцы данных:

• Право быть проинформированным
• Право доступа
• Право на исправления
• Право на объект
• Право на переносимость данных
• Право на удаление данных
• Право не подвергаться автоматическому принятию решений
• Право ограничить обработку данных

 

Однако игроки, которые хранят данные, также имеют права. Например, представьте, что пользователь подписался на вашу рассылку. Позже он решает, что больше не хочет получать рассылку и отписывается. Вы просто обязаны навсегда стереть адрес электронной почты этого пользователя. Однако, когда пользователь подписывается на рассылку, вы должны знать его IP-адрес, чтобы сопоставить с его согласием получать рассылку (как и должны), значит вы имеете право сохранить эти данные, чтобы продемонстрировать соблюдение своим сайтом правил GDPR.

 

 

Практические шаги по обеспечению соответствия требованиям

Важно понимать, что регулирующий орган ЕС не обязан доказывать ваше несоблюдение правил. Это является вашей юридической обязанностью доказывать, что вы соответствуете правилам, а неспособность сделать это само по себе является несоответствием требованиям.

Общие правила защиты данных определяются методом «Проектируемая конфиденциальность» (PBD – Privacy by Design). PBD подразумевает, что конфиденциальность не обеспечивается законным соблюдением, а скорее должна приниматься организацией как подход по умолчанию.

PBD считает, что конфиденциальность, скомпрометированная единожды, не может быть восстановлена, и поэтому следует заранее предусмотреть и предотвратить угрозы конфиденциальности. Проектируемая конфиденциальность определяется 7 принципами:

• Будьте активными: PBD является профилактическим, а не исправляющим. Поэтому, предусмотрите заранее возможные риски
• Конфиденциальность по умолчанию: пользователю не нужно предпринимать никаких действий для обеспечения конфиденциальности. Если пользователь ничего не делает, его данные обрабатываются как приватные
• Внедрение конфиденциальности в проект: конфиденциальность не добавляется в проект задним числом, она является неотъемлемым компонентом любого продукта или системы
• Конфиденциальность не ограничивает функциональность: PBD отвергает идею о том, что любое законное использование данных должно нарушать конфиденциальность
• Полный цикл конфиденциальности: PBD покрывает весь жизненный цикл частей данных, с момента их сбора, во время хранения и до тех пор, пока они не будут уничтожены
• Прозрачная конфиденциальность: стандарты конфиденциальности полностью прозрачны, поэтому любой, кто использует продукт или систему, четко понимает, как его данные защищены
• Конфиденциальность ориентирована на пользователя: PBD относится к соблюдению конфиденциальности отдельного лица, владелец данных имеет первый приоритет

 

 

Оценка воздействия на конфиденциальность (PIA)

Основным компонентом PBD и требованием соответствия GDPR является оценка воздействия на конфиденциальность (PIA).

Любой цифровой продукт должен иметь PIA. В идеале PIA – это онлайн-документ, который растет по мере разработки продукта (в соответствии с третьим принципом PBD).

Целью PIA является документирование угроз конфиденциальности в вашей системе и действий, предпринятых вами для борьбы с ними. Это, по сути, персонализированный контрольный список вопросов конфиденциальности и он может рассматриваться как дорожная карта для защиты конфиденциальности ваших пользователей.

Нет стандартного контрольного списка для PIA, потому что каждый проект уникален, но есть некоторые рекомендуемые практики, которым вы можете следовать. Не бойтесь добавлять дополнительные детали, если ваш проект гарантирует это.

• Определите потребность в PIA: Опишите сферу действия вашего проекта. Опишите, какие данные могут потребоваться. Опишите, насколько деликатными могут быть данные.
• Документируйте ожидаемые потоки данных: как пользователи будут раскрывать данные, как они будут передаваться и храниться, будут ли они обработаны, и если да, то как? Определите всех, кто будет использовать данные, включая руководство и разработчиков. Рассмотрите использование данных в будущем. Как долго будут храниться данные? Как пользователь может изменять или удалять свои данные?
• Процедура согласования документов: как вы зарегистрируете согласие пользователя? Как вы проверите согласие? Если согласие прямо не указано, существует ли юридически обоснованная основа для сбора данных?
• Определение рисков: каков риск от данных для отдельных лиц? Собираются ли какие-либо ненужные данные? Являются ли резервные копии данных, резервные копии имеют одинаковый уровень безопасности? Кто имеет доступ к данным, как насчет стажеров, как насчет третьих сторон? Что делать, если данные теряются, изменяются, раскрываются, используются неправильно? Оцените любые риски, включая юридические осложнения и потерю репутации.
• Определение решений: разработайте способы сокращения и, по возможности, устранения рисков конфиденциальности. Оцените стоимость решений с точки зрения времени и инвестиций. Как решения влияют на конфиденциальность пользователей и проект? Существуют ли надлежащие процедуры для обработки нарушения данных? Существуют ли надлежащие процедуры для соблюдения правовых процедур, таких как судебное постановление о раскрытии информации?

 

Продолжайте разрабатывать и расширять PIA на протяжении всего срока службы вашего продукта.

 

 

Назначение сотрудника по защите данных

Крупные организации и любой центр обработки данных (например, банки, хостинги и т.п.) должны назначать сотрудника по защите данных (DPO), роль которого заключается в обеспечении соответствия организации требованиям GDPR. Небольшие компании освобождаются от назначения официального DPO. Например, если вы владеете рестораном, вам обычно не нужно назначать DPO. Однако, если вы запускаете бизнес доставки из этого ресторана, и вы храните деликатные данные, такие как аллергия (информация о которой относится к медицинским данным) или предпочтения в еде (особенно если эти предпочтения являются религиозными), вам почти наверняка нужен будет DPO.

 

 

Обязательное согласие

Отсутствие «нет» не означает «да». Согласно 2-му принципу PBD, условие конфиденциальности должно приниматься по умолчанию.

Согласно 4-му принципу PBD, вы не можете сказать, что пользователь может использовать систему только в том случае, если он согласится нарушить свое право на неприкосновенность частной жизни. Пользователи имеют право на согласие, но они также имеют право не соглашаться.

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

 

В соответствии с GDPR, согласие тщательно определяется для обеспечения защиты прав пользователей:

• Согласие должно быть явным, поддающимся проверке и по доброй воле: вы не можете обмануть или надавить на пользователя. Флажок с предварительной отметкой в чекбоксе не является добровольным согласием.
• Согласие должно быть запрошено простым языком. У вас должны быть разумные основания полагать, что ваши пользователи поймут согласие, которое их просят дать.
• Согласие на цифровые услуги от ребенка в возрасте до 16 лет требует согласия родителей. Обратите внимание, что если вы получаете согласие от детей, запрос о согласии должен быть написан на языке, который понимает как ребенок, так и его опекун.
• Согласие должно быть детализированным: пользователи могут дать согласие сохранять и использовать свои данные, но не дать согласия передавать их третьим сторонам. Никогда не требуйте полных разрешений. Вы не можете использовать классический текст «При посещении этого сайта вы согласны…».

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

 

 

Написание публичного заявления о конфиденциальности

Большинство веб-сайтов размещают общее заявление о конфиденциальности, но соответствие требованиям GDPR требует гораздо более конкретного заявления о конфиденциальности.

Чтобы соответствовать принципам 6 и 7 PBD, ваш сайт, приложение или услуга должны иметь публичное заявление о конфиденциальности (PPS), написанное на простом языке, которое должно быть понятно пользователям.

Ваше PPS должно содержать следующую информацию:

• Какие данные вы собираете: убедитесь, что вы перечислили все данные, которые вы собираете, а не только очевидные; включая IP-адреса, часовые пояса, языки по умолчанию и т.п.
• Почему вы собираете эти данные: для каждой части данных объясните, почему вы ее собираете, и почему вы рассматриваете ее как разумную и необходимую.
• Какие данные обязательны: Перечислите любые данные, которые обязательны. Например, если вместо имени пользователя требуется адрес электронной почты пользователя, скажите об этом.
• С какими третьими сторонами вы делитесь данными: в разделе «GDPR» вы не можете публиковать общее заявление о совместном использовании с третьими лицами, вы должны указать, какие данные будут переданы, какой третьей стороне, и с какой целью.
• Откуда еще вы получаете данные: Если вы собираете данные из других источников, укажите, откуда вы их получаете и как вы их используете.
• Как долго вы будете хранить данные: будьте конкретны, как долго данные будут существовать в вашей системе. Вы удалите данные, как только пользователь перестанет быть клиентом? Если вы намерены хранить данные на неопределенный срок, скажите об этом.
• Как пользователь может воспользоваться своими правами: Объясните, как пользователь может узнать, какие его данные у вас есть, и как пользователь может запросить обновление данных или их удаление.

Обычно принято заверение типа «Мы ​​не будем делиться вашими данными с какой-либо третьей стороной», но это неверно для большинства компаний. Независимо от того, будь-то аналитика или веб-хостинг, мы делимся огромным количеством данных от имени наших пользователей, а GDPR требует от нас взять на себя ответственность за это. Не делайте обещаний, которые вы не можете выполнить.

 

 

GDPR для веб-дизайна

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

• Ввести уведомления в момент получения данных. Это привычка сообщать пользователям о данных, которые вы собираете, в момент сбора. Например, под полем подписки на рассылку новостей объясните, что вы запрашиваете адрес электронной почты для отправки маркетинговых (рекламных) материалов, и вы также записываете IP-адрес пользователя, чтобы он мог подтвердить свое согласие. Это гарантирует, что в соответствии с принципом 6 PBD пользователи знают, какие данные вы берете, с какой целью, и у них не должно возникать охоты читать полный текст политики конфиденциальности (но всегда указывайте ссылку на полное публичное заявление о конфиденциальности, чтобы пользователь мог получить дополнительную информацию).
• Чтобы соблюдать принцип 2 PBD, при получении согласия флажки чекбокса не должны быть предварительно выбраны.
• Уменьшите количество данных, которые вы записываете. Например, данные местоположения часто записываются с большей точностью, чем требуется. Если вам нужно знать область, в которой кто-то находится, из этого не следует, что вам нужно знать город или район города.
• Когда вы записываете данные пользователя, убедитесь, что вы записываете способ предоставления согласия, его дату и время. Включите опцию для отметки согласия в качестве отмененного, если вам нужно удалить данные в будущем.
• Псевдонимизируйте данные там, где это возможно, путем замены идентификационных данных, таких как имя или адрес электронной почты, анонимными идентификаторами.
• Разделяйте данные там, где это возможно, чтобы личные данные, такие как настройки приложения, не сохранялись вместе с данными безопасности, такими как имена пользователей и пароли.
• Ранее стандартная практика полагалась на адрес электронной почты в качестве имени пользователя. Подумайте о том, имеет ли это смысл в вашем случае. Эта практика может подвергать личные данные потенциальному раскрытию или неправильному использованию.
• Убедитесь, что ни одна часть вашего пользовательского интерфейса не отображает личные данные. Если ваш пользовательский интерфейс указывает, что кто-то вошел в систему, используйте наименее конфиденциальные данные. Например, аватар пользователя менее деликатно, чем его имя, которое менее деликатно, чем его адрес электронной почты.
• Может ли злонамеренный пользователь скомпрометировать данные, вызвав ошибку? Например, если пользователь вводит адрес электронной почты в форме «Забыли адрес электронной почты», будет ли форма выдавать сообщение, что напоминание о пароле было отправлено на некий е-мейл (и, соответственно, раскрывать данные, что у некоего пользователя есть учетная запись)?