Пять бухгалтеров и один общий логин в систему клиентов — так на практике выглядит доступ к данным во многих небольших бухгалтерских бюро. Любой из команды может открыть карточку любого клиента, даже того, с которым никогда не работал, а сказать точно, кто и когда туда заходил, не может никто. Дело не в доверии к команде — это пробел в том, как бюро выполняет обязанность из ст. 29 RODO.
Из этого текста ты узнаешь: что именно требует ст. 29 RODO от администратора и от людей с доступом к данным, чем роль администратора отличается от роли процессора в повседневной работе бюро, как ограничить доступ карточками «своих» клиентов вместо всей базы и когда список уполномочий нужно пересматривать заново.
Один общий логин на карточки всех клиентов
Команда из 3–8 бухгалтеров обычно растёт быстрее, чем система прав доступа. Сначала есть одна бухгалтерская программа и два человека, которые в курсе всех дел. Потом приходят новые бухгалтеры, клиентов делят между ними, но логин в системе остаётся один общий, либо каждому дают полный доступ «на всякий случай» — чтобы можно было подменить коллегу в отпуске.
Результат: бухгалтер, которая два года ведёт исключительно строительные компании, технически имеет доступ и к кадровым документам клиента из совсем другой отрасли, которым никогда не занималась. Никто не планировал это как нарушение — это просто самый удобный способ сделать так, чтобы никто никогда не остался без доступа. Проблема в том, что RODO спрашивает не о намерениях, а о том, реально ли администратор контролирует, у кого и в каком объёме есть доступ к данным. Тот же принцип разбираем в статье о том, что реально можно передать системе, а что нет — доступ к данным клиента как раз из тех вещей, которые нельзя отдавать на откуп удобству.
Что требует ст. 29 RODO: уполномочие — не формальность для папки
Ст. 29 RODO указывает, что процессор и любой человек, действующий по уполномочию администратора или процессора и имеющий доступ к персональным данным, обрабатывают их исключительно по указанию администратора. Именно на это обращает внимание Управление по защите персональных данных Польши (UODO), отвечая на вопрос, должен ли администратор вообще ещё выдавать уполномочия при действующем RODO (UODO об обязанностях администратора). Ответ: должен, потому что это один из конкретных способов показать, что доступ реально контролируется, а не что у каждого есть ключ от всего.
Что именно значит «уполномочие»
UODO обращает внимание на языковой нюанс: польское слово «upoważnienie» по словарю — это формальная доверенность, но английская версия RODO говорит о человеке, «acting under the authority of the controller» — действующем под властью администратора. Иначе говоря, дело не столько в бумажке, сколько в том, чтобы администратор реально контролировал, кто, в каком объёме и на каких условиях обрабатывает данные. Уполномочие — один из инструментов, которым эту власть можно показать.
Кого касается обязанность: не только штатных сотрудников
Из текста UODO следует также, что речь не только о постоянных сотрудниках, но и о каждом, кому бюро поручило работу, требующую доступа к данным клиентов, — включая практикантов и стажёров. Исключение — люди, которые сами являются процессором или его сотрудником: там обязанность регулирует договор поручения обработки, а не внутреннее уполномочие.
Администратор должен контролировать, у кого и в каком объёме есть доступ
UODO формулирует это прямо: смысл в том, чтобы администратор контролировал, кто и в каком объёме имеет доступ к персональным данным и на каких условиях их обрабатывает. Меры, которые для этого принимает администратор, должны предотвращать неправомерный ввод, просмотр, изменение или удаление данных, а уполномоченные люди должны иметь доступ только к тем данным, которые охватывает их уполномочие, — не ко всей базе автоматически.
Выдача уполномочий — одна из таких организационных мер. На её основании потом применяют механизмы контроля доступа в самой информационной системе: конкретному человеку дают конкретный объём прав, а не логин администратора для всех.
Администратор и процессор: две роли одного и того же бюро
Бухгалтерское бюро редко бывает только тем или только другим. По отношению к данным собственных сотрудников — кадры, зарплата, учёт рабочего времени — бюро является администратором и само решает цели и способы обработки. По отношению к данным клиента, которые оно обрабатывает по его поручению в рамках бухгалтерской услуги, бюро чаще всего выступает процессором — то есть выполняет указания администратора, которым в этом случае является сам клиент.
Почему это различие меняет что-то на практике
Если бюро выступает процессором по отношению к данным клиента, правила доступа внутри команды всё равно должны соответствовать тому же требованию ст. 29 RODO — каждый бухгалтер, действующий по уполномочию бюро, обрабатывает данные клиента исключительно по его указанию, в объёме, который следует из договора. Роль администратора или процессора не освобождает от контроля за тем, кто реально что видит.
Ответственность не исчезает после подписания договора
Один из коммуникатов UODO хорошо показывает механизм, хотя касается совсем другой отрасли, чем бухгалтерия: по делу о штрафах для McDonald's Polska председатель UODO прямо указал, что за защиту персональных данных отвечают и администратор, и процессор (коммуникат UODO, 21.07.2025). В этом деле, среди прочего, не хватало надлежащего договора поручения обработки, хотя обязанность его заключить следовала из ст. 28 п. 4 и 9 RODO ещё до проверки.
Суммы штрафов и сама отрасль общепита не имеют отношения к бухгалтерскому бюро — переносить их сюда было бы нечестно. Но механизм универсален: то, что данные обрабатывает субподрядчик или отдельный сотрудник, не снимает ответственности с администратора, и наоборот. Уполномочия внутри команды и договор поручения обработки с клиентом — это две отдельные обязанности, которые нужно выполнить обе сразу, а не взамен друг друга.
Доступ по клиенту, а не доступ ко всей базе
Практическое следствие простое: доступ должен быть привязан к конкретным клиентам, с которыми человек реально работает, а не к базе целиком. В крупной бухгалтерской системе это обычно настраивается на уровне ролей — бухгалтер видит своих клиентов, руководитель команды видит команду, владелец видит всё, а не у каждого один и тот же аккаунт с полным доступом.
Ограничение доступа клиентами, с которыми человек реально работает, — это на практике принцип минимизации данных из ст. 5 RODO: данные должны быть адекватными, уместными и ограниченными тем, что необходимо для цели обработки (пособие UODO, цитирующее ст. 5 RODO). В бухгалтерском бюро «целью» отдельного бухгалтера является обслуживание своих клиентов, а не просмотр всей базы на случай, если когда-нибудь пригодится.
Пример на условных числах — подставь свои: бюро с 5 бухгалтерами и 60 активными клиентами, где каждый бухгалтер технически имеет доступ ко всем карточкам, даёт 5 × 60 = 300 возможных комбинаций «сотрудник–клиент», хотя реально обоснована лишь часть из них. После равного распределения клиентов между бухгалтерами (60 ÷ 5 = 12 клиентов на человека) число обоснованных комбинаций падает до 5 × 12 = 60 — остальное доступ без причины, которую никто не сможет объяснить проверяющему.
Как это выглядит на уровне ролей в системе
На практике это три уровня: у бухгалтера есть доступ к назначенным клиентам, у человека, который подменяет коллегу в отпуске, — временный доступ со сроком действия, а у владельца или руководителя — доступ ко всему, потому что это следует из его роли, а не из удобства входа в систему. Чем больше людей делят один аккаунт «на всякий случай», тем труднее кому-либо показать, кто реально обрабатывал данные конкретного клиента.
Что не решает одно только уполномочие
Уполномочие наводит порядок внутри команды бюро. Оно не заменяет договор поручения обработки данных, который бюро обязано подписать с каждым клиентом, если обрабатывает его данные по его поручению. Это два разных документа, две разные обязанности и две разные стороны — один регулирует отношения бюро–сотрудник, другой — отношения бюро–клиент. О том, где физически оказываются данные клиентов, когда задействовано несколько систем и субподрядчиков, мы пишем отдельно в статье автоматизация и РОДО.
Когда пересматривать список уполномочий
Список уполномочий — не документ, который подписывают раз и кладут в папку. Естественные моменты для пересмотра: окончание трудового договора или договора подряда, смена роли в команде — например, повышение до руководителя, которому нужен более широкий доступ, — и завершение работы с конкретным клиентом, после которого доступ к его карточке должен исчезнуть, а не остаться «на потом».
| Ситуация | Что сделать с доступом |
|---|---|
| Новый бухгалтер присоединяется к команде | Дать доступ только к назначенным ему клиентам |
| Практикант или стажёр работает над конкретным делом | Уполномочие на срок практики и объём этого дела |
| Сотрудник меняет роль (например, повышение) | Обновить объём уполномочия под новую роль |
| Договор с сотрудником заканчивается | Забрать доступ в день окончания, а не «когда-нибудь» |
| Клиент завершает сотрудничество с бюро | Закрыть доступ команды к его карточке |
Сделай сам за неделю: список доступов
- Выпиши всех, у кого есть хоть какой-то доступ к системе с данными клиентов, — включая практикантов и людей на подмене.
- Рядом с каждым отметь, с какими клиентами он реально работает в этом месяце.
- Сравни это с тем, к чему у него реально есть доступ в системе, — разница и есть доступ без обоснования.
- Проверь, есть ли у каждого из них письменное или электронное уполномочие, а не просто логин, переданный на словах.
- Отметь в календаре, когда заканчиваются договоры, практики и сотрудничество с клиентами, — это естественные моменты для отзыва доступа.
Для команды из восьми человек этот список занимает один вечер и показывает именно те случаи, которые трудно объяснить при проверке: «почему этот человек вообще это видит». Если это первая такая ревизия данных в бюро, статья с чего начать автоматизацию в малой компании: четыре порога вместо общего анализа показывает, с чего начинать.
Как это выглядит, когда доступами управляет система
Вручную вести список уполномочий в таблице удобно, пока команда не вырастет или кто-то не забудет обновить запись. Система, где доступ привязан к клиенту, а не к общему аккаунту, ведёт эту бухгалтерию сама:
- 01сотрудник
- →02назначенные клиенты
- →03журнал открытий карточки
- →04сигнал по чужому клиенту
У кого именно есть доступ к каким клиентам, решает владелец бюро — система Aura не решает это сама, а только следит за уже установленными правилами. В услуге CRM и автоматизации данные клиентов и ответственные за них люди хранятся в одном месте вместо разрозненных файлов, а Интеграции следят, какой источник данных настоящий, а какой лишь копия, — не нужно гадать, где карточка клиента обновлялась последний раз. Программный доступ к самим данным — если бюро пользуется собственными инструментами — выдаётся и отзывается на стороне прав в API, а не рассылкой пароля по почте. Пересмотр уполномочий после окончания договора или смены роли можно превратить в обычную задачу (Задачи) со сроком и ответственным человеком, чтобы это не зависело от чьей-то памяти. Доступы — один из элементов порядка в компании: рядом с CRM, интеграциями, API и задачами в той же системе стоят Дашборды с показателями продаж и финансов и еженедельные AI-отчёты, похожие на те, что описаны в статье про автоматизацию отчётности, которые сами приходят к команде, вместо того чтобы ждать, пока кто-то откроет панель. Пройти оценку, какие звонки и заявки теряются в самом бюро, можно на портале /ocena.
Частые вопросы
Нужно ли уполномочие практиканту в бухгалтерском бюро?
Да. UODO прямо указывает, что обязанность касается не только штатных сотрудников, но и каждого, кому администратор поручил работу, требующую доступа к персональным данным, — включая практикантов и стажёров. Исключение — люди, которые сами являются процессором или его сотрудниками: для них действует договор поручения обработки.
Чем уполномочие отличается от договора поручения обработки данных?
Уполномочие регулирует доступ внутри команды бюро — какие сотрудники и в каком объёме могут обрабатывать данные. Договор поручения обработки — отдельный документ между бюро и клиентом, обязательный, помимо прочего, по ст. 28 RODO, и это совершенно другая обязанность — одно не заменяет другое.
Отвечает ли администратор, если ошибку допустил процессор?
Да. В деле о штрафах для McDonald's Polska, на которое ссылается UODO, ведомство подтвердило, что за защиту персональных данных отвечают и администратор, и процессор, — одна сторона не берёт на себя всю ответственность за другую.
Что именно значит, что администратор должен «контролировать» доступ?
По формулировке UODO речь о реальном контроле над тем, кто, в каком объёме имеет доступ к данным и на каких условиях их обрабатывает, — а не о наличии одного документа. Уполномочие — один из инструментов, которым эту власть можно показать, наряду с механизмами контроля доступа в самой системе.
Обязательно ли уполномочие оформлять письменно?
Зависит от того, из какой нормы следует обязанность в конкретном случае. UODO указывает, что многие отраслевые законы — например, Трудовой кодекс — прямо требуют письменного уполномочия. Какая форма нужна именно твоему бюро, стоит уточнить у юриста или инспектора по защите данных, поскольку это зависит от отрасли и основания обработки.
Когда нужно забирать у человека доступ к данным клиентов?
Естественные моменты — окончание трудового договора или подряда, смена роли в команде и завершение сотрудничества с конкретным клиентом. Ни в одном из этих случаев доступ не должен оставаться «на всякий случай» — именно такие забытые аккаунты труднее всего объяснить при проверке.