GDPR compliance: відповідність GDPR у 2027. Кращі практики

Ще кілька років тому «GDPR compliance» означало приблизно таке: зробили privacy policy, банер cookies, RoPA, підписали DPA з підрядниками. Було зручно, бо багато хто працював за чеклистами: покривав публічну сторону приватності (публікував privacy notice і публічний DPA), проводив стандартний тренінг, купував стандартний плагін для cookie-банера, і реагував на всі запити субʼєктів даних, які встигав перехопити у команди сапорта. Але 2027 рік принесе багато нових викликів і челенджів; про них і поговоримо в цій статті. 

Календар на найближчі півтора року виглядає так:

• до 9 грудня 2026 року держави-члени мають імплементувати нову Product Liability Directive, яка застосовується до продуктів, виведених на ринок після цієї дати; 
• 2 квітня 2027 року починає застосовуватися Регламент (ЄС) 2025/2518 про додаткові процедурні правила забезпечення GDPR; 
• 2 грудня 2027 року вступають в силу норми про обов’язки AI Act для окремих high-risk систем з Annex III; і, зрештою, 
• 11 грудня 2027 року вже діятимуть основні обов’язки Cyber Resilience Act.

Що таке GDPR compliance

На рівні ЄС. GDPR є регламентом: він діє напряму, і його не треба імплементувати національним законом. Тому для багатьох компаній «GDPR compliance» звучить як один стандарт для всього ЄС. Насправді це рамка з чотирма рухомими частинами:

• Текст регламенту: принципи ст. 5, законні підстави ст. 6, права суб’єктів ст. 12-22, privacy by design ст. 25, безпека ст. 32, повідомлення про інциденти ст. 33-34, DPIA ст. 35, передачі даних розділ V тощо.
• Позиції EDPB: guidelines, opinions і щорічні скоординовані перевірки (наприклад, у 2026 році EDPB запустив п’яту скоординовану дію, цього разу щодо обов’язків прозорості й інформування за ст. 12-14 GDPR, у якій беруть участь 25 органів із захисту даних).
• Практика Суду ЄС: вона регулярно додає пояснення різним визначенням або концептам GDPR, наприклад, щодо нематеріальної шкоди чи псевдонімізації.
• Процедура примусу до виконання GDPR: механізм one-stop-shop і те, як органи взаємодіють у транскордонних справах.

Рівень держав-членів. GDPR є регламентом, але містить також і так звані “відкриті положення”, що залишають державам-членам чимало простору для регулювання національними законами. Тому в різних країнах застосування помітно відрізняється, зокрема щодо: 

• згоди дитини на обробку даних (держави можуть встановлювати поріг від 13 до 16 років; для продукту з дитячою аудиторією це різні потоки згоди в різних країнах); 
• обов’язкове призначення DPO (держави можуть додавати більше порогів для обовʼязкового призначення DPO: Німеччина, наприклад, встановлює цей обовʼязок за умови досягнення певної кількості співробітників, що постійно працюють з автоматизованою обробкою даних); 
• трудових відносин (держави можуть приймати спеціальні норми для трудових відносин, зокрема щодо моніторингу та рекрутингу); 
• роботи органів нагляду (у Німеччині нагляд децентралізований, у Ірландії сконцентровані великі технологічні компанії і він повільно реагує, в Іспанії багато невеликих штрафів тощо) і багатьох інших аспектів. 

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

Країни поза ЄС. Але не варто ігнорувати бізнес-одиниці, що беруть участь в обробці даних, але не знаходяться в ЄС. Наприклад, 

