DPIA за съгласие с бисквитки: Кога издателите трябва да проведат оценка на въздействието върху защитата на данните

Повечето издатели смятат оценката на въздействието върху защитата на данните за задача по съответствие за някой друг — длъжностното лице по защита на данните, външния юрисконсулт, рядкия инженерен проект, свързан с биометрика. В действителност GDPR изисква DPIA за много по-широк набор от дейности, отколкото повечето оператори в рекламните технологии осъзнават, и много потоци за съгласие с бисквитки и поведенческа реклама попадат точно в обхвата на задействащите условия. Въпросът, който регулаторите сега задават на издателите при одити и разследвания на жалби, е директен: проведохте ли DPIA преди да внедрите това проследяване и можете ли да ни го покажете? Това ръководство обяснява кога DPIA е задължително, какво трябва да съдържа и как да изготвите такъв, който да издържи проверката на регулаторите.

Какво е DPIA и защо съществува

Оценката на въздействието върху защитата на данните е дефинирана в член 35 на GDPR. Тя представлява документиран анализ, който администраторът трябва да извърши преди стартирането на всяка операция по обработка, която е вероятно да доведе до висок риск за правата и свободите на физическите лица. DPIA задължава администратора да опише обработката, да оцени нейната необходимост и пропорционалност, да идентифицира рисковете и да документира мерките, предприети за намаляването им. Ако остатъчният риск остане висок, администраторът трябва да се консултира с надзорния орган преди пускането в действие.

За издателите DPIA не е еднократен правен артефакт. Той е централният документ, който регулаторът ще поиска при разследване на жалба, свързана с бисквитки или проследяване, и документът, който определя дали издателят може да демонстрира отчетност по член 5(2). Без него тежестта на доказване се измества решително срещу вас.

Кога DPIA е задължително за потоци за бисквитки и съгласие

Член 35(3) изброява три изрични задействащи условия за DPIA. Насоките на Article 29 Working Party (сега приети от EDPB) добавят списък от девет ориентировъчни критерия. Дейност по обработка, която отговаря на два от тези критерия, се предполага, че изисква DPIA. За потоци за бисквитки и рекламни технологии най-релевантните критерии са:

Типичен сайт на издател от средно ниво, използващ поведенческа реклама и управляващ повече от шепа пиксели на трети страни, ще отговаря едновременно на поне три от тези критерии. Презумпцията, че DPIA е необходимо, на практика е почти сигурност. Няколко национални надзорни органа за защита на данни са публикували свои собствени задължителни списъци за DPIA; италианският Garante, френският CNIL и германският DSK са посочили програматичната реклама и профилирането между сайтове като задействащи условия по подразбиране за DPIA.

Какво трябва да съдържа документът DPIA

Член 35(7) определя четири задължителни съдържания. DPIA, в което липсва което и да е от тях, се третира от регулаторите като изобщо непроведено.

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

Това не е едно-параграфно резюме. Описанието трябва да обхваща всяка категория лични данни, обработвани от всяка цел, всеки получател, всеки срок на съхранение и всяко трансгранично предаване. За поток от рекламни технологии това означава изброяване на всеки доставчик в TCF низа, данните, които всеки получава, и правното основание, претендирано за всеки от тях. Издателите, които копират директно списъка с доставчици от TCF v2.2 в приложението към DPIA, са изготвили работещи документи; тези, които го обобщават в две изречения, не са го направили.

Оценка на необходимостта и пропорционалността

Необходимостта пита дали същата цел може да бъде постигната с по-малко данни или с неличностни данни. За поток за поведенческа реклама това означава честно разглеждане на въпроса дали контекстуалната реклама би послужила на същата цел. EDPB Opinion 28/2024 е изричен, че DPIA не може да отхвърли контекстуалната реклама в един ред — администраторът трябва да демонстрира, че алтернативата е разгледана, и да обясни защо е отхвърлена.

Оценка на рисковете за субектите на данни

