Про GDPR, практика (4): получение данных, изменение, гайдлайны

Мы тут уже в середине истории, ранее в нашем сериале про GDPR было: про документы и регулятора, про консенты и идентификации, про удаление, деперсонализацию и UGC. Если вся тема вам важная, лучше их тоже впитать, чтобы вам было понятнее, а я не повторялся.

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

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

Article 15 GDPR, Recital 63 — это «право доступа» (Right of Access). Основная цель реализации такого права пользователем — проверить законность обработки (и объемы обрабатываемого). Именно на это фокус. Предоставить такие данные оператор обязан всегда, вне зависимости от консентов. Причем в понятном пользователю виде.

Article 20 GDPR, Recital 68 — это «право на переносимость» (Right to Data Portability). Основная цель реализации — обеспечить получение объема данных для использования извне, то есть, избежать vendor lock. Предоставлять такие данные оператор обязан не всегда, а только если с пользователем есть договорные отношения (то есть, получены консенты). Обязательные к предоставлению только сами данные пользователя, то что он нам предоставлял; свои собственные можно не отдавать. Формат подходит любой машиночитаемый.

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

Чем больше пользователь будет способен понять — тем меньше доебется до регулятора/дкома — меньше вопросов и текстоговорильни.

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

Да, это говорит о чьей-то, возможно, профнепригодности. Но имеем что имеем: пойти и купить отдельного GDPR-юриста с актуальной практикой — это дорого и искать надо. Путь хороший, но теоретический.

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

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

Продлевать крайне сложно, обоснования и оправдания регулятор не любит. Месяц и всё. Ну и пофиг, собрать данные обычно не настолько критичное и сложное действие (как удаление).

Я делал как: аналогичное устройство

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

Регулятору норм.

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

Но делали и способ проще: когда под заявку выделяется файлопомойка, S3-бакет, в который источник сам должен пойти и сложить своё добро. Бакет одноразовый, у него ограничен доступ, и мы точно знаем а) данные все лежат вот тут и б) гарантированно потом его автоматизированно прибьем.

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

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

Про понятность

Понятность от нас требуется по Статье 15. Без нее в A15 нельзя.
Чего там хотят, в общем, как сводный рецепт:

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

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

Разделять ли A15 и A20

Операционно проще делать сразу оба. Но ряд требований у статей отличаются, и для каких-то систем это отличие может быть критичным. Особенно в части дополненных данных: observed data, inferred data, derived data.

Требования A15 в этом смысле жестче, надо отдать всё что отдается, ограничивать можно только по A15(4) «коммерческая тайна». Дополнительные данные могут быть коммерчески значимыми, и вашей развесистой интеллектуальной внутрянкой, которая вам денег стоила.

Если вы обрабатываете данные на законном интересе (LIA) — у вас нет обязанности по переносимости (A20), но есть полная обязанность по доступу (A15).

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

Форматы и объемы

То, что однозначно подпадает под A15, сами анкетные данные, и то что пользователь сам нам давал — должно быть в человеко-понятном виде. Документы, HTML ok, PDF ok, ссылки на сорцы медийки, исходники документов/файлов.

То, что подпадает под A20, может быть в машиночитаемом виде, в том виде, в котором вы сами это используете. JSON, XML, CSV нормально.

Требуется обеспечить только машиночитаемость (и переносимость), то есть отдавать шифрованный JSON нельзя, критерий читаемости не выполняется. Отдавать гигаметры json можно, вы же сами их ровно так из системы получаете. Практика есть в WP29/WP242 .

Лайфхаки, кратенько

