DPIA для згоди з файлами cookie: Коли видавці повинні проводити оцінку впливу на захист даних

Більшість видавців розглядають оцінку впливу на захист даних як завдання відповідності для когось іншого — спеціаліста із захисту даних, зовнішнього юридичного радника, рідкісного інженерного проекту, що стосується біометрії. Насправді GDPR вимагає DPIA для набагато ширшого кола діяльності, ніж усвідомлює більшість операторів ad-tech, і багато потоків згоди на файли cookie та поведінкової реклами прямо підпадають під тригер. Запитання, яке регулятори зараз ставлять видавцям під час аудитів і розслідувань скарг, є прямим: чи проводили ви DPIA перед розгортанням цього відстеження, і чи можете ви показати його нам. Цей посібник пояснює, коли DPIA є обов'язковою, що вона повинна містити та як підготувати таку, що витримає перевірку регулятора.

Що таке DPIA і чому вона існує

Оцінка впливу на захист даних визначена в Article 35 GDPR. Це задокументований аналіз, який контролер повинен провести перед запуском будь-якої операції обробки, яка, ймовірно, призведе до високого ризику для прав і свобод фізичних осіб. DPIA змушує контролера описати обробку, оцінити її необхідність і пропорційність, визначити ризики та задокументувати заходи, вжиті для їх пом'якшення. Якщо залишковий ризик залишається високим, контролер повинен проконсультуватися з наглядовим органом перед початком роботи.

Для видавців DPIA — це не одноразовий юридичний артефакт. Це центральний документ, який регулятор запросить під час розслідування скарги на файли cookie або відстеження, і саме цей документ визначає, чи може видавець продемонструвати підзвітність відповідно до Article 5(2). Без нього тягар доведення рішуче обертається проти вас.

Коли DPIA є обов'язковою для потоків файлів cookie та згоди

Article 35(3) містить три чіткі тригери DPIA. Настанови Article 29 Working Party (тепер прийняті EDPB) додають перелік дев'яти орієнтовних критеріїв. Вважається, що діяльність з обробки, яка відповідає будь-яким двом із цих критеріїв, потребує DPIA. Для потоків файлів cookie та ad-tech найбільш актуальними критеріями є:

Типовий сайт видавця середнього рівня, який використовує поведінкову рекламу та запускає більше кількох піксельних тегів третіх сторін, відповідатиме принаймні трьом із цих критеріїв одночасно. Припущення про те, що потрібна DPIA, на практиці є майже впевненістю. Кілька національних DPA опублікували власні обов'язкові списки DPIA; Italian Garante, French CNIL і German DSK всі назвали програматичну рекламу та міжсайтове профілювання стандартними тригерами DPIA.

Що повинен містити документ DPIA

Article 35(7) встановлює чотири обов'язкові складові. DPIA, в якій відсутня будь-яка з них, розглядається регуляторами як така, що взагалі не була проведена.

Систематичний опис обробки

Це не однопараграфний підсумок. Опис повинен охоплювати кожну категорію персональних даних, що обробляються, кожну мету, кожного одержувача, кожен термін зберігання та кожну транскордонну передачу. Для потоку ad-tech це означає перелік кожного постачальника у вашому рядку TCF, даних, що отримує кожен, і правової підстави, заявленої для кожного. Видавці, які копіюють список постачальників TCF v2.3 безпосередньо до додатка DPIA, підготували придатні документи; ті, хто підсумовує це двома реченнями, — ні.

Оцінка необхідності та пропорційності

Необхідність запитує, чи можна досягти тієї самої мети з меншою кількістю даних або з неперсональними даними. Для потоку поведінкової реклами це означає чесне звернення до питання, чи контекстна реклама слугувала б тій самій меті. EDPB Opinion 28/2024 прямо вказує, що DPIA не може відхилити контекстну рекламу в одному рядку — контролер повинен продемонструвати, що альтернатива була розглянута, і пояснити, чому вона була відхилена.

Оцінка ризиків для суб'єктів даних