Анализът на риска трябва да вземе предвид незаконен достъп, неразрешено разкриване, промяна, загуба и по-широките социални рискове от профилирането — охлаждащи ефекти, дискриминация, затвореност. За всеки идентифициран риск оценката трябва да посочи вероятност, тежест и остатъчното ниво след мерките за намаляване.

Мерките, предприети за справяне с рисковете

Тук платформата за управление на съгласието се появява в DPIA. Детайлно улавяне на съгласието, отказ на ниво доставчик, лесно оттегляне, ограничения на съхранението, криптиране при предаване и в покой, договорни гаранции за обработващите данни — всяка мярка трябва да бъде свързана с конкретен идентифициран риск. Общото изявление, че издателят използва CMP, не е мярка.

Ролята на длъжностното лице по защита на данните

Член 35(2) изисква администраторът да потърси съвета на DPO при провеждането на DPIA. За издатели с определено DPO това е просто. За по-малките издатели без такова, DPIA все пак може да се проведе, но трябва да се извърши с документирани външни съвети — външен юрисконсулт, отраслов консултант или екипът за съответствие на доставчика на CMP. Ролята на DPO е да оспорва анализа на необходимостта на администратора, а не да го одобрява с печат.

Кога се изисква предварителна консултация

Член 36 изисква предварителна консултация с надзорния орган, когато DPIA показва, че обработката би довела до висок риск, който администраторът не може да намали. На практика това е рядкост за потоци за бисквитки и съгласие — повечето рискове могат да бъдат намалени чрез детайлно съгласие, намаляване на доставчиците, ограничения на съхранението и договорни гаранции. Но не е нула. Два случая, задействали предварителна консултация през 2024 и 2025 г.: идентификатор базиран на пръстов отпечатък, внедрен без TCF интеграция, и граф на идентичност между устройства, комбиниращ данни от първа страна с брокери на данни от трети страни. Издателите, проучващи един от двата модела, трябва да планират срок на консултация от шест до дванадесет седмици.

Как регулаторите използват DPIA в разследвания

DPIA е единственият документ, който регулаторът иска пръв, когато жалба за бисквитки достигне официалния етап на разследване. Италианският Garante, френският CNIL, белгийският APD и баварският BayLDA отварят процедурните си досиета с искане за DPIA, обхващащо въпросната дейност. От скорошните решения се появяват три модела:

Закъснело изготвените DPIA са силно обезценени

DPIA, датирано след искането на регулатора, няма да се третира като доказателство за оценка преди пускане. Няколко решения от 2025 г. изрично са отбелязали, че документът е създаден впоследствие и са го претеглили по съответния начин. DPIA трябва да предхожда пускането на обработката, а метаданните или историята на версиите на документа трябва да го изяснят.

Общите DPIA се третират като липсващи

Шаблонно DPIA, копирано от портала на доставчик на CMP без специфичен за сайта анализ, се отхвърля все по-често. Решението на Garante от 2025 г. срещу италианска издателска група посочи шест от деветте сайта в обхвата и установи, че едно споделено DPIA, обхващащо всички тях, не удовлетворява член 35.

Мерките за намаляване трябва да съответстват на действително внедреното

Ако DPIA описва 60-дневно съхранение на бисквитки, но внедрените бисквитки използват 24-месечен живот, регулаторът ще третира DPIA като неточно. Тримесечният одит на внедрената конфигурация спрямо описанието в DPIA вече не е по избор.

Обединяване на всичко

За повечето издатели практическият отговор е един и същ: DPIA е задължително, трябва да бъде изготвено преди всяко ново проследяване да бъде стартирано, и трябва да се преглежда тримесечно спрямо внедрената конфигурация. Документът не трябва да е дълъг, но трябва да е специфичен за сайта, написан преди пускане, одобрен от DPO или документиран външен съветник, и съобразен с това, което всъщност работи в продукция. Издателите, които уредят тези четири точки правилно, превръщат DPIA от тежест за съответствие в най-силната защита, която имат, когато регулаторът дойде да пита.

← Блaderegistrdelays delays Прочети всичко →