• можно не отдавать «вторичные» данные, а только указать где брать. Если у вас 100500 записей из базы про фотки пользователя, можно отдать только 100500 записей метаданных и ссылки на исходники (например на CDN), по ссылкам пускай сам ходит качает, можно не паковать это в гигаметровый архив
• хорошей идеей будет приложить (статическое) описание формата в минимальном виде. Типа «вот тут лежат данные о фотках — формат JSON, UTF8, уникальный айдишник, оригиналы медиа по ссылкам вот в таких полях». Это не обязательно, но если регулятор/юзер/дком захотят доебаться, то доебутся меньше, а вы заранее молодец
• если по какому-то срезу требуется «человеко-читаемое» описание по A15, ну сделайте процессинг JSON в html по простому шаблону, и положите рядом. Файл читаемый? Читаемый, окей.
• вы не обязаны предоставлять данные, которых у вас в системе нет, сбор которых потребует лично от вас дополнительных затрат и внешних телодвижений. Например, ходить в системы третьих лиц. Решается описанием в тексте + ссылка на полиси + куда ходить самому
• вы не обязаны предоставлять данные, если их сбор и процессинг носит чисто технически-функциональный характер, не применяется к конкретному юзеру/любому юзеру в отдельности, и даже не описан в целях обработки. Так можно убрать (например) потенциальный сбор логов доступа с серваков, кому эти портянки нужны, если они никаким целям пользователя не служат (они для вас), и сами помрут через 30 дней
• вы не обязаны предоставлять данные, если они не имеют отношения к данным пользователя И к целям обработки одновременно. Это про всякую внутрянку, где для ваших собственных целей живет, например, только ID аккаунта. Формально это данные пользователя, но смысл того ID только в получении анкетных данных, других персданных там нет, и контента нет — а анкетные по ID вы уже и так дали. Вычеркиваем, ничего дополнительного там нет.
• но если у вас «по айдишнику» инфа об осмысленных действиях пользователя, лучше оставить, тк тут на тоненького (см дальше про observed)
• вообще базовый принцип, «если юзер что-то может сам увидеть в системе, применительно к себе — лучше это дать». Потому что потом он чего-то не увидит в выгрузке, и пойдет нудить, рря-атата, вот мне вон там не дали. Оно вам не надо.
• дополнительно как-то процессить данные вы можете, но не обязаны.
• единственное, чего обязаны — это вычистить (или не отдавать) данные, где явно затронуты другие физлица, пользователи и их персданные. Здесь же читать про balancing test, реализация юзером своего права не должна ущемлять ни интересы третьих лиц, ни ваши коммерческие интересы. Это неплохо указать в полисях и документах, закон вам такое право дает (тоже A15).
• если информация раскрывает алгоритмы, исходники, торговые секреты итп — можно не отдавать. Но это надо обосновывать.
• отдать инфу по A20, запихав ее в какой-нибудь PDF, с идеей «заебутся парсить!» — нельзя, нарушение машиночитаемости по A20

Observed data (логи, клики)

Observed это инфа, связанная с действиями пользователя. Здесь были изменения.
Канва примерно следующая сейчас:

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

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

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

Коммерция

Коммерцию надо давать. Но только ту, которая непосредственно связана с пользователем и его активностью. Списки покупок, платежей итп — однозначно надо. Внутренние идентификаторы процессингов, ваши комиссии, взаимодействия с контрагентами в этой связи — исключаем (или не даем, или вычищаем, редоцирование допускается).

Всякие inferred/derived данные надо давать, потому что A15. Но — хачок — только если вы их у себя храните, и только в этом объеме. Если у вас, допустим, есть система внешнего скоринга (не ваша), которая что-то знает про пользователя, и вы оттуда берете его профиль — вот этот профиль надо дать, в том виде, в котором он у вас есть. Исходные данные, чего там скоринг сам себе думал и чего как обрабатывал — можно не давать, отправить пользователя туда, пускай сам разбирается, тк у вас этих данных тупо нет, а ходить доставать их вы не обязаны (может и вовсе не можете).

Contrib + UGC

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

Из неструктурированных хранилищ, типа почты, вообще строго говоря, тоже «надо давать». То есть, дамп емейл-переписки, например. Или созвоны из CRM по номеру телефона лида. Здесь актуальны все грабли, описанные в предыдущей статье, про неструктурированные помойки. Но если у вас есть описанная полиси, по которой вы не обязаны хранить почту свыше 30 дней, например — можно и лесом послать.

Обычно прокатывает, только убедитесь, что пользователь не сможет вам доказать обратное. Например, если ему вчера продажи написали «мы вашу переписку за 2 года подняли», а сегодня вы ему пишете «данные есть только за 30 дней» — одна из черепашек явно говорит неправду, и вы скорее всего окажетесь в жопе перед дкомом/регулятором. Это проблемно.

Деньги

Деньги брать нельзя. Можно только в случаях, когда вы сможете подтвердить ваши дополнительные затраты (но это решаемо). Как правило, достаточно после выполнения запроса в его основной части, если юзер настаивает, сказать что остальное потребует вам вот таких ориентировочных затрат, сумма может вырасти по ряду причин, включая проверку юридической чистоты нетипового запроса. Вот ценник на технарей, в часах, вот ценник на юристов, было бы предложено. И вот таких сроков. О чем уведомить и юзера, и дкома/регулятора. На этом, скорее всего, всё и закончится.

