Про GDPR, практика (1): закон, регулятор, data policy

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

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

Началось с европейского GDPR в 2016, который стал обязательным в 2018. И к 2019 надо было начинать ему соответствовать. До последнего момента вся индустрия оправданно нихера не делала, подозревая что еще ничего не понятно, «пускай сначала примут, а там поглядим», может еще переобуются. Не переобулись. И с горящей жопой та же индустрия побежала это раскуривать. Собрали все шишки, которые были. Как и я, мы оказались одним из крупнейших дата-операторов в отрасли (100+ миллионов юзеров), а я типа за это крайний.

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

GDPR, европейская дата-регуляция, вас касается если

• у вас бизнес в Европе (тут понятно)
• у вас есть представительство в Европе (тоже понятно)
• если у вас пользователи из Европы (эммм…)
• если вашими продуктами и сервисами хотя бы теоретически может воспользоваться гражданин Еврозоны

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

Должен причем много. 20 лямов зелени за залёт, либо штраф от оборота (до 4%), в зависимости что будет больше. Риски «несоответствия GDPR» таким образом уже достаточно серьезные, чтобы от них просто так отмахнуться. Можно на этом и закончиться, как бизнес.

Послать его фхер нельзя. Это наказуемо.

Страшно? Ну, неуютно точно. Давайте разбираться.

Чо за это будет

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

Комиссионер действует в жестких рамках, им не «всё можно». Но комиссионер имеет со штрафов комиссию себе. Иногда до 25 процентов. И несложно заметить, что если комиссионер вас нагнул на $20 млн, то положит себе с пола в карман $5 млн — за это можно и пободаться, согласитесь. То есть, ребята там замотивированные.

Если вы в еврозоне — понятно, штрафы.

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

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

И да, экстерриториальность и у остальных тоже. Хер знает, как должно работать в каждом конкретном случае, но заявлено.

Значит, перспектива судебного бодалова, по МЧП. Это долго и дорого.

Чо хотят

Основных геморроев и требований в своде законов можно выделить 5

1. Право на забывание. По требованию, надо перестать обрабатывать данные конкретного Васяна, забыть его нахрен, а потом забыть что ты его забыл.
2. Право на получение своих данных (право на доступ). Тут попроще, если хотят — надо дать. Чего дать и как — это уже детали.
3. Ограничения передачи. Должно быть исчерпывающе понятно всё, что там про «третьих лиц» и кому данные уходят. Соотв чем оно регулируется, кто крайний и как запретить.
4. Различные права на ограничения сервиса. Чувствительную инфу надо уметь хранить, не палить наружу (очевидно) и даже внутри себя, не использовать чувствительную инфу (раса пол гео итп) для внутренних ограничений в продуктах и/ли сервисах.
5. «Право знать» и контакты. Это самый важный пункт для вас на старте, хотя и самый несложный в реализации (это просто дока, но важная), далее с него и начнем наши рецепты.

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

Что за данные

Честно говоря, любые. Всё что может быть прямо или косвенно отнесено к конкретному физическому лицу.

• Понятно, что вся персональная инфа — имя, емейл, телефон, адреса, явки, клички, урлы — с ними очевидно. Документы, фотки, KYC тем более.
• Все персональные идентификаторы — айдишники, номера аккаунтов, референсные ссылки на контент — тут чуть менее очевидно, но если по ним можно однозначно понять физлицо, то подпадает.
• Косвенная идентификация — должность, роль, тикетка — если по какой-то паре признаков можно определить, что речь идет о конкретном лице. Тут посложнее. Например, логи: если можно по логам узнать что вот этот IP + вот это время = конкретный актор, значит, считается.

Проще считать, что почти всё.

Что можно исключить

То, что касается вашей коммерческой деятельности и/ли коммерческих интересов, а также составляет в какой-то степени коммерческую тайну. Например, это бухгалтерия, покупки и платежи.

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

Еще можно исключить те данные, обработка которых потребует от вас несоразмерных затрат. Тут на тоненького, потому что это придется обосновывать. А комиссионер вообще играет на стороне пользователя, финансово замотивирован, так что аргументы должны быть железобетонными, чтобы выдержать арбитраж в суде. Просто «нам лень в логах копаться» не прокатит.

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

Поехали по списку, чего в каждом случае надо делать.

Право знать и контакты

Самое важное для вас. Потому что регулятор и комиссионер будут смотреть в первую очередь именно на это.

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

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

Регулятор в 2026 может прямо потребовать, чтобы вы назначили представителя по GDPR в европейской юрисдикции. Есть конторы, которые такую услугу предоставляют, в принципе. Но как только вы его назначите / отдадите на аутсорс, это означает что и соответствовать + встревать придется по полной схеме. Отказ грозит вам только бодаловом и потенциальной блокировкой (вряд ли), надо смотреть что геморройнее.

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

