Общая политика защиты данных, также известная как GDPR, была принята Европейским союзом ещё в далёком 2016 году. Всем было дано 2 года на переход и адаптацию. Но судя по ажиотажу, возникшему в начале 2018, кто же станет делать всё вовремя? Обновления политик конфиденциальности многих весьма и не весьма крупных проектов посыпались в мае, за 2-3 недели до окончательного вступления закона в силу. И кажется мне, проекты поменьше будут ещё какое-то время догонять поезд после 25 мая. Если Вы ещё не внесли необходимые изменения в свои политики или не совсем поняли, какими они должны быть, эта статья для Вас.



GDPR действует уже несколько дней. В первый же день некий австрийский поборник приватности Max Schrems выкатил многомиллиардные иски Google и Facebook за несоблюдение политики. В частности, иски коснулись Instagram, WhatsApp и Android OS. Впрочем, этому и раньше спокойно не жилось. А какой-то музыкальный фанат с чувством юмора создал на Spotify плей-лист «Я люблю GDPR».



Вообще, суета вокруг GDPR в Европе проникла в разные сферы. На данный момент я живу в Латвии, и недавно мне нужно было получить посылку на почте. Одно из полей в форме на получение посылки — персональный код. Я рефлекторно его заполнил, чем несколько взволновал почтальоншу. Она его зачеркнула, а рядом написала просто тип предъявленного документа. В ответ на своё удивление я узнал, что это связано «с этим новым законом». О нём тут даже пишут в газетах, кстати. Обычных. Бумажных.



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

Legal disclaimer. Данный пост является видением автора, а не юридическим советом. И сам автор, и использованные им источники рекомендуют в случае непонятных ситуаций обращаться к специалистам по соответствию (compliance experts). Либо попробовать самостоятельно переварить 85 страниц первоисточника. Доступен также более удобочитаемый вариант.

Основные понятия

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

Data Subject (объект данных) — физическое лицо, которому принадлежат данные. Тут вроде сложностей нет.

Personal Data (личные данные) — любая информация, относящаяся к идентифицированному или идентифицируемому физическому лицу. Идентифицируемое физическое лицо — то, которое может быть идентифицировано напрямую или косвенно, в частности ссылаясь на идентификатор, такой как имя, персональный код, онлайн идентификатор или на один или несколько факторов, касающихся физической, физиологической, генетической, ментальной, экономической, культурной или социальной идентичности лица.

Дальше по тексту мы ещё вернёмся к этому, но вкратце упомяну, что личные данные делятся на две категории. Для обработки некоторых из них не всегда требуется непосредственное согласие объекта данных, для других — всегда (касается более «личных» категорий, таких как религиозные убеждения, заболевания и т.п.). Также обратите внимание на то, что тут уже начинаются расплывчатые формулировки. Под онлайн идентификатором можно понимать много чего.

Processing (обработка) — любые действия, произведённые над данными или массивами данных, автоматически или вручную, такие как сбор, запись, организация, структурирование, хранение, адаптация или изменение, извлечение, консультация, использование, раскрытие путём передачи, публикации или предоставления доступа любым другим образом, комбинирование, ограничение, стирание или удаление. По формальному признаку, сбор визиток на конференции подпадает под обработку персональных данных. Надеюсь, никто не будет доводить ситуацию до подобного уровня абсурда, впрочем.

Controller (контроллер) — физическое или юридическое лицо, организация и кто угодно вообще, кто самостоятельно или совместно с другими определяет цели и средства обработки персональных данных. У Вас форум с функцией регистрации — Вы контроллер. Разместили код Google Analytics на сайте — Вы тоже контроллер.

Processor (процессор, обработчик) — физическое или юридическое лицо либо любая друга я структура, обрабатывающая данные от имени контроллера. Храните базу клиентов у себя на компьютере или на управляемой Вами платформе — Вы обработчик. Используете стороннюю CRM-систему — обработчиком будут они.

Consent (согласие) объекта данных — свободно предоставленная, конкретная, информированная и недвузначная индикация желания объекта данных (посредством заявления или чёткого подтверждающего действия), которым он или она выражает согласие на обработку своих данных. Вспоминаем все эти галочки «Нажимая ОК, я даю согласие на обработку своих персональных данных». Другой вопрос — как быть с упомянутыми выше визитками?..

