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

Читать далее

Белорусские ИТ-компании, которые не будут соответствовать Общему регламенту защиты персональных данных Европейского союза (GDPR), потеряют многих европейских клиентов, а также клиентов из других стран, решивших сертифицироваться под GDPR. Дело в том, что Регламент под угрозой огромного штрафа запрещает иметь в цепочке поставщиков компанию, которая не отвечает требованиям GDPR. С другой стороны, если своевременно внедрить требования GDPR и пройти соответствующие сертификации, можно получить неоспоримое конкурентное преимущество.

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

Новый регламент вступит в действие 25 мая 2018 года. Документ переформатирует рынок не только внутри ЕС, но и в любой стране, поставляющей ИТ-услуги на европейский рынок.

Что такое персональные данные?

К персональным данным относят информацию, с помощью которой можно сразу идентифицировать человека, или которая делает возможной последующую идентификацию. В первом случае такого человека называют «идентифицированным», а во втором — «идентифицируемым». Любая дополнительная информация, которая потом станет описывать «идентифицированного» и «идентифицируемого» также становится персональной. Таким образом, одни персональные данные вначале превращают вас из неизвестного человека в идентифицируемого либо в идентифированного, а другие добавляют «краски» к вашему образу.

За словом «идентификация» прячется узнавание идентификатора пользователя — например, фамилии и имени, личного номера или уникального генетического кода. В отдельных случаях к идентификатору также относятся некоторые файлы cookies.

Почему вообще это должно волновать мой бизнес?

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

За примерами далеко ходить не надо. Ситуация: белорусский стартап без регистрации в Евросоюзе разработал полезное мобильное приложение. Оно использует геолокацию и требует авторизации с помощью email или социальной сети. Приложение опубликовано в Play Store, открыто для скачивания из Европейского союза, для работы приложения стартап использует сервер, арендованный в России. Это стопроцентное попадание под действие GDPR, несмотря на то, что ни компания, ни её мощности не находятся в ЕС. Используются европейские персональные данные, поэтому после 25 мая 2018 года у стартапа возникнет юридическая ответственность.

Во-вторых, если сама компания не обрабатывает европейские персональные данные, это ещё не значит, что их не обрабатывает конечный заказчик ПО, которое вы разрабатываете на аутсорсе. А значит, будьте готовы, что к вам постучится Data Protection Officer клиента и попросит подтвердить, что вы соответствуете GPDR. И хуже всего — попросит доказать это. Ведь «отдуваться» за нарушение подрядчика придётся именно ему, а ответственность соизмерима с ответственностью за отмывание денег или фальсификацию отчётности перед инвесторами.

Санкции на самом деле огромные: нарушение будут наказывать штрафом до €20 млн или 4 процентов от общего глобального оборота компании (в зависимости от того, что больше). Скажем, если компания не получила согласие от пользователей на обработку персональных данных, её грозит штраф до €20 млн, а если она не включила шифрование персональной информации или другим образом оставила персональные данные уязвимыми в своём ПО, штраф может достигнуть €10 млн.

Если законы о защите персональных данных в ЕС действовали и раньше, то какие нововведения привносит GDPR?

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

• Псевдонимизация: хранить информацию, которая позволяют сличить человека и данные, которые к нему относятся, нужно отдельно. Пример: имя человека хранится отдельно от истории его действий в аккаунте. В таком случае утечка информации о действиях не позволит злоумышленнику узнать, кому они принадлежат;
   
• Новые права субъектов данных, в частности, право «быть забытым», когда по простому волеизъявлению пользователя вся персональная информация о нём удаляется везде, включая резервные копии, или «право на портативность» (передача пользователю собранных одним провайдером данных для передачи новому провайдеру). Маркетинговые и страховые компании особенно затронет право на возражение против автоматизированного принятия решений;
   
• Утечка персональных данных: необходимость уведомлять власти и пользователей об утечке персональной информации не позже 72 часов после выявления утечки;
   
• Европейские надзорные органы для каждого. Компаниям придётся назначить своего представителя в ЕС. В некоторых случаях можно будет выбрать страну-члена ЕС, чей надзорный орган будет следить за обработкой персональных данных и, в случае чего, выдавать штрафы;
   
• Отмена уведомлений национальных надзорных органов об обработке персональных данных. С мая 2018 регистрация такой обработки не требуется;
   
• Инспектор по защите данных в каждой крупной организации. Должность, которой у многих ещё нет ни в организационной структуре, ни в штатных расписаниях, но которая скоро однозначно появится — Data Protection Officer (DPO);
   
