Compliance та приватність (GDPR & Data Protection): комплаєнс — це не про папірці, а про довіру клієнта

Екстериторіальність GDPR: чому Київ — не захист від Брюсселя

1.1. Де написано, що GDPR поширюється на Україну

Стаття 3 GDPR встановлює два незалежних критерії застосовності регламенту, жоден з яких не прив’язаний до місця реєстрації компанії:

Критерій 1 — критерій осілості (establishment criterion): GDPR застосовується, якщо компанія має «присутність» (establishment) на території ЄС — навіть філію, представництво або постійного представника без статусу юридичної особи. Обробка персональних даних, пов’язана з діяльністю такого закладу, підпадає під регламент.

Критерій 2 — критерій таргетування (targeting criterion): GDPR застосовується до будь-якого контролера або обробника за межами ЄС, якщо він: (а) пропонує товари або послуги суб’єктам даних в ЄС (незалежно від наявності оплати), або (б) відстежує поведінку суб’єктів даних, які перебувають на території ЄС.

Простий тест: якщо ваш сайт або застосунок доступний для користувачів з ЄС, ви збираєте їхні дані (електронну пошту, IP-адресу, cookies) і не вжили активних заходів для блокування такого доступу — GDPR застосовується до вас. Питання не в тому, де знаходиться ваш офіс, а в тому, де знаходяться ваші користувачі.

1.2. Реальні штрафи: скільки коштує ігнорування

GDPR передбачає два рівні санкцій:

До 10 млн євро або 2% річного глобального обороту — за порушення організаційних вимог (відсутність DPA, DPO, реєстрів обробки тощо).

До 20 млн євро або 4% річного глобального обороту — за порушення базових принципів (незаконна обробка, порушення прав суб’єктів, незаконні трансферти даних).

Регуляторні органи ЄС активно переслідують компанії за межами Союзу. У 2023–2024 роках мали місце прецеденти притягнення до відповідальності компаній без фізичної присутності в ЄС через їх представників або партнерів. Наведемо кілька показових прикладів.

Приклад 1. Meta Platforms (Ірландія / США) — штраф 1,2 млрд євро (2023)

Ірландська комісія із захисту даних (DPC) наклала на Meta рекордний на той момент штраф у розмірі 1,2 млрд євро за незаконну передачу персональних даних користувачів Facebook до США без належних правових гарантій після визнання Privacy Shield недійсним. Ключовий урок: недостатньо просто підписати SCC — необхідно також провести Transfer Impact Assessment (TIA) і перевірити, чи законодавство країни призначення забезпечує фактичний захист даних.

Приклад 2. TikTok (Ірландія / Китай) — штраф 345 млн євро (2023)

DPC оштрафувала TikTok за порушення принципів обробки даних дітей: налаштування приватності акаунтів неповнолітніх були встановлені як публічні за замовчуванням (порушення Privacy by Default), а батьківський контроль реалізовано неналежно. Компанія має юридичну особу в Ірландії, але сервери і материнська компанія — за межами ЄС. Урок: Privacy by Default — це не опція, а обов’язкова вимога, особливо для продуктів, орієнтованих на широку аудиторію.

Приклад 3. Clearview AI (Франція, Греція, Велика Британія та ін.) — сукупно понад 100 млн євро

Американська компанія Clearview AI, що збирала зображення облич з відкритих джерел в інтернеті для побудови бази біометричних даних, не мала жодного офісу в ЄС. Незважаючи на це, регулятори Франції (CNIL), Греції, Італії, Великобританії та інших країн наклали на неї штрафи та видали приписи припинити обробку даних резидентів своїх юрисдикцій. Справа наочно показала: відсутність фізичної присутності в ЄС не є перешкодою для регуляторного переслідування, якщо компанія обробляє дані осіб, що знаходяться на території ЄС.

1.3. Особливий статус України в контексті GDPR

Україна не визнана Єврокомісією країною з належним рівнем захисту даних (adequacy decision). Це означає, що передача персональних даних громадян ЄС до України за замовчуванням потребує додаткових правових механізмів: стандартних договірних положень (Standard Contractual Clauses, SCC), обов’язкових корпоративних правил (BCR) або іншого виняткового механізму, передбаченого статтею 49 GDPR.

Водночас Угода про асоціацію між Україною та ЄС зобов’язує Україну наблизити законодавство до стандартів ЄС у сфері захисту даних. Закон України «Про захист персональних даних» (2010, зі змінами) частково відображає ці стандарти, але суттєво відстає від GDPR за рівнем деталізації та правозастосуванням.

Data Processing Agreement (DPA): обов’язковий документ, про який часто забувають

2.1. Що таке DPA і чому він існує

Data Processing Agreement (угода про обробку даних) — це юридично обов’язковий договір між контролером (Controller) та обробником (Processor) персональних даних, передбачений статтею 28 GDPR. Його відсутність є самостійним порушенням регламенту, навіть якщо сама обробка даних відбувається законно.

DPA визначає: предмет, тривалість, характер і мету обробки; категорії персональних даних та суб’єктів даних; права та обов’язки сторін; технічні та організаційні заходи захисту; порядок залучення субпроцесорів; дії у разі витоку даних.

