Клієнт пише «видаліть мої дані» — і у тебе є місяць на відповідь. За цей час потрібно перевірити кожну систему, де зберігається його інформація: CRM, календар, SMS-шлюз, пошту, бухгалтерію та резервні копії. Якщо цього не зробити — ризикуєш скаргою до UODO та штрафом. Але видаляти потрібно не завжди — іноді закон дозволяє відмовити, а іноді навіть вимагає зберегти дані.
На цій сторінці — детальний посібник: коли видаляти обов'язково, коли можна відмовити, скільки є часу і як пройти по всіх системах крок за кроком. Наприкінці — готова процедура, яку можна впровадити відразу.
Коли видаляти обов'язково (ст. 17 RODO)
Стаття 17 RODO, право на забуття, зобов'язує видаляти дані в конкретних ситуаціях. Потрібно це зробити, коли дані більше не потрібні для мети, для якої були зібрані — наприклад, клієнт завершив співпрацю і у тебе немає причин їх зберігати. Згідно статті 17 RODO, потрібно видалити дані, коли відкликано згоду на їх обробку і немає іншої правової підстави.
Другий випадок — відкликання згоди. Якщо клієнт відкликав згоду на обробку маркетингових даних і у тебе немає іншої правової підстави (наприклад, законного інтересу), потрібно видалити ці дані. Третя ситуація — заперечення проти прямого маркетингу — тоді видаляєш дані зі списку маркетингу, навіть якщо є інша підстава.
Четвертий випадок — незаконна обробка: якщо дані збиралися або оброблялися незаконно. П'ятий стосується ситуацій, коли закон вимагає видалення — наприклад, дані дитини з послуг інформаційного суспільства. Нарешті, шостий випадок — дані, які потрібно видалити в рамках виконання правового обов'язку.
Пам'ятай: право на видалення не абсолютне. UODO прямо вказує, що адміністратор може відмовити, якщо дані необхідні для виконання правового обов'язку або для встановлення, пред'явлення або захисту вимог. Деталі — на сайті UODO Право на видалення даних на практиці.
Коли можна відмовити
Право на видалення не означає, що потрібно стирати все. Можна відмовити в кількох чітко визначених ситуаціях. По-перше, коли дані потрібні для виконання правового обов'язку — наприклад, рахунки-фактури повинні зберігатися 10 років на підставі закону про бухгалтерський облік.
По-друге, коли дані необхідні для встановлення, пред'явлення або захисту вимог. Якщо клієнт винен тобі гроші, можна зберігати його дані до з'ясування ситуації. По-третє, коли обробка потрібна для завдання в суспільних інтересах або для архівних цілей.
| Ситуація | Підстава для відмови | Приклад для фірми послуг |
|---|---|---|
| Рахунки та бухгалтерська документація | Закон про бухгалтерський облік | B2B-рахунки зберігаються 10 років |
| Медична документація | Закон про права пацієнта | Картка пацієнта — 20 років з останнього запису |
| Правові вимоги | Ст. 17 абз. 3(e) RODO | Неоплачений рахунок, справа в суді |
| Правова підстава обробки | Ст. 17 абз. 3 RODO | Інша згода або договір ще в силі |
У разі сумнівів — чи є конкретне повідомлення маркетингом, яка правова підходить — оцінить юрист або IOD. Не приймай самостійно рішення з питань, які можуть мати правові наслідки.
Строк: скільки є часу на відповідь
UODO чітко визначає строк: відповісти потрібно негайно, не пізніше ніж через місяць після отримання запиту. Дата отримання — точка відліку, тому так важливо правильно зареєструвати запит.
Якщо справа складна — наприклад, у тебе багато інформації про цю людину, дані розкидані по багатьом системам або потрібна консультація юриста — можна продовжити строк ще на два місяці. Але потрібно повідомити клієнта до закінчення першого місяця і пояснити причину затримки.
Запит, отриманий 5 травня, означає, що час є до 5 червня. Якщо потрібно продовження, надшли інформацію до 5 травня, що справа складна і потрібен додатковий місяць.
Схема:
- 01запит
- →02реєстрація
- →03пошук
- →04рішення
- →05відповідь
- →06закрито
Прийом запиту: канали і реєстрація
Запит на видалення даних може прийти різними шляхами. Найчастіше — по електронній пошті: клієнт пише на адресу фірми або адресу з політики конфіденційності. Може зателефонувати і подати запит по телефону, відправити форму на сайті, написати через месенджер (Messenger, WhatsApp) або навіть принести листа особисто.
Ключове — встановити момент отримання запиту. Від цієї дати відлічується місяць на відповідь. Тому кожен запит потрібно відразу зареєструвати в CRM з точною датою і часом. Якщо запит прийшов звичайною поштою, датою отримання вважається день, коли лист потрапив у твою скриньку, — не дата відправки.
В картці запиту в CRM мають бути: ім'я та прізвище того, хто подає, e-mail або телефон для верифікації, дата і час отримання запиту, канал отримання, опис запиту (цитата або короткий виклад), статус (в роботі / очікує рішення / відповідь відправлена), відповідальний, строк відповіді, результат (дані видалено / відмовлено / частково видалено), дата відповіді.
Де дані лежать окрім CRM
CRM — не єдине місце, де зберігаються дані клієнта. У типовій фірмі послуг дані розкидані по багатьом системах, і кожну потрібно перевірити перед відповіддю на запит.
Календар запису — якщо використовуєш Booksy, Calendly або іншу систему, потрібно видалити з неї записи, що стосуються цього клієнта. SMS-шлюз — надсилаєш нагадування? Видали номер телефону зі списку маркетингу та з історії надсилання. Електронна пошта — повідомлення від клієнта і йому, також у скриньках працівників. Телефонія та записи розмов — якщо записуєш розмови (і є згода), потрібно видалити записи або принаймні ідентифікуючі дані.
Таблиці працівників — якщо працівники ведуть власні нотатки про клієнтів у таблицях, ці дані теж підпадають під запит. Резервні копії — тут складно: копії зазвичай не видаляються на ходу, але потрібно знати, що вони існують. Якщо відновиш систему з копії, дані повернуться — потрібна процедура на цей випадок. Обробники — якщо користуєшся зовнішніми сервісами (SMS-шлюз, розсилка, бухгалтерія), потрібно перевірити і їх та за потреби надіслати запит на видалення.
| Місце | Хто видаляє | Як перевірити |
|---|---|---|
| CRM | Ти або відповідальний | Пошук за ID клієнта, видалити або знеособати |
| Календар запису | Ти (доступ до системи) | Перевірити історію візитів та майбутні бронювання |
| SMS-шлюз | Ти (панель провайдера) | Список контактів, історія надсилання |
| Електронна пошта | Працівники з доступом | Пошук адреси у всіх скриньках |
| Записи розмов | Провайдер або ти | Пошук за номером телефону |
| Таблиці працівників | Працівники (інструкція) | Пошук на спільному диску |
| Резервна копія | IT-адміністратор | Протокол — відновлення вимагає повторного видалення |
| Зовнішні провайдери | Провайдер (запит) | Підтвердження видалення письмово |
Що з рахунками і KSeF
Рахунки — окрема категорія. Якщо виставляєш електронні рахунки, вони потрапляють у систему KSeF, де архівуються на 10 років — незалежно від бажання клієнта. KSeF зберігає їх автоматично, тому навіть якщо видалиш рахунок зі свого CRM, він залишиться в KSeF. Видалити його раніше 10 років неможливо. Детальніше на сайті KSeF.
Що з медичною документацією
Якщо ведеш медичний кабінет, на тебе поширюється закон про права пацієнта. Медичну документацію потрібно зберігати 20 років з кінця календарного року, в якому зроблено останній запис. Це не опція — це правовий обов'язок.
Часткове видалення: що можна, а що ні
Видалення часто не буває чорно-білим. Можна видалити маркетингові дані, але залишити рахунки. Можна знеособатити історію замовлень замість повного видалення — це часткове видалення, і воно цілком допустиме.
Типовий сценарій: клієнт просить припинити надсилати новинну розсилку та маркетингові SMS. Видаляєш його зі списку розсилки та з SMS-шлюзу. Але залишаєш дані з рахунків, тому що закон велить зберігати рахунки 10 років. І залишаєш базові контактні дані — раптом у нього неоплачений рахунок і потрібно якось зв'язатися.
Інший сценарій: клієнт вимагає повного видалення, але ти ведеш бухгалтерію і повинен зберігати рахунки. У такій ситуації можна відмовити у видаленні частини, що стосується бухгалтерської документації — але потрібно чітко пояснити це у відповіді. Знеособування історії замовлень (замість повного видалення) — рішення, що вимагає консультації з IOD — не приймай таке рішення самостійно.
Відповідь клієнту: що повинна містити
Відповідь на запит про видалення даних — офіційний документ, але він не зобов'язаний бути складним. Повинен містити кілька ключових елементів.
По-перше, підтвердження отримання запиту і подяка за звернення. По-друге, інформацію про прийняте рішення — видалені чи дані, відмовлено (на якій підставі) або видалено лише частину. По-третє, детальний перелік того, що видалено — CRM, SMS, пошта, календар — щоб клієнт бачив, що ти дійсно працював.
По-четверте, пояснення того, що залишилося і чому — наприклад, «рахунки зберігаються 10 років на підставі закону про бухгалтерський облік». По-п'яте, інструкція, куди скаржитися — якщо клієнт не згоден з твоїм рішенням, він може подати скаргу до UODO. Це обов'язковий елемент відповіді. І нарешті, твої контактні дані або контакти IOD — щоб клієнт знав, до кого звернутися з питаннями.
Відправ відповідь тим самим каналом, яким прийшов запит, або безпечнішим способом (лист з підтвердженням отримання). Збережи копію відповіді в CRM як додаток до справи.
Процедура «зроби сам»: крок за кроком
Якщо хочеш впровадити процедуру обробки запитів на видалення даних у своїй фірмі, почни з простого тесту: подай запит на себе. Попроси колегу або IOD надіслати у твою фірму прохання видалити «твої» дані — і пройди весь шлях від отримання до відповіді. Засіки, скільки часу зайняло і де виникли труднощі.
Перший крок — Мапа систем. Склади список усіх місць, де зберігаються дані клієнтів: CRM, календар, SMS, пошта, бухгалтерія, резервні копії, таблиці працівників, зовнішні провайдери. Для кожної системи визнач: хто має доступ, як шукати клієнта, як видалити дані.
Другий крок — Шаблон запиту в CRM. Створи шаблон справи з полями: дата отримання, канал, дані клієнта, строк відповіді, статус. Додай автоматичне нагадування за 7 днів до закінчення строку.
Третій крок — Перевірка особи. Встанови процедуру: як підтверджуєш, що людина, яка подає запит, — твій клієнт. Це може бути лист на зареєстровану адресу, SMS на номер з бази або телефонний дзвінок.
Четвертий крок — Журнал запитів. Веди журнал всіх отриманих запитів — хто подав, коли, який результат, дата відповіді. Це твоя документація, яка може захистити у разі перевірки UODO.
П'ятий крок — Шаблони відповідей. Підготуй зразки відповідей на типові ситуації: повне видалення, часткове видалення, відмова із зазначенням причини. Підставляй конкретні дані і системи.
Як це виглядає в системі
Коли обробляєш запит на видалення даних в системі, весь процес упорядкований і автоматизований. Клієнт надсилає запит — поштою, через форму або месенджер. Система автоматично створює завдання зі строком (за замовчуванням 30 днів) і призначає відповідального.
Завдання містить список всіх модулів, де система бачить дані цього клієнта. Бачиш CRM (профіль клієнта, історія, нотатки), SMS-шлюз (надіслані повідомлення), календар (бронювання), інтеграції (всі зв'язки з іншими системами). Система показує, де дані, і допомагає видалити або знеособати.
Для кожного елемента система відзначає, чи можна видалити або є виняток за законом (рахунки, медична документація). Рішення про виняток — зберігати чи дані на підставі закону — приймає фірма і вимагає консультації з IOD у сумнівних випадках.
Після видалення даних система генерує відповідь клієнту з переліком того, що видалено і що залишилося із зазначенням причини. Все записується в журнал — у тебе є доказ, що ти діяв згідно з RODO.
Що залишається людині: перевірка особи клієнта, рішення про винятки за законом (дійсно чи потрібно зберігати рахунки, чи можна знеособатити), підписання відповіді перед відправленням, консультація з юристом або IOD з питань, що викликають сумніви. Решта — пошук, видалення, генерація відповіді — працює в системі.
Дізнайся, як працює обробка запитів на видалення даних на практиці:
- CRM та автоматизації — єдина воронка для звернень з усіх каналів
- Дані клієнтів — одна картка замість п'яти списків у п'яти системах
- Завдання — термін, людина, статус і нагадування
- Інтеграції — зв'язування систем, щоб дані були в одному місці
- Адмін-панелі — панель для керування фірмою
Прочитай більше по темі:
Перевірка особи, яка подає запит
UODO вказує, що адміністратор зобов'язаний перевірити, чи особа, яка подає запит, є тим, за кого себе видає. Не можна просто видалити дані на основі повідомлення від невідомої адреси — це ризиковано і може створити проблеми.
На практиці перевірка виглядає так: просиш клієнта підтвердити особу способом, який є в системі. Якщо клієнт у твоій CRM, можна надіслати посилання для верифікації на його зареєстрований e-mail або зателефонувати за номером телефону, який є в базі. Якщо це нова людина, попроси копію документа, що посвідчує особу — але пам'ятай, що сам документ теж стає персональними даними, які потрібно обробляти за RODO.
Якщо є сумніви — чи справді це той клієнт, чи не є повідомлення підробленим — порадься з IOD. Краще витратити додатковий день на перевірку, ніж видалити дані не тієї людини.
Часті питання
Чи потрібно відповідати на запит про видалення даних, якщо він прийшов через Facebook Messenger?
Так, кожен канал — офіційний канал зв'язку. Отримав запит через Messenger, WhatsApp, форму на сайті або по телефону — зареєструй його і відповісти. Усний запит краще підтвердити письмово (поштою), щоб був доказ, що саме просив клієнт.
Чи можу я відмовити у видаленні даних, якщо у клієнта є неоплачений рахунок?
Можна зберегти дані, необхідні для стягнення боргу — але лише ті, що потрібні для цього. Сама інформація про неоплачений рахунок (сума, дата, номер) не вимагає повних даних клієнта. У сумнівних випадках порадься з юристом або IOD.
Що робити, якщо запит стосується даних, які я вже видалив?
Відповідь чесно: «дані були видалені раніше, у зв'язку із завершенням співпраці» — і покажи, коли це сталося (якщо є запис). Це цілком правильна відповідь. UODO вимагає дії, а не конкретного стану даних.
Чи потрібно видаляти дані з резервних копій?
Резервні копії — складна тема. На практиці їх не видаляють на ходу — але якщо відновлюєш систему з копії, пам'ятай, що дані повернуться. Тому процедура повинна включати повторне видалення після відновлення. В ідеалі — шифруй копії і маєш процедуру безпечного відновлення.
Скільки коштує обробка одного запиту на видалення даних?
Підготовка процедури — разовий витрата. Обробка одного запиту при відлагодженій процедурі займає близько 30–60 хвилин (перевірка, пошук, видалення, відповідь). Без процедури — може зайняти кілька годин пошуку навмання. Тому мапа систем і процедура — це інвестиція, яка дає результат при першому ж запиті.