• після Brexit Велика Британія має власну версію GDPR: UK GDPR, Data Protection Act 2018 і нещодавній Data (Use and Access) Act 2025 (DUAA). Для компаній, які працюють у ЄС і у Великій Британії, це вже два різні режими, хоча й близькі, і їх потрібно враховувати і намагатися поєднати у своїй системі комплаєнсу; 
• Швейцарія має власний оновлений закон, який теж дуже близький до GDPR, але не ідентичний; 
• Бразилія має власне законодавство, що структурно близьке, але досі розвивається і активно впроваджується бразильськими компаніями; 
• Китай використав GDPR як шаблон, але створив власну, доволі ефективну і керовану систему правил для обробки даних китайських користувачів. Китай має дуже активного і зацікавленого регулятора, швидко реагує на соціальні та технологічні зміни, і запозичує регуляторні тренди з усього світу, але це призводить до того, що compliance більше схожий на “документований звіт регулятору”, ніж на внутрішню політику, націлену на соціальне благо у формі крайнього виявлення прав людини; 
• Індія також сильно реформувала свій режим регулювання персональних даних: основні обов’язки (інформування про обробку, безпека, повідомлення про порушення, права суб’єктів тощо) застосоватимуться з 13 травня 2027 року; тим не менш, модель “notice and consent” та Consent Managers відрізняється від логіки GDPR, тому ця різниця має враховуватися при побудові процедур обробки персональних даних; 
• а в Україні ще очікуються зміни: законопроєкт №8153 “Про захист персональних даних” було ухвалено в першому читанні 20 листопада 2024 року з метою наблизити регулювання до стандартів ЄС, але поки що подальшого прогресу не видно, хоча і очікується. 

Окремо згадаємо про транскордонні передачі. Ризик від використання американських провайдерів послуг з обробки даних нікуди не зник. Загальний суд ЄС підтвердив чинність Data Privacy Framework у вересні 2025 року, але це рішення  було оскаржене (справа C-703/25 P). Тому не будуйте архітектуру так, ніби DPF – це остаточна відповідь: тримайте запасний механізм (наприклад, BCR, SCC або пряму згоду) з оцінкою впливу передачі.

Як загалом виглядає GDPR compliance

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

Системи (технічні заходи). Тут живе те, що видно в коді та інфраструктурі: класифікація даних, retention-джоби, механізми видалення та експорту, контроль доступу, шифрування, логування без зайвих персональних даних, consent-механізми, lineage (звідки прийшли дані, куди пішли). Головне питання цього шару: чи можемо ми знайти всі дані про людину і зробити з ними те, що вимагає закон? Якщо ні, то статті 15, 17 і 25 виконуються лише на папері. 

Процеси (організаційні заходи). Це те, що відбувається щодня: як обробляється DSAR (запит на доступ до даних від субʼєкта даних), хто вирішує, чи потрібен DPIA до нової фічі, як онбордяться нові постачальники, як команди реагують на інциденти у безпеці даних. Сюди ж належить новий вимір відповідальності: після 9 грудня 2026 року PLD застосовується до нових продуктів, тобто у випадку позову до компанії суд може вимагати розкрити докази комплаєнсу, і невиконання такої вимоги може створити презумпцію дефектності продукту, який створює ваша команда. Тобто внутрішні процеси щораз більше стають потенційними судовими доказами: обліковуйте їх і плекайте. 

Документація. Класичний набір: RoPA, DPIA, LIA, TIA, DPA, політики та повідомлення про приватність, реєстр інцидентів, реєстр запитів суб’єктів. Тут найчастіша помилка – це трактувати документи як самоціль. Документ корисний, лише якщо його можна звірити з реальністю і застосувати. RoPA, який не збігається зі станом систем, гірший за відсутній, бо створює хибну впевненість. DPIA, який не призводить до виявлення ризиків і їхнього подолання, є тільки ширмою для комплаєнсу. 

Культура, публічна позиція та маркетинг. Політика приватності – це не тільки юридичний додаток; це уже де-факто публічна заява компанії про те, як вона поводиться з даними. Її читають три аудиторії: користувачі, регулятори і конкуренти. Тобто розбіжність між тим, що написано у політиці, і тим, що відбувається в системі, це вже не абстрактний ризик. З маркетингом та ж історія: коли справа доходить до banner cookies, підписок, відстеження, збагачення профілів, то функція комплаєнсу у компанії буде стикатися з опором і комерційними інтересами. Тому важливо вибудувати довірливі та функціональні стосунки з менеджментом і маркетологами: вони здатні як за хвилину знищити всі зусилля комплаєнс-команди, так і кратно підсилити. Інколи маркетинг пропонує компроміс у приведенні лише найбільш помітної функції (наприклад, текстів на сайті) у комплаєнс, а все інше лишити більш дружнім до комерційних інтересів компанії. Ми у Legal IT Group ще у 2021 році виділяли імітацію privacy compliance як один із ключових ризиків, і відтоді цей ризик тільки зріс: коли документи є, а систем, які їм відповідають, немає, то це швидше за все побачить регулятор або постраждала особа, а не ви. Це доволі прикрий поворот у долі компанії, тож краще до нього не доводити і не витрачати сил на красиву картинку замість поступового вибудовування зрілої програми. 