2.2. Controller vs Processor: найважливіша різниця

Розуміння різниці між цими ролями є фундаментальним для правильного структурування відносин та документації.

2.3. Типові помилки в аутсорсингових відносинах

IT-аутсорсинг — це середовище підвищеного ризику з точки зору GDPR. Розробник або сервісна компанія, що отримує доступ до бази даних клієнта з персональними даними, є процесором і зобов’язана укласти DPA з клієнтом-контролером.

Найпоширеніші помилки, які ми спостерігаємо на практиці:

• DPA взагалі відсутній — сторони обмежуються NDA або стандартним договором на розробку.
• DPA є, але не містить обов’язкових елементів статті 28 GDPR — наприклад, відсутній перелік технічних заходів захисту або порядок дій при витоці.
• Субпроцесори не задекларовані — розробник залучає третіх підрядників (хостинг, аналітику), не повідомляючи контролера та не укладаючи з ними окремих DPA.
• Ролі контролера та процесора переплутані — компанія вважає себе процесором, але фактично самостійно визначає мету обробки даних.
• DPA укладено, але дані фактично передаються до країн без adequacy decision без SCC.

Privacy by Design: захист даних з першого рядка коду

3.1. Що це і чому це важливо

Privacy by Design — це принцип, закріплений у статті 25 GDPR, згідно з яким захист персональних даних має бути вбудований в архітектуру продукту або системи на етапі її проектування, а не доданий як «шар» перед запуском або після перевірки регулятором.

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

Data Protection by Design: технічні та організаційні заходи захисту мають бути закладені в дизайн системи від початку (шифрування, псевдонімізація, контроль доступу, мінімізація даних).

Data Protection by Default: за замовчуванням система повинна обробляти мінімально необхідний обсяг персональних даних для конкретної мети. Тобто «максимальна приватність» — це стан за замовчуванням, а не опція.

3.2. Практичне впровадження на кожному етапі

Фаза 1. Discovery та проектування архітектури

Перед початком розробки необхідно провести Data Protection Impact Assessment (DPIA) — оцінку впливу на захист даних. DPIA є обов’язковою (стаття 35 GDPR) у разі «систематичного та масштабного» профілювання, обробки чутливих даних або публічного моніторингу. Але навіть там, де DPIA формально не вимагається, її проведення є ознакою зрілого compliance-підходу.

На цьому етапі слід визначити: які персональні дані збираються і для якої мети; правову підставу обробки (consent, contract, legitimate interest тощо); хто матиме доступ до даних; як довго зберігатимуться дані; як дані передаватимуться третім сторонам.

Фаза 2. Розробка

• Шифрування: дані в спокої (at rest) та в русі (in transit) мають бути зашифровані (AES-256, TLS 1.2+).
• Псевдонімізація: там, де можливо, замінювати прямі ідентифікатори псевдонімами або хешами.
• Принцип мінімізації даних: не збирати поля, що не потрібні для функціоналу. Якщо для реєстрації потрібен лише email — не запитуйте номер телефону.
• Контроль доступу: впроваджувати role-based access control (RBAC), принцип найменших привілеїв (least privilege).
• Логування: вести детальні журнали доступу до персональних даних для аудиту.
• Автоматичне видалення: реалізувати механізми retention policy — дані автоматично видаляються після закінчення строку зберігання.

Фаза 3. Тестування та QA

Тестові середовища не повинні містити реальних персональних даних. Використовуйте синтетичні або анонімізовані дані для тестів. Проводьте penetration testing та перевірки на вразливості до виходу в продакшн.

Фаза 4. Реліз та подальша підтримка

Ведіть реєстр обробки персональних даних (Article 30 Records of Processing Activities). Призначте Data Protection Officer (DPO) — якщо це вимагається масштабом або характером обробки. Встановіть процедуру реагування на витоки даних: GDPR вимагає повідомлення регулятора протягом 72 годин з моменту виявлення порушення.

Cookie-комплаєнс: чому кнопка «ОК» — це ще не compliance

4.1. Правова основа: GDPR + ePrivacy Directive

Cookie-комплаєнс регулюється не лише GDPR, але й Директивою ЄС про приватність і електронні комунікації (ePrivacy Directive, 2002/58/EC, у редакції 2009 року) — так звана «Cookie Law». Ці два нормативних акти діють одночасно, і дотримання одного не замінює дотримання іншого.

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

4.2. Три категорії cookies та їхній правовий режим

4.3. Що не є valid consent: типові порушення

Регулятори ЄС (особливо французький CNIL, ірландський DPC та нідерландський AP) накладали штрафи саме за неправильну реалізацію механізмів згоди. Ось що однозначно не є дійсною згодою:

• Pre-ticked boxes — попередньо відмічені чекбокси для аналітичних або маркетингових cookies.
• «Продовжуючи переглядати сайт, ви погоджуєтесь» — продовження навігації не є згодою.
• Банер лише з кнопкою «OK» або «Зрозуміло» без кнопки «Відхилити» або «Налаштувати» — це dark pattern.
• Відмова має бути такою ж легкою, як і згода — кнопка «Прийняти все» поруч з кнопкою «Налаштувати» (де відмова захована у глибині меню) визнається незаконним dark pattern.
• Відсутність granular consent — користувач повинен мати можливість окремо погодитись або відмовитись від аналітики та маркетингу.
• Не зберігається запис про надану згоду — ви повинні мати докази того, хто, коли і на що погодився (consent management records).

