GDPR правила та підводні камені в захисті персональних даних

Головна помилка при впровадженні GDPR (далі – Регламент) – розраховувати, що кілька політик на сайті або стандартна позначка у внутрішніх документах забезпечують відповідність правилам GDPR. На практиці таке ставлення до захисту персональних даних призводить до багатомільйонних штрафів для бізнесу, що показує: Регламент встановлює значно ширші зобов’язання, які торкаються кожного процесу роботи компанії, а регулятори активно перевіряють дотримання GDPR правил. 

У цій статті ми розберемося детальніше, які непомітні помилки в роботі з персональними даними найчастіше призводять до серйозних санкцій.

На які GDPR правила бізнесу варто звернути увагу? 

1. Основні вимоги Регламенту

Дані – це не лише про зручність і нові можливості, а й про велику відповідальність. Як тільки дані були зібрані у картотеку чи іншу базу даних – компанія зобов’язана виконати усі принципи за ст. 5 GDPR, що включають:  

1. Законність, справедливість і прозорість. Законність – компанія повинна мати обґрунтовану підставу для обробки персональних даних. Справедливість – організація не може приховувати мотиви збору даних, а користувачі повинні бути впевнені, що їхні дані не використовуються неправомірно. Прозорість – чітке, відкрите та чесне пояснення того, як і з якою метою обробляються персональні дані.
2. Обмеження мети збору даних. Цей принцип означає, що персональні дані повинні збиратися виключно для конкретної, чіткої та законної мети. Приміром, під час працевлаштування кандидатів часто просять заповнити розгорнуту анкету з великою кількістю запитань, хоча на практиці роботодавцю зазвичай достатньо лише ПІБ, номера телефону, електронної пошти та, за потреби, адреси проживання для надсилання поштової кореспонденції.
3. Мінімізація даних. Компанії слід збирати лише ті дані, які дійсно потрібні для досягнення заявленої мети. Наприклад, якщо метою є формування бази підписників для розсилки, компанія повинна запитувати лише ту інформацію, що необхідна для надсилання матеріалів.
4. Точність. Організація має гарантувати, що дані, які вона збирає та зберігає, є точними. Відповідно вона повинна вживати заходів для виправлення, оновлення або видалення неправильних чи неповних даних, зокрема на запит суб’єкта даних. 
5. Обмеження терміну зберігання. Згідно з GDPR, компанія повинна обґрунтувати період зберігання даних. Йдеться про встановлення крайніх термінів, які відповідають політиці обмеження зберігання даних. Наприклад, компаніям варто встановити чітку заборону для працівників на зберігання копій клієнтських баз на локальних ноутбуках або перенесення персональних даних на зовнішні носії, зокрема USB-пристрої. Створення кількох несанкціонованих копій одних і тих самих даних у різних місцях розглядається як суттєве порушення вимог GDPR.
6. Цілісність і конфіденційність. GDPR вимагає забезпечення цілісності та конфіденційності даних, захищаючи їх від внутрішніх і зовнішніх загроз. Необхідно запобігати несанкціонованій або незаконній обробці, а також випадковій втраті, знищенню чи пошкодженню даних.
7. Підзвітність. Відповідно до принципу підзвітності, компанія повинна вести належну документацію, яка підтверджує дотримання принципів обробки даних, а регулятор має право ознайомитися з цією документацією за потреби.

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

Підводні камені:

На практиці однією з найпоширеніших помилок є розрахунок на те, що впровадити належні умови захисту персональних даних в компанії можна буде вже по ходу запуску продукту або сервісу. На ділі ж, захист персональних даних і приватності повинен враховуватися на всіх етапах обробки даних і починатися ще на етапі планування архітектури продукту чи сервісу, а не на завершальному етапі розробки. Зокрема таку вимогу встановлює ст. 25 Регламенту, закріплюючи принцип “Privacy by Design”. Цей принцип вимагає враховувати захист персональних даних ще на етапі планування архітектури застосунків чи сервісів. Це означає, що компанія має продумати, як збирати, обробляти, зберігати, видаляти та анонімізувати дані користувачів, ще до початку кодування чи запуску продукту так, щоб вони відповідали загальним принципам у ст. 5 Регламенту. 

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

Case study: Показовим є кейс німецького наглядового органу щодо порушень у веденні електронних архівів рієлторської компанії. Інспекційна палата виявила, що компанія не передбачила механізму видалення персональних даних за запитом користувачів та зберігала їх довше за розумний строк. Архів включав документи щодо працевлаштування, податкової історії, медичного страхування та банківських розрахунків. Лише після втручання регулятора компанія почала видаляти зайві дані та співпрацювати з інспекторами. В результаті компанію було оштрафовано на 14,5 млн євро за порушення принципу “Privacy by Design”.

2. GDPR – це командна робота

