GDPR для сервісів скорочення посилань: що насправді хоче бачити ваш DPO

Я провів чотири роки, аналізуючи Угоди про обробку даних (DPA) SaaS-сервісів з боку постачальника, і ще рік — з позиції покупця у фінтех-компанії. Пункти, про які всі зазвичай хвилюються — шифрування при зберіганні, терміни зберігання, SLA щодо повідомлення про порушення — у серйозних сервісів скорочення зазвичай у порядку. Пункти, які насправді визначають результат закупівлі, набагато тонші. Це ті, щодо яких у DPO вже сформувалася думка після багаторазового прочитання, і ті, які не вирішуються звичайним значком "GDPR compliant".

Ця стаття — це погляд чинного DPO на те, чого GDPR вимагає від сервісу скорочення посилань, який обробляє дані про кліки суб'єктів з ЄС, із посиланням на номери статей, щоб ви могли передати ці тези своєму юристу для перевірки. Я позначу, де позиція Elido є консервативною, де вона відповідає галузевим стандартам, а де розсудливому покупцеві все ж варто попросити про додаткову угоду.

Посилання на статті стосуються Регламенту (ЄС) 2016/679 — консолідованого тексту GDPR на EUR-Lex. Там, де я посилаюся на вказівки наглядових органів, я даю посилання на першоджерело рішення. Там, де я цитую судову практику, посилання веде на рішення Суду ЄС (CJEU).

Чому сервіс скорочення посилань взагалі потрапляє під дію регламенту#

Сервіс скорочення посилань є процесором згідно зі Статтею 4(8), коли він обробляє дані про кліки ідентифікованих фізичних осіб від імені клієнта. Клієнт є контролером; він вирішує, навіщо збираються дані (атрибуція кампанії) і на якій підставі (Стаття 6 — зазвичай законний інтерес згідно з 6(1)(f) для аналітики на рівні кліків, згода згідно з 6(1)(a), якщо залучено деталізоване відстеження). Сервіс скорочення є процесором; він обробляє ці дані лише за документально підтвердженими інструкціями контролера, що є суттю Статті 28.

Дві категорії даних роблять це очевидним. Кожен редирект фіксує IP-адресу; Суд ЄС (CJEU) ще у справі Breyer (C-582/14, 2016) постановив, що динамічні IP-адреси можуть бути персональними даними, якщо їх об'єднати з інформацією, доступною контролеру. Кожен редирект також фіксує рядок user-agent, який у поєднанні з IP та міткою часу часто дозволяє виокремити осіб у багатьох сценаріях високого трафіку — EDPB зазначив це у Рекомендаціях 04/2020 щодо використання даних про місцезнаходження, і цей принцип є загальним.

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

Стаття 3: територіальна сфера застосування#

Стаття 3 — це стаття, яку найчастіше неправильно тлумачать американські вендори, що продають послуги в ЄС.

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

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

Стаття 6: законність обробки#

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

6(1)(a) — згода. Контролер отримав згоду суб'єкта даних на обробку. Для відстеження кліків на рівні сервісу скорочення згода зазвичай інтегрується в кукі-банер або в процес підписки на маркетинг на цільовій сторінці. Рекомендації EDPB щодо згоди (Guidelines 05/2020, version 1.1, 2020) вимагають вільної, конкретної, поінформованої та однозначної згоди.

6(1)(b) — необхідність для виконання договору. Сам редирект — отримання кліку та спрямування його за призначенням — необхідний для надання послуги, яку запросив користувач. Найчіткіша межа полягає в тому, що маршрутизація є виконанням договору, тоді як рівень аналітики (чи записується цей клік для подальшого аналізу) є окремою операцією обробки, яка може потребувати іншої підстави.

6(1)(f) — законний інтерес. Більшість B2B-клієнтів обґрунтовують аналітику на рівні кампаній законним інтересом після проведення Оцінки законного інтересу (LIA). LIA балансує інтерес контролера у вимірюванні ефективності маркетингу та інтереси суб'єкта даних; для агрегованих показників кліків та стандартної атрибуції баланс зазвичай схиляється на користь контролера. Для поведінкового профілювання з високою роздільною здатністю — фінгерпринтингу, відстеження між сайтами, ретаргетингу на рівні користувача — обґрунтувати LIA стає набагато складніше.

Сервіс скорочення є процесором у всіх трьох випадках. Він обробляє дані за документально підтвердженими інструкціями контролера. Він не обирає законну підставу; це робить контролер.

Стаття 28: договір з процесором#