Є ще і прихований (у всіх сенсах) пʼятий шар комплаєнсу: дані працівників і контрагентів. По-перше, працівники теж суб’єкти даних: HR-системи, моніторинг, рекрутинг, внутрішні розслідування, BYOD є легітимними елементами політики приватності, які не можна ігнорувати. Держави-члени часто мають окремі правила для обробки даних працівників (дивіться ст. 88 Регламенту), тому “глобальна HR-політика” рідко може працювати без локальних адаптацій. По-друге, часто з-під погляду комплаєнс-команд ховають підрядників, субпроцесорів, SaaS-сервіси, AI-провайдери. Це помилка: тут комплаєнс означає не лише підписаний DPA, а й розуміння того, куди фактично йдуть дані, чи навчають на них моделі, який механізм передачі та які залишкові ризики, і що компанія збирається робити з цим.

Кращі практики

Будуйте гнучкі системи, готові до змін

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

• Параметри замість констант. Строки зберігання, вікові пороги для згоди, набори обов’язкових повідомлень і сповіщень для інформування субʼєкта даних про обробку, перелік підстав обробки не мають бути зацементованими для всіх типів користувачів у всьому світі. Вони мають жити в конфігурації, прив’язаній до конкретної юрисдикції та цілі обробки. Слідкуйте за власними ринками. 
• Розрізняйте рівні ідентифікованості даних. Реформа GDPR, якщо вона втілиться у зміни до GDPR, найімовірніше, чіпатиме межу між псевдонімізацією й анонімізацією (з огляду на потребу врегулювання використання ШІ). Якщо у вашій системі це різні класи даних із різними правилами, то зміна закону – це різниця в одному правилі. Якщо ж усі дані – це однорівневі “персональні дані” без градацій, то це потягне переробку всієї схеми і створення правил. Багато роботи! 
• Маркуйте мету обробки (наприклад, як метадані). Дані з міткою про мету обробки легко переглянути, коли змінюється закон або з’являється нова мета. Дані без мітки доведеться реконструювати з пам’яті команди (якщо команда ще та ж, що була при створенні цього масиву даних).
• Будуйте юрисдикційність як модуль. Це включатиме створення feature flags за країнами, окремі шаблони повідомлень, окремі consent-потоки. Правило “комплаєнс за найсуворішим законом” звучить привабливо, але на практиці часто призводить до надмірних обмежень там, де вони не потрібні, і водночас пропускає локальні особливості, яких немає в найсуворішому законі.
• Не покладайтеся на один механізм передачі даних. Страхуйте свої потоки. Краще давати трохи більше безпеки користувачам, ніж лишити їхні дані без нагляду у країні, яка не дотримується GDPR навіть у похідній формі (міжурядових угод на кшталт DPF).

Враховуйте комплементарне законодавство

GDPR тепер працює в синергії (переважно, але не завжди, звісно) з іншими актами.

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

Акт	Що додає до GDPR	Практична точка перетину
AI Act	Fundamental rights impact assessment (ст. 27) рухається за таймлайном high-risk і відкладена до 2 грудня 2027 року. Максимальні штрафи не змінилися: €35 млн/7%, €15 млн/3%, €7,5 млн/1%.Також додає нові вимоги до документації, керування даними, безпеки та навіть повідомлень для користувачів.	DPIA і FRIA для одного й того самого use case мають узгоджуватися.
Cyber Resilience Act	Виробники мають подати раннє попередження протягом 24 годин, а повне повідомлення протягом 72 годин, і фінальний звіт через 14 днів після усунення вразливості або обробки інциденту. Штрафи до €15 млн або 2,5% світового обороту.	Один інцидент може одночасно вимагати сповіщення за GDPR (72 години), CRA і NIS2. Потрібен єдиний процес, а не три окремі під кожен акт.
Product Liability Directive	Програмне забезпечення та AI прирівняні до продуктів; відшкодовується також втрата чи пошкодження даних, не пов’язаних із професійною діяльністю; суд може зобов’язати розкрити докази комплаєнсу.	Документація стає доказом у справі, а не лише «оберегом від регулятора».
NIS2, DORA	Управління кіберризиками, ланцюги постачання та інші вимоги.	Спільні вимоги до безпеки та інцидентів (поміж багатьох інших вимог до відповідальності, документації, сповіщень, інцидентів, навчання…).