Коли мова йде про особу відповідальну за комплаєнс із GDPR у компанії, Регламент передбачає положення про Data Protection Officer (DPO). Хоча сам Регламент формально не містить визначення DPO, на основі аналізу інших положень GDPR можна зробити висновок, що DPO – це особа, яка забезпечує нагляд за дотриманням конфіденційності та захистом даних в компанії. Основне завдання такої особи – це контролювати законність обробки персональних даних бізнесом, оцінювати ризики для прав і свобод суб’єктів даних, співпрацювати з контролюючими органами, а також забезпечувати відповідність технічним аспектам обробки персональних даних. 

GDPR вимагає обов’язкового призначення DPO за наявності хоча б однієї наступних умов:

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

Такі вимоги є доволі неоднозначними і щоб точно зрозуміти, чи компанія підпадає під них, варто звернутися до роз’яснень національних контролюючих органів у сфері захисту персональних даних або до національного законодавства держави-члена ЄС, де відбувається збір та обробка. 

Детальніше про роль DPO: Data Protection Officer для вашого бізнесу

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

Підводні камені:

Навіть якщо компанія призначає DPO, він не несе повну відповідальність за порушення, адже Регламент, формулюючи обов’язки, прямо покладає відповідальність за все на контролера, хоча й з певними винятками. Простіше кажучи, DPO сам по собі практично не може нести фінансової відповідальності у вигляді штрафу по GDPR, оскільки, як показує практика, регулятори штрафують саме контролерів або процесорів за недбалість у забезпеченні належної роботи DPO. 

Case study: Показовим є кейс бельгійського регулятора щодо неправильно адресованих рахунків-фактур. Інспекційна палата Бельгійського DPA виявила кілька недоліків під час розгляду звіту, один з яких стосувався необхідної незалежності його DPO. Судова палата постановила, що DPO мав надмірний вплив на критичні процеси обробки даних, оскільки він також очолював відділ відповідності, ризиків та аудиту і відповідав за прийняття рішень щодо обробки даних у багатьох критичних видах діяльності. Конфлікт було описано як прояв “значного ступеня недбалості”, а штраф у розмірі 50 000 євро був накладений на контролера, а не на DPO. 

3. Оцінка ризиків як основа комплаєнсу

За Регламентом проведення процедури оцінки ризиків у компанії пов’язується, як правило, із використанням окремих правових підстав для обробки персональних даних, необхідністю обробки окремих типів даних або ж використанням певних технологій обробки. Основна мета таких процедур полягає у тому, щоб виявити та усунути ризики, пов’язані з обробкою персональних даних ще на початковій стадії розробки сервісу або продукту. 

Регламент виділяє такі види процедур оцінки ризиків:

Підводні камені:

Саме на підставі аналізу ризиків компанія має самостійно визначати, які документи їй потрібні та які технічні й організаційні заходи доцільно впроваджувати. При цьому Регламент свідомо не встановлює «правильного» кінцевого результату такої оцінки. Це пов’язано з тим, що рішення, ефективні для однієї компанії, можуть бути абсолютно непридатними для іншої. Лише з урахуванням рівня рия зику та конкретного характеру загроз можна підібрати адекватні заходи захисту саме для вашої бізнес-моделі.

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

Як наслідок, якщо бізнес буде проводити лише формальну оцінку ризиків безвідносно до специфіки роботи конкретної компанії, то заходи безпеки можуть бути недостатньо пропорційними або неадекватними, що робить таку компанію вразливою до порушень GDPR правил. 

Читайте також: DPIA: privacy інструмент, який недооцінюють

4. Згода – не картбланш на обробку персональних даних

Нагадаємо, що за ст. 6 Регламенту згода особи є лише однією з підстав для обробки персональних даних. Інші п’ять підстав включають: юридичний обов’язок, виконання договору, захист життєво важливих інтересів, суспільні інтереси та законний інтерес компанії.  

Ст. 7 GDPR встановлює такі умови для надання згоди: 

1. У разі, якщо опрацювання засновано на згоді, контролер повинен бути спроможним довести те, що суб’єкт даних надав згоду на опрацювання своїх персональних даних.

2. Якщо суб’єкт даних надає згоду в контексті письмової декларації, що також стосується інших питань, запит на надання згоди необхідно подавати у формі, що чітко відрізняється від інших питань, у зрозумілій та доступній формі, з використанням чітких і простих формулювань. Будь-яка частина такої декларації, що становить порушення цього Регламенту, не є зобов’язальною.

3. Суб’єкт даних повинен мати право відкликати свою згоду в будь-який момент. Відкликання згоди не повинно впливати на законність опрацювання, що ґрунтувалося на згоді до її відкликання. До надання згоди суб’єкта даних необхідно про це повідомити. Необхідно однаково забезпечити можливість як відкликати, так і надати згоду.

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

