GDPR для українського IT-бізнесу

Коли GDPR застосовується до української компанії

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

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

• пропонують товари чи послуги фізичним особам, які перебувають у ЄС (незалежно від того, чи оплата стягується), або
• моніторять поведінку таких осіб — аналітика, профайлінг, трекінг, таргетинг.

Для української IT-галузі це означає, що SaaS-платформа з європейськими користувачами, мобільний застосунок з аналітикою, маркетплейс або сервіс аутсорсингу розробки для європейського клієнта вже сьогодні є предметом регулювання GDPR. Окремо застосовується ст. 3(1): якщо у компанії є представництво, філія чи дочірня структура в ЄС і обробка здійснюється в контексті її діяльності, Регламент діє і через цю підставу.

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

І практичне: у ланцюжку «європейський клієнт — українська компанія — українські підрядники на ФОП» GDPR застосовується до кожної ланки, а не лише до першої. Такі питання ми ведемо в межах практики IT-права.

Контролер чи обробник: від цього залежить усе

Це найважливіше розмежування GDPR, і саме його частіше за все визначають у договорі неправильно.

Контролер визначає цілі та способи обробки персональних даних. Обробник обробляє дані за дорученням контролера й у межах цього доручення.

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

А тепер типові ситуації, у яких українська компанія є саме контролером і цього не усвідомлює:

• власний продукт із користувачами з ЄС — ви самі визначаєте, які дані збирати й навіщо;
• дані власних працівників і підрядників, зокрема з ЄС;
• маркетинг і розсилки за власними базами;
• рекрутинг — резюме кандидатів із ЄС;
• аналітика та трекінг на власному сайті, налаштовані на власний розсуд.

Можлива й конструкція спільних контролерів (ст. 26 GDPR), коли дві компанії разом визначають цілі обробки: тоді потрібна окрема угода про розподіл обов’язків. Помилкова самоідентифікація як обробника там, де ви фактично контролер, означає відсутність власної правової підстави обробки, політики конфіденційності та механізмів реалізації прав — тобто порушення за кількома статтями одночасно.

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

DPA: угода про обробку даних за статтею 28

Ст. 28 GDPR вимагає, щоб відносини «контролер — обробник» оформлювалися письмовою угодою про обробку даних (data processing agreement, DPA). Це не формальність: за її відсутності порушення фіксується в обох сторін.

DPA має визначати щонайменше:

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

Що варто перевіряти українській компанії у DPA, який надсилає клієнт. По-перше, обсяг відповідальності та наявність (або відсутність) стелі — нерідко DPA покладає на обробника необмежену відповідальність за штрафи контролера. По-друге, строки реагування на запити: «протягом 24 годин» виглядає нешкідливо, поки не настає інцидент у п’ятницю ввечері. По-третє, умови аудиту: необмежене право перевірок на місці в будь-який час для невеликої компанії є реальним операційним ризиком. По-четверте, перелік субобробників: якщо ви використовуєте хмарних провайдерів і підрядників на ФОП, вони мають бути розкриті, інакше кожне залучення стає порушенням.

І окремо — внутрішній ланцюжок. Зобов’язання з DPA потрібно дзеркально перенести на договори з власними розробниками та підрядниками, у тому числі з ФОП. Про саму конструкцію такого договору — у статті про договір з розробником B2B.

Передача даних в Україну: чому потрібні SCC

Розділ V GDPR дозволяє передавати персональні дані до третіх країн на підставі рішення Європейської комісії про адекватність, стандартних договірних положень (SCC), обов’язкових корпоративних правил або інших передбачених гарантій.

Україна наразі не має рішення Європейської комісії про адекватність. Це ключовий практичний факт: передача даних з ЄС українським постачальникам послуг відбувається переважно на підставі стандартних договірних положень, і до них додається оцінка впливу передачі (transfer impact assessment) — аналіз того, чи законодавство й практика країни отримувача не підривають гарантії SCC, та які додаткові заходи застосовуються.

Що це означає на практиці для української компанії:

• SCC підписуються у правильному модулі: контролер — обробник, обробник — субобробник, контролер — контролер. Помилка з модулем робить документ неробочим;
• до SCC додаються додатки з описом передачі, категорій даних і технічних та організаційних заходів — саме їх найчастіше залишають порожніми;
• клієнт попросить описати додаткові заходи: шифрування під час передачі й зберігання, керування ключами, псевдонімізація, мінімізація обсягу даних, обмеження доступу, розташування серверів;
• окреме питання воєнного часу — безперервність і доступність: клієнти очікують резервування інфраструктури та плану відновлення, і це теж частина технічних і організаційних заходів;
• для передач до США основним механізмом залишається рамкова угода про захист даних між ЄС і США, тому ланцюжок «клієнт у ЄС — українська компанія — американський хмарний провайдер» описується окремо.

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

Представник в ЄС, відповідальна особа і документація

Представник в ЄС (ст. 27 GDPR). Компанія, яка підпадає під ст. 3(2) і не має представництва в ЄС, повинна призначити представника в Союзі. Його контактні дані зазначаються в політиці конфіденційності, і саме до нього звертаються суб’єкти даних і наглядові органи. Це реальний обов’язок, а не рекомендація, і він має власну ціну: представника наймають за договором у відповідній державі.

Відповідальна особа (DPO, ст. 37 GDPR). Призначення обов’язкове у визначених випадках — зокрема коли обробка вимагає систематичного масштабного моніторингу суб’єктів або коли масштабно обробляються спеціальні категорії даних. В інших випадках призначення добровільне, але корисне: наявність DPO є аргументом у перемовинах з європейськими клієнтами.

Privacy by design і privacy by default (ст. 25 GDPR). Для IT це означає, що вимоги захисту даних враховуються ще на етапі проєктування продукту та вбудовуються в архітектуру, а не «накручуються» після релізу. Практично: мінімізація полів у формах, налаштування за замовчуванням на користь приватності, псевдонімізація, строки зберігання, вбудовані механізми видалення й експорту даних.

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

• реєстр операцій з обробки (records of processing activities, ст. 30) — хто, які дані, з якою метою, на якій підставі, кому передає, скільки зберігає;
• політика конфіденційності, що відповідає ст. 13—14: перелік цілей, підстав, строків, одержувачів, прав і механізмів їх реалізації;
• оцінка впливу на захист даних (DPIA, ст. 35) для обробок високого ризику;
• процедура реалізації прав суб’єктів: доступ, виправлення, видалення, обмеження, заперечення, перенесення даних, із строками реагування;
• політика зберігання й видалення та план реагування на інциденти;
• угоди з субобробниками та актуальний їхній перелік.

Окремо: у структурах із релокацією перенесення інфраструктури та даних за кордон вимагає перегляду правових підстав обробки й усіх договорів з обробниками — див. статтю про релокацію IT-бізнесу.

Інциденти: правило 72 годин

Це та норма, через яку компанії отримують штрафи частіше, ніж через саму безпеку.

За ст. 33 GDPR контролер зобов’язаний повідомити наглядовий орган про порушення захисту персональних даних протягом 72 годин з моменту, коли йому стало відомо про таке порушення. Якщо повідомлення надіслано пізніше, до нього додається обґрунтування затримки. За ст. 34 суб’єкти даних інформуються без невиправданої затримки, якщо порушення створює для них високий ризик.

Обробник зобов’язаний без затримки повідомити контролера — і це пряме зобов’язання української компанії в моделі аутсорсингу. На практиці DPA встановлює ще жорсткіший строк, ніж GDPR: 24 або навіть 12 годин. Саме тому строк у DPA читають уважно до підписання.

Що для цього потрібно мати заздалегідь:

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

Відповідальність за GDPR серйозна: ст. 83 Регламенту передбачає адміністративні штрафи до 20 млн євро або до 4 % загального світового річного обороту за попередній фінансовий рік — залежно від того, яка сума більша. Для порушень меншої категорії межа становить 10 млн євро або 2 % обороту. Але для української компанії частіше болючішим є інше: розірвання договору європейським клієнтом і регресні вимоги за DPA.

Технічний бік підготовки до інцидентів ми розбираємо у матеріалі про кібербезпеку та витік даних.

Українське законодавство: чинне і те, що готується

Чинним залишається Закон «Про захист персональних даних» № 2297-VI від 1 червня 2010 року. Його останнє суттєве оновлення ґрунтувалося на Директиві 95/46/ЄС, яку 27 квітня 2016 року скасовано й замінено на GDPR. Тобто український закон побудований на правовій базі, якої в ЄС уже немає — звідси й розрив у вимогах.

