Разграничение доступа к персональным данным: кто и что видит в компании

Если в компании десять человек имеют доступ к 1С или CRM, у скольких из них на самом деле должен быть доступ к персональным данным сотрудников и клиентов? На практике - у двух-трех. Остальные видят чужие телефоны, зарплаты и адреса просто потому, что при настройке базы никто не разграничивал права.

Разграничение доступа к персональным данным сотрудников и клиентов - отдельная строка в проверочных листах Роскомнадзора и в приказе ФСТЭК №21: у оператора должен быть перечень лиц, допущенных к обработке персональных данных, и техническая настройка систем должна ему соответствовать. Разберем, как составить такой перечень, какой приказ о допуске к персональным данным под него оформить и как выглядит матрица доступа к персональным данным на практике - с таблицей и порядком действий, а не пересказом закона.

Пример из практики: в интернет-магазине менеджер по продажам видит в CRM не только имя и телефон покупателя, но и паспортные сведения от службы доставки, данные курьера и историю платежей за полгода. Ни один из этих блоков ему для работы не нужен. Похожая картина в клиниках, где администратор на ресепшене видит результаты анализов, и в фитнес-клубах, где тренер получает доступ к медицинской справке клиента вместе с суммой на карте абонемента.

Частое заблуждение - считать, что разграничение доступа означает покупку дорогого программного обеспечения или сертифицированной системы защиты. На деле для большинства компаний это организационная работа: составить список, оформить приказ, включить встроенные роли в уже используемых 1С и CRM. Отдельные лицензии и сертифицированные средства защиты информации нужны не всем операторам, а тем компаниям, где это требует конкретный уровень защищенности - и это отдельный вопрос, не имеющий отношения к базовому порядку с доступом.

Зачем разграничивать доступ к персональным данным сотрудников

Статья 19 закона 152-ФЗ обязывает оператора принимать организационные и технические меры для защиты персональных данных при их обработке. Одна из таких мер - разграничение прав доступа. Требование не абстрактное: приказ ФСТЭК России от 18 февраля 2013 года №21 прямо называет среди обязательных мер определение перечня лиц, доступ которых к персональным данным необходим для выполнения ими служебных обязанностей. Какой именно набор мер обязателен, зависит от уровня защищенности, который определяется по постановлению правительства №1119 от 1 ноября 2012 года: чем чувствительнее данные и больше их объем, тем строже требования к разграничению.

На практике смысл проще, чем в формулировках закона. Каждый лишний человек с доступом к персональным данным - лишняя точка утечки. Если пароль от 1С знают семь бухгалтеров и два стажера, найти виновного при утечке зарплатной ведомости почти невозможно, а отвечать перед Роскомнадзором и субъектами данных все равно оператору. С 30 мая 2025 года за утечки действуют оборотные штрафы и статья 272.1 УК РФ, введенные 420-ФЗ от 30 ноября 2024 года, и вопрос о том, кто именно имел доступ к базе, - первый при разборе инцидента. Суммы штрафов для небольших компаний за такие нарушения собраны в отдельном материале о том, во сколько обходится нарушение 152-ФЗ индивидуальному предпринимателю.

Есть и менее очевидная причина. У сотрудника или клиента есть право узнать, кто из работников компании имеет доступ к его персональным данным и на каком основании, - такой запрос оператор обязан обработать по существу. Если в компании нет ни перечня, ни приказа о допуске, ответить нечем: остается либо признать, что доступ никак не разграничен, либо предоставить список всех сотрудников подряд, что при проверке будет выглядеть как отсутствие контроля над обработкой данных.

Перечень лиц, допущенных к обработке персональных данных

Перечень - документ, а не абстрактное правило. В него включают сотрудников, которым доступ к персональным данным нужен для исполнения трудовых обязанностей: кадровика, бухгалтера, руководителя отдела продаж, системного администратора. Секретарь, который просто передает документы, в перечень обычно не попадает - ему не нужен доступ к базе, только право принять и отдать бумажный конверт.

Перечень составляет тот, кто в компании отвечает за организацию обработки персональных данных, - эта роль и обязанности назначаются отдельным приказом с четким кругом задач. Хорошая практика - делать перечень приложением к приказу о допуске, а не отдельным никем не подписанным списком в общей папке на сервере. Обновлять его нужно при каждом кадровом изменении: уволился менеджер - убрали из перечня и закрыли доступ в CRM в тот же день, а не через две недели, когда кто-то вспомнит об этом.