Стаття 28(3) містить перелік із восьми зобов'язань, які повинні бути включені в будь-який договір між контролером і процесором. Прочитайте це безпосередньо; підпункти від (a) до (h) є короткими та конкретними. Придатна DPA для сервісу скорочення посилань має охоплювати кожен із них.

Я розповім, як ці пункти виглядають на практиці.

(a) Обробка лише за документально підтвердженими інструкціями. Інструкції контролера — це договір плюс письмові вказівки клієнта щодо конкретних функцій (наприклад, "обробляти події кліків для цих робочих просторів, зберігати протягом X місяців"). Сервіс скорочення не може використовувати дані про кліки для власних цілей без інструкції контролера. На практиці це означає: жодного використання даних про кліки клієнтів для навчання внутрішніх рекомендаційних моделей без згоди, жодної агрегованої аналітики, що передається третім особам без попередження. Стандартна DPA Elido чітко про це говорить; якщо DPA вашого поточного сервісу скорочення цього не містить, запитайте чому.

(b) Конфіденційність. Особи, які обробляють дані, зобов'язані дотримуватися конфіденційності. Це операційне питання на боці постачальника, яке рідко викликає заперечення.

(c) Заходи безпеки (Стаття 32). Розглянуто нижче в окремому розділі.

(d) Залучення субпроцесорів. Процесор залучає субпроцесорів лише з дозволу контролера, і субпроцесор повинен прийняти еквівалентні зобов'язання за письмовим договором. Існує два типи дозволу. Конкретний попередній дозвіл вимагає від контролера надання згоди на кожного нового субпроцесора. Загальний попередній дозвіл вимагає лише завчасного повідомлення з правом на заперечення. Більшість SaaS-контрактів використовують загальний дозвіл із 30-денним терміном повідомлення. Обидва варіанти прийнятні згідно зі Статтею 28; важливо, щоб у контракті було вказано, який саме використовується.

(e) Допомога у забезпеченні прав суб'єктів даних. Процесор повинен допомагати контролеру відповідати на запити суб'єктів даних згідно зі Статтями 15-22. Для сервісу скорочення це означає, що контролер може попросити експорт записів кліків за конкретним ідентифікатором (рідко, але трапляється), і сервіс скорочення повинен мати можливість його надати. API Elido містить GET /v1/clicks?subject_id= саме для цієї мети; якщо у вашого поточного сервісу цього немає, вам доведеться відповідати на запити суб'єктів вручну.

(f) Допомога згідно зі Статтями 32 / 33 / 34 / 35 / 36. Процесор повинен допомагати контролеру виконувати зобов'язання щодо безпеки, повідомлення про порушення та DPIA. "Допомога" є операційною — надання звітів про аудит безпеки, повідомлення про порушення в межах SLA, надання технічних деталей, необхідних для DPIA.

(g) Повернення або видалення після закінчення надання послуг. Після закінчення терміну дії договору процесор повертає або видаляє всі персональні дані, якщо законодавство Союзу або держави-члена не вимагає їх зберігання. Стандартний пункт Elido передбачає 30 днів після припинення дії договору з наданням документального підтвердження видалення за запитом.

(h) Права на аудит. Процесор повинен надавати всю інформацію, необхідну для демонстрації відповідності, та дозволяти проведення аудитів. SaaS-контракти зазвичай обмежують це письмовими опитувальниками та виїзними аудитами з завчасним повідомленням; повні необмежені права на аудит рідко зустрічаються поза корпоративними контрактами.

Якщо в DPA вашого поточного сервісу відсутній або розмитий будь-який із пунктів (a)-(h), розмову про закупівлю не варто продовжувати. DPA, що відповідає Статті 28, — це мінімум, а не максимум.

Стаття 30: реєстри операцій з обробки#

Стаття 30 вимагає від процесорів вести реєстри операцій з обробки (RoPA). RoPA процесора — це документ, призначений для контролера, який дозволяє вашому DPO зрозуміти, що саме сервіс скорочення робить із даними.

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

Стаття 32: безпека обробки#

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

Для сервісу скорочення посилань операційний мінімум, який шукатимуть більшість DPO:

TLS 1.3 при передачі, без відкату до TLS 1.0 або 1.1.
Шифрування при зберіганні для сховища подій кліків із задокументованою ротацією ключів.
Мережева сегментація між рівнем редиректів та рівнем аналітики.
Автентифікація через SSO/SAML або OIDC для клієнтського інтерфейсу; взаємодія між сервісами через короткочасні облікові дані.
Журнал аудиту адміністративних дій на боці сервісу скорочення, що зберігається щонайменше 12 місяців.
Задокументована процедура реагування на інциденти та регулярні практичні навчання.
Сертифікація ISO 27001 або еквівалентне незалежне підтвердження.

