Українська компанія без офісу в ЄС: коли застосовується GDPR і що перевірити до першого європейського клієнта

Типова ситуація: українська IT-компанія або SaaS-постачальник домовляється про роботу з клієнтом із ЄС. До підписання договору контрагент просить DPA, перелік субпроцесорів, опис заходів безпеки, правила зберігання й видалення даних та пояснення, на якій підставі дані передаватимуться в Україну. І саме в цей момент з’ясовується, що компанія має окремі політики, але не розуміє, які вимоги GDPR реально стосуються її моделі.

Для бізнесу ризик тут не лише у можливій відповідальності за порушення. Непідготовленість може затримати контракт, змусити команду терміново переробляти документи або погодитися на зобов’язання, які продукт фактично не може виконати.

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

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

Так. Відсутність офісу в ЄС не звільняє українську компанію від застосування GDPR. Регламент може застосовуватися, якщо бізнес цілеспрямовано пропонує товари або послуги людям у ЄС чи відстежує їхню поведінку там. Водночас випадковий відвідувач із ЄС або сам факт договору з європейською компанією ще не дає автоматичної відповіді — потрібно перевірити конкретні операції та роль кожної сторони.

Отже, стаття 3 GDPR використовує територіальні критерії. Для української компанії практично важливі три ситуації.

1. Обробка пов’язана з діяльністю осідку компанії в ЄС. Це може бути не лише окрема юридична особа: значення мають стабільність діяльності та реальний зв’язок обробки з європейським осідком.
2. Компанія без осідку в ЄС пропонує товари або послуги людям, які перебувають у ЄС. Платність не є обов’язковою. Значення мають ознаки наміру працювати саме з цим ринком: реклама для конкретних країн, доставка в ЄС, ціни у відповідній валюті, місцеві домени, мови та інші ознаки наміру обслуговувати людей у ЄС. Самого факту, що український сайт можна відкрити з Європи, зазвичай недостатньо.
3. Компанія відстежує поведінку людей у ЄС — наприклад будує профілі, системно аналізує їхні дії для прогнозування або персоналізованої реклами. Не кожен технічний журнал є “моніторингом”, тому слід оцінювати мету, масштаб і подальше використання даних.

Окремо важливо не плутати місце перебування людини з її громадянством (громадянство людини саме по собі не є критерієм статті 3). Дані громадянина Франції, який перебуває в Україні, не підпадають під GDPR автоматично лише через його паспорт. І навпаки, український громадянин, якому цілеспрямовано пропонують послугу під час перебування в Польщі, може бути особою в ЄС у значенні цієї норми.

Для бізнесу це означає, що визначити, чи застосовується GDPR до компанії, лише за країною її реєстрації або громадянством користувачів не можна.

Наприклад, якщо український SaaS має англомовний сайт, на який випадково зайшли кілька людей із Німеччини, цього ще недостатньо, щоб автоматично поширити GDPR на весь бізнес. Але ситуація змінюється, якщо компанія запускає рекламу на Німеччину, адаптує пропозицію для цього ринку або системно аналізує поведінку людей у ЄС для персоналізації.

Тому перше практичне питання для компанії звучить не “чи є в нас користувачі з Європи?”, а “які саме операції пов’язані з людьми в ЄС і чому?”.

Цікаво: Як створити сайт та вести бізнес в інтернеті: юридичні аспекти для створення сайту

Розподіл ролей між контролером та процесором персональних даних

Для B2B-компаній це одна з найчастіших точок плутанини. Сам факт договору з компанією з ЄС не означає, що кожна операція українського постачальника автоматично підпадає під GDPR за статтею 3(2). Але вимоги захисту даних все одно можуть зайти у проєкт через договір і вимоги самого клієнта.

Український розробник або SaaS-постачальник часто обробляє дані не для власних цілей, а за інструкціями європейського клієнта. У такій частині відносин українська компанія може бути процесором, а клієнт — контролером.

Сам факт, що процесор продає послуги компанії з ЄС, не тотожний пропозиції товарів або послуг людям у ЄС за статтею 3(2). Проте європейський контролер зобов’язаний залучати процесорів із достатніми гарантіями та укласти договір за статтею 28. 

Що це означає для бізнесу? Навіть якщо пряме застосування GDPR до всіх ваших операцій потребує окремої оцінки, європейський клієнт може перевіряти безпеку, субпроцесорів, міжнародне передавання даних, порядок реагування на інциденти та зміст DPA ще до підписання основного контракту.

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

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

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

Сім кроків аудиту перед підписанням договору DPA з контрагентом із ЄС

Сильна підготовка — це не найдовша Privacy Policy. Контрагенту важливо бачити, що документи, договори, технічні процеси і реальний шлях даних не суперечать один одному. До підписання контракту варто пройти сім перевірок.

Зрозуміти, які саме операції підпадають під GDPR

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

Така карта допомагає не створювати GDPR-проєкт наосліп. В однієї компанії частина операцій може прямо підпадати під Регламент, інша — регулюватися вимогами через договір із клієнтом, а частина взагалі не мати зв’язку з ЄС.

Отже, практична вигода такого аналізу — не витрачати ресурси на вимоги, які не стосуються конкретної операції, і водночас не пропустити ті, які реально перевірить клієнт.

Правильно розподілити ролі контролера і процесора

