Когда вся канцелярия заходит в 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).