Всего в разделе «Определения» описано 26 терминов. Не все из них столь важны нам, но если Вы считаете, что я упустил какое-то важное — дайте знать.

Есть ещё несколько связанных с GDPR ключевых концепций, которые стоит рассмотреть отдельно.

Немного о согласии объекта данных

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

Всё это в прошлом. GDPR требует, чтобы в случаях, когда законным основанием является согласие, оно было явным и осведомлённым. Т.е. пользователь должен понимать, что, отмечая конкретный чекбокс, он даёт своё согласие на хранение своего e-mail и получение маркетинговых рассылок, а не просто с чем-то там согласен. Отсутствие явного волеизъявления следует считать отказом и никак иначе.

The Right to be forgotten (право быть забытым)

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

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

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

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

В других случаях у Вас могут быть причины, имеющие превосходство над правом на забвение. Например:

• исполнение права на свободу самовыражения и информации (вспоминаем пример с отзывами на бирже фриланса);
• подача, исполнение или защита от судебных исков (например, если мошенник порядком накосячил на Вашем сервисе, а теперь требует удалить его данные, ссылаясь на GDPR, адресуйте его к подпункту 3(e) статьи 17);
• законодательство ЕС или страны-члена требует от контроллера обработки данных (и вот тут может возникнуть интересная ситуация, когда законодательство, скажем, РФ требует хранить какие-то данные, а вот законодательство ЕС требует их удалить; от кого страшнее получить по шапке — придётся выбирать самим контроллерам из третьих стран);
• данные получены на основании, не требующем непосредственного согласия, и они всё ещё нужны для целей, для которых были собраны (простейший пример — контракт ещё в силе, но вообще при использовании этого пункта лучше советуйтесь с юристом).

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

Специальные категории личных данных

Пункт 1 статьи 9 запрещает обработку следующих категорий личных данных:

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

Пункт 2 той же статьи тут же расписывает, в каких случаях данный запрет не работает. Как правило, это либо согласие самого лица, либо если обработка данных требуется для выполнения регламентированных законом обязательств, защиты жизненных интересов владельца данных или третьих лиц, а также если данные представляют общественный или научный интерес. А ещё страна-участник может запретить объекту данных давать согласие на обработку каких-либо данных из специальной категории. Запрет на запрете и запретом погоняет…

Также обработка данных о судимостях и уголовных преступлениях должна проводиться под надзором властей и никак иначе.

Data Protection Officer (ответственный сотрудник по защите данных)

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

К счастью, нужен он далеко не всем. К несчастью, определение, кому же он таки нужен, несколько туманно. Наличие такого специалиста требуется в случаях, если:

• обработка данных государственными структурами и органами власти, за исключением судов, выполняющих свои стандартные обязанности;
• основной деятельностью контроллера либо процессора являются операции, которые по своей природе, сфере и/или целям требуют регулярного и систематического мониторинга объектов данных в больших масштабах;
• основной деятельностью контроллера либо процессора является обработка больших массивов специальных данных, о которых я рассказывал чуть выше.

И если с первым пунктом всё понятно, то что такое «большие объёмы» — в законе не указано. Google и Facebook точно подпадают под это, но вот где нижняя грань? Некоторые источники утверждают, что в черновике закона фигурировали цифры «более 250 сотрудников» и «более 5000 записей». В окончательный текст они не попали, потому до установления судебной практики лучше себя поберечь и по возможности действовать по принципу «лучше перебдеть, чем недобдеть».

Некоторые юристы советуют пойти по следующему консервативному пути: всё, что больше, чем способен обслужить специалист в какой-то сфере, считать большими объёмами. Скажем, Вы на свою голову обрабатываете медицинские данные, да ещё и в объёмах, больших, чем врач в среднем обслуживает пациентов? Позаботьтесь о контракте с ответственным по защите данных. Вариант, более приемлемый в реалиях вне ЕС — тихо наблюдайте за судебной практикой и не отсвечивайте. Как первые вляпаются — поймёте для себя, какие объёмы считать большими.

Ваш путь к обновлённой политике конфиденциальности

Чтобы понять, что именно Вы будете писать в политике конфиденциальности, необходимо провести небольшую предварительную подготовку, чтобы чётко понять, как и с какими данными Вы работаете.

