Про GDPR, практика (6): байдизайны, DPIA, статистика и полезное

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

Финалочка по GDPR. Начало тут https://cgvictor.ru/gdpr-2026-1.

Что за by design

Article 25 вводит этот термин, он далее у регулятора устоявшийся, применяется широко — Data protection by design and by default. Общий смысл — чтобы защита данных не была прикручена костылями сбоку «для регулятора», а некие основополагающие принципы соблюдались по всей системе.

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

Что там по сути

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

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

— повышенный уровень защиты для детей. Потому что ограничений там больше, а мозгов у пользователя меньше.

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

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

— риски. Надо ввести модель оценки рисков, и посмотреть, где вы рискуете встрять по крупному (и в каких ситуациях). Если увиденное вам не нравится и сыкотно — предпринимайте меры, снижайте риски

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

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

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

— accountability. Должно быть внятно прописано, кто ответственный в процессах, и за что конкретно. Не просто «DPO/юротдел потом разберется», а конкретные решения, конкретный импакт и набор практик (по рискам), что и как мы будем делать, если что-то пойдёт по звезде.

Так-то справедливые требования, согласитесь. Если бы все им следовали, мир был бы чуточку лучше (или как минимум спокойнее).

Какие байдизайны точно посмотреть

— Большой гайд от британского ICO https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/data-protection-by-design-and-by-default/ там много базовых штук + ссылки куда копать

— Про детей, есть раздел от ICO тоже https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/childrens-information/childrens-code-guidance-and-resources/best-interests-self-assessment/. Если кратко, то в случае, когда сервисом пользуются (или могут пользоваться) дети under the law age, необходимо сначала ввести для всех ряд «детских» ограничений, а только потом какую-то часть аудитории проверять и из-под ограничений выводить. Тема непростая, вон Дискорд недавно продолбался на отличненько. Обратите внимание, что требования региональных регуляторов (UK, US/CA) вводят требования строже, чем базовый GDPR

— Про AI, и AI-assisted сервисы есть кратенько тут https://www.wilmerhale.com/en/insights/blogs/wilmerhale-privacy-and-cybersecurity-law/20250729-ai-and-gdpr-a-road-map-to-compliance-by-design--episode-2-the-design-phase. Это пост из блога, потому что сам оригинальный документ весьма убогий https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ:L_202401689. Кратко суть — не надо пихать в AI произвольное количество юзерских данных, чтобы AI их там как-то переварил: во-первых, вы все еще пихаете куда-то на сторону третьи данные, а во-вторых, за результат работы того AI в общем-то никто не отвечает (а значит, нагибать будут вас, как автора сервиса, оператора и контроллера). Иногда полезно тоже что-то поанонимизировать, деперсонализировать и избыточного набора данных на сторону не сгружать

— вот тут есть список мест, которые заранее считаются регулятором «высокорисковыми» https://cy.ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/examples-of-processing-likely-to-result-in-high-risk/. А значит, смотреть туда (и потенциально нагибать) будут в первую очередь. Включает в себя Biometric data, Large-scale profiling, Targeting of children, Data matching, Innovative technology и прочее, что мы все так любим

— мобилки, гайд от CNIL французского — CNIL Recommendation on mobile applications. PDF есть по ссылке тут https://www.cnil.fr/en/mobile-applications-cnil-publishes-its-recommendations-better-privacy-protection (https://www.cnil.fr/sites/cnil/files/2025-05/recommendation-mobiles-app.pdf). Обратите внимание, что сейчас только версия на французском считается актуальной (only the French version is legally binding). В конце каждого раздела есть checklist; по каждому пункту теоретически к вам могут прийти из дкома и спросить, «а как у вас конкретно вот это реализуется».

— про геймдев, игровые механики и детей в этой связи (лутбоксы передают привет) https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/childrens-information/childrens-code-guidance-and-resources/top-tips-for-games-designers-how-to-comply-with-the-children-s-code/

— ISO 31700 Consumer protection — Privacy by design https://www.iso.org/standard/84977.html и его расширение ISO/IEC DTR 31700-2 (tech draft) https://www.iso.org/standard/91874.html. Там есть операционные практики и примеры (покупать документ не надо, их есть в сети и вам нейросетка запросто найдет выжимки). Если у вас стандартизация, то вполне имеет смысл посмотреть.

