Про GDPR, практика (2): консенты, запросы от дкома, identity check

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

Итак, в прошлой части я рамочно проговорил про доки. Главный это дата полиси. А в нем главное, для вас практическое — работающий ваш контакт Data Protection Officer, или хотя бы юротдела (в котором типа есть DPO).

Дока и контакт это базовая точка старта во всей этой истории, без нее никак. Надо идти и делать, если вы еще нет.

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

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

И вот туда, в механики и инструменты, пытаетесь зарулить абсолютно-подавляющую часть GDPR-related задач.

Бодалово «на руках» по каждому GDPR-запросу запросто выжжет вам весь саппорт и юротдел, это раз. Типовые задачи по данным должны решаться типовыми механизмами, и мы о них поговорим.

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

Да, вы должны делать достаточно много, но не обязаны реализовывать чьи-то нетиповые фантазии. Дком об этом в курсе.

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

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

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

~~На суде зачтется.~~

Как правило, такие ситуации и бодалова, где все нормально с коммуникацией, выливаются далее просто в рекомендации «сделайте там у себя еще вот такую штуку, на всякий», и на этом всё.

Точно не штраф и не суд.

От коллег знаю, что вроде как бывают ситуации «сразу горчичник». У меня не было. Типа, когда прилетает сразу подписание, выглядит грозно.

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

Написать надо обязательно. У нормального горчичника указаны все юридические контакты, вплоть до персональных с ФИО. Проверяете их в сети, списки контор которые могут действительно от вас что-то захотеть — описаны по странам и регионам. Пишете туда.

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

Но чаще проще, есть куча мошеннических контор, которые маскируются под регулятора/дком, и просто разводят на бабло. Берут на испуг. Нормальный запрос может быть сходу горчичником только в одном случае: если по вам уже была рассмотрена ситуация, и комиссией вынесено решение не в вашу пользу. Либо судом, на котором вас не было. Значит, надо и ситуацию, и комиссию, и решение вам показать. Если этого нет — идут лесом. Разводил очень много, как и везде.

В тексте письма можете аргументированно засомневаться, что описанное вас касается, и запросить идентификацию. Имеете право, рекомендую всегда так и делать для старта.

Про идентификацию юзеров дальше будет, там много и важно.

Ограничения передачи + ограничения коммерциализации (do not sell)

Передача в данном случае касается «кому передача» — речь про «третьих лиц», в основном, и о других юрисдикциях в частности.

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

Должны быть прописаны цели — это два. Обычно они как-то связаны или с целями самого продукта/сервиса, то есть смысл этой передачи польза для юзера или сервиса. Или нужны для бизнеса и своей коммерциализации, это тоже нормально, но должно быть указано, чего достигаем и для кого. Например, вы передаете персдату в скоринг, чтобы уменьшить свои финансовые риски. Окей. Юзерам может и не нравится, но регулятору с этим норм, бизнес есть бизнес.

Вроде пока канает конструкция «мы передаем данные своим бизнес-партнерам», по закрытому конечному списку. Но будьте готовы, что придется что-то показывать и обосновывать, по запросу дкома. Просто кому попало чего угодно — нет, нельзя.

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

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

А сервис = ваш. Крайние за этот факт = вы.

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

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

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

Базовый вариант всегда смотрите как «отказ в сервисе». Вот есть условия, на которых сервис предоставляется (eula-tos-priv-contrib + DP), в вашем конкретном случае, если не нравится можем не предоставлять — это норм. А вот «подкрутите вот там для меня лично» или «хочу то же самое, но на других условиях» — уже не норм.

Если вы к этому прилагаете хоть какую-то внятную аргументацию — например, интересы других пользователей, безопасность, стабильность — дкому придется встать на вашу сторону, т.к вы в своем праве.

Просто так отказать в обслуживании или в реализации права нельзя. Аргументированно — можно.

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

Консенты (согласия), consent

Консентом в широком смысле обозначается факт согласия пользователя с каким-то предписанием, условием, политикой или ее изменением. Консенты бывают given or implied: либо пользователь явно согласился, либо его согласие вытекает из его действия или бездействия.

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

Беда, как обычно, в нюансах.

Что, если мы с пользователем уже взаимодействуем, он нам уже там какие-то данные шлёт (сам, без спросу), а документально это никак не оформлено — м?

Что, если пользователь и не собирается иметь с нами договорных отношений, но ему не нравится, например, рекламная аналитика и таргетинг?

Что, если пользователь был согласен с прошлой версией оферты/политики, а потом перестал, что в таком случае происходит с его данными и его правами в этой связи — ?

Пока, для простоты, примем что:

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

Если вас с юзером связывают договорные отношения — это хорошо, вы (или он) их можете прекратить, если что-то не нравится. Нюансики есть, но канва такая.

Если вас с юзером отношения не связывают, но вы что-то делаете, а ему не нравится — должны быть описания, что делать для реализации прав.

Обычно второй пункт, как более мутный сводится к следующему ответу:

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

Вы не просто шлете пользователя нахрен (потому что это какой-то нонейм который даже не ваш), а даете ряд способов, воспользоваться которыми он вполне может и в своем праве. Удобные, неудобные, это уже другой вопрос. Это не для него, это больше для регулятора с дкомом. Способ надо предоставить? Способ был.

Про идентификацию лайфхак ниже.

Консент трекинг

Для тех, кто в договорных отношениях (ваши пользователи), надо уже отслеживать, кто там с чем согласен

Документы и их версии. Если вы меняете документ, это еще не значит автоматически, что «юзер не видел нового, нет консента, значит ничего нельзя». В принципе, иногда можно.

