Две недели до дедлайна: как выполнить предписания надзорного органа по GDPR в срок
- FoodTech
- Enterprise
Что делать, если до срока исполнения предписаний по GDPR осталось чуть больше двух недель, а необходимые изменения зависят от нескольких компаний и иностранной технической команды? В этом кейсе показываем, как мы разобрали решение регулятора, проверили пользовательский путь в мобильном приложении, подготовили документы и перевели юридические требования в конкретные задачи для разработки.
Коротко о результате
Клиент в установленный срок направил надзорному органу ответ по каждому предписанию и приложил подтверждающие материалы: обновлённые политики, опубликованную версию политики на местном языке и техническое задание для разработчиков. Изменения, которые нельзя было внедрить за две недели, были включены в производственный цикл с обоснованным графиком реализации.
Запрос клиента
К нам обратился европейский оператор международной сети заведений общественного питания. Компания готовит и реализует продукцию под брендом сети и принимает заказы напрямую через мобильное приложение и сайт.
Незадолго до обращения надзорный орган провёл плановую проверку того, как приложение информирует пользователей об обработке персональных данных. По итогам проверки были установлены нарушения требований GDPR о прозрачности и информировании. Штраф в первоначальном решении назначен не был, однако регулятор выдал обязательные предписания с конкретным сроком исполнения.
Клиент обратился к нам, когда до дедлайна оставалось чуть больше двух недель.
Наше решение
Мы разобрали решение надзорного органа по пунктам, оценили риски и помогли клиенту сформировать правовую позицию. Затем прошли пользовательский путь в приложении экран за экраном и сопоставили каждое предписание с конкретным моментом сбора данных.
Для команд разработки и дизайна мы подготовили памятку и готовые интерфейсные формулировки: маркировку обязательных полей, пояснения о последствиях непредоставления данных, информирование до начала сбора данных и раздельные согласия на разные виды рекламных рассылок и уведомлений.
Параллельно мы обновили политику конфиденциальности, выделили самостоятельную политику использования cookie и подготовили техническое задание на доработку cookie-баннера. Для надзорного органа сформировали ответ с таблицей соответствия по каждому предписанию и приложили материалы, подтверждающие выполненные и запланированные изменения. Это позволило последовательно показать ход исполнения предписаний и подтвердить сотрудничество с надзорным органом, как того требует ст. 31 GDPR.
Ведущий консультант проекта
CIPP/E, AIGP, FIP.
Ключевые сложности проекта
Разделение ролей между оператором и владельцем бренда
Клиент является местным оператором сети: он готовит и реализует продукцию под брендом сети и принимает заказы через мобильное приложение и сайт. Персональные данные собираются при вводе адреса доставки, регистрации и оформлении заказа — в частности, имя, номер телефона, адрес и сведения об оплате. Именно эти интерфейсы и политика конфиденциальности стали предметом проверки.
В стране проверки деятельность ведут несколько юридических лиц, выступающих совместными контролерами в смысле ст. 26 GDPR. При этом приложение разрабатывает и поддерживает центральный офис владельца бренда.
Юридическая ответственность за прозрачность интерфейсов лежала на контролерах, а фактическая возможность изменить приложение — у иностранной технической команды. Поэтому клиент не мог самостоятельно внедрить все необходимые изменения до дедлайна.
Отсутствие выделенной локальной функции по защите данных
Экспертиза по защите данных в группе была сосредоточена в центральном офисе владельца бренда. Местная юридическая служба отвечала преимущественно за коммерческие и операционные вопросы.
У клиента не было выделенной локальной функции, которая могла бы быстро связать требования регулятора, продуктовые изменения и коммуникацию между несколькими компаниями группы. Для анализа требований, подготовки правовой позиции и перевода предписаний в конкретные задачи для внутренних команд компания привлекла внешних профильных консультантов.
Сжатые сроки и зависимость от цикла разработки
Решение надзорного органа поступило в компанию за несколько месяцев до истечения срока исполнения предписаний, поэтому времени на подготовку и внедрение изменений изначально было достаточно. Решение было адресовано клиенту, однако необходимые изменения затрагивали продукт и процессы, в которых участвовали несколько компаний группы, включая центральный офис бренда. Поэтому исполнение предписаний требовало координации между несколькими командами и учета внутренних процессов разработки.
Когда клиент обратился к нам, оставалось чуть больше двух недель. За это время требовалось проанализировать решение, скоординировать местные подразделения и центральный офис, подготовить изменения в документах и интерфейсах и направить официальный ответ.
Какие нарушения GDPR установил надзорный орган
Проверка касалась не только политики конфиденциальности. Регулятор оценивал весь пользовательский путь: когда человек получает информацию об обработке данных, насколько легко её найти и как оформлены поля ввода.
1. Информация предоставлялась несвоевременно и была труднодоступна
При первом запуске приложение сразу запрашивало адрес доставки, но не сообщало, как будут обрабатываться данные. Политику конфиденциальности приходилось искать через несколько разделов, названия которых не раскрывали содержание документа, то есть более чем за два касания. В магазине приложений была размещена неактуальная версия политики на другом языке, не предназначенная для местного рынка.
Регулятор квалифицировал это как несоблюдение требований ст. 12(1) и 13(1)–(2) GDPR.
2. Не было активного уведомления об изменениях политики
Пользователь мог узнать об изменениях, только если самостоятельно открывал новую редакцию документа. Рекомендация периодически проверять политику не заменяет активного уведомления о существенных изменениях, например сообщения в приложении.
Нарушение было связано с требованиями прозрачности по ст. 12(1) GDPR.
3. Обязательные поля и последствия их незаполнения были неочевидны
В формах не указывалось, какие данные обязательны и что произойдёт, если их не предоставить. При этом без имени и номера телефона оформить заказ было невозможно.
Статья 13(2)(e) GDPR требует сообщать, является ли предоставление данных обязательным и каковы возможные последствия отказа.
4. Информация о праве на жалобу была неполной
Политика называла только национальный надзорный орган. В ней не было разъяснено, что пользователь также может обратиться в орган страны своего обычного места жительства или работы.
Обязанность сообщить о праве на жалобу предусмотрена ст. 13(2)(d) GDPR. Право обратиться в надзорный орган государства обычного места жительства, места работы или предполагаемого нарушения конкретизировано в ст. 77(1) GDPR.
5. Не были разграничены данные, полученные от пользователя и из других источников
Сведения, поступающие от поставщиков платёжных услуг, были перечислены вместе с данными, которые пользователь предоставляет самостоятельно. В результате политика не позволяла понять происхождение отдельных категорий данных.
Это затрагивало требования ст. 14(1)(d) GDPR.
По итогам проверки надзорный орган выдал шесть предписаний: разместить актуальную информацию на местном языке в магазинах приложений и в самом приложении; обеспечить простой доступ к политике; внедрить уведомление о существенных изменениях; обозначить обязательные поля и последствия их незаполнения; разграничить категории данных по источникам; дополнить информацию о праве на жалобу.
Что важно для бизнеса
Регулятор проверял не только содержание юридических документов, но и фактический пользовательский путь. Даже корректная политика конфиденциальности не устраняет риск, если человек получает информацию слишком поздно или не может найти её без дополнительных действий.
Какие дополнительные риски выявил анализ приложения
Мы решили не ограничиваться только вопросами, указанными в решении надзорного органа, и дополнительно проанализировали пользовательский путь в целом. Такой анализ выявил риски, которые не были предметом проверки, но могли стать причиной претензий в дальнейшем.
🔹 отсутствие механизма получения согласия на необязательные cookie и иные трекеры с учётом требований ePrivacy;
🔹 единое согласие на рекламные сообщения без разделения по каналам и целям, что требовало дополнительной проверки с учётом ст. 7 GDPR и ePrivacy;
🔹 заранее проставленная галочка сохранения данных банковской карты, которая могла поставить под сомнение свободу выбора пользователя и соблюдение принципа защиты данных по умолчанию.
Исторически маркировка обязательных полей символом * и поясняющие подсказки воспринимались как вопрос удобства интерфейса. Продуктовые и маркетинговые команды нередко возражают против таких элементов, поскольку они могут перегружать экран и влиять на конверсию.
Однако практика показывает, что дизайн форм может оцениваться надзорными органами как часть исполнения требований прозрачности по ст. 12–13 GDPR. Неисполнение выданных предписаний может повлечь дополнительные меры ответственности, включая административные штрафы по ст. 83 GDPR. Поэтому решения об интерфейсе нельзя рассматривать отдельно от требований законодательства о защите данных.
Как мы организовали работу за две недели
Работу распределили между двумя консультантами и вели по трём параллельным направлениям.
Направление 1. Диагностика пользовательского пути и оценка рисков
Мы сопоставили каждое предписание с фактическим пользовательским путём и операционными процессами клиента. Для этого прошли приложение шаг за шагом и зафиксировали экраны, на которых требования не выполнялись.
Анализ показал, что формального письма без изменений в документах и интерфейсах было бы недостаточно. Надзорному органу требовались подтверждаемые меры, а не общие обещания исправить нарушения в будущем.
Направление 2. Сбор информации и устранение расхождений
Мы собрали сведения у юридической, технической и маркетинговой команд и свели полученные от них описания процессов обработки в единую непротиворечивую картину. Это было необходимо, чтобы документы, интерфейсные тексты и официальный ответ не противоречили друг другу.
Направление 3. Юридический ответ и реалистичный план разработки
Разработка действующего приложения подчиняется циклу планирования, тестирования и выпуска обновлений. Срочное изменение логики регистрации могло привести к сбоям в оформлении заказов и прямым потерям. Кроме того, часть работ могла выполнить только техническая команда центрального офиса. Для запуска этих изменений требовалось формализованное обращение в центральный офис с юридическим обоснованием и готовыми требованиями.
Поэтому мы разделили меры на две группы:
1) То, что можно выполнить до дедлайна: обновление политики конфиденциальности и политики cookie, публикация актуальной версии политики на местном языке в магазинах приложений, подготовка ответа и подтверждающих материалов.
2) То, что требует обновления приложения: изменение конкретных экранов, правил отображения, валидации полей, согласий и уведомлений.
Для второй группы каждое требование было привязано к конкретному экрану и дополнено готовым текстом, правилами отображения и макетами соответствующих элементов интерфейса. Благодаря этому центральная продуктовая команда могла поставить изменения в работу без дополнительной юридической интерпретации, а клиент — направить ответ в срок, не дожидаясь ближайшего обновления приложения.
Мы также подготовили несколько вариантов ответа, чтобы клиент мог обсудить технические ограничения внутри группы и выбрать реалистичный сценарий внедрения. В официальном ответе мы описали процесс разработки, приложили техническое задание и представили обоснованный график внедрения. Это подтвердило, что компания уже начала исполнять предписания, даже если часть изменений ещё не вошла в ближайший релиз.
Для бизнеса это означало, что исполнение предписаний не превратилось в срочную и хаотичную переделку приложения. Компания получила понятный план: какие меры можно закрыть документами и публикацией обновлённых материалов, а какие требуют изменения интерфейса и участия центральной технической команды.
Что получил клиент
За две недели была подготовлена документальная и техническая база для исполнения предписаний:
1) Пошаговый разбор пользовательского пути с привязкой каждого нарушения к конкретному экрану.
2) Памятка и техническое задание для разработки и дизайна с требованиями по каждому пункту решения, правилами валидации полей и макетами элементов интерфейса.
3) Ответ надзорному органу с таблицей соответствия, статусом мер и перечнем приложений.
4) Готовые интерфейсные тексты для информирования до начала сбора данных, маркировки обязательных полей, пояснений в информационных иконках и раздельных согласий на рекламные сообщения.
Например, техническое задание предусматривало пояснение рядом с обязательным полем номера телефона:
«Зачем это нужно? Номер телефона используется для создания вашей учётной записи и для информирования о важных изменениях по заказу».
5) Обновлённая политика конфиденциальности с разграничением данных по источникам, дополненной информацией о праве на жалобу, порядком уведомления об изменениях и доступом к предыдущим редакциям.
6) Отдельная политика использования cookie и техническое задание на cookie-баннер: установка необязательных cookie только после согласия, раздельный выбор категорий, корректная кнопка отказа и ведение журнала согласий.
Результат проекта
Клиент вовремя направил надзорному органу ответ, в котором по каждому пункту были указаны принятые меры и подтверждающие приложения: обновлённые политика конфиденциальности и политика cookie, опубликованная версия политики на местном языке и техническое задание для разработки.
Для изменений, зависевших от центральной технической команды, в ответе были зафиксированы график внедрения и готовность информировать регулятора о ходе работ. Такой подход позволил перевести взаимодействие в конструктивный режим и снизить риск дополнительных мер ответственности.
Исход каждого дела зависит от его обстоятельств. Однако этот проект показывает, что даже при коротком сроке компания может представить содержательный и подтверждённый план исполнения, если юридические требования заранее переведены в конкретные продуктовые задачи.
Проект стал отправной точкой для системных изменений: оценив риски, руководство решило продолжить сотрудничество. Следующим этапом стало оформление распределения ответственности между совместными контролерами по ст. 26 GDPR — это отдельная история.
Частые вопросы
Нужно ли успеть внедрить все изменения до срока ответа регулятору?
Это зависит от содержания решения и обстоятельств дела. Если техническое изменение объективно нельзя безопасно выпустить до дедлайна, важно показать фактический прогресс: подготовить подробное техническое задание, определить ответственных, зафиксировать реалистичный график и объяснить ограничения. Такой пакет не заменяет исполнение предписания, но подтверждает, что компания уже принимает конкретные меры.
Достаточно ли просто обновить политику конфиденциальности?
Не всегда. Если нарушение связано с моментом и способом информирования, необходимо проверять весь пользовательский путь: первый запуск, регистрацию, оформление заказа, настройки аккаунта и уведомления. Корректный документ не решает проблему, если пользователь получает его слишком поздно или не может легко найти.
Какие доказательства исполнения можно приложить к ответу?
В зависимости от ситуации это могут быть новые редакции политик, скриншоты и макеты интерфейсов, техническое задание, таблица соответствия предписаниям, подтверждение публикации документов, внутренние задачи с ответственными и согласованный график релизов.
Есть предписание или запрос надзорного органа?
Мы помогаем оценить риски, подготовить ответ, собрать подтверждающие документы и перевести требования GDPR в задачи для юридической, продуктовой и технической команд.
Что можно сделать уже сейчас
Кейс показывает: при коротком сроке риск дальнейших санкций можно снизить, если действовать последовательно и подтверждать каждый этап исполнения документами.
1) Проверяйте пользовательский путь, а не только документы.
Информация об обработке должна предоставляться до или в момент сбора данных, а не после того, как пользователь уже ввёл адрес, телефон или платёжные сведения.
2) Обозначайте обязательные поля и последствия их незаполнения.
В форме должно быть видно, какие сведения необходимы для оказания услуги и что произойдёт, если их не предоставить.
3) Распределяйте ответственность заранее.
Зафиксируйте, кто получает корреспонденцию регуляторов, контролирует сроки и координирует изменения, особенно если продукт поддерживает другая компания группы.
4) Подтверждайте фактический прогресс.
Приложите к ответу выполненные документы, техническое задание, макеты и график релизов. Общих обещаний недостаточно.
5) Проверяйте сопутствующие риски.
Предписание может касаться одного элемента интерфейса, но анализ пользовательского пути нередко выявляет связанные проблемы с cookie, рекламными согласиями и настройками по умолчанию.
Рассылка Data Privacy Office
А в ней — скидка 10 % на курс GDPR DPP, полезные материалы от экспертов и наши новости.