Практична рекомендація: створіть єдиний реєстр контролів, у якому кожен контроль прив’язаний до всіх актів, що його вимагають. Тоді тест “чи працює шифрування на цьому сховищі?” дає доказ одразу для GDPR ст. 32, CRA та NIS2.

Автоматизуйте приватність там, де це можливо

Автоматизація може тут працювати і надзвичайно ефективно, але лише якщо чітко розділити, що можна автоматизувати, а що ні.

Що варто автоматизувати:

• Data discovery і lineage. Проводьте регулярне сканування сховищ і систем на персональні дані та автоматично будуйте карти потоків – бо це основа для RoPA, DSAR і retention.
• Синхронізація RoPA із реальністю. RoPA, що генерується або перевіряється на основі інфраструктури та даних, а не пишеться вручну раз на рік (на вже неактуальних даних через пришвидення розробки). 
• DSAR-пайплайни. Збір, верифікація, експорт, видалення за єдиним workflow з журналом дій – ідеальні кандидати на автоматизацію. 
• Retention. Автоматичні джоби видалення чи анонімізації, привʼязані до політики зберігання, з правами доступу до них для різних категорій користувачів. 
• Перевірки у CI/CD. Ви можете піти навіть далі і вбудувати автоматичні privacy-перевірки прямо в процес розробки: перед деплоєм код і конфіг перевіряються на порушення, як лінтер, але для комплаєнсу. 
• Генерація документів і коду. Шаблони документації, чек-лісти для PR та правила й скіли для AI-асистентів розробки: все це теж може пригодитися для автоматизації комплаєнсу. 

Що автоматизувати не варто (або лише з людиною в циклі прийняття рішень):

• вибір законної підстави і оцінка законного інтересу;
• висновок “DPIA (не) потрібен” або автоматична генерація DPIA;
• рішення про передачу даних до третьої країни;
• оцінка того, чи є щось справді анонімним.

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

Враховуйте штрафну практику і плани регуляторів

Регулятори різні, і це треба брати до уваги при плануванні.

Спочатку загальна картина: за даними DLA Piper, у 2025 році наглядові органи наклали приблизно €1,2 млрд штрафів, а загальна сума з травня 2018 року досягла €7,1 млрд; кількість повідомлень про порушення зросла на 22% і в середньому становила 443 на день. Тобто активність висока й стабільна, а не спалахами продуктивності: регулятори мають річні цілі і виконують їх. 

Але для планування важливіші деталі:

• Тематичні кампанії. Скоординовані перевірки EDPB часто заявляють про тему наперед. Наприклад, у 2026 році це була прозорість. Практичний наслідок: якщо ви ще не переглядали свої повідомлення про приватність (тобто політики приватності та різні сповіщення на сайтах і застосунках на точках збору даних), то зараз найкращий момент.
• Різні стилі роботи у різних органів. Одні реагують переважно на скарги, інші проводять власні перевірки за плановими темами, а деякі органи публікують річні пріоритети перевірок. Для кожного ключового ринку варто зробити коротку “картку регулятора”: хто це, як швидко відповідає, які теми пріоритетні, який типовий розмір санкцій.
• Відшкодування збитків. Штрафи це лише частина картини. Суди ЄС розглядали низку справ про компенсацію, зокрема щодо критеріїв вимог про нематеріальну шкоду. Готуйтесь до найгіршого, сподівайтесь на краще, слідкуйте за оновленнями у директивах, законах та практиці судів у ключових юрисдикціях.

Тестуйте приватність і зберігайте докази, успішні й неуспішні

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

Що тестувати:

• DSAR end-to-end. Створіть тестового користувача, зробіть запит на доступ і видалення й перевірте, чи справді дані зникли з усіх сховищ, кешів, бекапів і аналітики.
• Consent-потоки. Чи справді відмова від відстеження зупиняє відстеження, а не лише ховає банер?
• Retention. Чи видаляються дані після спливу строку зберігання? Чи співпадає він з публічними заявами? А що з бекапами?  
• Інцидент-реагування. Навчання за сценарієм (tabletop) із реальними таймерами: 72 години за GDPR, 24 години за CRA. Хто програє – наступний місяць слідкує і розслідує всі інциденти! 
• AI-системи. Тести на витік персональних даних, prompt injection, обхід обмежень, і це лише початок…
• Передачі даних. Чи справді дані залишають дозволені регіони? А які регіони у використовуваного SaaS-ПЗ? 

