DPIA для согласия на cookie: когда издатели должны проводить оценку воздействия на защиту данных
Большинство издателей думают об оценке воздействия на защиту данных как о задаче соответствия для кого-то другого — сотрудника по защите данных, внешнего юрисконсульта, редкого инженерного проекта, затрагивающего биометрию. На самом деле GDPR требует DPIA для гораздо более широкого набора видов деятельности, чем понимает большинство операторов ad-tech, и многие потоки согласия на cookie и поведенческой рекламы попадают прямо в триггер. Вопрос, который регуляторы сейчас задают издателям в аудитах и расследованиях жалоб, прямой: проводили ли вы DPIA до развёртывания этого отслеживания и можете ли вы показать его нам. Это руководство объясняет, когда DPIA обязательна, что она должна содержать и как создать такую, которая выдержит проверку регулятора.
Что такое DPIA и почему она существует
Оценка воздействия на защиту данных определена в Статье 35 GDPR. Это задокументированный анализ, который контролёр должен выполнить до запуска любой операции обработки, которая, вероятно, приведёт к высокому риску для прав и свобод физических лиц. DPIA вынуждает контролёра описать обработку, оценить её необходимость и пропорциональность, выявить риски и задокументировать меры, принятые для их смягчения. Если остаточный риск остаётся высоким, контролёр должен проконсультироваться с надзорным органом перед запуском.
Для издателей DPIA — это не разовый юридический артефакт. Это центральный документ, который регулятор запросит при расследовании жалобы на cookie или отслеживание, и это документ, который определяет, может ли издатель продемонстрировать подотчётность согласно Статье 5(2). Без неё бремя доказывания решительно смещается против вас.
Когда DPIA обязательна для потоков cookie и согласия
Статья 35(3) перечисляет три явных триггера DPIA. Руководящие принципы Рабочей группы по Статье 29 (теперь принятые EDPB) добавляют список из девяти индикативных критериев. Деятельность по обработке, которая соответствует любым двум из этих критериев, считается требующей DPIA. Для потоков cookie и ad-tech наиболее релевантные критерии:
- Систематическая и обширная оценка — включая профилирование для рекламы и персонализации контента.
- Крупномасштабная обработка — измеряемая объёмом данных, числом субъектов данных, географическим охватом и продолжительностью. Сайты издателей с семизначным числом ежемесячных пользователей почти всегда квалифицируются.
- Инновационное использование технологий — охватывает снятие отпечатков, кросс-устройственную идентификацию, федеративное обучение, измерение внимания, поведенческий вывод на основе ИИ.
- Отслеживание местоположения или поведения — напрямую захватывается поведенческой рекламой и ретаргетингом.
- Комбинирование или сопоставление наборов данных — включая серверное обогащение, графы идентичности, чистые комнаты данных, сшивание платформ данных клиентов.
Типичный сайт издателя среднего уровня, который использует поведенческую рекламу и запускает более горстки сторонних пикселей, попадёт под минимум три из этих критериев одновременно. Презумпция, что DPIA требуется, на практике почти достоверность. Несколько национальных DPA опубликовали свои собственные обязательные списки DPIA; итальянский Garante, французский CNIL и немецкий DSK — все назвали программатическую рекламу и кросс-сайтовое профилирование триггерами DPIA по умолчанию.
Что должен содержать документ DPIA
Статья 35(7) устанавливает четыре обязательных содержания. DPIA, в которой отсутствует любое из них, рассматривается регуляторами как вообще не проведённая.
Систематическое описание обработки
Это не одно-абзацная сводка. Описание должно охватывать каждую категорию обрабатываемых персональных данных, каждую цель, каждого получателя, каждый период хранения и каждую трансграничную передачу. Для потока ad-tech это означает перечисление каждого поставщика в вашей строке TCF, данных, которые каждый получает, и заявленной правовой основы для каждого. Издатели, которые копируют список поставщиков TCF v2.3 прямо в приложение DPIA, произвели работоспособные документы; те, кто резюмирует его в двух предложениях, — нет.
Оценка необходимости и пропорциональности
Необходимость спрашивает, может ли та же цель быть достигнута с меньшим количеством данных или с неперсональными данными. Для потока поведенческой рекламы это означает честное рассмотрение того, служила бы контекстная реклама той же цели. Заключение EDPB 28/2024 явно гласит, что DPIA не может отвергнуть контекстную рекламу одной строкой — контролёр должен продемонстрировать, что альтернатива была рассмотрена, и объяснить, почему она была отклонена.
Оценка рисков для субъектов данных
Анализ рисков должен учитывать незаконный доступ, несанкционированное раскрытие, изменение, потерю и более широкие социальные риски профилирования — сдерживающие эффекты, дискриминацию, привязку. Для каждого выявленного риска оценка должна указывать вероятность, серьёзность и остаточный уровень после смягчений.
Меры, принятые для устранения рисков
Именно здесь платформа управления согласием появляется в DPIA. Детальный захват согласия, отказ от каждого поставщика, лёгкий отзыв, ограничения хранения, шифрование при передаче и в покое, договорные гарантии на обработчиков данных — каждая мера должна быть привязана к конкретному выявленному риску. Общее заявление, что издатель использует CMP, не является мерой.
Роль сотрудника по защите данных
Статья 35(2) требует от контролёра запрашивать совет DPO при проведении DPIA. Для издателей с назначенным DPO это просто. Для меньших издателей без него DPIA всё равно может быть проведена, но должна выполняться с задокументированным внешним советом — внешний юрисконсульт, отраслевой консультант или команда соответствия поставщика CMP. Роль DPO — оспаривать анализ необходимости контролёра, а не штамповать его.
Когда требуется предварительная консультация
Статья 36 требует предварительной консультации с надзорным органом, когда DPIA показывает, что обработка приведёт к высокому риску, который контролёр не может смягчить. На практике это редко для потоков cookie и согласия — большинство рисков можно смягчить через детальное согласие, сокращение поставщиков, ограничения хранения и договорные гарантии. Но это не ноль. Два случая, которые запустили предварительную консультацию в 2024 и 2025 годах: идентификатор на основе снятия отпечатков, развёрнутый без интеграции TCF, и кросс-устройственный граф идентичности, который объединял first-party данные со сторонними брокерами данных. Издатели, исследующие любой из этих паттернов, должны планировать срок консультации от шести до двенадцати недель.
Как регуляторы используют DPIA в расследованиях
DPIA — это единственный документ, который регулятор запрашивает первым, когда жалоба на cookie достигает стадии формального расследования. Итальянский Garante, французский CNIL, бельгийский APD и баварский BayLDA — все открывают свои процедурные дела с запроса DPIA, покрывающей рассматриваемую деятельность. Из недавних решений вытекают три паттерна:
Поздно созданные DPIA сильно дисконтируются
DPIA, датированная после запроса регулятора, не будет рассматриваться как доказательство предзапусковой оценки. Несколько решений 2025 года явно отметили, что документ был создан задним числом, и взвесили его соответственно. DPIA должна предшествовать запуску обработки, и метаданные документа или история версий должны делать это ясным.
Общие DPIA рассматриваются как отсутствующие
Шаблонная DPIA, скопированная из портала поставщика CMP без анализа, специфичного для сайта, всё чаще отклоняется. Решение Garante 2025 года против итальянской издательской группы назвало шесть из девяти сайтов в области применения и постановило, что единая общая DPIA, покрывающая их все, не удовлетворяет Статье 35.
Меры смягчения должны соответствовать тому, что фактически развёрнуто
Если DPIA описывает 60-дневное хранение cookie, но развёрнутые cookie используют 24-месячный срок жизни, регулятор будет рассматривать DPIA как неточную. Ежеквартальный аудит развёрнутой конфигурации против описания DPIA больше не является необязательным.
Собираем вместе
Для большинства издателей практический ответ одинаков: DPIA требуется, она должна быть составлена до запуска любого нового отслеживания, и она должна проверяться ежеквартально против развёрнутой конфигурации. Документ не должен быть длинным, но он должен быть специфичен для сайта, написан до запуска, одобрен DPO или задокументированным внешним советником и согласован с тем, что фактически работает в производстве. Издатели, которые правильно выполняют эти четыре пункта, превращают DPIA из бремени соответствия в самую сильную защиту, которая у них есть, когда регулятор приходит с вопросами.