Elido має сертифікат ISO 27001 і перебуває в процесі отримання SOC 2 Type II (ціль — друга половина 2026 року). Технічні заходи контролю задокументовані на сторінці довіри. Для трафіку, що підпадає під дію HIPAA, на плані Business доступні угоди BAA.

Формулювання статті тут має значення: "відповідно до ризику" — це відносний стандарт. Сервіс скорочення, що обробляє кліки рекламних кампаній на публічному маркетинговому сайті, має нижчий рівень ризику, ніж той, що використовується всередині компанії для обміну автентифікованими URL-адресами сесій. Заходи вашого DPO повинні відповідати ризику, який ви насправді несете.

Стаття 35: DPIA#

Стаття 35 вимагає проведення Оцінки впливу на захист даних для обробки, яка "може призвести до високого ризику для прав і свобод фізичних осіб", з особливою увагою до (a) систематичного та розлогого оцінювання, (b) спеціальних категорій даних та (c) систематичного моніторингу загальнодоступних зон у великих масштабах.

Для більшості випадків використання сервісів скорочення DPIA не є суворо обов'язковим — відстеження кліків кампанії на маркетинговому сайті не є "систематичним та розлогим оцінюванням" у розумінні Статті 35(3)(a). Коли проведення DPIA стає доцільним:

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

Якщо ви замовляєте DPIA для обробки, пов'язаної з сервісом скорочення, методологічним орієнтиром є рекомендації WP29 (WP248 rev.01); багато наглядових органів опублікували власні шаблони, включаючи програмне забезпечення PIA від CNIL.

Стаття 28(2): розкриття інформації про субпроцесорів#

Найпростіше питання щодо GDPR — "хто ще торкається даних?". Стаття 28(2) вимагає, щоб процесор розкривав інформацію про будь-якого субпроцесора, якого він залучає, та отримував дозвіл. На практиці кожен серйозний SaaS публікує список субпроцесорів та описує процес сповіщення про нових.

Як виглядає хороший список:

Назва субпроцесора, місце обробки, роль.
Категорії персональних даних, що передаються.
Законна підстава для передачі (де застосовно).
Дата додавання субпроцесора.
Механізм сповіщення про нових субпроцесорів (зазвичай email + RSS/JSON-фід).
Право на заперечення: зазвичай 30 днів з моменту повідомлення.

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

Schrems II: коли резидентство в ЄС стає частиною контракту#

Рішення Schrems II (CJEU C-311/18, 2020) скасувало дію програми EU-US Privacy Shield і висунуло вимогу для міжнародної передачі даних на основі SCC проводити Оцінку впливу передачі (TIA), щоб оцінити, чи забезпечує режим нагляду країни призначення ефективний захист прав суб'єктів з ЄС.

Наступна структура — EU-US Data Privacy Framework, прийнята рішенням Комісії (ЄС) 2023/1795 — замінює Privacy Shield для організацій-учасниць. Два важливих зауваження:

Участь є добровільною; не кожен американський SaaS-вендор сертифікований. Перевірте список учасників DPF.
Сама структура є предметом поточних судових розглядів. NOYB заявив про намір оскаржити її, тому третє рішення Schrems є цілком імовірним. Покупці, які планують такий сценарій, все частіше вимагають обробки виключно в межах ЄС.