Отмалчиваться нельзя. Не коммуницировать с пользователем нельзя. Слать нахуй нельзя. Комиссионера тем более. Тут как с налоговой: если вовремя не очнулся, получишь сходу горчичник, и ебись потом сам.

Если письмо регулятора/дкома ушло в спам… ну… чья то беда, угадайте.

Состав данных и полиси

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

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

Если вы данными делитесь, или обрабатываете сторонними силами, надо указать — что, кем, и как. Если применяются дополнительные документы (100% это так), надо указать ссылки на связанные дата-полиси.

Что еще лучше указать

Лайфхак-раз. В законах есть некоторый зазор в прописанных деталях ваших взаимодействий и правил. Их лучше указать «в свою пользу» в своем документе, чтобы далее использовать по-максимуму. Если этого не сделать, то комиссионер будут что-то там с пользователем выдумывать на лету, а вам вариантов не останется. Лучше прописать.

— сроки. Вы можете запросить до 30 дней на первичную обработку, причем с оговорками (на всякие кросс-проверки), и до 90 дней на реализацию. Рекомендую, во-первых, именно так и сделать; во-вторых там же прописать, что конкретно и в какие тайминги будет происходить, а также до какого момента ничего происходить НЕ будет — потому что операции иногда критические, их надо перепроверять. Больше срок, вам проще.

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

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

— идентификация. Самое веселое: для того, чтобы обрабатывать запросы пользователя, пользователь должен явно и однозначно убедить вас, что он тот, за кого себя выдаёт, и в том, что он имеет на это право. Об этом напишу ниже (upd читать тут), там полезное; в документе на этом этапе должно быть написано, что перед тем, как что-то делать руками, вы будете проводить проверку identity. И даже запрашивать документы, по вот такому списку. Если юзер список предоставлять не хочет — он может воспользоваться автоматизированными способами, на общих основаниях и не ебать вам + дкому голову.

Делать это отдельным документом, или включать в существующие — без разницы, смотрите сами. Кто-то пихает в privacy policy, кто-то делает отдельную data-policy, кто-то объединяет с cookie policy. Главное, чтобы всё перечисленное было в наличии.

Главное — написанные и работающие контакты + коммуникация. Там самое критичное. Все сложные случаи, разборки, тупняк, влажные фантазии все равно отправятся туда.

Ходить самому к регулятору, и говорить «вот мы красивые» — не надо и некуда. Им пофиг, у вас контакт должен быть в наличии, и всё на том.
Понадобитесь — найдут. Как с налоговой, короче.

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

Регулятор и коммиссионер сами по себе к вам не придут. За очень редким исключением, им без основания запрещено.

Stay agile.

Когда начиналась вся эта байда, в 2019 все конкурентные игроки рынка (включая нас) пошли, и запросили друг у друга по GDPR всю возможную обработку))) чтобы смотреть, у кого чего сделано, как устроено, и передрать лучшие практики)) давно индустрия так централизованно и быстро не вырабатывала рабочие решения и правила игры. Голландский, блин, штурвал. Или бельгийский.

Зато все со всеми перезнакомились.

Права на ограничения

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

Если про явные ограничения и «так нельзя» (пол-возраст-итп) уже много написано ранее, и с ними всё понятно; то еще могут прибежать ныть и жаловаться на какие-то ограничения неявные. Чаще всего выдуманные, мало ли городских сумасшедших на миллионной юзербазе.

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

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

Реализация прав и разруливание кейсов обычно сводится к корректному, вежливому ответу что:

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

Статистическую информацию, которая вам нахрен не нужна и валяется где-то в data lake и/ли бекапах, лучше не хранить свыше 30 дней, как минимум без обработки (шифрование, выкидывание лишнего). По ряду причин, в этом и в других пунктах тоже. Не хранишь = не используешь = не проебешь. И опять же, не используйте естественную инфу, используйте ID юзера, он у вас и так есть. Его можно деперсонализировать, расскажу.

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

Блин, опять простыня выходит, разобью текст.

Здесь неплохо пойти, инвентаризовать ваши документы. Обычно их 4 штуки:

• EULA — соглашение об использовании, чего дают и на каких условиях;
• TOS — правила сервиса, чего можно и чего нельзя;
• Privacy — как происходит обработка данных, в какой юрисдикции и чем регламентируется;
• Contribution/UGC policy — как используется то, что юзера сами приносят в сервис, и что там с правами.

Почему эти документы важны именно в конкретном составе, я расскажу в части про трекинг консента и про сами консенты (consent).

Куда запихнуть дата полиси, возможно сделать отдельным доком, или впихнуть в прайваси — смотрите по амбициям и аппетитам. Больше бумаги = чище жопа.

Hope that helps. Следом продолжим, про мякоть и технические решения.

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