Аналіз відповідності GDPR та іншим регуляторним вимогам

Zahist персональних даних — це сфера, в якій український бізнес найчастіше недооцінює ризики до моменту, коли вже надто пізно. На відміну від договірних або податкових ризиків, які накопичуються поступово, штрафи за порушення регламенту захисту персональних даних можуть бути миттєвими і нищівними. Загальний обсяг штрафів за порушення GDPR з моменту набуття ним чинності у 2018 році вже перевищив 7,1 млрд євро, з яких лише за 2025 рік накладено понад 1,2 млрд євро. Лише один штраф TikTok у травні 2025 року склав 530 млн євро за неправомірну передачу даних до Китаю.

Помилкою є вважати, що GDPR стосується лише європейських компаній. Загальний регламент захисту персональних даних (Регламент (ЄС) 2016/679) має екстериторіальну дію (ст. 3 GDPR) і застосовується до будь-якої компанії — незалежно від місця її реєстрації — якщо вона:

1. пропонує товари або послуги резидентам ЄС (навіть безкоштовні);
2. здійснює моніторинг поведінки осіб, що перебувають у ЄС;
3. обробляє персональні дані резидентів ЄС в межах діяльності у Союзі.

Тобто українська ІТ-компанія з клієнтами у ЄС, український e-commerce з європейськими покупцями, український агросектор з контрагентами у ЄС — усі вони підпадають під GDPR. До цього додаються вимоги українського Закону «Про захист персональних даних», нові регуляторні рамки ЄС (AI Act, NIS2, DORA, DSA, DMA), а для конкретних галузей — спеціальні режими (медицина, фінанси, телекомунікації).

Аналіз відповідності GDPR та регуляторним вимогам — обов'язкова процедура при:

1. роботі з персональними даними резидентів ЄС/ЄЕЗ;
2. купівлі або продажу бізнесу (M&A), залученні інвестицій;
3. виході на європейські ринки;
4. запуску нових продуктів з обробкою даних;
5. впровадженні штучного інтелекту, профайлингу, систем автоматичного прийняття рішень;
6. роботі з біометрією, медичними даними, даними дітей;
7. хмарних міграціях та зміні провайдерів;
8. укладенні значимих договорів з європейськими контрагентами (вони майже завжди вимагають GDPR-комплаєнсу).

АО «Zahist» проводить комплексний аналіз відповідності GDPR та іншим регуляторним вимогам — як для української компанії, що працює з європейським ринком, так і для контрагентів перед укладенням значимих угод. У цій статті ми розкриваємо ключові аспекти такої перевірки.

Що саме перевіряється

Аналіз відповідності GDPR — це структуроване дослідження, що дає відповіді на ключові питання:

1. Чи підпадає компанія під дію GDPR? І якщо так — у якому обсязі (як контролер, як процесор, як спільний контролер).
2. Які процеси обробки персональних даних здійснюються? Інвентаризація з повним описом.
3. На якій правовій підставі? Для кожного процесу окремо.
4. Які процедурні та технічні засоби захисту впроваджено? Чи відповідають вони ризикам.
5. Як забезпечуються права суб'єктів даних? Чи готова компанія до запитів.
6. Як організована робота з порушеннями? Чи можна виявити їх вчасно і повідомити органи протягом 72 годин.
7. Чи правомірні транскордонні передачі даних? Особливо до США, Великобританії, інших країн поза ЄЕЗ.

Етапи аналізу

1. Визначення статусу компанії та обсягу застосування

Перший крок — встановити, чи підпадає компанія під дію GDPR, і у якій ролі вона виступає:

1. контролер (controller) — особа, що визначає мету та засоби обробки;
2. процесор (processor) — особа, що обробляє дані за дорученням контролера;
3. спільні контролери (joint controllers) — кілька осіб разом визначають мету і засоби.

Це принципово важливо: обсяг зобов'язань для контролера та процесора відрізняється, як і відповідальність. Часто українські компанії називають себе «процесорами», хоча фактично є контролерами, або, навпаки, не усвідомлюють своєї ролі.

Окремо перевіряється:

1. наявність зобов'язання призначити представника в ЄС (EU Representative) за ст. 27 GDPR — обов'язково для компаній поза ЄС, що систематично обробляють дані резидентів ЄС;
2. наявність зобов'язання призначити DPO (Data Protection Officer).

