Якщо ви створюєте будь-який застосунок, що збирає email-адреси користувачів у Європі — чи взагалі будь-кого, — вам треба розуміти, що GDPR каже про email-адреси. Не страшну версію і не бюрократичну версію з галочками. А практичну версію для розробників, яка допоможе будувати все правильно з самого початку, без страху й без марнування часу на показну відповідність, що насправді нікого не захищає.
Добра новина: більша частина GDPR — це здоровий глузд, одягнений у юридичну мову. Щойно ви зрозумієте основні принципи — навіщо збираєте дані, що з ними робите, як довго їх зберігаєте і які права мають користувачі, — усе інше випливає саме собою. Регламент написали у відповідь на десятиліття галузевих практик, які справді шкодили людям. Розуміння цього контексту значно полегшує сумлінне дотримання правил.
Цей посібник написано для розробників, а не юристів. Він охоплює принципи, які вам справді треба розуміти, практичні наслідки для розробки ПЗ і те, як виглядає розумна система, що відповідає вимогам. Номери статей GDPR наведено там, де це корисно, але мета — ясність, а не вичерпність.
За GDPR email-адреси — це персональні дані
GDPR відносить email-адреси до персональних даних, бо за ними можна ідентифікувати людину. Навіть на вигляд анонімна адреса на кшталт [email protected] вказує на реальну людину, яка створила цей акаунт. Робоча адреса на кшталт [email protected] ідентифікує ще прямолінійніше. Це означає, що щоразу, коли ви збираєте, зберігаєте, обробляєте чи передаєте email-адресу людини, яка може перебувати в ЄС, до цієї обробки застосовується GDPR. Крапка.
Декого з розробників це дивує, бо вони вважають, що GDPR стосується лише чутливих категорій даних — медичних записів, фінансової інформації, біометрії. Насправді GDPR застосовується до будь-якої інформації, яку можна пов’язати з конкретною фізичною особою. Email-адреси цей поріг явно перетинають. Та сама логіка в багатьох випадках стосується IP-адрес, ідентифікаторів пристроїв та імен користувачів.
Варто також зазначити, що це не суто європейське питання. CCPA в Каліфорнії, LGPD у Бразилії, PIPEDA в Канаді, український Закон «Про захист персональних даних» і багато інших національних систем захисту приватності або безпосередньо натхненні GDPR, або працюють на дуже схожих принципах. Будувати з урахуванням GDPR — по суті означає будувати з урахуванням добрих практик приватності, а це стане вам у пригоді в будь-якій юрисдикції. Electronic Frontier Foundation багато писала про те, чому ці глобальні системи важливі, і її аналіз варто прочитати для ширшого контексту.
Шість правових підстав — спрощено для розробників
GDPR вимагає мати правову підставу для кожної дії з обробки даних. Таких підстав шість, але більшості розробників споживчих застосунків глибоко треба знати лише дві.
Договір — ваша правова підстава, коли email-адреса потрібна, щоб надати послугу, яку запросив користувач. Користувач реєструє акаунт, ви надсилаєте лист підтвердження, надсилаєте транзакційні сповіщення, пов’язані з користуванням сервісом. Користувач зареєструвався — надання адреси було частиною укладення цієї угоди. Це чисто й не потребує окремої згоди. Але потребує ось чого: email справді має бути потрібен для послуги. Ви не можете посилатися на договір як підставу для маркетингових листів лише тому, що людина є вашим клієнтом.
Згода — ваша правова підстава для всього, що виходить за межі самої послуги. Маркетингові листи, розсилки, передавання третім сторонам, побудова рекламних профілів. GDPR ставить високу планку для згоди: вона має бути вільною (не прив’язаною до доступу до послуги), конкретною (саме щодо того, що ви робите), поінформованою (простою мовою, а не захованою в юридичних формулюваннях) і однозначною (активна дія з підтвердження, а не заздалегідь проставлена галочка). Заздалегідь позначені поля «Я погоджуюся отримувати маркетингові листи» прямо не відповідають вимогам. Правильний шаблон — поле, яке за замовчуванням не позначене.
Інші чотири підстави — юридичний обов’язок, життєво важливі інтереси, виконання публічного завдання й законні інтереси — для типової розробки вебзастосунків актуальні рідше. Законні інтереси заслуговують на коротке пояснення, бо їх часто неправильно розуміють: багато організацій намагаються використовувати їх як універсальну підставу, щоб не питати згоди. На практиці законні інтереси вимагають задокументованого тесту на баланс інтересів, і виправдати ними холодні маркетингові розсилки не вийде. Якщо сумніваєтеся, згода — завжди найбезпечніший вибір.
Мінімізація даних — найпрактичніший принцип
Стаття 5(1)(c) GDPR каже, що персональні дані мають бути «адекватними, доречними й обмеженими тим, що необхідно для цілей, для яких їх обробляють». Це принцип мінімізації даних, і для розробників він, мабуть, найкорисніша на практиці ідея всього регламенту.
Перевірте свої форми реєстрації. Скільки полів ви просите заповнити? Якщо вашому сервісу потрібна лише email-адреса, щоб надіслати посилання для підтвердження й створити акаунт, навіщо ви ще питаєте номер телефону, дату народження, стать і поштову адресу? Кожне поле, яке ви збираєте понад справді потрібне, створює додаткову відповідальність, збільшує наслідки витоку й додає тертя, яке знижує конверсію. Мінімізація даних — це водночас і добра відповідність вимогам, і добрий дизайн продукту.
Практичний тест простий: для кожного поля форми запитайте себе: «Що станеться із сервісом, якщо я приберу це поле?» Якщо відповідь «для більшості користувачів нічого не зміниться», поле, найімовірніше, зайве. Періодично проходьте цю вправу з усією моделлю даних, а не лише під час початкової розробки. З часом додаються функції, які збирають більше даних, і накопичене може суттєво відійти від того, що справді потрібно. Посібник британського ICO про мінімізацію даних містить докладні розібрані приклади, які справді допомагають у такому аудиті.
Як довго можна зберігати email-адреси?
Принцип обмеження зберігання GDPR (стаття 5(1)(e)) вимагає зберігати персональні дані «не довше, ніж це необхідно для цілей, для яких персональні дані обробляються». Іншими словами: вам потрібна політика зберігання, і її треба реально застосовувати у своїх системах.
Що означає «необхідно» на практиці? Поширений розумний підхід: зберігати email-адреси активних користувачів, поки їхній акаунт активний. Для неактивних — тих, хто не заходив і не взаємодіяв 12–24 місяці, — визначте поріг, надішліть сповіщення, що акаунт буде видалено, якщо людина нічого не зробить, і видаліть його після пільгового періоду. Для непідтверджених реєстрацій (користувачів, які так і не підтвердили email) поширений і обґрунтований строк зберігання — 30 днів. CNIL, французький орган із захисту даних, публікує докладні рекомендації щодо строків зберігання в різних галузях, які дають корисні орієнтири.
Застосовуйте політику зберігання в коді, а не лише в документації. Фонова задача, що щоночі чи щотижня видаляє або анонімізує записи з простроченим строком зберігання, набагато надійніша за ручні процеси. Пишіть логіку очищення одночасно з логікою збирання даних — додавати її згодом дорожче, і про неї легко забути.
Анонімізація тут дуже корисна. Якщо вам треба зберігати агреговану статистику чи записи для бухгалтерії, але сама email-адреса не потрібна, замініть її хешем або приберіть зовсім. Анонімізований запис більше не є персональними даними за GDPR і виходить за межі дії регламенту. Так ви можете зберігати корисні дані для аналітики, не зберігаючи персонального ідентифікатора.
Право на видалення
Стаття 17 GDPR дає користувачам право вимагати видалення їхніх персональних даних за певних обставин: коли вони відкликають згоду, коли дані більше не потрібні для мети, з якою їх зібрали, коли вони заперечують проти обробки й немає переважного законного інтересу або коли дані обробляли незаконно. У більшості споживчих застосунків, якщо користувач просить видалити його акаунт і дані, вам слід просто це зробити.
Зробіть сценарій «видалити мій акаунт» справді повним. Це означає: видалити або незворотно анонімізувати email-адресу в основній базі даних, прибрати людину з усіх розсилок і маркетингових платформ, каскадно поширити видалення на всі підсистеми (аналітику, CRM, систему звернень підтримки) і подбати про резервні копії — хоча видалити дані з бекапів одразу не вийде, у вас має бути процес, що гарантує виключення цих даних із будь-якої відновленої копії в межах строку зберігання. Шаблони м’якого видалення, коли запис лишається в базі з прапорцем deleted = true, операційно нормальні, але далі в ланцюжку мусить бути справжній крок остаточного очищення.
Технічно реалізувати видалення набагато простіше, якщо ви з самого початку побудували чисту модель даних. Якщо email-адреса — зовнішній ключ, що використовується в десятках таблиць із каскадними залежностями, видалення перетворюється на складну операцію. Якщо email-адреса — один атрибут запису користувача, а видалення цього запису чисто поширюється каскадом, усе просто. Це ще одна причина, чому архітектурні рішення, ухвалені на ранньому етапі, згодом впливають на відповідність вимогам.
Тимчасова пошта та дизайн у дусі GDPR
Є цікавий реальний приклад принципу мінімізації даних GDPR у дії: тимчасова електронна пошта, яка автоматично видаляється через 7 днів, — подивіться, як саме влаштоване це видалення. Жодних постійних персональних даних. Автоматичне видалення закладене в архітектуру. Не потрібно створювати акаунт. З погляду мінімізації даних це фактично взірець принципу: дані існують лише стільки, скільки потрібні для конкретної мети, а потім автоматично зникають, і на таку практику цілком законно покладатися.
Для розробника, який тестує, тут теж є практичний аспект GDPR. Коли ви створюєте й тестуєте системи, що працюють з email-адресами користувачів, використання тимчасової пошти для тестових акаунтів означає, що ви не накопичуєте реальних персональних даних у dev- чи staging-середовищі. Це справді добра практика — середовища розробки часто мають слабший захист, ніж продакшен, і персональним даним не місце в тестових базах. Тимчасові адреси для тестових акаунтів — чиста, обізнана щодо GDPR звичка розробника, яка природно вписується в ширший набір найкращих практик приватності електронної пошти.
Маркетингові листи за GDPR
Маркетингові листи за GDPR потребують явної згоди, і ця згода має стосуватися саме маркетингових повідомлень. Найкраща практика — подвійне підтвердження (double opt-in): користувач вводить email, отримує лист із проханням клікнути, щоб підтвердити, що хоче отримувати маркетингові листи, і лише після цього потрапляє у ваш маркетинговий список. Так з’являється задокументований слід, що людина сама активно вирішила підписатися.
Запис про згоду має містити: дату й час надання згоди, точне формулювання, яке людина бачила, погоджуючись (ведіть версії, якщо змінюєте його), і канал, через який отримано згоду. Це важливо, бо вам може знадобитися довести наявність згоди у відповідь на скаргу чи під час перевірки. Зберігання записів про згоду — один із небагатьох випадків, коли зберігати більше даних — саме те, чого вимагає відповідність.
Запити на відписку треба обробляти швидко — поширений стандарт — до десяти днів, але що швидше, то краще. Відписка має повністю зупиняти маркетингові листи; неприпустимо вважати її відмовою лише від одного списку, продовжуючи надсилати з інших. Переконайтеся, що механізм відписки працює в усіх інструментах для розсилок, якими ви користуєтеся. І перегляньте своє обґрунтування «законними інтересами», якщо зараз використовуєте його для непрошених комерційних листів, — планка для законних інтересів вища, ніж вважає більшість маркетологів. Посібник FTC про спам дає додатковий контекст щодо антиспамових законів, які доповнюють вимоги GDPR, особливо для аудиторій, пов’язаних зі США.
Сторонні обробники пошти
Будь-який сервіс, яким ви користуєтеся, щоб надсилати, зберігати чи обробляти email-адреси від вашого імені, за GDPR є обробником даних. SendGrid, Mailchimp, Postmark, Mailgun — усі вони. З кожним із них вам потрібна угода про обробку даних (Data Processing Agreement, DPA). Добра новина: усі великі провайдери пропонують її автоматично в межах своїх умов користування або на запит. Варто переконатися, що ви формально прийняли умови DPA (зазвичай це галочка в налаштуваннях акаунта чи документ, на який посилаються їхні умови).
DPA важлива, бо визначає, що обробник може й чого не може робити з даними, які ви йому передаєте, і розподіляє відповідальність за витоки на його боці. Принципово важливо, що обробник даних не може використовувати надані вами персональні дані для власних цілей — лише обробляти їх за вашими вказівками. Якщо маркетингова платформа використовує ваш список адрес, щоб будувати власні моделі таргетингу, це порушення правил GDPR для обробників. Уважно читайте умови платформ, бізнес-модель яких побудована на рекламі.
Практичний чек-лист GDPR для розробників
- Задокументуйте правову підставу для кожного типу обробки email: транзакційної, маркетингової, аналітичної. Запишіть її, хай навіть неформально.
- Пишіть простою мовою в момент збирання. Пояснюйте користувачам, навіщо вам їхній email, просто у формі, а не ховайте це в політиці конфіденційності.
- Реалізуйте «видалити мій акаунт» повністю. Основна база даних, розсилки, підсистеми, шлях виключення з резервних копій.
- Налаштуйте політики зберігання та автоматичне видалення. Фонові задачі, що забезпечують заявлений строк зберігання.
- Підпишіть угоди про обробку даних з кожним стороннім обробником, пов’язаним із поштою.
- Ніколи не проставляйте заздалегідь галочки згоди на маркетинг. Згода має бути активним, однозначним вибором.
- Використовуйте подвійне підтвердження для маркетингових списків і зберігайте записи про те, коли і як отримано згоду.
- Перевірте форми реєстрації. Приберіть кожне поле, яке не є справді необхідним для послуги.
- Використовуйте тимчасову пошту для тестових акаунтів у dev- і staging-середовищах, щоб не накопичувати реальних персональних даних.
Ширший погляд
Про GDPR часто говорять як про тягар — витрати на відповідність, юридичні ризики, бюрократія. Але його логіка слушна: якщо ви збираєте чиїсь персональні дані, у вас має бути вагома причина, ви маєте бути щодо цього відкритими, зберігати дані лише стільки, скільки потрібно, і давати людям змогу бачити й видаляти те, що ви про них зберігаєте. Це не надмірні вимоги. Це основа програмного забезпечення, якому можна довіряти.
Найважче з GDPR зазвичай доводиться тим розробникам і компаніям, які накопичили великі обсяги даних без чіткої мети, без задокументованої політики зберігання й без чистого шляху видалення. Побудувати ці структури з самого початку незрівнянно легше, ніж додавати їх згодом. А довіра, яку ви здобуваєте в користувачів, відповідально поводячись із їхніми даними, має реальну цінність, що переживе будь-яку галочку відповідності. Electronic Frontier Foundation добре це формулює: програмне забезпечення, що поважає приватність, — краще програмне забезпечення, і не лише юридично, а й для людей, які ним користуються.