Коли вся канцелярія заходить у CRM під одним спільним логіном, кожен юрист і асистент бачить справи всіх клієнтів — включно з тією, що закрита три роки тому. Це не просто незручно: RODO вимагає, щоб адміністратор даних контролював, хто і в якому обсязі має доступ, а не залишав це на волю спільного пароля. Для невеликої канцелярії з кількома юристами й асистентами це питання повертається з кожним новим працівником і кожною перевіркою: кому давати доступ, коли його звужувати і коли взагалі можна видалити дані клієнта, справу якого давно закрито.
Далі — що саме кажуть ст. 29 і ст. 17 RODO про контроль доступу й видалення даних, де закінчується відповідальність канцелярії і починається відповідальність постачальника CRM, і як на практиці виглядає закриття справи — від звуження доступу до нагадування про перегляд.
Один спільний логін у CRM канцелярії бачить усе
У багатьох канцеляріях у CRM один акаунт на всю команду, або всі заходять під одним і тим самим адміністративним доступом. Результат: асистентка, яка прийшла цього місяця, бачить у тому самому вікні справу трирічної давнини, давно закриту й розраховану. Ніхто цього не планував — просто ніхто не вимкнув доступ, бо не було ні такого перемикача, ні такої процедури.
Приклад на умовних числах — підстав свої: якщо канцелярія веде умовно 40 справ на рік, а доступ до закритої справи ніхто свідомо не звужує, то через 3 роки в одному спільному акаунті висить доступ приблизно до 120 закритих справ, які бачить уся команда, включно з тими, хто над цими справами взагалі не працював.
Проблема не теоретична: чим більше людей має доступ до справи, у якої минув сенс подальшого поширення, тим важче відповісти на питання перевіряючого з UODO, хто і чому міг побачити ці дані. Відповідь «усі, бо так було зручніше» захистити не вийде.
Ст. 29 RODO: уповноваження і контроль доступу
Що саме каже ст. 29 RODO
Ст. 29 RODO коротко: процесор і будь-яка особа, яка діє за уповноваженням адміністратора і має доступ до даних, обробляє їх лише за дорученням адміністратора (UODO — уповноваження на обробку даних). Інакше кажучи: доступ до даних клієнта канцелярії — це не право працівника, а доручення, яке адміністратор, тобто сама канцелярія, свідомо дає і в будь-який момент може відкликати.
Уповноваження як організаційний захід, а не формальність
UODO прямо вказує, що видача уповноважень може бути одним з організаційних заходів, мета яких — контроль над тим, хто має доступ до даних і в якому обсязі (там само). У CRM це напряму перетворюється на ролі: юрист, який веде справу, бачить її матеріали, людина поза командою не бачить їх узагалі, доки хтось свідомо не змінить це налаштування. Уповноваження на папері, не відображене в налаштуваннях системи, — це фікція, яка не витримає питання перевіряючого про те, як це влаштовано на практиці.
Хто адміністратор, а хто процесор у CRM
Канцелярія, яка збирає дані клієнтів, — адміністратор цих даних. Якщо CRM веде зовнішній постачальник програмного забезпечення, цей постачальник зазвичай виступає як процесор — обробляє дані за дорученням канцелярії, а не за власний рахунок. Це розмежування — не формальність для договору, а реальний поділ відповідальності.
Коли CRM веде зовнішній постачальник
У повідомленні про штрафи для McDonald's Polska та його процесора UODO нагадує загальне правило: за захист персональних даних відповідають і адміністратор, і процесор (UODO, 21.07.2025). Для канцелярії це означає, що вибір постачальника CRM і перевірка того, як цей постачальник захищає доступ до даних, — не формальність, яку підписав один раз і забув, а частина відповідальності, яку не можна повністю перекласти на постачальника. Перед підписанням такого договору варто перевірити, що система взагалі відкриває назовні — іноді відповідь «нічого», і краще знати це заздалегідь, ніж після інциденту, — так само, як перевіряється будь-яка Інтеграції двох систем. Про те, де фізично опиняються дані клієнтів при таких зв'язках, окремо пишемо в тексті про автоматизацію і RODO.
Ст. 17 RODO: обов'язок видалити дані і застереження про претензії
Ст. 17 RODO зобов'язує адміністратора видалити дані, серед іншого, коли вони вже не потрібні для мети, заради якої їх зібрали (UODO — право на видалення даних на практиці). Для закритої справи клієнта питання звучить прямо: чи потрібні ще канцелярії дані з цієї справи хоч для чогось?
Право на видалення даних не абсолютне. Адміністратор може відмовити у видаленні, якщо дані необхідні, серед іншого, для встановлення, відстоювання або захисту претензій (там само) — а для канцелярії це звична ситуація: справа, закрита сьогодні, може повернутися як підстава для претензії клієнта чи іншої сторони через рік-два.
Якщо клієнт сам попросить видалити свої дані, адміністратор повинен відповісти невідкладно, не пізніше ніж протягом місяця; при складній справі строк можна продовжити ще на два місяці, повідомивши про це до завершення першого місяця (там само). Це реальний строк, під який у канцелярії має бути заведена процедура, а не те, що вигадується на ходу під час першого такого запиту.
Доступ по справі, а не до всієї бази клієнтів
Практичне правило, яке випливає прямо зі ст. 29 RODO, звучить простіше за саму статтю: доступ надається до конкретної справи, а не до всієї бази клієнтів канцелярії. Юристу, який веде спір про стягнення оплати, не потрібен доступ до розлучної справи іншого клієнта, яку веде колега з тієї самої команди.
Доступ надається і відкликається на стороні прав, а не надсиланням комусь пароля — це той самий механізм, на якому стоїть API у системах, які розділяють доступ до даних за ролями, а не за тим, хто просто знає логін. Обсяг визначається прямо: що конкретна людина бачить, а що залишається поза її досяжністю, замість стандартного «бачить усе, бо вона в команді».
Чого система не вирішує за юриста
Жодна CRM не здатна оцінити, чи потрібні ще дані із закритої справи клієнта канцелярії для захисту від претензії, чи вже ні. Це вимагає оцінки конкретної справи — хто був стороною, про що був спір, чи є ще розумна підстава очікувати претензію, — а таку оцінку робить юрист, а не автоматика.
Система може максимум нагадати, що цю оцінку варто зробити до встановленого строку після закриття справи; саме рішення про видалення чи збереження даних вона ні за кого не приймає. Це розмежування варто явно прописати у внутрішній процедурі канцелярії, щоб ніхто не вирішив, ніби «система заблокувала б, якби щось було не так».
Як виглядає закриття справи в CRM крок за кроком
На практиці закриття справи в CRM розкладається на кілька станів, які відрізняються тим, хто і що бачить:
| Статус справи | Хто має доступ | Що можна робити |
|---|---|---|
| Справа відкрита | вся команда, призначена на справу | бачить і редагує матеріали щодня |
| Закрита, менше року | команда, яка її вела | бачить без права редагування |
| Закрита, більше року | лише архівна роль | має перегляд, без редагування |
| Надіслана на оцінку юристу | призначена на перегляд людина | вирішує: зберегти чи видалити дані |
Перехід між цими станами не відбувається сам по собі через плин часу — це налаштування, яке канцелярія обирає свідомо, а система лише стежить, щоб його не пропустили для конкретної справи.
Перевір сам: список справ, закритих рік тому і раніше
- Випиши з CRM усі справи, закриті понад рік тому — не лише за датою закриття, а й за тим, чи хтось торкався їх відтоді.
- По кожній справі дай відповідь одним реченням: чи є підстава, щоб дані залишалися доступними всій команді, наприклад відкритий спір, де справа може бути доказом.
- Там, де підстави немає, звузь доступ до людини, яка справді відповідає за архів, замість того щоб залишати його всій команді.
- Познач у справі дату, коли хтось до неї повернеться і вирішить остаточно: тримати дані далі чи видалити.
Такий перегляд легше не забути, коли він перетворюється на звичайне завдання зі строком і відповідальним, а не на добру волю, про яку забувають під навалом поточних справ (Завдання). Заразом під час такого перегляду часто виявляється, що в одного й того самого клієнта в CRM дві картки — одна зі старої справи, інша з нової. Дані клієнтів об'єднує такі записи за тим, що справді ідентифікує людину — за телефоном або e-mail, — щоб поруч не жили два незалежні профілі однієї й тієї самої людини. Детальніше про те, що з такого прибирання реально можна передати системі, а що завжди залишається за командою, — у тексті що реально можна передати системі, а що ні.
Як це виглядає, коли доступом керує система
- 01Справу закрито
- →02доступ звужено до архіву
- →03нагадування про перегляд
Aura в цьому сценарії не вирішує, що робити з даними, — це в будь-якому разі залишається за юристом. Система стежить лише за тим, щоб закриття справи реально звужувало доступ, а нагадування про перегляд строку не залежало від того, чи хтось про нього пам'ятає. Це той самий механізм ролей і прав, на якому стоять Адмін-панелі — одна спільна структура доступу замість окремих налаштувань під кожну справу. Схожий механізм нагадувань стоїть за автоматизацією звітності, яка стежить, щоб цифри самі доходили до власника, а не чекали, поки хтось відкриє панель.
Якщо хочеш подивитися, як таке звуження доступу і нагадування виглядають на практиці, зазирни в Інтеграції або подивись, як влаштована вся структура даних клієнта в Дані клієнтів. Якщо це лише перший крок канцелярії в бік автоматизації, розумно почати з чотирьох порогів замість загального аналізу; а перш ніж питати ціну, поглянь на діапазони цін автоматизації процесів на 2026 рік.
Часті питання
Чи обов'язково робити в CRM канцелярії один спільний логін на всю команду?
Ні, і за ст. 29 RODO так бути не повинно — адміністратор має контролювати, хто і в якому обсязі має доступ до даних (UODO). Один спільний логін означає, що цього контролю на практиці немає, бо ніхто не знає, хто саме відкрив конкретну справу.
Хто відповідає за безпеку даних, якщо CRM веде зовнішній постачальник?
За захист персональних даних відповідають і адміністратор — канцелярія, і процесор — постачальник CRM (UODO, 21.07.2025). Вибір постачальника і перевірка його захисту — це не те, що можна повністю перекласти на його плечі.
Чи потрібно видаляти дані клієнта одразу після закриття справи?
Не автоматично. Адміністратор зобов'язаний видалити дані, коли вони стають непотрібними, але може їх зберегти, якщо вони необхідні для встановлення, відстоювання або захисту претензій (UODO) — а для канцелярії це дуже частий випадок.
Скільки часу має канцелярія на відповідь, якщо клієнт просить видалити його дані?
Відповідь має пролунати невідкладно, не пізніше ніж протягом місяця; при складному запиті строк можна продовжити ще на два місяці, якщо повідомити про це до завершення першого місяця (UODO).
Чи може CRM сама вирішити видалити дані клієнта?
Ні — система може максимум нагадати про строк перегляду справи. Рішення про те, чи потрібні ще дані для захисту інтересів канцелярії, ухвалює юрист, а не автоматика.
Що повинен бачити новий працівник канцелярії в CRM першого дня?
Лише справи, до яких його формально прикріпили, а не всю історію канцелярії цілком. Це пряме застосування принципу зі ст. 29 RODO: доступ випливає з уповноваження на конкретний обсяг даних, а не із самого факту працевлаштування (UODO).