2. Інвентаризація процесів обробки (Records of Processing — RoPA)

Стаття 30 GDPR зобов'язує більшість компаній вести записи про діяльність з обробки персональних даних(Records of Processing Activities, RoPA). Це не формальна папірка, а фактично основа всього комплаєнсу: без розуміння, які дані компанія обробляє, неможливо забезпечити їх захист.

Для кожного процесу обробки документується:

1. мета обробки;
2. категорії суб'єктів даних (клієнти, працівники, кандидати, контрагенти);
3. категорії персональних даних (контактні, фінансові, медичні, біометричні тощо);
4. категорії одержувачів;
5. транскордонні передачі;
6. строки зберігання;
7. технічні та організаційні заходи безпеки;
8. правова підстава обробки.

На цьому етапі майже завжди виявляються «сліпі плями»: процеси, про які юридична служба не знала, дані, які зберігаються без правової підстави, інтеграції з третіми сторонами без належного оформлення.

3. Перевірка правових підстав обробки

Стаття 6 GDPR встановлює виключний перелік правових підстав для обробки:

1. згода суб'єкта;
2. виконання договору;
3. виконання юридичного обов'язку;
4. захист життєво важливих інтересів;
5. виконання завдання у публічних інтересах;
6. легітимний інтерес.

Для спеціальних категорій даних (ст. 9 GDPR — расова приналежність, політичні погляди, релігійні переконання, дані про здоров'я, сексуальна орієнтація, біометрія, генетика) — окремі, значно жорсткіші підстави.

Перевіряється, чи має кожна обробка обґрунтовану правову підставу. Особливо часті помилки:

1. згода використовується там, де її не можна вважати «вільною» — наприклад, у трудових відносинах, де працівник не може фактично відмовитися;
2. легітимний інтерес декларується без проведення тесту балансу (balancing test) між інтересами компанії та правами суб'єкта;
3. виконання договору поширюється на всі дії, навіть ті, які не є необхідними для виконання договору (наприклад, маркетинг).

4. Перевірка згоди (Consent Management)

Якщо обробка ґрунтується на згоді, вона має відповідати жорстким вимогам ст. 7 GDPR і Керівним принципам EDPB:

1. згода вільна, конкретна, інформована, однозначна;
2. надана активною дією (мовчазна або «опція за замовчуванням» — не згода);
3. можливість відкликати так само легко, як надати;
4. ведеться аудиторський слід згоди (хто, коли, на що).

З 2024 року для онлайн-сервісів обов'язковим є Google Consent Mode v2. За даними галузевих досліджень, 67% реалізацій містять порушення — найчастіше: cookie-банери, що завантажують трекери до отримання згоди, нерівнозначні кнопки «Прийняти» та «Відхилити», тривалі та заплутані опції відмови (так звані «dark patterns»).

EDPB у 2026 році оголосив, що координована наглядова кампанія цього року сфокусована на обов'язках прозорості (ст. 12-14 GDPR) — це означає, що приклад уваги до cookie-банерів та політик конфіденційності буде підвищеною у наглядових органів усіх країн ЄС.

5. Аналіз політик та процедур

Перевіряються внутрішні документи компанії, що стосуються захисту даних:

1. Privacy Notice / Privacy Policy для зовнішньої аудиторії (клієнти, відвідувачі сайту, користувачі);
2. внутрішні політики обробки даних;
3. процедури обробки запитів суб'єктів даних;
4. процедури реагування на інциденти безпеки;
5. політики зберігання та видалення даних (Retention Policy);
6. політики безпеки та класифікації даних;
7. політики у сфері штучного інтелекту і автоматизованого прийняття рішень;
8. політики у сфері роботи з постачальниками.

Часті проблеми: політики складені роками тому, не оновлюються, копіюються з шаблонів без адаптації, суперечать одна одній.

6. Перевірка договорів про обробку (DPA)

Стаття 28 GDPR вимагає укладання Data Processing Agreement між контролером і процесором. Більшість українських компаній взаємодіє з європейськими SaaS-провайдерами, маркетинговими платформами, хмарними сервісами, аутсорсерами — і у всіх цих відносинах потрібен DPA.

Перевіряється:

1. наявність DPA з кожним процесором;
2. відповідність DPA вимогам ст. 28 (інструкції контролера, конфіденційність, заходи безпеки, повідомлення про порушення, повернення/видалення даних);
3. наявність DPA від процесорів зі своїми субпроцесорами;
4. повідомлення контролера про залучення нових субпроцесорів;
5. наявність аудит-прав контролера.

Для українських ІТ-компаній, які є процесорами для європейських клієнтів, наявність якісних DPA з усіма власними субпідрядниками — це питання збереження ключових клієнтів.

7. Транскордонна передача даних

Один із найбільш складних блоків. GDPR (Глава V) встановлює жорсткі обмеження на передачу даних поза ЄЕЗ. Дозволені механізми:

1. рішення про адекватність (adequacy decision) Європейської комісії — країна забезпечує адекватний рівень захисту. Україна має такий статус з 2025 року, що значно спрощує роботу українських компаній з європейськими даними;
2. Стандартні договірні положення (SCC) — стандартні шаблони, затверджені Європейською комісією у 2021 році;
3. Корпоративні правила, що мають обов'язкову силу (BCR) — для багатонаціональних груп;
4. сертифікації, кодекси поведінки — менш поширені;
5. виняткові випадки (ст. 49) — згода, виконання договору тощо, але лише як виключення.

Спеціальна увага — передачі даних до США. Після рішень Schrems I і Schrems II і нового EU-US Data Privacy Framework 2023 ситуація стабілізувалася, але вимагає окремої перевірки сертифікації американського партнера. Після штрафу TikTok 530 млн євро у 2025 році за неправомірні передачі до Китаю наглядові органи особливо ретельно перевіряють транскордонні передачі.

Окремий блок — Transfer Impact Assessment (TIA), обов'язковий для оцінки ризиків кожної транскордонної передачі.

8. Data Protection Impact Assessment (DPIA)

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

1. систематичної та масштабної оцінки персональних характеристик (профайлинг);
2. масштабної обробки спеціальних категорій даних;
3. систематичного спостереження у публічних місцях;
4. використання нових технологій (AI, біометрія, IoT);
5. автоматизованого прийняття рішень з юридичними наслідками.

DPIA — це не папірка для архіву, а структуроване дослідження, що має включати: систематичний опис обробки; оцінку необхідності та пропорційності; оцінку ризиків для прав і свобод суб'єктів; запропоновані заходи з мінімізації ризиків.

EDPB у березні 2026 року опублікував оновлений шаблон DPIA, що проходить публічну консультацію до 9 червня 2026 року. Сучасна практика — застосування автоматизованих платформ DPIA, які скорочують час підготовки з тижнів до днів.

9. Призначення DPO (Data Protection Officer)

Призначення відповідального за захист даних обов'язкове (ст. 37 GDPR) для:

1. державних органів та публічних установ (крім судів);
2. компаній, основна діяльність яких передбачає систематичний моніторинг суб'єктів даних у великому масштабі;
3. компаній, які масштабно обробляють спеціальні категорії даних або дані щодо кримінальних справ.

DPO має бути незалежним (ст. 38), прямо звітувати найвищому керівництву, не може отримувати інструкції щодо виконання своїх завдань, не може бути звільнений за виконання своїх обов'язків. Це означає, що DPO не може бути керівником ІТ-відділу, маркетингу або юридичної служби — інакше виникає конфлікт інтересів.

DPO може бути штатним або зовнішнім (Outsourced DPO). Для багатьох компаній зовнішній DPO — оптимальне рішення з точки зору як вартості, так і незалежності.

10. Безпека даних (ст. 32 GDPR)

Стаття 32 GDPR вимагає впровадження «належних технічних і організаційних заходів» для забезпечення рівня безпеки, що відповідає ризикам. Це не конкретний чек-лист, а ризик-орієнтований підхід. Перевіряються:

1. шифрування персональних даних (at rest і in transit);
2. псевдонімізація та анонімізація;
3. управління доступом (рольова модель, принцип мінімальних привілеїв);
4. ведення аудиторських логів;
5. регулярне тестування ефективності заходів;
6. процедури відновлення доступу після інцидентів;
7. управління уразливостями та оновленнями;
8. захист від втрати даних та несанкційного доступу.

Поширена помилка — пуста ст. 32: компанія декларує заходи, але не може довести їх реальне впровадження. EDPB у керівних принципах 2025-2026 років чітко вказує: фрагментовані логи у непов'язаних системах не вважаються доказом готовності до аудиту.

11. Реагування на інциденти (ст. 33-34)

Компанія повинна мати:

1. процедуру виявлення інцидентів;
2. процедуру оцінки ризиків інциденту;
3. готовність повідомити наглядовий орган протягом 72 годин (ст. 33);
4. готовність повідомити суб'єктів даних — у разі високого ризику для їх прав (ст. 34);
5. регістр інцидентів безпеки.

Прострочене або непровідомлення про інцидент — одна з найчастіших підстав для значних штрафів.

12. Права суб'єктів даних (ст. 12-22)

Компанія має забезпечити можливість суб'єктів реалізовувати свої права:

1. право на інформування;
2. право доступу;
3. право виправлення;
4. право на видалення («право бути забутим») — у 2025 році EDPB провів координовану наглядову кампанію саме щодо цього права;
5. право на обмеження обробки;
6. право на переносність даних;
7. право заперечення;
8. права у зв'язку з автоматизованим прийняттям рішень і профайлингом.

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

Інші регуляторні вимоги ЄС

1. EU AI Act

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

1. класифікація AI-систем компанії за ризиками (заборонений, високий, обмежений, мінімальний);
2. наявність технічної документації, систем управління якістю, людського нагляду;
3. вимоги до прозорості (повідомлення користувачів про взаємодію з AI);
4. оцінка впливу на основні права (Fundamental Rights Impact Assessment).

2. NIS2 Directive

Директива щодо мережевої та інформаційної безпеки 2.0 — поширюється на «важливі» та «суттєві» суб'єкти у визначених секторах (енергетика, транспорт, банкінг, фінансова інфраструктура, охорона здоров'я, цифрова інфраструктура, державне управління, аерокосмічний сектор, водопостачання, поштові послуги, виробництво харчових продуктів, хімічна промисловість, наукові дослідження). Українські компанії, що працюють з європейськими партнерами у цих секторах як постачальники, можуть підпадати під вимоги через ланцюги постачання.