• Приватность по умолчанию (privacy by default) и «встроенная приватность» (privacy by design). Об этом мы ещё поговорим дальше.

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

Шаг 1. Сделать приватность настройкой по умолчанию

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

Шаг 2. «Встроить приватность»

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

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

Список вопросов DPIA, официальное руководство, а также её шаблоны с недавнего времени доступны онлайн. В июне 2017 года даже вышел стандарт ISO/IEC 29134:2017 по проведению такой оценки.

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

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

Шаг 3. Выявить персональные данные и процессы, в которых они используются

Заведите и поддерживайте Реестр персональных данных. Это может быть как самостоятельный документ, так и составляющая Реестра информационных активов (Information Asset Register или IAR). С помощью этого инструмента ведите учёт персональных данных с указанием их местоположения, ответственного владельца файла или процесса, чувствительности информации, уровня доступа к ней, периода хранения, рисков и значимости, доступности данных и т.д. Заранее определите, кто в вашей организации ведёт данный реестр и наделите его необходимыми ресурсами и полномочиями. Впоследствии информация пригодится для оценки воздействия защиты данных.  

Для учёта процессов обработки персональных данных подойдёт любая привычная вам форма: Data Flow Charts, Processing Registers, Data Inventories, Data Indexes, Data Mappings. Для целей GDPR помимо характеристик процесса отражаются виды обработки данных (сбор, хранение, изменение, передача, удаление и т.д.), контакты инспектора по защите данных компании, которая дала заказ на обработку данных, основание для обработки данных (согласие, законный интерес и т.д.), местоположение сервера и его оператора, юридическое основание для размещения данных на сервере, данные процессора (обработчика) персональных данных, производилась ли оценка воздействия защиты данных.

Шаг 4. Минимизировать персональные данные

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

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

Шаг 5. Задокументировать выполнение требований GDPR

Регламент обязал компании не просто соответствовать требованиям GDPR, но и быть способными доказать это соответствие документально. Даже если компания выполнила все нормы Регламента, но «забыла» задокументировать это, все незадокументированные меры будут считаться нереализованными. Проверка надзорным органом или аудит покажут, что вы ничего не сделали, со всеми вытекающими последствиями.

Поэтому важно оформлять необходимые политики, проведённые Оценки воздействия защиты данных (DPIA), вести Реестр персональных данных, прописывать стандартные контрактные положения о защите персональных данных, вводить обязательные корпоративные правила.

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

Шаг 6. Получить осведомлённое согласие на обработку персональных данных

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

Шаг 7. Внедрить меры информационной безопасности

Регламент повысил ставки за утечку информации. Теперь за удавшуюся хакерскую атаку придётся заплатить не только репутацией, но серьёзным штрафом. Иными словами, придётся заплатить за ненадлежащую заботу о конфиденциальности, целостности и доступности персональных данных пользователей. Потому уже на начальном этапе разработки ПО стоит позаботиться о системе его защиты. Авторы Регламента особенно полюбили шифрование в качестве меры, но список открытый и предполагается, что разработчики ПО самостоятельно выберут самый сильный набор мер защиты. Безусловно, для этого подойдут классические меры для обеспечения конфиденциальности, целостности и доступности информации, с той лишь поправкой, что планируемый уровень защиты должен соответствовать актальному уровню технических возможностей (state-of-the art). Этого напрямую требует регламент в статье 32.

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

Хотя Регламент и не называет конкретных стандартов в области информационной безопасности, сертификация из семейства ISO 27xxx — системное решение этого вопроса. Наличие сертификатов позволит легко продемонстрировать заказчикам и надзорным органам внедрённые данные меры и снять большинство вопросов при заключении сделок и разбирательствах об утечках персональных уданных.

Итак, потерянные заказы и разорванные связи с давними клиентами, потерянные рынки, заблокированные в Apple Store и Google Market мобильные приложения и многомиллионные штрафы — довольно мрачная перспектива. Однако, как говорится, нет худа без добра, и зачищенный от конкурентов европейский рынок займут компании, мастерски работающие с персональными данными. Спешите: май 2018 года уже скоро!

Сергей Воронкевич — специалист в области защиты персональных данных, юрист, корпоративный тренер. Получил степень MBA по специальности «Global Management» в Германии. Работал в ТНК Allianz SE (Мюнхен), исследовал воздействие GDPR на систему менеджмента информационной безопасности глобальных страховых компаний, ведёт курс «Защита персональных данных» в Школе Бизнеса «TopSkills» (Минск).

Место солидарности беларусского ИТ-комьюнити

Далучайся!