Два слова (ну трішки більше, ніж два!) про докази. Головна ідея цієї практики: зберігайте докази не лише успішних тестів, а й неуспішних теж. Це звучить контрінтуїтивно, але це важливо, тому що:

• неуспішний тест із записом про виправлення та повторним успішним тестом – це найкращий доказ того, що ваша програма працює. Він показує, що ви шукали проблеми, знаходили їх і усували;
• ідеальна історія “все завжди працювало” виглядає підозріло і, як правило, не витримує першого ж запитання регулятора;
• ця логіка узгоджується з принципом підзвітності: за ст. 5(2) GDPR ви маєте вміти демонструвати відповідність, а не просто заявляти про неї, і процес тестування тут є очевидним продовженням процесу створення будь-якого бізнес-процесу;
• слабка документація або нездатність пояснити рішення (зокрема, посиланням на проведене тестування) можуть збільшувати регуляторний ризик.

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

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

Замість епілогу: greenfield і brownfield-комплаєнс

Порада “зробіть усе правильно” одна й та сама для нових і старих систем, але шлях у них буде різний.

Greenfield: коли продукт (і компанія) тільки будуються

Це найкращий момент для закладання комплаєнс-принципів і його найчастіше проґавлюють. Що варто зробити:

• Карта даних до схеми бази. Спочатку відповісти на питання: які дані, навіщо, на якій підставі, як довго, де зберігаються, а вже потім проєктувати таблиці.
• Privacy-вимоги в беклозі нарівні з функціональними. Кожна історія має відповідь на питання «чи торкається ця система персональних даних?».
• Видалення як функція з першого дня. Якщо архітектура не дозволяє чисто видалити дані, це дешево виправити на початку і дуже дорого глибоко в процесі.
• Дефолти на користь приватності: мінімум збору, короткі строки, вимкнене за замовчуванням відстеження. Економите простір на сховищі і ризики від витоків даних. 
• Вибір постачальників з урахуванням їхнього комплаєнсу, а не після інтеграції і виявлених проблем з виконанням законодавства.
• Автоматизація з початку: перевірки в CI/CD, правила для AI-асистентів, шаблони DPIA – все може допомогти (якщо будувати ці процеси правильно).

Brownfield: коли система вже працює

Тут потрібна інша логіка: не “як би ми зробили це з нуля”, а “з чого почати, щоб ризик знижувався найшвидше”:

• Виявлення. Спочатку зрозумійте, що у вас насправді є: де живуть персональні дані, включно з тіньовими копіями, кешами, бекапами й забутими сервісами. 
• Пріоритизація за ризиком. Спеціальні категорії даних, діти, великі обсяги, транскордонні передачі, AI-обробка – спершу вони, а потім вже інші тригери на кшталт даних за юрисдикціями або особливих правил для працівників.
• Швидкі перемоги. Очищення логів від зайвих персональних даних, автоматизація retention, виправлення повідомлень, відновлення DSAR-процесу. Вони дають помітний ефект за тижні і допомагають закріпити позитивний досвід у всіх залучених – це шлях до швидких перемог.
• Поступова заміна замість великого переписування. Звичайна історія для багатьох зрілих систем: нові сервіси будуються правильно, старі виводяться з обігу або оточуються захисними шарами; в сумі ситуація з захистом даних безупинно покращується.
• Реєстр толерованого privacy-боргу. Те, що не вдасться виправити зараз, має бути записане в беклог з обґрунтуванням, власником, строком і повідомленням DPO. 
• Докази від першого дня. Не чекайте “завершення” програми великого прайвасі-будівництва, фіксуйте прогрес щокварталу і рухайтесь невеликими кроками, але регулярно.

Головний ризик brownfield: парадокс “ми не можемо почати, бо все надто заплутано”. Найкраща відповідь на нього – це спланувати маленький перший крок із чітким результатом, і закріплювати цей результат.

Підсумок

Compliance у 2027 році – це не проєкт із датою завершення, а операційна здатність: знати, які у вас дані, бачити, які правила на вас діють, швидко адаптуватися до змін і мати докази того, що ви це робите (і робите правильно). 

Компанії, які збудують цю здатність один раз і належним чином, будуть витрачати на кожен наступний акт (AI Act, CRA, PLD і той, що з’явиться після них) значно менше, ніж ті, хто щоразу починає з нуля.