Тайный покупатель: Как команда Data Privacy Office представилась пользователями и нашла ошибки в обработке запросов субъектов
Время от времени в компанию обращаются клиенты/пользователи/покупатели с запросами, связанными с персональными данными. Они могут попросить удалить их данные или дать подробную информацию, для чего они используются. Компания может описать все процедуры ответа на такие запросы и подготовить соответствующие политики, но всё равно допускать досадные ошибки в самых заметных местах.
Рассказываем, как мы сыграли в шпионов и помогли команде найти грубые ошибки в обработке запросов субъектов.
Запрос
К нам обратилась компания, которая хотела проверить: правильно ли они реагируют на запросы пользователей?
Наше решение
Мы не пошли по обычному пути: рассмотрение политик реагирования. Мы поставили перед собой задачу «выйти в поле» и оценить, как всё происходит не на бумаге, а на практике. Для этого мы отправили три запроса от лица якобы обычных пользователей с личных (обычных не корпоративных) почтовых ящиков. Само собой, никакой юридической терминологии в запросе, ведь про GDPR мы просто «что-то слышали» 🙂
Важно: наша команда намеренно не проводила обучение сотрудников клиента перед началом теста, чтобы оценить текущее состояние процессов. Консультанты даже не сообщали об этой проверке сотрудникам отдела, который мы тестировали. Лишь privacy-команда компании была в курсе, что мы отправим несколько запросов — в этом заключалось пожелание клиента. Только хардкор!
Ведущий консультант проекта
Дарья Заграничнова,
CIPP/E, GDPR DPP, лидер команды консультантов Data Privacy Office.
Результаты эксперимента
После отправки запросов и долгого ожидания мы получили такие результаты:
Запрос 1
Запросили информацию об обработках внутри приложения: ответ так и не получили.
Запрос 2
После запроса на удаление данных сразу же пришёл автоматический ответ, в котором было указано, что мы получим ответ в течение 3 часов (или позднее в случае, если поддержке потребуется больше времени). Однако ответ так и не пришёл.
За что ставим плюс: у пользователя есть возможность быстро обратиться к компании с запросом и получить моментальный автоматический ответ о том, что запрос получен.
За что ставим минус:
- Несколько каналов связи (почта privacy-отдела и служба поддержки).
- Отсутствие темы «Privacy» в обращении в поддержку.
- Отсутствие ответа от поддержки, хотя как раз этот кейс можно было решить роботом: если в компанию поступает запрос на удаление данных, то робот может высылать инструкцию, как удалить свой аккаунт. К тому же, нужно разработать чёткий механизм того, как именно пользователь получит информацию о том, что его данные удалены.
Запрос 3
С запросом на доступ к информации, то есть, на получение копии данных, всё тоже оказалось не так просто. На этот запрос команда действительно ответила, даже с соблюдением сроков ответа — 14 дней, но допустила ошибку в самих данных.
Запрос требовал предоставить сами данные, а команда прислала описание того, как с ними работает компания, и предложила изучить остальные детали самостоятельно в Политике конфиденциальности.
Основные ошибки
Подмена понятий: «Информация» вместо «Копии».
GDPR различает два права пользователя: просто узнать, как обрабатываются данные, и получить копию этих данных. В ответе мы получили общее описание процессов (какие данные собирает компания, зачем, на каком основании), что по сути дублирует политику приватности. Но запрос был именно на копию (ст. 15(3) GDPR). Это значит, что сотрудники должны были выгрузить данные из системы и прислать конкретный файл с данными пользователя (например, ID, email, страну, историю транзакций, логи активности и т. д.), а не просто текст с общим описанием процессов.
Отсутствие обязательных деталей.
Даже в текстовой части ответа не хватало важной конкретики. Сотрудники не указали точный список получателей наших данных (кому они передаются) и конкретные сроки их хранения. Просто дать ссылку на политику приватности в данном случае недостаточно — ответ должен быть индивидуальным.
Нет объяснений.
Так как копию данных сотрудники не приложили, они должны были объяснить субъекту (то есть нам), почему они этого не сделали. В ответе пояснений об отказе в выдаче копии не содержалось.
Как нужно было поступить?
Вместо общего описания сотрудникам следовало выгрузить из базы данных информацию, относящуюся к этому пользователю (включая технические логи, историю просмотров и данные профиля), и предоставить возможность скачать этот файл в одном из распространенных файловых форматов. Если данных слишком много, закон разрешает сначала спросить у пользователя: «Какие именно данные или за какой период вам нужны?», но просто игнорировать требование копии нельзя.
Проблемы в процессе, которые мы нашли
В ходе эксперимента мы выявили критические нарушения процесса обработки запросов.
Игнорирование запросов
Из трёх отправленных запросов компания ответила только на один. Запросы на получение информации об обработке и на удаление данных были пропущены.
Некорректный ответ
Единственный ответ, который был получен (на запрос о копии данных), оказался неправильным. Вместо предоставления копии данных компания ограничилась лишь информацией об их обработке.
Общий сбой процесса
Эксперимент показал, что процесс не работает должным образом и сотрудники совершают ошибки при работе даже с простыми запросами.
Готовы к тайной проверке?
Напишите нашему менеджеру — расскажем о формате и подберём решение под ваш случай.
Что бы произошло, если бы это были реальные запросы субъектов?
Если бы это были запросы от реальных пользователей, то самые нетерпеливые из субъектов уже вполне могли бы обратиться к надзорному органу. А это, в свою очередь, может привести:
К штрафу
Хотя на практике часто сумма санкций меньше, в теории штраф за нарушение этой нормы GDPR может достигать 10 млн EUR.
К дополнительным проверкам
Надзорный орган может запросить информацию вне рамок жалобы и выявить другие нарушения.
К тратам времени команды
В коммуникации с надзорным органом и попытках исправить ситуацию команда тратит больше своего времени, чем она бы потратила на корректный ответ субъекту. К тому же, в таком случае есть риск, что компания не сможет уладить ситуацию с надзорным органом самостоятельно и ей придётся потратить часть бюджета на привлечение сторонних консультантов.
А если команда пропустит запросы от надзорного органа так же, как и от субъектов, то в некоторых юрисдикциях, например, на Кипре, это может повлечь уголовную ответственность для руководителя бизнеса.
Как мы предложили исправить проблемы в текущем процессе реагирования?
Чтобы запросы не терялись (как это произошло с запросом на удаление в нашем эксперименте), мы порекомендовали перестроить работу службы поддержки:
- Обучение первой линии: сотрудники поддержки должны уметь распознавать слова-триггеры (например, «GDPR», «delete my data», «access request») и знать, кому передавать такие запросы.
- Логирование: необходимо вести реестр всех поступивших запросов с фиксацией даты получения, дедлайна и предпринятых действий. Это позволит контролировать сроки и анализировать ошибки.
Мы пояснили, что просто нажать кнопку «удалить» в базе данных недостаточно. Правильный процесс должен включать:
- Удаление из всех систем: данные должны стираться не только из «боевой» системы (live system), но и из резервных копий (back-ups).
- Цепочка уведомлений: если компания передавала данные партнёрам или подрядчикам, она обязана сообщить им о требовании пользователя удалить эти данные.
- Обработка исключений: если данные удалить нельзя (например, закон требует хранить финансовую отчётность 5 лет), об этом нужно прямо и аргументированно сообщить пользователю, а не просто молчать. Молчание компании может вполне сыграть с ней злую шутку.
Чтобы снизить юридические риски и нагрузку на команду, мы предложили внедрить чёткие стандарты общения:
- Шаблоны ответов: использовать заранее заготовленные юридически выверенные тексты (скрипты) для разных типов запросов, чтобы исключить самодеятельность сотрудников. Шаблоны — это удобно и предсказуемо.
- Правило «Первого касания»: хорошей практикой считается сразу письменно подтвердить получение запроса и указать дату, до которой будет предоставлен ответ.
- Уточнение запроса: если пользователь требует предоставить его данные, а данных очень много, можно попросить пользователя уточнить, что именно ему нужно. Ведь пользователь может даже не подозревать, СКОЛЬКО данных ему предоставят (хотя реально ему нужны, например, лишь данные о платежах за последний месяц). Важный нюанс: такая просьба не останавливает течение законного 30-дневного срока на ответ.
Итог: главная цель этих рекомендаций — сделать так, чтобы ответ на запрос занимал у компании минимум ресурсов, но при этом удовлетворял пользователя и регулятора.