4.4. Що вимагається насправді: чеклист

• Consent Management Platform (CMP): використовувати сертифіковану платформу (OneTrust, Cookiebot, Axeptio тощо) або самостійно реалізовану систему, що відповідає вимогам IAB TCF 2.2.
• Cookie audit: провести повний аудит усіх cookies, що встановлює ваш сайт — включно з тими, що додаються через третіх постачальників.
• Cookie policy: окрема сторінка з описом кожного cookie, його призначення, строку дії та постачальника.
• Opt-out mechanism: можливість відкликати згоду в будь-який момент так само легко, як її було надано.
• Відсутність cookies до надання згоди: технічно забезпечити, щоб аналітичні та маркетингові cookies не встановлювалися до кліку «Прийняти».
• Оновлення при зміні постачальників: кожен новий трекінговий піксель або аналітичний інструмент вимагає оновлення cookie policy та CMP.

Рекомендації для бізнесу

5.1. Оцінка застосовності GDPR (перший крок)

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

• Чи є у вас користувачі, клієнти або контакти, що фізично знаходяться на території ЄС?
• Чи доступний ваш продукт / сайт для резидентів ЄС без блокування?
• Чи збираєте ви будь-яку інформацію (email, IP, cookies) від осіб з ЄС?
• Чи є у вас юридична особа, партнер або субпідрядник на території ЄС?

Якщо хоча б на одне запитання відповідь позитивна — GDPR застосовується. Наступний крок — gap analysis: оцінка розриву між поточним станом справ і вимогами регламенту.

5.2. Мінімально необхідний compliance-пакет для IT-компанії

• Privacy Policy: публічна, зрозуміла, актуальна. Має описувати всі операції з даними.
• Реєстр обробки (Article 30 RoPA): внутрішній документ із переліком усіх процесів обробки персональних даних.
• DPA з усіма процесорами: хостинг, CRM, email-сервіси, аналітика, аутсорс-команди.
• SCC для трансферу даних за межі ЄС: якщо ваші сервери або підрядники знаходяться поза ЄС.
• Cookie-банер та CMP: відповідно до вимог ePrivacy та GDPR.
• Процедура реагування на витоки даних: хто повідомляє регулятора, у який строк, що міститиме повідомлення.
• Процедура обробки запитів суб’єктів даних: право на доступ, виправлення, видалення (right to be forgotten), портабельність.

5.3. Коли потрібен Data Protection Officer (DPO)

Призначення DPO є обов’язковим у трьох випадках: (1) державний орган або публічна організація; (2) систематичний та масштабний моніторинг суб’єктів даних; (3) масштабна обробка спеціальних категорій даних (здоров’я, біометрія, расова приналежність тощо). Для більшості B2B IT-компаній DPO не є обов’язковим, але його наявність — значний плюс при аудитах та у відносинах з enterprise-клієнтами з ЄС.

5.4. Compliance як конкурентна перевага

Варто змінити кут зору: GDPR-комплаєнс — це не витрата, а інвестиція. Enterprise-клієнти з ЄС і США як стандартна практика проводять vendor due diligence, що включає security questionnaire та перевірку наявності DPA, Privacy Policy та внутрішніх процедур. Компанія без базового compliance регулярно програє тендери та переговори навіть там, де має кращий продукт або ціну.

Підсумки

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

• Географія офісу не має значення: якщо ваші користувачі в ЄС — GDPR застосовується до вас незалежно від того, де знаходиться ваш сервер або юридична адреса.
• DPA — обов’язковий документ у будь-яких відносинах контролер-процесор. Його відсутність є самостійним порушенням, що тягне штраф.
• Privacy by Design означає, що захист даних проектується разом з продуктом, а не додається перед релізом.
• Cookie-банер «OK» без кнопки відмови є незаконним dark pattern. Потрібна рівноцінна можливість відмовитись та granular consent.
• Compliance — це довіра клієнта, можливість укладати контракти з ЄС-замовниками та відсутність штрафів до 20 млн євро.
• Початок — gap analysis: зрозумійте, де ви знаходитесь зараз, і складіть дорожню карту до повного compliance.

Зміни у регулюванні продовжуються: очікуваний Регламент ePrivacy має замінити поточну Директиву і ще жорсткіше врегулювати cookie-практики. Компанії, що вже мають зрілу compliance-культуру, адаптуються до змін значно легше, ніж ті, хто будує процеси з нуля під тиском регулятора.

Потрібна допомога з GDPR-комплаєнсом для вашої компанії?

Barbashyn Law Firm надає повний цикл послуг з data protection compliance: від gap analysis та розробки DPA до впровадження Privacy by Design і представництва перед регуляторами ЄС.

barbashyn.law • GDPR • Data Protection • IT-право • Privacy Compliance