Нафига и как конкретно (DPIA)

DPIA это комплекс для оценки мер и рисков, касательно защиты данных — Data Protection Impact Assessment. Просторный документ на этот счет лежит тут https://ec.europa.eu/newsroom/article29/items/611236 — WP248 Guidelines on Data Protection Impact Assessment (DPIA).

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

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

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

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

Список с деталями по DPIA неплохой тут (ICO UK) https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/

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

— насколько больно, насколько часто нагибают и за что?

Ну вообще достаточно ощутимо. Вот навскидку старый репорт от Proxyrack с цифрами https://www.proxyrack.com/blog/gdpr-report/, можно поискать посвежее.

Основное нагибалово, как видно из отчета — insufficient legal basis. Это когда хреновые доки, в них чего-то нет, или написана отсебятина в надежде, что никто не будет ее читать. Нет, это так не работает: регулятор внимательно читает. Как правило, после первой жалобы. Лучше первой жалобы не дожидаться, потому что как я ранее писал, вам вполне конкурент может накатать жалобу, чтобы посмотреть как вы выкручиваться будете.

Кроме самих доков, сюда же попадает про консенты, или их отсутствие: сбор и обработка данных без спросу. Я подробно писал, там где про консенты, и там где про рекламу (обрабатывать targeted advertising с вашей стороны требует консента).

Следующее — non-compliance with basics. Вот именно поэтому мы говорим про байдизайны, у нас есть рекомендации, как должно быть сделано нормально.

Далее — insufficient measures. Это когда вы что-то обязаны делать, но не делаете, как по факту выясняется.

Следом пачка — insufficient fullfillment. Чисто процедурная процессуальная хрень, на ней запросто проебаться. Есть регламент, вне зависимости от сути и вопросов вы обязаны его соблюдать, по отношению к юзерам, запросам, регулятору итп. Нарушение регламента — само по себе отдельное нарушение, и достаточно серьезное. Даже если юзер всех заебал и хотел странного (суть никакая), но вы продолбали с ним коммуникацию и корректные ответы по существу — это залёт.

И вкусное, insufficient cooperation. Если регулятору покажется, что вы его нахер шлёте, это отдельное нарушение. Всегда, всегда держите контакт с дкомом. Отвечайте, спрашивайте, помогайте, уточняйте как сделать лучше, просите ссылки на примеры, гайды, отраслевые практики.

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

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

— почему ты говоришь «оператор» данных, когда в законе речь про контроллера?

Оператор — общий термин для тех, кто что-то с данными делает (operate). Обычно это вы сами, и те, кто согласно вашим гайдам что-то делает (и ответственность на вас, либо на вашей стороне).

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

Со стороны сервиса:

• data controller это лицо/организация, которая определяет цели обработки ПД. Может сам не обрабатывать. Но точно за всё отвечает. Он решает, «что» обрабатываем, и «зачем» обрабатываем.
• data processor тот, кто непосредственно что-то делает с данными. Чаще всего это с контроллером одно лицо. Обязанность иметь data protection officer (DPO) возложена именно на него. В его зоне ответственности ответ на вопрос «как» обрабатываем. Цели обработки он не определяет (а если определяет, то считается контроллером). Юридически процессор только оказывает услугу контроллеру, и действует по его полисям и инструкциям — это может быть важно, например, если у вас контроллеров несколько, ex. разные юрлица в разных юрисдикциях.
• sub-processor аналогично предыдущему, обрабатывает только часть данных под частью целей, может быть отдельный, действует по полисям и инструкциям
• third party + recipient любое третье лицо кроме контроллера, процессоров, регулятора и самого пользователя, которое получает доступ к данным. Поскольку в терминах закона у него тоже есть цели и объемы данных, мы вправе считать что на той стороне тоже есть свои controller+processor, а мы с ними взаимодействуем в соответствии с их полисями
• joint controller это несколько контроллеров, у которых общие цели и общий набор данных. Они могут документально прописать взаимодействие и разделить зоны ответственности.

Вот эти все, кроме third party — так или иначе операторы.

Со стороны регулятора:

