Відповідність GDPR: як досягти за 10 кроків у 2026 році
Багато бізнесів досі недооцінюють ризики, пов’язані з недотриманням GDPR, вважаючи, що ці правила залишаються формальністю. Проте реальність зовсім інша: тисячі штрафів за порушення і мільярди євро санкцій до кінця 2025 року показують, що регулятори активно перевіряють дотримання вимог GDPR. У цій статті ми розглянемо 10 кроків, які допоможуть захистити ваш бізнес і побудувати програму GDPR комплаєнсу щоб мінімізувати ризики в 2026 році.
Чому українським компаніям варто готуватися до відповідності GDPR
Чому питання GDPR комплаєнсу є важливим навіть для бізнесу, що зареєстрований в Україні? Все більше українських компаній планує вихід на ринки ЄС. З одногу боку, це приносить нові можливості для розвитку та зростання, але, з іншого, ще й нові обов’язки та відповідальність за обробку персональних даних громадян ЄС. А порушення правил може призвести до серйозних штрафів і репутаційних втрат. Тому компанії починають впроваджувати вимоги GDPR ще на етапі ідеї розширення на новий ринок, за довго до того як почнуть активно працювати з європейськими клієнтами. І це дійсно правильна стратегія.
Про поширення GDPR на українські компанії читайте тут: Територія застосування GDPR
Тому щоб планувати без ризиків і підготувати бізнес до GDPR, розгляньте 10 практичних кроків, які допоможуть налагодити ваші процеси обробки персональних даних і почати будувати свій комплаєнс.
1. Аудит і перевірка процесів обробки персональних даних
Перший крок для побудови програми комплаєнсу – GDPR аудит, тобто перевірка того, на якому етапі комплаєнсу ваша компанія знаходиться зараз і що потрібно змінити або додати для того, щоб привести процеси у відповідність або покращити окремі елементи обробки даних.
Що робити на практиці? Перш за все оцінити, наскільки ваш функціонал сервісу чи робочий процес включає в себе обробку персональних даних.
Про поняття “персональних даних” за GDPR читайте тут: Що таке персональні дані за GDPR?
Також варто подумати про очікування суб’єктів даних: якщо функція обробляє дані у спосіб, який може здатися неочікуваним для суб’єкта, це перший сигнал перевірити відповідність і уникнути порушень.
Тобто GDPR аудит допомагає побачити слабкі місця, закрити їх ще до запуску і системно підготувати компанію до подальшого розвитку продукту. Наступні кроки стануть логічним продовженням цього процесу.
Детальніше про те яким має бути GDPR аудит читайте тут: GDPR аудит: як провести?
2. Збираємо і оцінюємо потоки персональних даних
Після аудиту логічно перейти до наступного кроку – збору та оцінки потоків персональних даних. На цьому етапі ми вже розуміємо, які дані обробляємо, тож тепер наше завдання – зафіксувати це на папері. Важливо, що цей процес цілком може йти паралельно з аудитом.
Починаємо із запитань про те звідки до нас потрапляють персональні дані, що з ними відбувається далі, кому ми їх передаємо і хто матиме до них доступ (як в межах, так і за межами компанії).
Результати можна оформити у вигляді таблиці, схеми, діаграми або обрати будь-який інший зручний для вас формат. Головне, щоб ці схеми реально відображали ваші процеси.
Далі ці потоки варто звірити з тим, що вже задокументовано: політиками, внутрішніми процедурами, договорами з підрядниками. Дуже часто саме тут стає очевидно, що частина обробки даних існує на практиці, але ніде не описана або описана не повністю. Якщо знаходите такі прогалини – головне не ігнорувати їх, а зафіксувати і скласти план, що саме потрібно задокументувати, у якому документі і в якій послідовності.
3. Визначаємо правові підстави для обробки персональних даних
Визначення правових підстав для обробки персональних даних – це не менш важливий крок, ніж аудит чи опис потоків даних. За GDPR, кожна окрема операція з обробки персональних даних має спиратися на одну чітко визначену правову підставу і саме контролер даних несе відповідальність за цей вибір.
GDPR передбачає шість правових підстав для законної обробки персональних даних: згода суб’єкта даних, виконання договору, дотримання юридичного обов’язку, захист життєво важливих інтересів, виконання завдання в суспільних інтересах або здійснення офіційних повноважень, а також законний інтерес контролера або третьої сторони. Для більшості бізнесів на практиці найчастіше використовуються чотири підстави: згода суб’єкта даних, виконання договору, дотримання юридичного обов’язку та законний інтерес контролера або третьої сторони.
Вибір правової підстави залежить від того, навіщо і як саме ви використовуєте дані. Нижче додаємо таблицю, щоб легше зорієнтуватися, коли вашій компанії можна використовувати кожну правову підставу із чотирьох найактуальніших для бізнесу та на що слід звертати увагу, щоб не порушити GDPR.
| Правова підстава | Коли застосовується | Приклади | Можливі ризики |
| Згода суб’єкта даних | Коли обробка не є обов’язковою і користувач має вибір (тобто може надати чи не надати згоду і це не вплине на його ситуацію) | Маркетингові розсилки, cookies для аналітики чи маркетингу, персоналізована реклама | Недійсна згода або неможливість відкликання |
| Виконання договору | Коли обробка необхідна для надання послуги або виконання умов договору | Обробка платіжних даних, адреси доставки, або для реєстрації користувача на платформі | Надмірний збір та обробка даних, які не пов’язані з необхідністю виконання договору |
| Юридичний обов’язок | Коли закон прямо вимагає обробки даних | Податковий облік, бухгалтерська звітність | Використання даних для інших цілей поза вимогами закону |
| Законний інтерес | Коли обробка потрібна для бізнес-інтересів і не порушує права суб’єкта | Збір і обробка даних з CCTV, розміщення необхідних файлів cookies на сайті | Відсутність балансу інтересів, неправильна оцінка ризиків |
4. Документуємо процеси
Після того як ми визначилися з правовими підставами для обробки персональних даних, наступний крок – оформлення процесів у документах. Документи можуть бути публічними або внутрішніми. Якщо ваш сервіс доступний онлайн, почніть з розробки таких публічних документів:
- Privacy Policy (щодо того які дані збираються, з якою метою і на яких підставах);
- Cookies Policy (щодо того які файли cookies можуть розміщуватися та як їх можна відхилити);
- Data Processing Addendum (для підписання з клієнтами, якщо ви надаєте сервіс, що включає обробку даних і ви вистуваєте процесором, а клієнт – контролером).
Не забуваємо також і про cookie banner та налаштовуємо його показ користувачам, збираємо згоду на розміщення файлів cookies там, де потрібно.
Наступний етап – підготовка внутрішніх політик та процедур, які допомагають команді працювати з даними правильно і документувати всі процеси. Серед основних внутрішніх документів:
- Data Retention Policy (визначає строки зберігання даних і правила їх видалення);
- Roles and Responsibilities Policy (описує, хто за що відповідає у процесах обробки даних, включно з ролями DPO та контролю доступу);
- DPIA Procedure (процедура оцінки ризиків обробки, особливо при запуску нових продуктів чи функцій);
- LIA Procedure (процедура оцінки балансу між законними інтересами бізнесу та правами користувачів, якщо обрана правова підстава “законний інтерес”;
- TIA Procedure (оцінка ризиків передачі даних за межі ЄС);
- ROPA (обов’язковий реєстр усіх операцій обробки персональних даних).
Важливо пам’ятати, що цей перелік не є вичерпним. Конкретні документи та процедури залежать від того, які саме процеси обробки даних реалізує ваша компанія. На цьому етапі також варто визначити, чи потрібні LIA, TIA або DPIA щодо конкретних процесів обробки даних.
5. Чи потрібен DPO?
Кожен бізнес, який працює з персональними даними, рано чи пізно стикається з питанням: чи потрібен нам DPO? Регламент визначає, коли призначення DPO є обов’язковим:
- якщо організація є державним органом або органом публічної влади;
- якщо основна діяльність компанії полягає у масовій та систематичній обробці персональних даних, особливо чутливих категорій (здоров’я, расова/етнічна приналежність, політичні переконання тощо);
- якщо основна діяльність включає моніторинг поведінки осіб.
Навіть якщо ваша компанія не потрапляє під ці обов’язкові умови, призначення DPO може бути дуже корисним. Насамперед, це показує користувачам і партнерам, що ви серйозно ставитеся до захисту персональних даних і маєте окрему незалежну особу (працівника або стороннього консультанта), яка все тримає під контролем.
6. Договори з клієнтами і підрядниками про обробку персональних даних
Регламент прямо вимагає, щоб будь-яка передача даних між контролером і процесором, або між процесорами, була оформлена належним договором. На практиці це означає, що з клієнтами та підрядниками, які мають доступ до персональних даних, має бути укладений Data Processing Agreement (або якщо це публічний документ, то ще називають Data Processing Addendum). Такий договір фіксує ролі сторін, цілі та обсяг обробки, заходи безпеки, порядок залучення субпроцесорів (у разі наявності) і правила повернення або видалення даних.
Окрему увагу слід приділити міжнародній передачі персональних даних, тому що якщо дані передаються за межі ЄС або ЄЕЗ, одного DPA недостатньо. У такому випадку додатково застосовуються Standard Contractual Clauses (SCCs) (стандартні договірні положення, затверджені Європейською Комісією). Вони забезпечують належний рівень захисту даних тоді, коли країна отримувача не визнана такою, що забезпечує належний рівень захисту.
7. Технічні і організаційні заходи
GDPR не встановлює вичерпного переліку технічних і організаційних заходів, які вважаються “достатніми”. І це зрозуміло, тому що технології постійно розвиваються, з’являються нові ризики, тому й підходи до захисту даних змінюються разом із ними. Те, що було достатнім кілька років тому, сьогодні може вже не відповідати рівню загроз.
Саме тому заходи безпеки мають обиратися з урахуванням конкретної ситуації, типів персональних даних, обсягів обробки, цілей використання, потенційних ризиків для прав і свобод суб’єктів даних. Універсального списку тут немає, кожна компанія має оцінювати свої процеси окремо і впроваджувати ті заходи, які реально відповідають її ризикам.
Щодо прикладів, то до технічних заходів зазвичай належать шифрування даних, багатофакторна автентифікація, псевдонімізація або анонімізація даних, резервне копіювання, логування доступів і регулярне оновлення програмного забезпечення.
Організаційні заходи стосуються внутрішніх процесів, тобто це обмеження доступу до даних за принципом необхідності, внутрішні політики безпеки, навчання працівників, процедури реагування на інциденти, регулярні аудити щодо відповідності вимогам. Саме організаційні заходи часто визначають, наскільки ефективно працюють технічні рішення на практиці.
8. Отримали запит від суб’єкта даних: що робити?
Як опрацьовувати запити від суб’єктів персональних даних – одне з найпрактичніших питань для бізнесу. Важливо пам’ятати, що такий запит може надійти через будь-який канал: електронною поштою, телефоном, у соціальних мережах, через форму на сайті або навіть звичайним листом. Формат не має значення, тому що якщо людина звертається зі вимогою реалізації свого права, то це вже запит у розумінні GDPR.
Якщо вже отримали запит – у вас є один місяць щоб надати відповідь. Гарною практикою є одразу підтвердити отримання запиту. Далі варто перевірити особу заявника, з’ясувати суть запиту та залучити відповідальних осіб або команду, яка працює з персональними даними.
Якщо запит є складним або їх надійшло багато одночасно, GDPR дозволяє продовжити цей строк ще максимум на два місяці (тобто до трьох загалом). У такому разі важливо вчасно повідомити суб’єкта даних про продовження і пояснити причини затримки.
Важливо, що GDPR допускає можливість відмови у виконанні запиту (наприклад, якщо він є явно необґрунтованим або надмірним, або якщо виконання запиту суперечить законодавчим вимогам). Але навіть у таких випадках суб’єкта даних потрібно обов’язково поінформувати і пояснити причини відмови. Ігнорування запиту – це порушення GDPR, яке може призвести до скарг і штрафів.
9. Навчання команди
Навіть найкращі політики, договори та технічні рішення не працюють, якщо працівники не знають як правильно працювати з персональними даними на практиці. Тому саме людський фактор найчастіше і стає причиною порушень.
Загальні тренінги допомагають сформувати базове розуміння GDPR для всієї команди про те що є персональними даними, які є права суб’єктів даних, як виглядають типові ризики тощо.
Проте окрім загального навчання, ефективною практикою є цільові тренінги для окремих команд. У різних підрозділів різний рівень доступу до персональних даних і різні сценарії роботи з ними, тому універсального підходу часто недостатньо.
Спеціалізовані тренінги дозволяють глибше пропрацювати конкретні ризики. Команда маркетингу працює зі згодами і розсилками, сапорт – із запитами користувачів і доступом до акаунтів, сейлзи – з контактними даними клієнтів і договорами. Для кожної команди варто розбирати реальні кейси, типові помилки і чіткі сценарії дій.
Такий підхід робить навчання практичним і корисним. Команда розуміє як застосовувати правила, прописані в політиках, у своїй щоденній роботі, що знижує ризики порушень і підвищує загальний рівень захисту персональних даних в компанії.
10. Як часто оновлювати документацію
GDPR не встановлює чітких правил як часто компанія має оновлювати документацію з захисту персональних даних. І це знову ж таки зрозуміло, тому що бізнеси різні, процеси змінюються з різною швидкістю, а універсального підходу не існує.
Водночас є ситуації, коли оновлення документації є обов’язковим. Насамперед це стосується змін у застосовному законодавстві або регуляторній практиці. Наприклад, оновлення вимог до міжнародної передачі даних або нові рекомендації наглядових органів.
Документацію також потрібно оновлювати, якщо компанія виходить на новий ринок. Це може означати появу нових категорій користувачів, інших правових підстав для обробки або нових вимог до трансферу даних.
Ще один поширений тригер – це зміна або запуск нового функціоналу. Нові функції можуть передбачати інші цілі обробки, збір додаткових даних або інший спосіб взаємодії з користувачем.
Якщо ж змін в обробці даних не відбувалося (бізнес-модель не змінюється, нові продукти не запускаються), гарною практикою є плановий перегляд документації раз на пів року або раз на рік.
Висновки
Отже, ми розглянули 10 базових кроків, які допоможуть вибудувати програму GDPR комплаєнсу у 2026 році. Це основа, з якої варто починати, якщо компанія працює з персональними даними або планує вихід на ринки ЄС. Водночас важливо розуміти, що комплаєнс – це не одноразова дія і не набір документів, які можна підготувати на старті і більше до них не повертатися.
Бізнеси розвиваються, продукти змінюються, з’являються нові функції, нові ринки і нові ризики. Разом із цим змінюються і вимоги до обробки персональних даних, регуляторна практика та очікування користувачів. Саме тому відповідність GDPR – це постійний процес, який потребує регулярного перегляду процесів, оновлення документації, навчання команди і контролю на практиці.
Якщо підходити до комплаєнсу комплексно, він перестає бути тягарем і стає частиною бізнес-стратегії. У разі, якщо вам потрібна індивідуальна оцінка процесів вашої компанії, допомога з побудовою або підтриманням GDPR-комплаєнсу, або призначення DPO, privacy команда Legal IT Group допоможе на всіх етапах, від першого аудиту до довгострокової підтримки та розвитку вашої програми захисту персональних даних.