Задержка на этом шаге - частая находка при проверках: бывший сотрудник по факту еще может зайти в базу, хотя формально уже не работает в компании. Если проверяющий сверит дату увольнения по приказу с датой последнего входа в систему по логам, объяснить разрыв в две-три недели будет нечем.

Форма перечня законом не установлена жестко: можно вести его бумажным списком с подписью ответственного лица, а можно таблицей в системе документооборота компании. Важно, чтобы документ существовал, был подписан и датирован, а не жил в виде устной договоренности «мы примерно знаем, кто у нас имеет доступ». При проверке такое знание в расчет не идет - нужен документ, который можно показать инспектору.

Приказ о допуске к персональным данным: что должно быть внутри

Приказ о допуске - короткий организационный документ, обычно на одну-две страницы. В нем указывают основание (требования статьи 19 закона и приказа ФСТЭК №21), перечень допущенных лиц или ссылку на приложение с этим перечнем, обязанность соблюдать конфиденциальность и ответственность за ее нарушение, дату вступления в силу.

К приказу обычно прикладывают два документа: сам перечень допущенных лиц и обязательство о неразглашении, которое подписывает каждый сотрудник из списка. Без подписанного обязательства перечень превращается в формальность - на бумаге доступ разграничен, а по факту никто из сотрудников не предупрежден письменно об ответственности за передачу данных на сторону.

Отдельный вопрос - подрядчики и удаленные сотрудники. Если бухгалтерию ведет аутсорсер и у него есть доступ к 1С, включать физлицо-исполнителя в общий перечень компании некорректно: с организацией-подрядчиком нужен договор поручения на обработку персональных данных, а конкретных сотрудников подрядчика допускают уже отдельным приказом на его стороне, по такой же схеме.

Стоит различать доступ по приказу и доступ в конкретной системе. Сотрудник может быть включен в общий перечень допущенных лиц, но при этом не иметь логина в CRM, если она ему для работы не нужна. Приказ дает право на обработку персональных данных в принципе - в рамках должностных обязанностей, а системные права в 1С, CRM или облачном хранилище уже реализуют это право технически, под конкретные задачи конкретного человека. Одно без другого работает плохо: приказ без настройки систем остается декларацией, а системные права без приказа - самовольным решением администратора, ничем не подкрепленным.

Матрица доступа к персональным данным: кто и что видит

Матрица доступа - таблица, где по вертикали роли, а по горизонтали категории данных и основание, по которому роль их получает. Строится она не абстрактно, а под структуру конкретной компании: в фитнес-клубе матрица одна, в компании с проектными командами другая. Устройство доступа в клубе, где пересекаются абонементы, турникеты и медсправки, разобрано на отдельном примере - там хорошо видно, как один человек на ресепшене может закрывать сразу несколько ролей.

Общий принцип - минимально необходимый доступ. Отдел продаж работает с контактами и историей заказов, но ему не нужны паспортные данные из документов на доставку. Бухгалтерия работает с зарплатными и налоговыми сведениями, но ей не нужна медицинская информация о причине больничного - только код диагноза для расчета, а не сам диагноз. Маркетинг вообще не должен видеть персональные данные в чистом виде: для рассылок и рекламных кабинетов используют обезличенные списки или сегменты, а не исходную базу с именами и телефонами.

Как построить матрицу у себя

Проще всего собирать матрицу не за столом в одиночку, а короткими разговорами с руководителями отделов: что именно нужно вашей команде для работы, к каким разделам базы вы обращаетесь чаще раза в неделю. Дальше эти ответы сверяют с фактическими правами в системах - и здесь почти всегда всплывает разрыв: у отдела прав больше, чем нужно для задач, потому что права выдавали по шаблону «как у всех» при найме нового сотрудника, а не под конкретную роль. Матрицу составляют по итогам этой сверки, а не по должностным инструкциям, которые часто устарели или написаны слишком общо.

Ниже пример базовой матрицы, которую можно адаптировать под свою структуру.