Як це впливає на вибір сервісу скорочення: якщо ваш покупець наголосив на резидентності даних або ваше галузеве регулювання вимагає обробки тільки в ЄС (німецька охорона здоров'я згідно із законом про захист соціальних даних, французькі медичні дані через сертифікацію HDS, фінансові послуги згідно з вказівками EBA), сервіс скорочення з хостингом в ЄС спрощує контракт. Пункт про резидентство є конкретним, TIA стає непотрібною, а цикл закупівлі скорочується.

Elido за замовчуванням хоститься у Франкфурті. Клієнти плану Business+ можуть закріпити дані в Ашберні або Сінгапурі, якщо того вимагає їхній профіль трафіку. Закріплення здійснюється на рівні робочого простору, документально підтверджується в контракті та забезпечується на операційному рівні — це не просто маркетингова заява.

Мінімізація даних: що вам не потрібно логувати#

Стаття 5(1)(c) вимагає, щоб обробка була "адекватною, відповідною та обмеженою тим, що необхідно для цілей, для яких вони обробляються". Для сервісу скорочення це стосується схеми подій кліків.

Сигнали, які сервіс скорочення може збирати під час редиректу:

IP-адреса (повна, усічена /24 або хешована).
Рядок user-agent (повний або розібраний на клієнт/ОС без рідкісних токенів, що створюють фінгерпринт).
Реферер.
Мітка часу.
Геодані, отримані з IP (країна, місто).
Дані про пристрій, отримані з UA (мобільний/десктоп/планшет, сімейство ОС).
ID кліку (власний ідентифікатор події сервісу скорочення).

З-поміж них для реальної мети контролера зазвичай потрібні розібрані дані про пристрій, країна, мітка часу, ID кліку та, можливо, реферер. Сама IP-адреса рідко потрібна після моменту редиректу — щойно виконано парсинг геоданих та пристрою, IP можна усікти або хешувати перед тим, як він потрапить у сховище кліків. Те саме стосується UA: поля device.type / device.os — це те, що насправді використовує атрибуція; повний рядок UA є приманкою для фінгерпринтингу, яку варто відкинути.

Elido усікає IP-адреси до /24 (IPv4) або /48 (IPv6) перед збереженням подій кліків. Повний UA парситься і видаляється. Обидві дії задокументовані та можуть бути налаштовані для кожного робочого простору, якщо ваш конкретний випадок потребує даних вищої роздільної здатності — але стандартним налаштуванням є мінімізація, що є реалізацією вимог Статті 5(1)(c) за замовчуванням, а не як виправлення.

Права суб'єктів даних на рівні сервісу скорочення#

Контролер обробляє запити суб'єктів даних щодо їхніх прав; процесор допомагає. Для сервісу скорочення виникають два типи запитів:

Стаття 15 — право на доступ. Суб'єкт даних просить копію своїх персональних даних. Сервіс скорочення повинен мати можливість отримати події кліків за ідентифікатором суб'єкта. На практиці це складно, якщо єдиним ідентифікатором є "всі, хто натиснув на посилання X з цієї IP-адреси". Прагматична відповідь: сервіс скорочення експортує події кліків для IP/часового проміжку, який вказав контролер, а контролер фільтрує їх для відповідного суб'єкта.

Стаття 17 — право на видалення. Суб'єкт даних просить видалити дані. Сервіс скорочення повинен мати можливість видалити події кліків за запитом згідно з формулюванням GDPR "без невиправданої затримки" — стандартний операційний SLA становить 30 днів. Складність: події кліків зазвичай зберігаються в аналітичних базах даних, що працюють за принципом дозапису (ClickHouse, BigQuery, Snowflake). Видалення є реальним, але це DELETE по відношенню до розділу (partition), а не редагування окремого рядка. Переконайтеся, що DPA вашого сервісу містить конкретний SLA щодо видалення і що базова архітектура може його забезпечити.

Elido підтримує обидва варіанти через API: GET /v1/subjects/{id}/clicks та DELETE /v1/subjects/{id}. Видалення поширюється на сховище подій кліків протягом 24 годин і підтверджується через вебхук.

Про що запитати відділ закупівель#

Стислий контрольний список для розмови про закупівлю:

Де хоститься сервіс скорочення? (Коротка відповідь; можливість закріплення чи ні.)
Чи є DPA заздалегідь підписаною, чи вона обговорюється з кожним клієнтом окремо? (Заздалегідь підписана — це швидше.)
Скільки субпроцесорів? (Чим менше, тим простіше.)
Чи містить стандартний контракт обробку виключно в ЄС, чи це окремий додаток?
Яке налаштування усічення IP за замовчуванням для подій кліків?
Чи є кінцева точка (endpoint) для запитів за Статтями 15 / 17, чи видалення відбувається через службу підтримки?
Який SLA щодо повідомлення про порушення? (24 години з моменту виявлення — галузева норма.)
Незалежне підтвердження: ISO 27001? SOC 2 Type II? Коли проводився останній аудит?

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

Читайте серію основних матеріалів#

Ця стаття є основною в кластері відповідності (compliance). Інші публікації в кластері: майбутня Резидентність даних в ЄС для маркетингової аналітики (детальніше про специфіку контрактів), Schrems II та пікселі відстеження (практичний вплив на атрибуцію) та Атрибуція кліків після Safari ITP (операційні наслідки світу без кукі). Для короткого огляду для відділу закупівель варто зберегти сторінку довіри та solutions/compliance. Для ознайомлення з архітектурними деталями резидентності, документація архітектури edge-redirect пояснює, як забезпечується регіональне закріплення на рівні маршрутизації.