DPIA за онлайн бизнес – кога и как да направите оценка на въздействието по GDPR

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

Data Protection Impact Assessment (DPIA) е формална процедура за оценка на рисковете, които дадена обработка на лични данни създава за правата на физическите лица. Член 35 от Регламент (ЕС) 2016/679 (GDPR) задължава администратора на данни да извърши такава оценка, когато определен тип обработване – особено с нови технологии – може да доведе до висок риск. Процедурата не е пожелателна: КЗЛД и другите надзорни органи в ЕС очакват документирано доказателство, че рискът е анализиран преди стартиране на обработването. За онлайн магазини, SaaS платформи и мобилни приложения, които събират поведенчески данни или обработват плащания, DPIA често се оказва задължителна, а не просто препоръчителна.

Санкциите при неизпълнение са реални. GDPR предвижда глоби до 10 млн. евро или 2% от годишния глобален оборот (което от двете е по-високо) конкретно за нарушения на задълженията по чл. 35. Това е отделно от санкциите до 4% от оборота или 20 млн. евро за нарушения на принципите за обработка. КЗЛД вече е налагала предписания на български дружества за липса на документирана оценка на риска при мащабна обработка.

Кога DPIA е задължителна за онлайн магазин или платформа

Член 35, параграф 3 от GDPR изброява три случая, при които оценката е безусловно задължителна: систематично и мащабно оценяване на лични аспекти чрез автоматизирано обработване (включително профилиране), мащабно обработване на специални категории данни по чл. 9 или данни за присъди по чл. 10, и систематично мащабно наблюдение на публично достъпна зона.

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

Работна група 29 (сега заменена от EDPB) е публикувала списък с девет критерия, от които наличието на поне два обикновено означава задължителна DPIA. Тези критерии включват: оценяване или скоринг, автоматизирано вземане на решения с правен ефект, систематично наблюдение, обработка на чувствителни данни, мащабна обработка, комбиниране на набори от данни, данни на уязвими лица (деца, служители), използване на нови технологии и обработка, която възпрепятства упражняването на право.

Практически примери от електронната търговия

Онлайн магазин с над 10 000 регистрирани потребители внедрява система за препоръки, която анализира история на покупките, разглеждани продукти и демографски данни. Два критерия са покрити веднага – оценяване/скоринг и мащабна обработка. DPIA е задължителна.

Друг пример: SaaS платформа за управление на човешки ресурси обработва данни за здравословно състояние на служители. Тук се активират критериите за чувствителни данни и уязвими лица (служители в зависимо положение). Отново DPIA е задължителна.

Малък блог с контактна форма и Google Analytics, който няма регистрация и не събира данни извън стандартната аналитика? Вероятно не покрива нито един от деветте критерия. DPIA не е необходима, но кратка документация защо е взето това решение все пак е добра практика.

Стъпки за провеждане на DPIA

Стъпка 1: Опишете обработването

Документирайте какви данни се събират, от кого, за каква цел, на какво правно основание и на кого се предават. За онлайн магазин това означава да се опише целият поток – от попълване на поръчка през обработка на плащане до доставка и маркетинг след покупка. Ако използвате бисквитки на трети страни за ремаркетинг, те също влизат в описанието.

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

Задайте конкретни въпроси. Наистина ли е необходимо да съхранявате IP адреси за 24 месеца? Има ли по-малко инвазивен начин да постигнете същата бизнес цел? Можете ли да използвате анонимизирани данни вместо псевдонимизирани? Ако събирате данни „за всеки случай“, без конкретна цел, това е червен флаг.

Стъпка 3: Идентифицирайте рисковете

Рисковете се оценяват от гледна точка на субекта на данни, а не на бизнеса. Какво би се случило, ако данните изтекат? Какъв е рискът от неправомерно профилиране? Може ли автоматизирано решение да дискриминира определена група потребители? Типичните рискове за онлайн магазин включват: неоторизиран достъп до платежни данни, неправилно таргетиране на малолетни, загуба на данни при миграция на платформа.