Роль	Какие данные доступны	Основание доступа
Кадровик, HR	ФИО, паспортные данные, СНИЛС, зарплата, сведения о больничных	Трудовой договор, обязанности по кадровому учету
Бухгалтерия	ФИО, ИНН, банковские реквизиты, зарплата	Обязанности по расчету и отчетности
Отдел продаж, CRM	ФИО клиента, телефон, email, история заказов	Договор с клиентом, обработка заявок
Маркетинг	Обезличенные сегменты, статистика без прямой идентификации	Согласие на обработку в маркетинговых целях
ИТ-администратор	Технический доступ ко всем базам без права просмотра содержимого	Обслуживание информационных систем
Руководитель	Сводные отчеты, доступ к перечню сотрудников	Управленческие обязанности

Строку про ИТ-администратора часто упускают из виду: системный администратор технически может открыть любую таблицу, и полностью лишить его доступа нельзя - без этого он не настроит систему. Разграничение здесь работает иначе: доступ есть, но он фиксируется в журнале и ограничивается рамками обслуживания, а не просмотра содержимого баз.

Технические меры: роли в CRM и 1С, а не только бумага

Приказ и перечень на бумаге ничего не решают, если в CRM у всех менеджеров одна учетная запись и общий пароль, который не меняли три года. Проверка смотрит именно на это соответствие: сказано в документах, что доступ ограничен ролью, - должно быть видно в настройках системы.

Роли вместо общих логинов

В 1С и большинстве CRM ролевая модель уже встроена: можно завести отдельного пользователя каждому сотруднику и ограничить видимость справочников по ролям. Проблема обычно не в возможностях системы, а в лени при настройке - проще один раз завести общий логин на весь отдел, чем разбираться с правами для семи разных менеджеров. Это удобно ровно до первой проверки или до утечки, когда встает вопрос, кто именно из отдела выгрузил базу клиентов на флешку или переслал ее третьим лицам.

Экспорт в Excel и локальные выгрузки

Даже при аккуратно настроенных ролях в CRM сотрудник может выгрузить таблицу с персональными данными на локальный диск или переслать себе на личную почту для удобства работы. Формально это тоже обработка персональных данных, и если в компании нет правила про такие выгрузки, разграничение доступа в самой системе теряет смысл - данные все равно уходят за периметр. Рабочее решение: запретить экспорт ролям, которым он не нужен для работы, и логировать те выгрузки, которые все же разрешены отдельным сотрудникам.

Что еще стоит настроить

Двухфакторная аутентификация для доступа к базам с персональными данными снимает часть риска даже при утечке пароля - без второго фактора чужой логин бесполезен. Автоматический выход из системы после периода бездействия закрывает ситуацию, когда сотрудник ушел на обед, оставив открытую CRM на экране. Для удаленных сотрудников имеет смысл доступ к базе только через VPN компании, а не напрямую из любой сети, - это уже не роскошь, а базовая гигиена для распределенной команды. Ни одна из этих мер не требует сертифицированных средств защиты информации - речь о настройках, которые есть в большинстве современных систем из коробки.

Похожая история встречается там, где доступ к части данных пересекается сразу с двумя режимами защиты. Например, когда персональные данные одновременно попадают под режим коммерческой тайны, матрицу доступа приходится согласовывать с положением о коммерческой тайне, а не только с перечнем допущенных лиц - иначе на проверке выясняется, что закрыт только один из двух режимов.

Журнал учета доступа к персональным данным

Журнал доступа не обязателен для всех операторов без исключения, но для систем с более высоким уровнем защищенности по ПП-1119 контроль доступа входит в число мер, которые нужно подтвердить на проверке. Даже если формально журнал не требуется под конкретный уровень, вести его - самая простая защита оператора при разборе инцидента: без записей невозможно доказать, кто и когда заходил в базу.

В журнал обычно вносят дату и время доступа, ФИО и должность сотрудника, к какому разделу данных был получен доступ, и цель обращения, если это разовый доступ вне обычных рабочих обязанностей. Для рутинной ежедневной работы, когда менеджер открывает карточку клиента, отдельная запись не нужна - за это отвечает встроенное журналирование самой системы, если оно включено. А вот разовый доступ администратора к чужой учетной записи, выгрузку архивных данных или доступ подрядчика имеет смысл фиксировать отдельно от общего лога системы.

Хранить журнал стоит минимум столько же, сколько хранятся сами персональные данные, к которым он относится, - иначе на момент проверки может не остаться записей за интересующий инспектора период.