Но поскольку implied consent нам точно нельзя, вы должны пользователя адекватным способом уведомить — раз, этот консент у него запросить — два, и например сказать, что вы ограничите его в использовании сервиса, через время, пока/если консент получен не будет.

Говоря формально да, ничего, что прописано в «новом» документе и новой редакции, без спросу и без консента обычно нельзя. Вопрос к тому, а что там поменялось, суть захода. Того, что в значительной степени меняет права и возможности — точно нельзя. Также нельзя поставить заранее галку юзерам «эти согласны», и попросить снять — на opt-out очень косо смотрят отн.того, что регулирует закон.

Мы успешно делали так:

у юзера, по каждому типу документа, есть финальная версия, которую лично он акцептил. С датой акцепта, логами, тут понятно. Языком, кстати, т.к перевод не везде равен документу.
у документов, соответственно, есть версии. В какой-то момент версия документа обновляется, становится самой свежей — надо идти просить юзеров согласиться + посмотреть изменения
в доках зашито, что на акцепт дается 30 дней
если юзер к нам приходит, и мы видим, что текущая версия у нас новее, чем-то что акцептил он — и с момента выкатки новой 30 дней не прошло — вешаем ему надоедайку, иди галку ставь
если та же ситуация, но с момента появления новой уже 30 дней, а акцепта всё нет — софт-лок, надо идти и принять условия, это важно
если прошло больше 60 дней, аккаунт юзера понижается в правах, выкидывается из статы как неактивный (а где он там 2 месяца морозится), убирается из рекламной-аналитической выборки как неактивный
и с какого-то момента просто лочится, замораживается. Это все еще юзер, но а) явно не активный и б) нам юридически проблемный

Хорошей идеей будет у себя отрастить эти три механизма:
— юридические документы, их доступность и их версионность
— консент-трекер, который знает, кто там на что соглашался
— механизм проверки консентов, запроса недостающих, и софт-лока

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

Например, do not sell тот же самый; если вы и так не коммерциализируете пользователя, не продаете данные итп, то эта галка вроде бы ни на что не влияет; но.

Вам может юзер предьявить, что про это нигде не написано. Вам может регулятор предьявить за то же самое. Если вы вдруг окажетесь в ситуации, которая подпадает под do not sell, у вас не пройдет комплаенс. Если вдруг кто-то третий по вашим данным будет статистически делать коммерческое использование, это тоже залёт.

Ну и зачем вам всё это потенциальное бодалово?

Право на DNS не касается агрегаций, сводных и вторичных данных.

Коммерциализировать сами данные пользователя, анкетные, без спросу нельзя, это понятно. Но здесь можно opt-out по еуле — та самая do not sell
Продавать статистику, сколько там кого в нашем миллионе — можно, там нет персдаты, права не нарушены.
Продавать таргетинг — нельзя, если он не когортный, то есть позволяет докликаться до конкретных юзеров (на это Гугл напоролся в 2024).
Продавать эстимейты можно — аудитория в 47 конкретных Васянов это атата, а аудитория в примерно около 100 Васянов — уже нормально.

Тут пускай юротдел идет курит практику.

Давайте еще расскажу хак про идентификацию, потому что и так простыня. Механизмы потом.

Лайфхак: идентификация

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

Конкретно это прописано в 12(6) GDPR. Если контролёр имеет обоснованные сомнения относительно личности физического лица, подающего запрос, контролёр может запросить предоставление дополнительной информации, необходимой для подтверждения личности субъекта данных. Можно еще посмотреть preamble 64 и почитать тут и тут.

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

Отсюда видно, что это exploitable, это можно абузить и эксплуатировать)) Мы не будем ничего делать, пока нам юзер не принесет справку по форме-9, скан паспорта кота, и анализ крови выполненный аккредитованной организацией, не позднее 3х дней, по месту регистрации.

Совсем откровенные абуз-фильтры регулятор может попросить убрать. Да, они за 7 лет тоже прекрасно в курсе этого хака. Reasonable там не просто так написано.

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

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

Это лайфхак, потому что крутой разрешенный фильтр.

Это отсекает 80% васянов, которые будут писать херню и жать кнопочки, просто чтобы поприкалываться и «посмотреть, как это работает».

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

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

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

Если дком спросит — вы ревностно относитесь к безопасности, вот и всё.
То, что будет проверка — вон в доках написано, всё честно.

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

Еще полезно предусмотреть cooldown. Закон дает вам такое право, примерно с той же целью, провести дополнительные проверки, убедиться — заодно выиграть себе времени и возможностей. Пример:

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

Из моей практики, вот эта последняя строчка вызывала внезапно тонну и массу вопросов.

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

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

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

Например, в почту регулятору, ага.

А ему нужно было — просто аккаунт обнулить, чтобы начать/продолжить пользоваться с чистой системы, с нуля. Ну так бы и сказал сразу.

Если такая опция «с чистого листа» возможна, не поленитесь, пропишите это в документах. Никакой юридической ответственности нет, и можно предусмотреть нормальные человеческие средства — например, undo, мульти-аккаунтинг (одна почта разные акки), всякие тестовые песочницы итд итп. А не GDPR-танцы.

С запросами канва примерно такая:

Зафиксируйте запрос и оцените его контекст, кто там и чего хочет
Решите, нужна ли проверка: есть ли у вас «разумные сомнения»?
Выберите соразмерный метод проверки (для ваших юзеров и васянов из емейла путь будет разный)
Запросите информацию у юзера или представителя, чётко объяснив причину
Подтвердите личность, полномочия (представитель, опекун, адвокат) и далее выполните запрос в соответствии со своими полисями
Документируйте процесс (почему и как проверяли) для демонстрации соответствия принципу accountability

В третьей части будет про механики, про деперсонализацию и чо можно/чо нельзя. Печатать задолбался.

Hope that helps.