Стъпка 4: Определете мерки за намаляване на риска

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

Стъпка 5: Документирайте и преразглеждайте

DPIA не е еднократен документ. Преразглеждайте оценката при всяка съществена промяна в обработването – нов доставчик на плащания, добавяне на чатбот с AI, смяна на хостинг, въвеждане на програма за лоялност.

Минимално съдържание на DPIA документа

Член 35, параграф 7 от GDPR определя четири задължителни елемента: систематично описание на обработването и неговите цели (включително легитимен интерес, ако е приложимо), оценка на необходимостта и пропорционалността спрямо целите, оценка на рисковете за правата и свободите на субектите, и предвидените мерки за справяне с рисковете.

На практика един работещ DPIA документ за онлайн магазин съдържа между 8 и 25 страници. Формат по избор – КЗЛД не налага шаблон, но CNIL (Франция) предлага безплатен софтуер PIA, а ICO (Великобритания) публикува подробен шаблон, който е напълно съвместим с GDPR и може да се адаптира за български контекст.

Кога трябва да се консултирате с КЗЛД

Ако след приключване на DPIA остатъчният риск остава висок и не може да бъде намален с разумни мерки, чл. 36 от GDPR изисква предварителна консултация с надзорния орган – за България това е КЗЛД. Органът разполага с до 8 седмици (с възможност за удължаване) да даде становище.

Тази ситуация е по-рядка при стандартна електронна търговия. По-често се среща при проекти, които обработват биометрични данни, данни за здравословно състояние в голям мащаб или прилагат експериментални AI модели за вземане на решения с правен ефект.

Техническа реализация: DPIA регистър в WordPress

За собственици на магазини на WooCommerce, които искат да поддържат вътрешен DPIA регистър, custom post type е практичен подход:

add_action('init', function () {
    register_post_type('dpia_record', [
        'labels' => [
            'name' => 'DPIA Records',
            'singular_name' => 'DPIA Record',
        ],
        'public' => false,
        'show_ui' => true,
        'show_in_menu' => true,
        'supports' => ['title', 'editor', 'revisions'],
        'menu_icon' => 'dashicons-shield',
        'capability_type' => 'post',
    ]);
});

Полето 'public' => false гарантира, че записите не са достъпни от frontend. Revisions позволяват проследяване на промените във времето, което е полезно при одит. Допълнителни мета полета за дата на преразглеждане, статус на риска и отговорно лице се добавят чрез ACF или custom meta boxes.

Връзка между DPIA и останалите GDPR задължения

DPIA не съществува изолирано. Оценката на въздействието е част от по-широкия комплект документация, който включва политика за защита на лични данни, регистър на дейностите по обработване (чл. 30 от GDPR) и процедури за уведомяване при нарушение на сигурността (чл. 33-34). Когато един онлайн магазин вече е изготвил подробни общи условия и политика за поверителност, голяма част от описателната информация за DPIA вече е налична – остава да се допълни с анализ на риска и мерките.

Обработването на данни чрез CMP (Consent Management Platform) за Consent Mode v2 също трябва да бъде отразено в DPIA, ако платформата извършва профилиране или мащабно проследяване.

Чести грешки при изготвяне на DPIA

Копиране на шаблон без адаптация към конкретния бизнес е най-разпространеният проблем. Надзорните органи разпознават генерични документи и ги третират като неизпълнение на задължението. Друга грешка е провеждане на DPIA след стартиране на обработването – чл. 35 изрично изисква оценката да бъде направена преди началото на обработката.

Третият типичен пропуск е липсата на преразглеждане. Онлайн бизнесът се променя бързо – нов платежен процесор, интеграция с CRM система, преминаване към нов хостинг – всяка такава промяна може да изисква актуализация на DPIA.

Често задавани въпроси