GDPR (Регламент ЄС 2016/679) зобов'язує сайт, який обробляє персональні дані жителів Європейського Союзу, виконувати технічні й організаційні вимоги — незалежно від того, де розміщено сервер. Стаття розбирає, що з регламенту прямо стосується адміністратора сайту і хостингу: ролі, договір обробки, строки повідомлення про витік і права користувачів. Стаття не замінює консультацію юриста — висновки щодо конкретного сайту варто перевіряти з профільним фахівцем.
Ролі: контролер і процесор
Регламент розрізняє контролера (controller) — того, хто визначає цілі і способи обробки персональних даних, і процесора (processor) — того, хто обробляє дані за дорученням контролера. Власник сайту, який збирає дані відвідувачів через форму чи інтернет-магазин, зазвичай виступає контролером; хостинг-провайдер, на серверах якого ці дані зберігаються, зазвичай виступає процесором.
Розділення ролей важливе не формально: регламент прямо покладає на контролера обов'язок обирати процесорів, які надають достатні гарантії захисту даних, і підписувати з ними договір обробки, а не просто довіряти інфраструктурі.
Договір обробки даних
Стаття 28 регламенту вимагає, щоб відносини між контролером і процесором закріплювалися договором обробки даних (Data Processing Agreement, DPA): у ньому описується, які дані обробляються, з якою метою і на який строк. Усної домовленості чи загальних умов обслуговування без окремого DPA регламент не вважає достатньою підставою.
Якщо на сайті використовуються сторонні сервіси — аналітика, платіжний провайдер, розсилка листів — кожен з них також виступає процесором (чи субпроцесором) щодо даних відвідувачів сайту, і договір обробки потрібен і з ними, а не лише з хостинг-провайдером.
Технічні й організаційні заходи
Стаття 32 регламенту вимагає від контролера і процесора технічних і організаційних заходів, що відповідають ризику обробки: шифрування даних, контролю доступу, журналювання подій і здатності відновити доступ до даних після інциденту. Конкретний набір заходів регламент жорстко не фіксує — він має відповідати характеру і обсягу оброблюваних даних.
На практиці це означає захист вебзастосунку від типових атак, наприклад через Content Security Policy, і журналювання доступу та змін на сервері, описане у статті «Аудит безпеки Linux з auditd»: обидва інструменти допомагають і запобігти інциденту, і зафіксувати, що сталося.
Повідомлення про витік даних
Стаття 33 регламенту зобов'язує контролера повідомити надзірний орган про витік персональних даних не пізніше 72 годин з моменту, коли про нього стало відомо, за винятком випадків, коли витік не створює ризику для прав і свобод фізичних осіб. Якщо повідомлення подано пізніше 72 годин, регламент вимагає додати пояснення причини затримки.
Стаття 34 додатково вимагає повідомити самих суб'єктів даних без невиправданої затримки, якщо витік створює високий ризик для їхніх прав і свобод — наприклад, скомпрометовано паролі без шифрування. Якщо процесор (хостинг-провайдер) виявляє витік першим, він зобов'язаний повідомити контролера без невиправданої затримки, а подальше повідомлення надзірного органу — обов'язок контролера.
Права суб'єктів даних і резервні копії
Регламент надає користувачу кілька прав щодо його персональних даних: право на доступ до даних, право на їх виправлення, право на видалення («право бути забутим»), право на обмеження обробки, право на перенесення даних до іншого постачальника і право на заперечення проти обробки. Контролер зобов'язаний відповідати на такі запити у розумний строк, встановлений регламентом як загальне правило в один місяць, з можливістю продовження за складних запитів.
Право на видалення створює практичну напругу з резервним копіюванням: дані, видалені з основної бази, зазвичай продовжують існувати у резервних копіях до закінчення строку їх зберігання. Регламент не вимагає негайно перебирати вже створені резервні копії за кожним запитом на видалення, але вимагає, щоб політика зберігання резервних копій, описана, наприклад, у статті «Як створити резервну копію сайту», була відома і відповідала заявленим строкам зберігання даних.
- Договір обробки даних підписаний з усіма процесорами, включно з хостингом
- Політика зберігання резервних копій узгоджена зі строками зберігання персональних даних
- Є процедура повідомлення надзірного органу протягом 72 годин
- Форма на сайті запитує лише ті дані, які дійсно потрібні
- Є процедура обробки запитів користувачів щодо доступу і видалення даних
| Вимога | Стаття регламенту | Строк/вимога |
|---|---|---|
| Повідомлення надзірного органу про витік | стаття 33 | не пізніше 72 годин |
| Повідомлення суб'єктів даних про витік | стаття 34 | без невиправданої затримки, за високого ризику |
| Відповідь на запит суб'єкта даних | стаття 12 | зазвичай 1 місяць, з можливістю продовження |
| Договір обробки даних | стаття 28 | обов'язковий між контролером і процесором |
# Мінімальний набір полів для внутрішнього журналу інциденту (стаття 33)
date_detected: РРРР-ММ-ДД ГГ:ХХ
data_categories: <які дані порушено>
affected_records_estimate: <оцінка кількості записів>
notified_authority_at: <дата і час повідомлення>
notified_within_72h: yes/noЧасті питання
Що робити, якщо сайт працює лише українською чи російською мовою і фізично не орієнтований на Європейський Союз?
Застосовність регламенту залежить не від мови інтерфейсу і не від місця розміщення сервера, а від того, чи обробляє сайт персональні дані жителів Європейського Союзу — наприклад, через продаж товарів чи послуг, доступних для замовлення з ЄС, або через стеження за поведінкою відвідувачів з ЄС. Точну оцінку застосовності регламенту до конкретного сайту варто робити з юристом, який розбере фактичну аудиторію і спосіб обробки даних, а не за загальним описом.
Який штраф загрожує за порушення GDPR?
Регламент встановлює два рівні адміністративних штрафів у статті 83: до 10 млн євро або 2% річного обороту за менш тяжкі порушення і до 20 млн євро або 4% обороту — за більш тяжкі, береться більша з двох величин. Це верхня межа з тексту регламенту, а не прогноз для конкретного випадку: фактичний розмір визначає надзірний орган, і оцінювати його має юрист, а не стаття в базі знань.
Чи потрібна хостинг-провайдеру окрема згода користувача на обробку даних?
Ні, підставою для обробки даних хостинг-провайдером як процесором є договір обробки даних з контролером (власником сайту), а не окрема згода кінцевого відвідувача сайту. Згоду відвідувача, якщо вона потрібна за законом для конкретної операції — наприклад, для необов'язкових cookie — отримує і обробляє контролер, а не хостинг-провайдер безпосередньо.