Просто писать «вот это мы делаем через кассу» нельзя; Гугл поначалу в 2018-2019 так пробовал, все поржали конечно — им это сильно помогло, сам факт прописывания цены — но потом регулятор сказал что нет, так у нас не принято. Можно выполнить ряд действий, а потом сказать что остальное будет через кассу: так можно.

Право на изменение данных

Редкий запрос, я такие на своей памяти видел штучное количество раз вообще. Это Article 16. Юзер вам пишет, что вот такие данные в системе он хотел бы либо исправить на свой вариант, либо дополнить. В ряде случаев такой запрос приходит следом за A15, когда он данные себе получил, и что-то там занимательное увидел.

Срок дается месяц (30), продлевать проблемно, считаем что нельзя.

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

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

Второе что вы делаете — спрашиваете основание. Запрашивать единственно возможный документ нельзя (хотя обычно очень хочется). Можно спрашивать основание из числа разумных/reasonable доказательств, с учетом вашей юрисдикции (это хак). Основание все еще должно соответствовать целям обработки.

Дальше просто ситуативные хаки

• вы можете принять какое-то изменение от юзера, но вы совершенно не обязаны принимать его как факт далее внутри себя и своих систем. Вы можете приложить его документом, как supplementary statement а потом забить болта
• также обязаны принять изменение, но не обязаны удалять какие-то старые данные в этой связи, и править всю историю вопроса. Мнение юзера фактом не является, будет просто рядом лежать
• вы можете и даже должны уведомить всех заинтересованных лиц, чьи права могут быть затронуты в этой связи — см пример про историю покупок
• момент «в нашей системе такое изменить нельзя» в общем случае нет, не прокатывает. Потому что дизайн системы разрабатывали вы сами, это ваша сфера ответственности. Гуглите юридическую практику про GDPR и блокчейн (который заведомо неизменяемый). Но технически вы правку пользователя принимаете, к себе фиксируете, соглашаетесь что вы молодцы, а потом придумываете как бы это всё дальше использовать в вашем зоопарке
• пользователь должен явно понимать, что с его запросом происходит. Что его приняли, как его поняли, что поменяется, какие меры будут приняты, когда они приняты. Просто принять к сведению и отмолчаться — нельзя, были штрафы за подобное. Даже если вы юзеру отказываете нафиг, вы все равно должны на каждый его спам ответить что нет, приняли, рассмотрели, делать не согласны, вот почему. Можно пожаловаться дкому, если у вас есть его контакт, пусть будет в курсе.
• в этой же связи, нарушение самой процедуры = это все еще грубое нарушение, отдельное плохое, даже если от вас хотят какую-то херню
• можно отказать, если налицо злоупотребление правом: юзер хочет какую-то правку, чтобы получить неоправданный (на ваш взгляд) бонус или привилегию. Поэтому ходим и выясняем цели. Подробнее хорошо есть в гайде тут
• все правила по идентификации все еще действуют. Вы не обязаны менять чувствительные данные по требованию произвольного нонейма из почты, тем более если эта правка потенциально затронет кого-то еще

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

Гайдлайны

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

На гайдлайны смотят регулятор и дкомы, надо посмотреть и вам. Нейросетки вам их запросто найдут, они все публичные (навскидку, вот)

Что может вам помочь

— Guidelines 3/2018 — про то, что такое территориальный scope, кто подпадает под закон, кто может от вас что-то захотеть
— WP242 — про отдачу данных и переносимость (A15 A20), как раз то о чем выше написано. Как быть с юрисдикциями, в Guidelines 2/2018 есть
— WP260 — про то, как писать доки, и про transparency
— Guidelines 2/2019 — про то, что подпадает под «необходимые нам данные по договору», и что туда нельзя включать без спросу
— Guidelines 4/2019 — байдизайны, как спроектировать системы так, чтобы потом не получить пиздюлей «ну, оно у нас просто вот такое по факту». Про байдизайны видимо потом отдельно поговорим
— Guidelines 05/2020 — про консенты, почему implied consent и «ты не ушел, значит согласен» использовать нельзя
— Guidelines 08/2020 — рекламное и третьи лица. Видимо, тоже рассмотрим рекламу отдельно

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

Только один вопрос кратенько, из прошлой темы

• почему деперсонализация, когда закон прямо пишет про удаление (erase)

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

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

Hope that helps.