• supervisor advisory сам регулятор. Это государственный орган, сам он ничего (применительно к вам) руками не делает; обычно проксирует жалобы структурам на местах, и занимается формированием политик (гайды выпускает, например). Но если требуется какой-то большой legal action, например поставить вас на аудит, назначить расследование или изьять сервера, вот это будет делать именно он — дком к нему придет
• data protection board формирует политики, гайды, синхронизирует требования регуляторов. Если вы в юрисдикции Кипра, а запрос прилетел по британскому ICO, и дком сам не справился, разруливать спор и требования будет именно board
• DPO, protection officer. Обычно ваш человек, как дата-процессора, но может случиться так, что регулятор/дком вам назначат отдельного protection officer со своей стороны
• auditors, compliance assessors внешние конторы, которые для регулятора вас анализируют (по требованиям), и готовят отчет регулятору — в рамках DPIA, например
• data commissioner, строго говоря, это глава надзорного ведомства в конкретной стране. Для вас это и есть «регулятор», в части практической. Но реально дкомов в ЕС несколько, иногда несколько в рамках страны, и чаще всего это полу-государственные коммерческие структуры (или их части), на которые регулятор возлагает ряд функций. Это удобно, потому что для вас нет необходимости бегать по большим законодательным конторам хрен знает каких стран, и кому-то что-то доказывать. Обычно на дкома возложены вообще все функции и все задачи относительно data protection, которые уже он сам разруливает, и реагирует на обращения

Что тут важно: для вас проще считать, что дком может всё, что может регулятор. Даже если что-то дком не может сделать сам, он соберет отчет и запросит необходимые операции уже у своего супервайзера. А вы будете дкому всеми силами помогать и содействовать, потому что для вас дком представляет регулятора, пофиг в какой части.

— чего может дком?

Всё, что может регулятор. Требовать предоставления любой информации. Проводить аудиты и проверки (камеральные-документальные сам, физические запросит у advisory). Получать доступ к оборудованию, через назначение officer. Выносить предупреждения и замечания. Запрещать и ограничивать обработку, на время и/ли в какой-то части. Предписывать какие-то действия — например, изменить или удалить данные. Налагать штрафы. Утверждать договорные clauses (так бывает в случае коллизий с региональными законами, см. trade laws). Выдавать заключения по дизайну, принимать или отвергать проекты. Ограничивать трансграничную обработку.

Что тут еще важно:

• дком, как представитель регулятора, обязан обработать все обращения, жалобы, нестыковки и увиденные расхождения. Он не может «просто забить», по каждому кейсу должен быть результат. Иначе взьебут уже самого дкома. Чтобы дком не выдумывал обеспечительные меры, удобно для разруливания им сразу предлагать: «хотите, можем разрешить данную ситуацию так и вот так» (и почему).
• у дкома есть право дискреции, выбора обеспечительной меры. Это то, что будет реально сделано — предписание, замечание, предупреждение, штраф на охулиард. По моему опыту, если оператор нормально идет на контакт, то дком не лютует (хотя в штрафах финансово заинтересован). Повлиять на дискрецию нельзя, ни со стороны оператора (вас), ни со стороны жалобщика — пользователь не может ныть регулятору «вкатите им штраф», будет точно так же послан. Дком решает сам.
• onestop. Операторы не обязаны общаться напрямую с различными органами и комиссиями разных стран (хотя могут), а обязаны только дкому. Который представляет все функции регулятора в заданной стране и юрисдикции.

— как проверить, что ко мне пришел именно дком?

Да, это можно и нужно делать, обязательно. Потому что речь про очень юридически значимые запросы, и про пользовательские sensitive данные.
Есть официальные списки

• https://www.edpb.europa.eu/about-edpb/about-edpb/members_en (EU)
• https://www.legislation.gov.uk/ukpga/2018/12/part/5/data.xht (GB)
• https://privacyenforcement.net/index.php/content/members (рядом)

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

— обязательно ли разжевывать юридические документы, и писать изменения к консентам?

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

Сейчас стало проще, ну припашите нейросетку в виде «сравни два документа и напиши простыми словами, что поменялось». Глазами проверьте, что получилось. Готово, вы восхитительны.

Hope that helps.

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