Неочевидні нюанси GDPR. Що треба знати про принцип Privacy by Design, щоб не отримати штраф на $16 мільйонів
Ця стаття написана в співавторстві з Yuliya Miadzvetskaya.
Що спільного між витоком даних, порушенням права на забуття та штрафом у 16 млн доларів? Їх усіх об’єднує принцип європейського права під назвою Privacy by Design (PbD), за порушення якого низка компаній уже отримала рекордні штрафи.
Ми маємо європейську юридичну освіту, досвід роботи в консультуванні ІТ-компаній, вирішення кейсів щодо застосування PbD й GDPR, участі в європейських дослідницьких проєктах щодо PbD та роботи на приватні й академічні інституції. У цій статті ми пояснимо, що таке PbD, за що його критикують, як не отримати мільйонні штрафи та чому це важливо для українських ІТ-компаній.
Стаття буде цікавою насамперед для керівників компаній, системних архітекторів, техлідів, проєктних менеджерів, бізнес-аналітиків, спеціалістів з Information security, комплаєнсу, ейчарів та рекрутерів, а також розробників, які працюють з персональними даними громадян і резидентів ЄС.
Ілюстрація Уляни Патоки
2019 року європейські контрольні органи видали перші штрафи за порушення принципу PbD, закріпленого в GDPR — Регламенті ЄС щодо захисту персональних даних, що набрав чинності в травні
Навіть епідемія коронавірусу не змусила європейську владу послабити нагляд за дотриманням GDPR. А враховуючи збільшення частки людей, що працюють з дому чи у віртуальних офісах, значення GDPR зростатиме. Українські компанії зобов’язані дотримуватися вимог GDPR, якщо їхні розробки використовуються в ЄС. Загалом Privacy by Design — вимога для всіх компаній, але в цій статті ми сконцентруємося на секторі ІТ.
Що таке PbD
Принцип Privacy by Design означає, що захисту персональних даних і приватності має приділятися увага в software development lifecycle (SDLC) ще на етапі планування архітектури, а не наприкінці розробки, як це трапляється зазвичай. Тобто ще під час планування структури застосунку чи сайту треба продумати, як забезпечити захист персональних даних, їх обробку та видалення на вимогу користувачів.
Якими бувають штрафи та за що
Поряд з PbD є technical and organizational measures (технічні й організаційні заходи) — TOMs, за якими контрольні органи можуть оцінити рівень комплаєнсу. Штрафи можуть виписувати як за незастосування PbD загалом, так і за погану реалізацію окремих TOMs.
Розмір штрафів здебільшого залежить від тяжкості наслідків, до яких призвело порушення.
Вони можуть бути дуже маленькими, коли, наприклад, DPA (Data Protection Authority, орган контролю) Румунії оштрафувала асоціацію домовласників (на кшталт нашого ОСББ) за недостатні TOMs під час встановлення камер відеоспостереження в багатоквартирному будинку. Зокрема, ОСББ не розмістила попереджень про наявність камер, не забезпечила обмеження строків зберігання відеозаписів і не обмежила доступ користувачів до файлів із записами. ОСББ отримали два офіційних попередження та штраф у 500 євро. Повний текст румунською.
Трохи дивний кейс розглядала DPA Чехії, коли оштрафувала ІТ-підприємця, власника онлайнової гри. Сайт онлайн-гри став жертвою DdoS-атаки. Власник невдало спробував відновити сервери та встановити захист. Зловмисники вдалися до шантажу й почали вимагати від підприємця гроші за припинення атак. До того ж вони запропонували допомогу з установленням нового фаєрволу, щоб не допустити подібних атак у майбутньому. Власник сайту заплатив гроші та встановив фаєрвол, код якого надіслали самі зловмисники. Код містив бекдор, через який шахраї дістали доступ до серверів гри, встановили редирект на власний сайт і завантажили персональні дані користувачів. База даних 4500 користувачів (імена, паролі, імейли, телефони тощо) була опублікована в Інтернеті. Штраф за відсутність адекватних TOMs становив 980 євро. Повний текст чеською.
Також можна згадати доволі поширений кейс, коли магазини здійснюють загальну імейл-розсилку, де внаслідок помилки чи незнання не приховують адреси інших отримувачів. За таке порушення TOMs DPA Іспанії виписала штраф у 5000 євро. Повний текст іспанською.
Це кейси, які стосувалися невеликих компаній або приватних ІТ-підприємців. Але в разі роботи з великим масивом даних або особливого характеру інформації (дані про здоров’я, особисте життя, фінанси тощо) штрафи пропорційно збільшуються. DPA Румунії влітку
При оплаті онлайн зайві персональні дані платника надсилалися отримувачеві. Часто таке трапляється внаслідок неправильного генерування електронних документів (інвойсів, платіжок, чеків), чиї поля заповнюються автоматично через запити до баз даних. Контрольні органи звернули увагу на це порушення внаслідок скарги, найімовірніше від одного з клієнтів банку. Загалом особисті коди й адреси 337 042 клієнтів опинилися в доступі сторонніх осіб. Штраф за недостатні TOMs становив 130 тис. євро. Повний текст румунською.
Трохи інший кейс трапився з румунською фінансовою організацією, яка видавала мікропозики онлайн. Служба підтримки фінорганізації надсилала документи з персональними даними клієнта на чужий імейл. Власник імейла скаржився службі підтримки, а після відсутності реакції надіслав запит до DPA, яка розпочала розслідування. Встановлено, що фінорганізація не мала механізмів верифікації отриманих даних і не повідомила органам контролю про факт витоку персональних даних. Фінорганізація отримала три штрафи сумарно на 14 тис. євро лише за одне, але все ж порушення PbD. Повний текст румунською.
Ще один поширений кейс, який дратує навіть авторів статті. Часто різні компанії або магазини здійснюють розсилки або навіть дзвінки, від яких неможливо відписатися. DPA Греції розслідувала скаргу користувача, що натиснув магічну кнопку ‘unsubscribe’, але спам і далі надходив. Контрольні органи видали штраф за порушення PbD через відсутність відповідного реагування на запити користувачів на 400 тис. євро. Пресреліз англійською.
DPA Франції провела цікаве онлайн-розслідування за скаргою одного з клієнтів компанії, яка займається нерухомістю. У скарзі зазначалося, що під час користування онлайн CRM-системою модифікація кількох символів в URL-адресі дозволила отримати неправомірний доступ до особистих документів сторонніх осіб.
Під час онлайн-моніторингу інспектори виявили, що проста зміна цифр в URL-адресі справді дозволила завантажити податкові документи, копії посвідчень особи, картки страхування, податкові повідомлення, свідоцтва про смерть, свідоцтва про одруження, посвідчення про соціальне страхування, свідоцтва фонду сімейних виплат, пенсійні посвідчення, довідки про наявність інвалідності, свідоцтва про розлучення, виписки з рахунків, виписки з банків і квитанції про оренду, які стосувалися сторонніх осіб.
Загалом, простою заміною символів інспектори завантажили 9466 документів різних користувачів. Скаржник повідомив компанію про дефект у TOMs у березні
Інспектори встановили, що на момент перевірки у фактично вільному доступі перебували 290 870 документів. Компанія спробувала подати заперечення, посилаючись на процедурні порушення, проте заперечення відхилили. У підсумку за сукупністю умов, серед яких відсутність належних TOMs, природа даних (фінанси, особисте життя), а також за відсутність реакції на скарги, на компанію наклали штраф у 400 тис. євро, при початковій вимозі інспекторів накласти штраф у 900 тис. євро. Повний текст французькою.
Один з найбільших штрафів отримала одна німецька компанія. Під час перевірки DPA Берліна (ФРН) виявила порушення в обслуговуванні електронних архівів німецької рієлторської компанії. Компанія не передбачила механізму видалення даних за запитом користувачів і зберігала дані довше за розумний строк.
В архіві накопичувалися документи щодо працевлаштування, податкової історії, медичного страхування та банківських розрахунків. Перевірку провели у вересні
Після цього компанія доклала зусиль до співпраці з інспекторами та видалення зайвих даних, зокрема колишніх клієнтів чи заявників, що не користувалися послугами компанії. Співпрацю компанії врахували, визначаючи штраф за порушення PbD, що сягав 14,5 млн євро (понад 16 млн доларів у березні 2019 р.). Станом на час публікації постанови компанія ще мала шанс оскаржити штраф. Повний текст рішення німецькою.
Наостанок можна згадати цікавий штраф, виданий державному органові. DPA Болгарії оштрафувала місцеву Національну агенцію доходів. Унаслідок неналежного технічного захисту хакери отримали дані щодо імен, ідентифікаційних номерів, адрес, телефонних номерів, податкові декларації, фінансові дані, дані соціального страхування, виплати за медичними страховками, дані щодо адміністративної відповідальності понад 4 млн живих (фактично все працездатне населення країни) і майже 2 млн померлих осіб. Штраф: 2,6 млн євро. Повний текст болгарською.
За що критикують PbD
PbD часто критикують за недостатню специфічність і відсутність точних «правил гри». І часом ця критика обґрунтована. Державні інспекції та органи з нагляду за дотриманням законодавства про захист персональних даних у своїх постановах щодо PbD посилаються або на недотримання принципу загалом, або на відсутність чи недостатність TOMs.
Вичерпного списку ТОМs немає, але з назви можна зрозуміти, що вони мають дві основні складові: технічні заходи й організаційні заходи. Крім того, ці заходи повинні бути ефективними, а не просто формальними «галочками» у списку завдань. Така широка «сіра зона» є джерелом невизначеності, але завдяки штрафам і судовим ухвалам ми вже маємо уявлення про певні «межі».
Як виконати вимоги PbD
Єдиного рецепта немає, бо кожна компанія та продукт унікальні. Нижче ми подаємо приблизну інструкцію щодо TOMs, яку можна взяти до уваги на шляху до комплаєнсу з PbD в секторі ІТ.
Технічні заходи включаються в архітектуру ПЗ на етапі планування та загалом у технічні процеси, зокрема в офісах і на виробництві ІТ-компанії (якщо компанія виробляє чи налаштовує ґаджети). Архітектурою має бути передбачено, що доступ до персональних даних не отримають особи, які не мають для цього законних підстав. Окрім того, архітектура має забезпечити приватність, що найчастіше досягається мінімізацією збору й використання персональних даних.
Зокрема, треба зробити таке:
- Компанія має розробити чіткі внутрішні процедури обробки даних, а також визначити тривалість зберігання даних.
- Встановити відповідні обмеження, процедури авторизації та верифікації для унеможливлення незаконного доступу до даних.
- Видалення певних персональних даних повинно бути автоматизованим. Це стосується насамперед застарілих даних і даних колишніх користувачів.
- Треба переконатися, що неможливо повторно ідентифікувати анонімізовані дані чи відновити видалені дані.
- Використовувати захищені клауд-сервіси, високі вимоги до протоколів передачі даних, забезпечувати шифрування та/або анонімізацію даних при їхній передачі чи зберіганні.
- Вибрати найекономніші та найефективніші в плані обробки даних алгоритми, фреймворки й (інколи) мови програмування для розробки відповідного ПЗ.
- Подбати про захист інформації від атак (кібербезпека).
- Мінімізувати збір і використання персональних даних. Річ не тільки в зменшенні кількості імен або імейлів у базі даних ваших користувачів, а й у мінімізації будь-яких операцій з даними. Витік великих і деталізованих баз даних призводить до тяжчих наслідків. GDPR вимагає, щоб для досягнення цілей (надання послуги, розробки продукту) використовувалася якнайменша кількість потрібних для цього даних. Це саме стосується й кількості операцій (запитів до БД, збору, оновлення та пересилання даних) з персональними даними.
Організаційні заходи. Якщо технічні заходи стосуються технологій, сервісів і налаштувань, то організаційні заходи стосуються менеджменту й операцій у компанії. Конкретні заходи включають:
- Призначення Data Protection Officer (DPO), який/яка забезпечує розробку та впровадження відповідних заходів, документів, політик і інструкцій для компанії, а також буде відповідальною особою для зв’язків з органами контролю. Призначення DPO в разі обробки великої кількості даних є обов’язковим.
- Проведення навчання для працівників. Воно охоплює вміння відрізняти персональні дані від неперсональних, запобігання ненавмисному розголошенню даних; правила використання шифрування, пересилання даних громадян ЄС за межі ЄС (наприклад, коли клієнт хоче дати доступ до своїх БД розробникові з України), порядок дій у разі витоку даних. Особливо це стосується персоналу (РМ, ВА, розробники, рекрутери, служба підтримки), який напряму працює з персональними даними громадян країн ЄС і з клієнтами. На жаль, рівень культури при роботі з даними залишається вкрай низьким; з нашого досвіду можемо сказати, що лише одиниці читають власноруч підписані NDA, де зазначено правила поводження з даними й відповідальність за порушення.
- У компанії має бути протокол дій на випадок інспекції або офіційного листа від DPA чи іншого уповноваженого органу та відповідальна особа для опрацювання подібних звернень. Окрім DPA, розкриття даних можуть вимагати прокуратура, поліція, спеціальні служби, суди. І далеко не в усіх випадках ці органи матимуть відповідні повноваження.
- Установлення режимів фізичного доступу до комп’ютерів і серверів. Немає потреби перетворювати офіс ІТ-компанії на військову базу, але є рація переглянути доцільність доступу всієї команди до серверів чи «холодних архівів» з персональними даними.
Як зазначено в статті 25 GDPR, береться до уваги state of the art. Таким чином ІТ-компанії мають враховувати останні досягнення в технологіях для забезпечення приватності своїх користувачів і захисту їхніх персональних даних. Окрім state of the art, ІТ-компанії мають збалансувати свої ТОМs із витратами на реалізацію та цілями обробки персональних даних.
Простий приклад передбачає, що для обробки даних щодо здоров’я людини (особливо актуально для фітнес-застосунків і розумних годинників) потрібні жорсткіші та ґрунтовніші ТОМs, аніж для захисту бази даних з ніками користувачів онлайн-гри.
GDPR вимагає, щоб власник запроваджував технічні й організаційні заходи, зокрема внутрішні політики, механізми мінімізації обробки даних, псевдомінізації даних, прозорості обробки даних. Розробляючи та плануючи архітектуру застосунків, сервісів і продуктів, спрямованих на обробку або використання персональних даних, розробники мають брати до уваги право на захист персональних даних і право на приватність.
Самостійно провести оцінювання на предмет комплаєнсу власного бізнесу з GDPR важко, тому гарним початком стане безпековий і юридичний аудит. Безпековий аудит виявить проблеми з технічними заходами, а юристи зможуть правильно налаштувати організаційні моменти й оцінити внутрішні політики.
Для невеликих і середніх компаній (<100 співробітників) буде досить зовнішнього професійного аудиту та DPO/ІТ-юриста з досвідом роботи з GDPR compliance. Стаття 25 (3) GDPR передбачає можливість сертифікації для комплаєнсу з вимогами GDPR. Це означає, що якщо власника сертифікували в одній з країн ЄС, контрольні органи враховуватимуть це у своєму глобальному оцінюванні відповідності GDPR, зокрема стосовно PbD.
Великі ІТ-компанії та компанії, які працюють на ринок ЄС, можуть розглянути можливість отримання такої сертифікації, умови якої кожна європейська держава визначає самостійно (ґрунтовно таку сертифікацію та критерії описала Європейська рада з питань захисту даних). Також наявний окремий варіант сертифікації за стандартом ISO:27001, який хоч і не створений спеціально для GDPR, але буде корисним для організації керування інформаційної безпеки в міжнародній компанії. Сертифікація добровільна й не звільняє від відповідальності за порушення.
Тобто захист персональних даних і приватність — чинники, які треба враховувати насамперед архітекторам ПЗ під час планування нових рішень та бізнес-аналітикам при визначенні вимог до продукту.
ІТ-юрист + програміст = ?
Нестача кваліфікованих кадрів і нормальної комунікації між юристом і айтішником — джерело більшості проблем, що стосуються комплаєнсу загалом і PbD зокрема. Тому компаніям у буквальному значенні цього слова доводиться налагоджувати процес методом спроб і помилок. Learning by doing, як-то кажуть.
З ускладненням правових вимог до ІТ-компаній з’явилося розуміння, що вже не можна обійтися юристом загальної практики, який «напише фопівський договір» і «шаблон для контрактів». Потрібні фахівці з інтелектуальної власності, міжнародних контрактів на розробку ПЗ і захисту персональних даних. Для невеликих компаній і студій буде досить мати юриста на аутсорсі, до якого звертаються кілька разів на місяць. Але зі збільшенням кількості клієнтів, зростанням компанії та ускладненням процесів з’являється потреба в in-house ІТ-юристі, а в разі роботи на ринок ЄС — і в Data Protection Officer.
Призначення DPO в ІТ-компанії — вимога GDPR, за винятком ситуацій, коли компанія взагалі не працює з персональними даними громадян країн ЄС. Єдина вимога до кваліфікації DPO — «експертне знання права захисту персональних даних». DPO підзвітний найвищому менеджменту компанії, фактично незалежний у здійсненні своєї діяльності (GDPR забороняє давати DPO вказівки щодо його/її обов’язків) і не має бути юристом.
Якщо в компанії є кваліфікований юрист або юридичний відділ, то роль DPO може виконувати спеціаліст у галузі інформаційної безпеки, який має розуміння GDPR. Залежно від специфіки компанії бекграунд спеціаліста може бути в compliance, system administration, DevOps, information security. Опитування, проведене International Association of Privacy Professionals, показало, що більшість з опитаних хочуть найняти in-house DPO з досвідом на посадах compliance specialist, IT specialist або non-technical manager з як мінімум 5 роками професійного досвіду.
Більшість також зазначили, що DPO буде підзвітний тільки Раді директорів компанії. У міжнародних корпораціях зазвичай є Global DPO й окремі DPO для кожної юрисдикції. Для невеликих компаній, які не можуть дозволити собі розділення ролей, виходом буде найняти DPO з юридичним бекграундом і забезпечити йому/їй технічну підтримку чи найняти DPO на аутсорс.
На нашу думку (але це не вимога GDPR), DPO чи відповідного спеціаліста також треба прилучати до деяких фаз SDLC для забезпечення дотримання принципу PbD й GDPR загалом.
Зокрема, DPO має брати безпосередню участь у плануванні архітектури продукту чи рішення, а також в аналізі вимог до такого продукту. DPO не обов’язково змушувати розбирати код, але його слід ознайомити з тим, які персональні дані збираються в користувача та яким чином вони використовуються, а також показати «рух» персональних даних. Це потрібно для того, щоб запобігти розробці вирішення, яке свідомо не відповідатиме вимогам GDPR.
DPO може бути одним зі спеціалістів, що братиме участь у імплементації рішення, зокрема для того, щоб не допустити «зрізання кутів» ціною законності. Також є корисною участь DPO в рев’ю проєкту, де можна дійти висновків і розробити економніші й ефективніші вирішення для забезпечення приватності та захисту персональних даних.
Зрозуміло, що кожна ІТ-компанія, а часом навіть і команда, мають власне бачення SDLC. Зазначене вище вирішення аж ніяк не претендує на повноту й безальтернативність, а радше є спробою мотивувати ІТ-компанії залучати DPOs і ІТ-юристів до SDLC.
Релевантність для України
На перший погляд може здатися, що PbD вартий уваги лише продуктових ІТ-компаній, які працюють на європейський ринок або мають представництво в ЄС, бо GDPR поки не поширюється на територію України. Проте все не так просто. Справді, поки немає докладних ухвал вищого судового органу ЄС — Суду справедливості — щодо застосування GDPR і PbD до іноземних компаній. Практика штрафів проти компаній, зареєстрованих поза ЄС, нерозвинена, бо поки незрозуміло, як DPAs зможуть проводити інспекції та виписувати штрафи на територіях третіх країн.
Цілком можливо, що державні органи вимагатимуть заборони діяльності таких компаній у ЄС і блокування доступу до їхніх ресурсів. Ініціативи ЄС вплинули навіть на США, де окремі штати (радимо ознайомитися з California Consumer Privacy Act і New York Privacy Act) ухвалюють або планують ухвалити власні закони про захист персональних даних.
Україна поки не має GDPR-подібних законодавчих ініціатив, хоча ухвалення такого законодавства може відбутися в рамках імплементації Угоди про Асоціацію з ЄС. Але з власного досвіду та зі спостереження за ринком можемо сказати, що все більше європейських компаній порушують тему GDPR у своїх переговорах з українськими аутсорсами.
Європейські стартапи та великі компанії з обережністю ставляться до персональних даних своїх користувачів і висувають серйозніші вимоги щодо приватності. Клієнти сподіваються отримати не просто технологічне рішення, а рішення, яке буде відповідати стандартам ЄС. У деяких конкретних кейсах, з якими стикалися автори, клієнти з Європейської економічної зони (куди входять ЄС і низка інших країн) навіть розглядали можливість призначення DPO в Україні з метою передати на аутсорс увесь свій проєкт разом з персональними даними. Окрім того, від техлідів, рекрутерів, PM і BA вимагатимуться навички роботи з персональними даними та бодай базові знання GDPR.
Висновки
GDPR «в силі» менш як два роки, але певні результати вже помітні. Нагляд за дотриманням GDPR ставатиме суворішим, як і вимоги європейського бізнесу до якості коду. До PbD додаються проблеми передачі персональних даних в Україну, не завжди оформлений належним чином допуск українських розробників до серверів з даними європейських компаній, елементарне незнання положень GDPR як європейськими замовниками, так і українськими розробниками. Українським ІТ-компаніям — як продуктовим, так і аутсорсам — уже замало бути GDPR-aware, а треба ставати проактивними у розробці своїх TOMs, щоб бути готовими до конкуренції на ринку.