3. DORA (Digital Operational Resilience Act)

Регламент про цифрову операційну стійкість фінансового сектору — діє з 17 січня 2025 року. Стосується банків, страхових компаній, інвестиційних фірм, провайдерів криптопослуг та їх ІКТ-постачальників (включно з третіми сторонами поза ЄС).

4. DSA/DMA

Digital Services Act (для онлайн-платформ) і Digital Markets Act (для «воріт» цифрового ринку) — встановлюють зобов'язання щодо помірації контенту, прозорості реклами, припинення поведінкового профайлингу неповнолітніх тощо.

5. CSRD/ESRS

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

6. ePrivacy

Поки що Директива 2002/58, але очікується нова Регуляція ePrivacy. Регулює cookie, електронні комунікації, прямий маркетинг.

Чому варто залучати юристів

GDPR-комплаєнс — це сфера, де помилки коштують винятково дорого. Сьогодні регулятори очікують демонстраційного, оперативного комплаєнсу — не лише наявності політик. Самостійна перевірка через шаблони з інтернету не дає реальної картини. Професійний аналіз відповідності GDPR передбачає:

1. комплексну інвентаризацію процесів обробки даних з виявленням «прихованих» процесів;
2. юридичну кваліфікацію ролі компанії (контролер, процесор, спільний контролер) у кожному процесі;
3. оцінку правових підстав з виявленням «вразливих» процесів;
4. аудит технічних і організаційних заходів захисту з точки зору достатності;
5. розробку повного пакету політик, процедур, договорів, шаблонів запитів;
6. розрахунок потенційних штрафів за виявленими порушеннями та їх пріоритизацію;
7. розробку плану усунення (compliance roadmap);
8. послуги зовнішнього DPO або підтримку штатного DPO;
9. юридичний супровід інцидентів і реагування на запити наглядових органів;
10. комплексну координацію з вимогами AI Act, NIS2, DORA, українського законодавства.