Data Protection Impact Assessment: проводити чи не треба?

Стаття 35 General Data Protection Regulation (далі – GDPR) встановлює обов’язок контролерів здійснювати оцінювання впливу на захист даних або, як ведеться це називати, Data Protection Impact Assessment (далі – DPIA), якщо опрацювання даних пов’язано з потенційною ризиковістю для прав та інтересів суб’єктів даних.

 

Моя хата скраю – нічого не знаю

 

А варто було б. Відповідно до ч. 3 ст. 35 GDPR ця вимога стосується контролерів, якщо наявні:

• Систематичне та масштабне оцінювання персональних даних, яке проводиться на основі автоматизованої обробки (automated processing), включно із профайлінгом, і якщо таке оцінювання має хоч якийсь вплив на відповідну особу;
• Масштабне опрацювання спеціальних категорій даних (sensitive data) та персональних даних про кримінальні правопорушення, судимості;
• Систематичний моніторинг публічно доступної ділянки великої площі.

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

Ясність ще може внести Guideline on DPIA, де додатково виділяють 9 критеріїв, коли операції з опрацювання можу вважатися досить ризиковими:

• Оцінювання або scoring, включно з профайлінгом та передбаченнями (приклад: компанії, які будують поведінкові або маркетингові профілі на основі поведінки користувачів на сайті).
• Автоматизоване прийняття рішень, яке має юридичні наслідки (приклад: якщо обробка призводить до виключення або дискримінації окремих осіб).
• Систематичний моніторинг;
• Особливі категорії даних, зокрема sensitive personal data (наприклад: зберігання даних пацієнтів);
• Обробка здійснюється щодо великої території. Тобто:
• Велика кількість суб’єктів даних залучена;
• Великий обсяг або діапазон даних, що обробляються;
• Тривалий або постійний процес опрацювання даних;
• Опрацювання здійснюється на великій географічній території.
• Узгодження або комбінування даних (наприклад: здійснюється різними контролерами, що перевищує очікування суб’єкта даних);
• Наявні вразливі категорії суб’єктів даних (наприклад: діти, люди похилого віку, ментально хворі тощо);
• Використання інноваційних технологій (наприклад: Інтернет речей);
• Опрацювання унеможливлює реалізацію суб’єктом даних свої прав (наприклад: коли банк перевіряє потенційних клієнтів щодо можливості надання кредиту).

 

У нас тільки один критерій спрацьовує. Ну, максимум два

 

Article 29 Working Party (WP29) зауважує, що чим більше критерії буде у процесора, тим більша ймовірність, що опрацьовуються ризикові дані. Більш того, залежно від типу даних, навіть наявність одного критерію може потребувати проведення DPIA.

 

А може все ж таки не треба?

 

Не заперечуємо, може бути й таке.  WP29 (за підтримки EDPB) виділяє загальний перелік випадків, коли проведення DPIA може бути необов’язковим. Це ситуації, коли:

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

 

У нас є кольоровий папір, клей та ножиці. Готові робити DPIA.

Раді Вашому ентузіазму, але спершу можна впевнитися у необхідності DPIA, а потім приступати до його проведення.

• здійснити аналіз операцій з опрацювання та їх цілей. Якщо компанія використовує legitimate interest як підставу опрацювання, то це у більшості випадків є «дзвіночком», що варто подумати над DPIA.
• встановити необхідність та пропорційність операцій з опрацювання поставленим цілям, врахувавши наявність втручання у права та інтереси суб’єктів даних.
• ідентифікувати заходи, які спрямовані на мінімізації ризиків та захист даних.
• зробити облік даних, отриманих з аналізу.
• за бажанням – прикрасити палітурку (або фон в Екселі) кольоровим папером.

На підставі цього можна зробити DPIA, але його результати не для того, щоб вони лежали собі тихенько у шухлядці. Може все ж таки варто їх застосувати? І безперечно, оскільки опрацювання є досить динамічним процесом, то,      щоб бути завжди compliant, можна час від часу переглядати результати DPIA на предмет виникнення нових ризиків.

 

Цікава оповідка для уважних читачів

 

У Великій Британії у 2019 році був кейс R (Bridges) v Chief Constable of South Wales Police and other^[1]. Якщо коротко, то розглядали питання щодо використання технології розпізнавання обличчя (facial recognition technology) поліцейськими на громадських заходах. У цій справі суд брав до уваги DPIA поліції та зауважив недолік: DPIA більше захищає дані тих, хто потрапив у список спостереження, ніж членів суспільства загалом. Попри це, суд визнав DPIA поліції достатньо чітким, детальним та таким, що відповідає GDPR, бо там добре описані цілі обробки та заходи захисту даних.

У пункті 146 цього рішення суд наголошує:

«What is required is compliance itself, i.e. not simply an attempt to comply that falls within a range of reasonable conduct»

«Те, що вимагається, це саме дотримання, тобто не просто спроба дотримання, яка підпадає під діапазон розумної поведінки»

 

Last, but not least

Відповідальність за проведення DPIA лежить на компанії, яка діє як контролер. Проте можна проконсультуватися із DPO. У разі, коли достеменно невідомо, чи DPIA є необхідним, WP29 рекомендує провести його, бо DPIA – це корисний інструмент, який допомагає контролерам бути у відповідності (compliance) із законодавством про захист персональних даних.

 

 

 

^[1] R (Bridges) v Chief Constable of South Wales Police and other [2019] EWHC 2341. URL: https://www.bailii.org/ew/cases/EWHC/Admin/2019/2341.html (дата звернення: 14.02.2022).