Защита персональных данных в компании: системы, меры и контроль

Какие процессы и системы включить в проверку

Статья 19 Федерального закона от 27 июля 2006 года № 152-ФЗ «О персональных данных» предусматривает правовые, организационные и технические меры безопасности. Практическая проверка начинается с инвентаризации: кадровая программа, CRM, сайт, почта, файловые папки, устройства, архив и сервисы подрядчиков. Список лицензий на программы не заменяет описание данных и маршрутов их обработки.

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

Различайте систему и отдельный процесс. Одна CRM может обслуживать несколько целей, а один процесс — проходить через сайт, почту, CRM и подрядчика. Границы проверки должны охватывать путь сведений. Иначе защита центральной базы будет подтверждена, а незашифрованная выгрузка на общем диске останется незамеченной.

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

Не включайте в общий доступ сам реестр с подробностями защиты. Документ может содержать внутренние адреса и сведения о настройках. Установите круг получателей, необходимый для выполнения работы, и безопасный способ обмена с привлечёнными исполнителями. В публичной политике не требуется воспроизводить конфигурацию системы защиты.

Как определить требования к уровню защищённости

Постановление Правительства РФ от 1 ноября 2012 года № 1119 устанавливает четыре уровня защищённости для информационных систем персональных данных. Уровень определяют по предусмотренным документом условиям, учитывая актуальные типы угроз, категории данных, состав субъектов и в соответствующих случаях их количество. Размер выручки или привычное название программы сами по себе уровень не определяют.

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

Сохраните решение с исходными параметрами и ссылками на применимые требования. Вывод «четвёртый уровень, потому что компания маленькая» не объясняет проверку условий. Если параметры изменились — например, добавлен иной набор данных или новый способ доступа, — основания решения рассматривают снова.

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

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

Как выбрать меры и проверить доступы

Приказ ФСТЭК России от 18 февраля 2013 года № 21 связывает выбор мер с установленным уровнем и особенностями системы. Базовый набор адаптируют, уточняют по актуальным угрозам и при необходимости дополняют. Выбор не сводится к покупке одинакового комплекта средств для любого оператора.

Сопоставьте угрозу, меру и проверяемый результат. Для доступа это может быть разграничение ролей, индивидуальная идентификация и контроль выдачи полномочий. Для целостности и доступности — соответствующие меры восстановления, контроля изменений и работы с носителями. Точные требования и применимость средств определяют по системе; пример не является полным обязательным перечнем.

Проверьте доступ на типовых рабочих действиях. Кто видит полную карточку, может выгрузить список, удалить запись или создать нового пользователя? Подтверждение настройки должно показывать действие разрешённой роли и отсутствие лишних полномочий. Используйте тестовые данные и согласованные способы проверки, чтобы сам контроль не создавал лишние копии персональных сведений.

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

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

Если отдельную меру технически реализовать невозможно, вопрос не закрывают записью «дорого» или «не поддерживается». Приказ № 21 предусматривает обоснование компенсирующих мер в соответствующих случаях. Решение должно показывать, как нейтрализуется актуальная угроза, а не просто исключать неудобное требование из реестра.

Реестр мер и подтверждений исполнения

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

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

Разделите состояние «мера запланирована», «внедрена» и «проверена». Это полезно для управления проектом, поскольку закупленный инструмент ещё может не охватывать все рабочие места. Для расхождений установите ответственного, способ исправления и повторного подтверждения. Не закрывайте задачу только по факту оплаты договора с подрядчиком.

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

Как распределить работу с подрядчиками

Облачный сервис не устраняет обязанностей компании. Сначала определяют договорную роль исполнителя и границы порученной обработки. Затем выясняют, какие меры выполняет сервис, какие настройки остаются клиенту и кто контролирует подключения, пользователей и выгрузки. Формулировка «за безопасность отвечает поставщик» не объясняет эту цепочку.

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

Отдельно рассмотрите копии и окончание работы. Какие сведения возвращают компании, какие удаляют, что сохраняется в резервном контуре и на каком основании? До завершения договора должны быть понятны действия сторон и способ подтверждения. Простой отзыв основного пароля может не прекращать все технические маршруты доступа.

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

Привлечение специализированного подрядчика может помочь выполнить профильные работы. Требования к лицензии и средствам оценивают по конкретным работам и нормативному режиму. Не следует утверждать, что любой оператор обязан получить лицензию ФСТЭК лишь потому, что хранит клиентские контакты.

Как проверять изменения и готовность к событиям

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

Заранее распределите обязанности по правовой оценке события и взаимодействию с органами. Применимые сроки и состав сообщений проверяют по действующим нормам для конкретной ситуации. Нельзя переносить любую цифру из старой памятки в универсальный регламент без проверки основания и текущей редакции.

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

Приказ № 21 предусматривает оценку эффективности реализованных мер не реже одного раза в три года. Этот интервал не отменяет контроля существенных изменений и актуальных угроз. Практический план проверки связывают с архитектурой системы, обязанностями исполнителей и фактическими событиями в компании.

Организационную часть дополняют статьи о документах и роли оператора. Чтобы сопоставить процессы, документы и подтверждения, можно начать с аудита по 152-ФЗ.

Материал проверен 09.10.2026: 152-ФЗ в редакции от 26.07.2026, приказ ФСТЭК № 21 в редакции от 14.05.2020 и постановление № 1119. Реестр — инструмент подготовки проверки, а не заключение об установленном уровне защищённости конкретной системы.

Вопросы и ответы

Достаточно ли политики и антивируса?

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

Можно ли выбрать уровень защищённости по размеру компании?

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

Передаёт ли облачный сервис ему всю ответственность?

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

Обязан ли каждый оператор иметь лицензию ФСТЭК?

Такой вывод нельзя делать только из факта обработки данных. Требования проверяют по конкретным работам и применимым нормам. Привлечение лицензированного исполнителя и собственная обязанность получить лицензию — разные вопросы.

Как часто оценивают эффективность мер по приказу № 21?

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

Источники

152-ФЗ, статья 19: меры безопасности.

Постановление № 1119: требования и уровни защищённости.

Приказ ФСТЭК № 21, общие положения и оценка эффективности.

Приказ ФСТЭК № 21: состав документа и меры защиты.

152-ФЗ: поручение обработки и обязанности оператора.