Шаг 0. Аудит данных

[sarcasm]Разве есть кто-то, кто не любит документировать всё и своевременно?..[/sarcasm] Долгое время работая над проектом, Вы можете успешно потерять след всего того, что, где, как и зачем Вы собираете. И вот нужно бы соответствовать GDPR уже пару недель назад, а Вы сходу не можете сказать, какие пользовательские данные Вы собираете, и так ли они Вам все нужны?.. Возьмите несколько чистых листов А4 или один чистый Google Document и ответьте на следующие вопросы:

• Какие данные Вы собираете? Выпишите в столбик всё, что Вы храните в своих базах, и что относится к категории персональных данных: имена, e-mail, IP-адреса, почтовые адреса и телефоны, предпочтения в интимной жизни (вдруг у Вас сайт знакомств, откуда мне знать). Те, что относятся к специальной категории (см. выше, зря послушались совета в начале статьи и сразу сюда доскроллили), выделите отдельным цветом и хорошенько подумайте над законным обоснованием сбора таких данных. Пометьте, в каких точках Вашего сайта/приложения Вы собираете данные, чтобы потом проставить там отсылы к политике конфиденциальности.
• Где Вы храните данные? В политике конфиденциальности нужно будет указать географическую локацию и носитель. Что-то вроде «Ваши данные хранятся на наших серверах в Амстердаме, Нидерланды» или «Ваши имена и телефоны мы распечатываем на жёлтые стикеры и клеим на стены и потолок нашего офиса в Вентспилсе, Латвия».
• Как Вы защищаете данные? Доступы по паролю? Шифрование? Ограничение доступа по IP? Даже просто для себя полезно с этим разобраться.
• Сколько времени Вы храните данные? В GDPR дано очень чёткое определение, сколько времени можно хранить пользовательские данные: «Не дольше, чем это необходимо». В идеале данные лучше не хранить дольше, чем Вам реально нужно. А вот сколько Вам нужно — решайте сами. Главное — суметь обосновать, почему именно столько. Это может быть срок исполнения контракта, например, или срок исковой давности по какой-то категории преступлений, которые могут быть сопряжены с использованием Вашего сервиса, например.
• Все ли данные Вы действительно используете? И, соответственно, как и почему? Собирать данные об адресах пользователей потому, что этого требует система регистрации доменных имён — не вопрос. Собирать те же данные просто потому, что Вам так захотелось — больше не прокатит. В политике конфиденциальности Вам нужно будет обозначить, каким образом и с какими целями Вы используете данные. Впрочем, усовершенствование пользовательского опыта — тоже может быть целью для некоторых типов данных.
• Каков процесс удовлетворения запросов на удаление данных? Иными словами, каким образом будет реализоваться право быть забытым? А ещё там регламенте прописано право объекта данных получить всё, что на него имеется, так сказать. Уясните для себя, как Вы это право намерены удовлетворять.

Шаг 1. Кто Вы?

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

Шаг 2. Каковы Ваши юридические основания?

GDPR чётко определяет, на каких основаниях (некоторые также переводят как «легальный базис») Вы можете собирать данные. Выберите вариант для себя.

• Согласие. Вы можете собирать данные, если объект данных дал явное согласие.
• Необходимость для выполнения контракта. Скажем, Вы не можете отправить товар получателю, не зная его имени и адреса. Или Вы не можете отправить данные для доступа к серверу, не зная e-mail.
• Соответствие законным обязанностям. Закон страны-члена ЕС обязует Вас собирать определённые данные.
• Жизненные интересы. Сбор данных необходим для решения вопросов жизни и смерти. Но вряд ли Вы — скорая помощь.
• Общественный интерес. Вы можете собирать данные, если Вы — государственная структура или частная компания, работающая в общественных интересах. Если вдруг используете это основание — будьте готовы обосновать.
• Законные интересы. Вы можете собирать персональные данные в законных интересах своей компании, если такие интересы не противоречат правам и свободам объекта данных.
• Данные касаются уголовных или административных правонарушений. Вряд ли этот пункт нас касается каким-то образом.
• Обработка, не требующая идентификации. Вы можете обрабатывать данные, если они не позволяют однозначно идентифицировать объект данных. Однако должны быть готовы продемонстрировать невозможность идентификации.

