Встроенная приватность в IT-продукты: ожидание и реальность

Что такое встроенная приватность и как её внедрять в IT-продукты, разберемся вместе со старшим консультантом Data Privacy Office, CIPP/E, PbD Еленой Себякиной.

Согласно статье 25 GDPR каждый контролер (оператор) персональных данных обязан внедрить надлежащие технические и организационные меры для обеспечения встроенной приватности по умолчанию (далее «встроенная приватность”) в своих процессах, системах и программном обеспечении (далее «ПО» или “продукт»).

Европейским советом по защите данных было разработано Руководство по встроенной приватности 4/2019, которое предложило контролерам (командам, участвующим в разработке продуктов, сервисов и систем) широкий спектр элементов дизайна процессов для встраивания каждого из принципов GDPR непосредственно в архитектуру. Например, для встраивания одного только принципа «минимизации» предлагается использовать такие элементы дизайна процессов как:

• Предотвращение — избегайте обработки персональных данных, когда это возможно;
• Ограничение — ограничьте объем собираемых персональных данных до необходимого минимума;
• Ограничение доступа — ограничьте доступ минимальным количеством лиц, которым он необходим;

• Актуальность — данные должны иметь отношение к обработке, и контролер должен быть в состоянии продемонстрировать эту актуальность;

• Необходимость — каждая категория персональных данных должна быть неизбежно необходима для указанных вами целей;

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

По встраиванию остальных принципов GDPR в продукты и процессы Руководство также предлагает соответствующие элементы дизайна.

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

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

Согласно статистике штрафов по GDPR, нарушение принципов, перечисленных в статье 5 GDPR, является наиболее популярным нарушением, а согласно отчету Bulletproof в UK, нарушение принципов GDPR было обнаружено в 100% рассмотренных ICO дел по этому закону за 2019-2020 годы.

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

То есть GDPR квалифицирует отсутствие мер встроенной приватности как обстоятельство, отягчающее ответственность контролера и процессора.

В частности 30 октября 2019 года германская риэлторская компания Deutsche Wohnen SE (контролер) была оштрафована по статье 25 GDPR на сумму около EUR 14 500 000 за неправильное хранение данных.

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

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

Требования по встраиваемой приватности распространяются и на таких процессоров как подрядчики разработки и поддержки ПО, провайдеры облачных сервисов. Европейский совет по защите данных выпустил Руководство 07/2020 по концепции контролера и процессора, исходя из которого любое третье лицо, имеющее потенциальный доступ к персональным данным контролера в рамках исполнения своих обязательств, является процессором.

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

Исходя из своего опыта, могу привести некоторые примеры встраивания приватности в продукты и процессы:

• предустановленное размытие лиц или полное закрашивание фигур субъектов при видеонаблюдении;

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

• автоматизация предоставления доступа к данным и реализации права на перенос данных к другому оператору;

• дизайн cookie согласий в соответствии с лучшими практиками и судебными решениями;
• встраивание этапа согласования с DPO компании, по вопросам установки на сайтах сбора новых cookies;
• автоматизация уведомлений субъектов об изменениях в политике обработки данных.

А теперь к лейтмотиву нашего рассуждения: как часто вы вписываете подобные требования (на стороне контролера) или согласовываете их (на стороне процессора) в техническом задании на создание IT продукта, связанного с обработкой персональных данных?

При этом: на какие законы, нормы, примеры вы ориентируетесь: GDPR, руководства EDPB или иных надзорных органов по встроенной приватности, 7 принципов встроенной приватности Анны Кавукян?

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

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

Зачастую, техническое задание составляет сам разработчик на первом этапе разработки. Либо же техническое задание является кратким и верхнеуровневым (например, при Agile разработке) и не может включать в себя все требования к элементам встроенной приватности.

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

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

То есть, в зависимости от условий договора, упомянутая ранее германская риэлторская компания Deutsche Wohnen SE, могла бы переложить на своего подрядчика — разработчика ПО по хранению и архивированию данных арендаторов, ответственность за нарушение статьи 25 GDPR, и потребовать возместить эти EUR 14 500 000 и сверх того: прочие понесенные убытки и расходы.

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

Финансовая сторона проблематики встроенной приватности понятна: контролер подразумевает, что разработчик встроит ее в силу своей обязанности по договору и не хочет переплачивать, прикрываясь фразой про «все законы всего мира», а разработчик не может ее встроить за свой счет.

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

Но, помимо очевидной финансовой «незаинтересованности» компаний во встраивании приватности в продукты, есть и другое серьезное препятствие: недостаток компетенций у команды разработки. А именно: отсутствие даже самого запроса со стороны заказчика на такие компетенции, которые были бы релевантны в команде разработки для встраивания приватности в ПО.

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

Сколько архитекторов из команды разработки знает требования GDPR или имеет хотя бы один сертификат CIPP/E, CIPT или Privacy by design? Сколько UI/UX дизайнеров и архитекторов в команде изучило Руководство по встроенной приватности 4/2019 и умеет его применять? Как часто Менеджер по защите персональных данных (DPO) участвует в разработке требований к ПО и, в дальнейшем, в его приемке?

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

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

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

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

Для снижения рисков наложения штрафов или возмещения убытков, вызванных несоответствием продукта требованиям GDPR, рекомендуется:

• На стадии выработки технического задания к продукту необходимо подробно описывать все требования ко встроенной приватности и пользовательскому опыту в сфере приватности;
• Привлекать к разработке компетентную команду, способную создать продукт в соответствии с требованиями GDPR, встроенной приватности и ожиданиями пользователя. В частности, включать в команду разработки юристов, технологов, инфобезопасников, инженеров и дизайнеров — с компетенциями и опытом в сфере приватности;
• Выполнять приемку или приемочный аудит продукта командой, обладающей всеми компетенциями из пункта 2;
• Обучать команды разработки ПО и проектные команды, создающие продукты, принципам встроенной приватности, проводить кросс-функциональные воркшопы;
• Обучение маркетинговых и продуктовых команд восприятию требований GDPR как руководства по пользовательскому опыту в сфере приватности;
• Выработка стратегии развития пользовательского опыта по продукту в сфере приватности (Privacy User Experience).