Підводні камені:

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

Case study: Показовим є кейс грецького регулятора щодо неправомірного використання згоди як підстави для обробки персональних даних працівників. Національний орган із захисту даних Греції (далі – Регулятор) встановив, що компанія PwC неправильно використовувала згоду для обробки персональних даних своїх співробітників, включно з передачею даних третім сторонам та відеоспостереженням. Основний аргумент Регулятора полягав у тому, що згода не була добровільною та вільною, оскільки працівники перебували у відносинах підпорядкування і як наслідок не мали свободи вибору щодо надання згоди на обробку своїх даних. Кейс демонструє, що покладатися на згоду за певних обставин доволі ризиковано, а підстава обробки персональних даних передусім має спиратися на мету та умови обробки таких даних. 

5. Транскордонна передача даних за правилами GDPR

GDPR містить доволі суворі правила передачі персональних даних за межі Європейської економічної зони. 

Так, передавати персональні дані за межі ЄС дозволено лише за умов, що така передача буде забезпечувати такий самий рівень захисту, як і в Європі: 

• “Рішення про відповідність”: Європейська комісія може визначити, що інша країна має належний рівень захисту даних і відповідно така передача не буде потребувати додаткового дозволу, оскільки буде прирівняна до передачі в межах ЄС. Таке рішення, наприклад, прийнято щодо Аргентини, Канади, Ізраїлю, США, Японії, Швейцарії, Великої Британії;
• Належні гарантії: Відповідно до ст. 45, контролер або процесор може передавати персональні дані в третю країну або міжнародну організацію, тільки якщо контролер або процесор забезпечує відповідні належні гарантії і за умови, що субʼєктам даних доступні права і ефективні засоби правового захисту, що мають силу примусового виконання (ст. 46 GDPR). До прикладу, такі гарантії забезпечуються шляхом впровадження затверджених обов’язкових корпоративних правил (binding corporate rules) за cт. 47 GDPR; стандартних умов захисту даних (standard data protection clauses) за ст. 40 GDPR; затвердженого механізму сертифікації згідно зі ст. 42 Регламенту;
• Відступи для спеціальних ситуацій: У випадку передачі даних, яка не покривається ні рішенням про відповідність, ні відповідними гарантіями захисту, така передача можлива лише, якщо на неї можна поширити одне з винятків, викладених у статті 49 GDPR.

Підводні камені:

Використання стандартних договірних положень саме по собі ще не гарантує належного рівня захисту персональних даних, якщо законодавство третьої країни дозволяє непропорційне втручання державних органів у право на приватність. Так, рішення Європейського суду у справі Schrems II Справа C-311/18 встановлює обов’язок для компаній проводити індивідуальний аналіз кожного кейса передачі даних з огляду на законодавство країни-імпортера щодо доступу державних органів до персональних даних і за необхідності вживати додаткові заходи безпеки. 

На практиці це означає, що компаніям потрібно проводити реальну Оцінку ризиків передачі даних за межі ЄС (Transfer Impact Assessment) для кожного конкретного кейсу окремо. Особливо це актуально у світлі доволі напруженої геополітичної ситуації у світі, адже політичні суперечки між країнами можуть призвести до посилення стеження, вилучення даних або навіть навмисного втручання в потоки даних. Саме тому відсутність або формальний характер Оцінки ризиків передачі даних за межі ЄС може призвести до того, що навіть формально допустима передача буде визнана такою, що порушує GDPR.

Що буде, якщо не розібратися з правилами комплексно? 

GDPR отримав свою популярність на просторах інтернету не в останню чергу завдяки суворості штрафів, які він передбачає. 

Рівень відповідальності передусім залежить від типу порушення.

Наприклад, за незначні порушення, такі як неналежне виконання обов’язків щодо сертифікації механізмів захисту даних, передбачено штраф до 10 000 000 євро або 2% річного обороту компанії за попередній рік – залежно від того, яка сума більша.

У випадку порушення основних принципів GDPR штраф зростає вдвічі – до 20 000 000 євро або 4% річного обороту компанії, знову ж таки залежно від того, яка сума перевищує іншу.

Під час розгляду справи контролюючі органи беруть до уваги тяжкість і тривалість порушення, його характер (навмисний чи ненавмисний), попередні порушення, ступінь співпраці компанії у розслідуванні, а також категорії персональних даних, яких це стосувалося.

Висновки 

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

У Legal IT Group є цілий посібник по тому, як розібратися з основними GDPR правилами і не загубитися в численних регулюваннях. Ба більше, він є доступним для безкоштовного завантаження за посиланням. 

П.С. Книга, хоч і написана кваліфікованими юристами, вона є дуже простою для розуміння і призначена для того, щоб бути настільним порадником для власників бізнесу, DPO та всіх, хто стикається з роботою з персональними даними.