Шаг 3. Один документ или несколько?

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

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

Шаг 4. Собираем всё в кучу.

Вы уже определились с основными моментами (какую роль исполняете, какие данные и зачем собираете и т.п). В зависимости от того, как именно Вы собираете информацию — напрямую или косвенно, будет немного отличаться то, что необходимо включить в конечный документ. Грубо говоря, сбор напрямую — это заполнение пользователем формы, косвенно — любые фоновые процессы (те же cookies, например), парсинг открытых источников, получение от партнёров и т.п. Ниже — сводная табличка по аспектам, которые необходимо затронуть в конечной версии документа.

	Собираем напрямую	Собираем косвенно
Личность и контакты Вашего офицера по защите данных (если есть)	Да	Да
Цель обработки, включая законные основания	Да	Да
Законные интересы Вашей компании или организации	Да	Да
Категории собираемых персональных данных	Нет	Да
Получатели или категории получателей персональных данных	Да	Да
Информация о передаче третьим лицам и меры защиты при такой передаче	Да	Да
Сколько Вы будете хранить данные, почему именно столько?	Да	Да
Наличие прав на конфиденциальность данных у объекта данных	Да	Да
Право отозвать согласие (где применимо)	Да	Да
Право подать жалобу в органы надзора	Да	Да
Источник данных; получены ли данные из открытых источников?	Нет	Да
Уставные и договорные обязательства, их последствия (если сбор данных необходим для выполнения контракта)	Да	Нет

К концу данного эпизода у Вас должен быть готов текст Вашей политики конфиденциальности. Но это ещё не всё. При сборе данных Вам необходимо уведомлять об этом пользователя.

Шаг 5. Уведомления о конфиденциальности

Способ уведомления отличается в зависимости от способа сбора (прямой или косвенный). Так, в случае прямого сбора Вам необходимо уведомлять каждый раз при первом использовании нового способа или сборе новых данных. При этом уведомление не обязательно должно намертво блокировать работу пользователя, но должно быть читаемым, задерживаться на экране достаточно долго для осознания и содержать отсыл к более подробной информации.

Если Вы собираете данные косвенно (например, получаете от партнёров), это вовсе не значит, что Вам уведомлять об этом не обязательно. Пункт 3 статьи 14 требует от контроллера уведомить объект данных:

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

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

• Какие данные собираются?
• Кто их собирает?
• Как Вы их собираете?
• Почему Вы их собираете?
• Как Вы их будете использовать?
• Планируете ли Вы передавать данные кому-либо?
• Как долго Вы будете их хранить?
• Как объект данных может ими управлять?
• Возможны ли отрицательные последствия для объекта данных?

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

Будьте лаконичными, используйте максимально доступную широкому кругу людей лексику. Для проверки дайте почитать текст нескольким людям, далёким от Вашей сферы деятельности, получите от них обратную связь.

Дополнительно, если Вы собираете данные косвенно, постарайтесь установить доверие. Подробнее укажите, кто Вы, чем занимаетесь, зачем Вам эти данные, какую выгоду получит объект данных.

Предельно осторожным необходимо быть, если Вашим ресурсом могут пользоваться дети. Статья 8 устанавливает, что давать согласие на обработку самостоятельно могут лица не младше 16 лет. В остальных случаях Вы должны произвести разумные усилия, чтобы убедиться, что согласие на обработку подтверждено родителями ребёнка. За странами-членами оставлено право снизить данный возраст, однако в любом случае он не может быть ниже 13 лет. Как бы там ни было, отследить данные тонкости может быть непростой задачей, если Ваш продукт ориентирован на широкую географию.

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

Эпилог

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

Не будет лишним напомнить ещё раз не только о серьёзных штрафах, о которых уже сказано немало, но и об основных целях нового закона — защите личного пространства граждан в условиях глобализации и информатизации от агрессивных и не всегда порядочных действий бизнеса. Уважайте своих пользователей, и они непременно ответят Вам лояльностью.

Спасибо, что остаетесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас оформив заказ или порекомендовав знакомым, 30% скидка для пользователей Хабра на уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps от $20 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле? Только у нас 2 х Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 ТВ от $249 в Нидерландах и США! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?