Що він дає сьогодні: поняття суб’єкта, володільця й розпорядника персональних даних, вимоги до згоди, права суб’єкта (доступ, виправлення, видалення), обов’язок контролера протягом 30 днів надати суб’єкту інформацію про наявність і зміст його даних, повідомлення Уповноваженого Верховної Ради з прав людини при обробці ризикового характеру, вимогу укладати письмові договори з іноземними одержувачами при транскордонній передачі. Прямої вимоги повідомляти регулятора про витік даних чинний закон не містить — натомість передбачено фіксування інциденту й звернення до Уповноваженого в разі ризиків.

Законопроєкт № 8153 «Про захист персональних даних» зареєстрований у Верховній Раді 25 жовтня 2022 року і прийнятий за основу в першому читанні 20 листопада 2024 року. Станом на 2026 рік він не набрав чинності. Що він має змінити:

• термінологію — відповідно до GDPR і Конвенції 108+, з новими поняттями: біометричні дані, профайлінг, DPIA, реєстр операцій з обробки;
• детальні вимоги до згоди та чіткіші підстави обробки;
• інститут відповідальної особи з питань захисту персональних даних — українського аналога DPO, з обов’язковим призначенням у визначених випадках, зокрема при широкомасштабній обробці чутливих даних; одну відповідальну особу можна призначити на групу компаній;
• детальні вимоги до договору між контролером і оператором: вид і категорії даних, строк, характер і мета обробки, категорії суб’єктів, дії оператора виключно за письмовим дорученням;
• 72-годинний строк повідомлення про витік — аналогічно GDPR;
• правила транскордонної передачі та принципи privacy by design і by default.

І головна зміна — відповідальність. Якщо сьогодні санкції радше символічні, то законопроєкт передбачає штрафи, які можуть досягати 90 млн грн або 5 % річного обороту компанії. За порушення, що не призводять до прямого порушення прав суб’єктів (обробка без законної підстави, порушення принципів обробки, недостатні заходи безпеки), для юридичних осіб передбачено 0,05—0,1 % річного обороту, але не менше 30 000 грн і до 50 млн грн або 3 % обороту; для фізичних осіб — 10 000—30 000 грн за випадок, до 10 млн грн загалом. За порушення, що безпосередньо впливають на права суб’єктів (відмова в доступі до даних, порушення права на захист від автоматизованих рішень), для юридичних осіб — 0,5—1 % обороту, не менше 100 000 грн і до 90 млн грн або 5 % обороту; для фізичних осіб — 30 000—100 000 грн за випадок, до 20 млн грн.

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

Чек-лист відповідності

Порядок, у якому ми це робимо з клієнтами.

1. Визначити, чи застосовується GDPR і за якою підставою — ст. 3(1) чи ст. 3(2).
2. Визначити роль у кожному потоці даних окремо: обробник, контролер або спільний контролер. Для одного бізнесу ролі можуть різнитися: обробник щодо даних клієнтів і контролер щодо даних працівників.
3. Скласти реєстр операцій з обробки — без нього неможливо ні відповісти клієнту, ні пройти аудит.
4. Визначити правову підставу для кожної цілі обробки: згода, договір, законний інтерес, виконання обов’язку.
5. Привести в порядок DPA з клієнтами і дзеркально — договори з підрядниками й субобробниками, включно з ФОП.
6. Оформити механізм передачі: SCC у правильному модулі, із заповненими додатками та оцінкою впливу передачі.
7. Призначити представника в ЄС, якщо діє ст. 3(2) і представництва в Союзі немає; оцінити потребу в DPO.
8. Оновити політику конфіденційності під ст. 13—14 і впровадити процедуру реалізації прав суб’єктів зі строками.
9. Впровадити план реагування на інциденти з реєстром інцидентів і строками, не довшими за ті, що в DPA.
10. Задокументувати технічні та організаційні заходи: шифрування, контроль доступу, резервування, логування, навчання персоналу.
11. Визначити строки зберігання й реалізувати видалення — не на словах, а в системі.
12. Повторювати перевірку при зміні продукту, появі нових потоків даних або нових субобробників.

Найчастіші помилки, які ми бачимо: політика конфіденційності, перекладена з чужого сайту; DPA, підписаний без прочитання строків реагування та умов відповідальності; SCC без заповнених додатків; відсутність реєстру операцій з обробки; підрядники на ФОП без жодних зобов’язань щодо даних; відсутність представника в ЄС при очевидній дії ст. 3(2); план реагування на інциденти, який існує лише у презентації.

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