Сам по себе журнал бесполезен, если его никто не смотрит. Раз в квартал стоит выделять время и пробегать записи глазами: доступ в нерабочее время, массовые выгрузки за один день, обращения к карточкам сотрудников, которые давно не работают в компании, - все это поводы разобраться отдельно, а не повод для паники, но и не то, что можно оставить без внимания до следующей проверки.

Типичные ошибки и что проверяет инспектор

На проверках Роскомнадзора и при внутреннем аудите одни и те же находки повторяются из компании в компанию.

Общий логин на отдел. Пять человек заходят в CRM под одной учетной записью sales или admin, и в логах системы физически невозможно понять, кто именно смотрел карточку конкретного клиента.

Доступ уволенных сотрудников. Человек уволился месяц назад, а пароль от 1С еще действует: отдел кадров сообщил об увольнении, но никто не отключил учетную запись вовремя.

Перечень есть, а приказа о допуске нет - или наоборот. Эти документы часто делают порознь и в разное время, и перечень не привязан ни к какому распорядительному документу, что снижает его вес как доказательства при проверке.

Матрица не совпадает с реальными настройками системы. На бумаге у маркетинга нет доступа к персональным данным, а по факту весь отдел работает в той же CRM с теми же правами, что и продажи, - просто никто не развел роли при внедрении системы.

Смешение с другими режимами защиты. В компаниях, где часть сведений подпадает и под коммерческую тайну, и под режим персональных данных, разграничение доступа иногда выстраивают только под один из режимов, а второй остается открытым.

Стажеры и практиканты без обязательств. Студент на практике получает временный логин от базы, чтобы «просто посмотреть, как все устроено», и никто не берет с него подписи об обязательстве неразглашения - формально такой человек вообще не должен был получать доступ, пока его нет в перечне.

Отраслевая специфика добавляет свои сложности. В страховой компании агент по продажам полисов не должен видеть медицинские сведения из заявления на выплату - это работа отдела урегулирования убытков, а не продаж, и устройство доступа для полисов, агентов и медицинских сведений разбирали отдельно. В компании с курьерской доставкой водитель работает с адресом и телефоном на день выполнения заказа, но история заказов клиента за прошлые месяцы ему не нужна и не должна отображаться в приложении.

Как навести порядок с доступом: план действий

Работа делится на организационную часть и техническую, и начинать стоит с организационной - иначе непонятно, под что настраивать системы.

1. Определите роли в компании и данные, которые нужны каждой роли для работы, - не по должностям из штатного расписания, а по фактическим обязанностям.
2. Составьте перечень лиц, допущенных к обработке персональных данных, с привязкой к конкретным ролям и системам.
3. Оформите приказ о допуске с приложением перечня и обязательствами о неразглашении для каждого сотрудника из списка.
4. Настройте ролевую модель в CRM, 1С и остальных системах так, чтобы техническая картина совпадала с приказом, а не жила отдельно от него.
5. Закройте общие логины и заведите персональные учетные записи там, где это еще не сделано.
6. Настройте журналирование доступа хотя бы для нестандартных операций: выгрузок, доступа администратора к чужим данным, работы подрядчиков.
7. Внесите в регламент правило: увольнение или смена должности - закрытие или пересмотр доступа в тот же день, а не по факту, когда кто-то вспомнит.

Матрицу доступа стоит пересматривать при любом изменении структуры компании: открыли новый отдел, подключили нового подрядчика, сменили CRM. Документы и настройки, актуальные год назад, вполне могли разойтись с реальностью уже сейчас.

Для компании из пяти-десяти человек весь этот порядок укладывается в пару рабочих дней: составить перечень, подписать приказ и обязательства, развести роли в уже используемой CRM без покупки чего-либо нового. Для компании из ста человек и нескольких филиалов работа растягивается на недели, потому что придется договариваться с руководителями отделов и перенастраивать несколько систем одновременно, а не одну. Масштаб задачи разный, а логика одна и та же: сначала бумага, потом настройка, потом контроль за тем, что первое совпадает со вторым.

Если перечень, приказ о допуске и настройки доступа в системах до сих пор существуют отдельно друг от друга, разумнее один раз свести их в общую картину, чем донастраивать по частям после каждой проверки. На 152fzpro.ru собраны примеры того, как приводят документы и техническую часть сайта в соответствие с 152-ФЗ - без обещаний аттестации ИСПДн, курсов или лицензий, только доработка документов и систем под требования закона.