Аналіз ризиків повинен враховувати незаконний доступ, несанкціоноване розкриття, зміну, втрату та більш широкі соціальні ризики профілювання — стримувальні ефекти, дискримінацію, прив'язаність. Для кожного виявленого ризику оцінка повинна вказувати ймовірність, серйозність і залишковий рівень після вжиття заходів зниження.

Заходи, вжиті для усунення ризиків

Саме тут у DPIA з'являється платформа управління згодою. Детальний збір згоди, відмова від підписки постачальника за постачальником, легке відкликання, обмеження зберігання, шифрування в дорозі та в стані спокою, договірні гарантії для обробників даних — кожен захід повинен бути пов'язаний із конкретним виявленим ризиком. Загальна заява про те, що видавець використовує CMP, не є заходом.

Роль спеціаліста із захисту даних

Article 35(2) вимагає від контролера отримати пораду DPO під час проведення DPIA. Для видавців із призначеним DPO це просто. Для менших видавців без нього DPIA все ще може бути проведена, але повинна бути здійснена з задокументованою зовнішньою порадою — зовнішнім юридичним радником, галузевим консультантом або командою з питань відповідності постачальника CMP. Роль DPO — оскаржувати аналіз необхідності контролера, а не просто його схвалювати.

Коли необхідна попередня консультація

Article 36 вимагає попередньої консультації з наглядовим органом, коли DPIA показує, що обробка призведе до високого ризику, який контролер не може пом'якшити. На практиці це рідко для потоків файлів cookie та згоди — більшість ризиків можна пом'якшити завдяки детальній згоді, скороченню постачальників, обмеженням зберігання та договірним гарантіям. Але це не нуль. Два випадки, що ініціювали попередню консультацію в 2024 і 2025 роках: ідентифікатор на основі відбитків пальців, розгорнутий без інтеграції TCF, і граф ідентичності між пристроями, що поєднував дані першої сторони з брокерами даних третіх сторін. Видавцям, які вивчають будь-який із цих шаблонів, слід планувати консультаційний графік від шести до дванадцяти тижнів.

Як регулятори використовують DPIA в розслідуваннях

DPIA — це єдиний документ, який регулятор запитує першим, коли скарга на файл cookie досягає стадії формального розслідування. Italian Garante, French CNIL, Belgian APD і Bavarian BayLDA — всі відкривають свої процесуальні справи запитом на DPIA, що охоплює відповідну діяльність. З нещодавніх рішень виявляються три закономірності:

DPIA, підготовлені із запізненням, значно знецінюються

DPIA, датована після запиту регулятора, не буде вважатися доказом оцінки до запуску. Кілька рішень 2025 року прямо зазначили, що документ був створений постфактум і зважений відповідним чином. DPIA повинна передувати запуску обробки, а метадані документа або його версійна історія мають це чітко підтверджувати.

Загальні DPIA розглядаються як відсутні

Шаблон DPIA, скопійований із порталу постачальника CMP без аналізу, специфічного для сайту, дедалі частіше відхиляється. Рішення Garante 2025 року проти групи італійських видавців назвало шість із дев'яти сайтів у сфері охоплення та встановило, що єдина спільна DPIA, що охоплює всі їх, не відповідає Article 35.

Заходи пом'якшення повинні відповідати тому, що фактично розгорнуто

Якщо DPIA описує 60-денне зберігання файлів cookie, але розгорнуті файли cookie мають термін служби 24 місяці, регулятор вважатиме DPIA неточною. Щоквартальний аудит розгорнутої конфігурації відносно опису DPIA більше не є необов'язковим.

Зведення всього разом

Для більшості видавців практична відповідь однакова: потрібна DPIA, її слід підготувати перед запуском будь-якого нового відстеження та переглядати щоквартально відносно розгорнутої конфігурації. Документ не має бути довгим, але він повинен бути специфічним для сайту, написаним до запуску, підписаним DPO або задокументованим зовнішнім радником і узгодженим із тим, що фактично працює у виробництві. Видавці, які правильно виконують ці чотири пункти, перетворюють DPIA з тягаря відповідності на найсильніший захист, який вони мають, коли регулятор приходить із запитаннями.

← Блaderegistrdelays delays Читати все →