Технічні заходи для GDPR compliance. Що саме потрібно робити?

Чому технічні заходи важливі для GDPR?

У XXI столітті персональні дані перетворилися на цінний актив, що потребує такого ж надійного захисту, як фінанси чи інтелектуальна власність. В Європейському Союзі Загальний регламент про захист даних (“GDPR”, “Регламент”) встановлює ключові вимоги для бізнесу щодо безпеки обробки персональних даних.

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

Саме тому так званий “технологічний GDPR” (комплекс технічних заходів і вимог, закріплених у Регламенті)  слід вважати фундаментальною передумовою реального захисту даних.

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

У якій статті GDPR згадуються технічні заходи?

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

Ключові положення щодо технічних вимог закріплено у самому Регламенті. Серед обовʼязків контролера, йдеться про принципи “privacy by design” та “privacy by default” (стаття 25), які вимагають технічної побудови процесів із захисту даних на всіх етапах починаючи від планування проекту.  

До базових рішень серед “організаційних і технічних заходів”, враховуючи рекомендації зі статті 32, належать: 

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

Але не все так просто. Це не є чіткий перелік заходів, які треба імплементувати у внутрішні бізнес процеси для комплаєнсу. Це радше вказівник – які аспекти треба точно врахувати, а от заходи вже обирає сама компанія. Адже GDPR вимагає застосування “належних технічних заходів”.

Як вибрати необхідний набір технічних рішень?

Вибір заходів не є довільним – він завжди базується на оцінці ризиків (risk assessment). Європейські суди підкреслюють, що адекватність заходів оцінюється “in concreto” та “on a case-by-case basis”, тобто залежно від обставин конкретної компанії.  При цьому вибір повинен базуватися з огляду на сучасний рівень технологій (“state of the art”), витрат компанії, масштабу та цілей обробки, а головне — на реальні ризики для людей. 

Наприклад: Італійський регулятор визнав відповідальною компанію-контролера Postel S.p.A, яка не оновила ПЗ серверів Microsoft Exchange, незважаючи на відомі вразливості. Штраф за недотримання ст. 32 GDPR, тому що не було вжито “state of the art” заходів безпеки, хоча вони на той момент вже були публічно рекомендовані. Це показує, що навіть коли загроза стала відомою, відсутність активного реагування дає підставу для санкцій.

Вагому увагу також слід приділити безперервному управлінню ризиками. 

У справі щодо malicious attacks, компанія Sandbox Interactive GmbH уникнула санкцій саме тому, що до атаки вже впровадила сучасні заходи: HTTPS-шифрування, двофакторну аутентифікацію, bcrypt-хешування паролів. Зловмисник скористався вразливістю стороннього ПЗ, але регулятор визнав, що контролер застосував усі “належні технічні заходи”, тож вини немає.Інша ситуація – справа Pieces Interactive AB. Там захист був вибірковим: сторінки сайту з контактними формами не мали HTTPS. Результат – порушення статті 32 і штраф. Застосовані заходи, на думку регулятора, були недостатніми.

Хто відповідальний?

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

Детальніше про Privacy by Design та Privacy by Default

Стаття 25 GDPR вимагає, щоб компанія закладала принципи захисту даних у саму архітектуру продукту (“privacy by design”) та гарантувала мінімізацію збору й обробки за замовчуванням (“privacy by default”). 

На практиці це може виглядати наступним чином: 

• privacy by default – Новий мобільний застосунок компанії з продажу квитків онлайн збирає лише дані, без яких неможливо надати послугу, а всі опційні поля (наприклад, інформація про сімейний стан) вимкнені до явної згоди користувача.
• privacy by design – У стартапі, що аналізує рух транспорту, GPS-дані одразу псевдонімізуються: зберігаються лише координати без прямих ідентифікаторів, ключ для розшифрування тримається окремо та автоматично ротується.

Прикладом порушення принципів privacy by design і privacy by default є справа щодо впровадження “туристичного податку” міською владою Венеції. Міська рада отримала €10,000 штрафу, оскільки надмірно збирала персональні дані від осіб, які мали пільги на сплату податку. Система перевірки була надмірно складною. Кроки збору даних дублювали інформацію, а кіоски для оплати мали налаштування автозаповнення, що дозволяло бачити чужі дані.У підсумку, приватність має бути продумана та вбудована у архітектуру проекту від початку його запуску.

Шифрування 

Відповідно до GDPR шифрування є одним з основних способів “забезпечення конфіденційності, цілісності й доступності персональних даних”. Ідеться про реальний інструмент, який часто визначає, чи буде інцидент кваліфіковано як “data breach”. Наприклад, Європейська рада із захисту даних у своїх рекомендаціях (Guidelines 01/2021 on Examples regarding Personal Data Breach Notification) зазначає, що якщо викрадені дані були захищені сучасним алгоритмом шифрування, а ключі зберігались окремо, інцидент може не вимагати повідомлення суб’єктів даних. Ризик ідентифікації у такому випадку мінімальний.

Псевдонімізація 

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

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

Ключовий виклик для бізнесу – правильно обрати підхід, щоб захистити дані. 

Журналювання (логи)

Журналювання/логування (збирання технічних файлів) – це також механізм доказу, що компанія контролює обробку персональних даних. Стаття 32 GDPR прямо зобов’язує демонструвати “цілісність та доступність”, а без журналів довести це майже неможливо. 

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

Добре налаштоване журналювання у разі інциденту дає відповіді хто, коли і як отримав доступ. А значить, допомагає не лише швидко локалізувати атаку, а й довести регулятору, що контролер справді виконав обов’язок “забезпечити безпеку обробки” за ст. 32 GDPR.

Моніторинг

Стаття 32 GDPR прямо вимагає від контролера й процесора впровадження “процедур для регулярного тестування, оцінювання та перевірки ефективності технічних і організаційних заходів безпеки”. Інакше кажучи, система захисту повинна працювати в режимі постійного моніторингу. І справді, без безперервного нагляду компанія не здатна вчасно виявити інцидент і обмежити його наслідки, а це саме по собі вже порушення.

На практиці моніторинг – це ціла система виявлення та запобігання вторгненням, автоматичні сповіщення про підозрілі дії, регулярні vulnerability-сканування й тестування на проникнення. 

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

Як уникнути інцидентів безпеки?

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

Висновок

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

Саме тому реальний захист даних починається не з політик “для галочки”, а з технологічних рішень, закріплених у самій архітектурі бізнес-процесів.

Хто може допомогти з плануванням технічних заходів програми GDPR-комплаєнсу?

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

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

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