• Контролер визначає цілі та істотні засоби обробки.
• Процесор діє від його імені та за документованими інструкціями.

Назва сторони в договорі не вирішує питання, якщо фактична поведінка інша.

Від ролі залежать повідомлення людям, відповіді на запити, договір за статтею 28, залучення субпроцесорів, повідомлення про інциденти та розподіл відповідальності. Тому недостатньо взяти договірний шаблон, у якому українську компанію вже названо “processor”. Спочатку потрібно перевірити, чи відповідає цьому реальна модель роботи.

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

Перевірити шлях даних із ЄЕЗ до України

Україна не входить до переліку країн, щодо яких Європейська комісія ухвалила рішення про належний рівень захисту. Тому передавання даних із Європейської економічної зони до української компанії зазвичай потребує іншого механізму глави V GDPR.

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

Якщо ж український отримувач уже прямо підпадає під GDPR за статтею 3 щодо цієї обробки, чинні положення 2021 року не слід підставляти механічно. Європейська комісія пояснює, що цей набір не розрахований на імпортера, до якого GDPR уже застосовується. Механізм передавання в такій ситуації оцінюють окремо.

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

Наприклад, навіть якщо сам український SaaS отримує дані від клієнта за належним механізмом, потрібно також розуміти, чи передає він їх далі хмарному сервісу, службі підтримки або іншому підряднику. Саме тому перевіряється весь маршрут даних, а не лише договір між двома основними сторонами.

Підготувати пакет доказів, а не одну політику

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

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

І варто розуміти, що тут мета підготовки — не зібрати найбільшу можливу папку документів. Ні.

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

Також може бути цікаво:  Документи для айті: юридична безпека ІТ-розробників

Перевірити, чи потрібні представник у ЄС і DPO

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

DPO потрібен не кожній компанії. Стаття 37 пов’язує обов’язок, зокрема, з регулярним і систематичним великомасштабним моніторингом або великомасштабною обробкою особливих категорій даних як основною діяльністю. Якщо обов’язку немає, компанія все одно має визначити відповідального за процеси та комунікацію.

Перевірити, чи продукт здатний виконати те, що написано в документах

Політика може бути юридично грамотною, але цього недостатньо. Користувач повинен мати реальну можливість отримати доступ до даних, виправити або видалити їх у належних випадках.

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

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

Цей етап часто потребує участі не лише юриста. Юридична вимога повинна перетворитися на конкретну можливість продукту або внутрішній процес.

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

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

Не змішувати GDPR з місцевими правилами окремої країни

GDPR є спільною основою для ЄС, але не скасовує національні правила держав-членів. Для маркетингових повідомлень, файлів cookie, даних працівників, відеоспостереження або окремих секторів можуть діяти додаткові вимоги. Тому запуск у Німеччині, Польщі чи Іспанії іноді потребує окремого місцевого додатка до загальної програми відповідності.

Для бізнесу це особливо важливо при масштабуванні. Те, що компанія вже підготувалася до роботи з одним європейським ринком, не означає автоматичної готовності до будь-якої країни ЄС.

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

Чому цей чекліст не замінює аналіз конкретної компанії

Наведені вище сім пунктів корисні для первинної самоперевірки. Але однаковий чекліст дає різні відповіді для різних бізнес-моделей. У двох SaaS-компаній можуть бути схожі сайти, але різні ролі, різні субпроцесори, різний шлях даних і різні функції продукту.

Саме тому небезпечно починати з універсального пакета документів. Спочатку потрібно побачити реальну схему: які дані отримує компанія, для чого, від кого, куди вони потрапляють, хто має доступ і що відбувається з ними після завершення договору. Лише після цього зрозуміло, які документи потрібні і які зміни треба впровадити саме в ваших процесах або продукті.

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

Три помилки, які руйнують впровадження GDPR та блокують контракти

• Помилка перша: Компанія обіцяє “повну відповідність GDPR”, не знаючи своїх потоків даних. Під час перевірки клієнт бачить невраховані аналітичні сервіси, резервні копії або доступ служби підтримки.
  
  І проблема тут не лише в самому сервісі, який забули зазначити. Для контрагента це сигнал, що компанія не має повної картини того, куди потрапляють дані його користувачів.
  
  
• Помилка друга: Стандартні договірні положення підписано, але в додатку немає точного опису даних, цілей, отримувачів і заходів безпеки. Формально документ існує, але практично він не відображає передавання.
  
  Тобто компанія вже витратила час на документ, але під час перевірки все одно змушена повертатися до аналізу фактичних потоків даних.
  
  
• Помилка третя: Політика описує права людини, але продукт не може виконати запит на видалення або вивантаження даних. Тоді юридичний текст створює додаткову обіцянку, яку бізнес не виконує.

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

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

Розробка документів GDPR та супровід  ІТ-юриста

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

Для керівника компанії кінцевий результат повинен бути ще простішим: зрозуміло, які вимоги стосуються бізнесу, де є прогалини, що потрібно зробити до контракту і які питання можна не впроваджувати без потреби. Це і є межа між формальною “GDPR-папкою” та системою, з якою бізнес може реально працювати.

Юристи “Правової Допомоги” можуть провести діагностику застосовності GDPR, аудит прогалин, підготувати договірний і внутрішній пакет та супроводити впровадження разом із технічною командою.

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

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

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

Більше про нашу послугу тут: Захист персональних даних на підприємстві.