Представьте обычную ситуацию. Бухгалтер получает сообщение от генерального директора с просьбой срочно перевести деньги на новый счёт поставщика. Письмо выглядит убедительно, подпись правильная, руководитель действительно находится в командировке. Бухгалтер проводит платёж. Через несколько часов выясняется, что деньги ушли мошенникам.
Антивирус мог ничего не обнаружить. Межсетевой экран работал исправно. Серверы оставались защищёнными. Компания потеряла деньги не из-за технической уязвимости, а потому, что никто не установил простое правило проверять изменение банковских реквизитов по независимому каналу связи.
Именно такие проблемы решают организационные меры информационной безопасности. Компания определяет, кто может получать доступ к информации, какие действия требуют согласования, как сотрудники обращаются с документами, кому сообщают о подозрениях и кто принимает решения при кибератаке.
Хорошая новость заключается в том, что многие организационные меры защиты информации почти не требуют дополнительных расходов на программное обеспечение. Плохая новость в том, что распоряжение директора само по себе ничего не защищает. Правила должны менять поведение сотрудников и настройки рабочих систем.
С чего начать прямо сейчас? Выберите пять наиболее важных информационных систем компании, проверьте список пользователей с доступом, найдите бывших сотрудников и подрядчиков, убедитесь, что администраторы работают через отдельные учётные записи, а финансовые операции нельзя согласовать одним сообщением в мессенджере. Уже такая проверка способна обнаружить серьёзные пробелы.
Материал посвящён законным мерам защиты собственной корпоративной инфраструктуры. Проверять доступы, проводить учебные фишинговые рассылки и анализировать действия сотрудников нужно с учётом их полномочий, требований законодательства о персональных данных и трудовых отношений. Предложенные процедуры не заменяют обязательные меры защиты, установленные для отдельных категорий информационных систем.
1. Кто отвечает за информационную безопасность и как распределить обязанности
Распространённая ошибка небольших компаний заключается в том, что информационную безопасность полностью поручают системному администратору. Администратор устанавливает обновления, создаёт учётные записи, настраивает компьютеры и одновременно решает, кому нужны права доступа. Контролировать собственные решения приходится тому же человеку.
Проблема не обязательно в недобросовестности администратора. Без независимого согласования сотрудник технической службы просто не знает, кому действительно необходим доступ к договорам, зарплатным ведомостям или клиентским базам.
Рабочая модель строится на разделении ответственности. Руководитель определяет допустимый риск и выделяет ресурсы. Владельцы бизнес-процессов решают, кому нужна информация. ИТ-специалисты технически предоставляют права. Ответственный за безопасность проверяет соблюдение правил.
| Участник | За что отвечает | Практическое действие |
|---|---|---|
| Генеральный директор | Принимает решения о рисках и ресурсах | Утверждает правила, назначает ответственных, рассматривает нарушения |
| Ответственный за ИБ | Координирует защиту и контроль | Проверяет доступы, организует обучение, ведёт реестр рисков и инцидентов |
| Системный администратор | Эксплуатирует и защищает ИТ-инфраструктуру | Создаёт и блокирует учётные записи, применяет настройки, собирает журналы событий |
| Руководитель подразделения | Определяет деловую необходимость доступа | Согласовывает права сотрудников и проверяет их актуальность |
| Кадровая служба | Сообщает о кадровых изменениях | Передаёт сведения о приёме, переводе и увольнении сотрудников |
| Юрист или ответственный за персональные данные | Контролирует правовые требования в пределах своей компетенции | Проверяет договоры, правила обработки информации, обязанности и уведомления |
| Каждый сотрудник | Соблюдает правила работы с информацией | Защищает свои учётные данные, проверяет подозрительные запросы, сообщает об инцидентах |
Небольшой компании не обязательно создавать отдельный департамент ИБ. Некоторые функции можно совмещать, часть задач передавать внешним специалистам. Однако директор должен понимать, кто принимает решения, кто выполняет работу и кто проверяет результат. Совмещение ролей не отменяет независимый контроль наиболее рискованных операций.
Например, в компании из 25 сотрудников директор утверждает политику безопасности, руководители отделов согласовывают права, системный администратор управляет учётными записями, а назначенный ответственный ежемесячно проверяет изменения. Внешнего специалиста привлекают для сложных вопросов и периодической независимой оценки.
Подобная модель соответствует логике NIST Cybersecurity Framework 2.0, где управление рисками, распределение ролей и контроль руководства рассматриваются как самостоятельные элементы кибербезопасности. Сам стандарт добровольный и не подменяет российские требования.
Что сделать в первую неделю
- Назначить ответственного за координацию информационной безопасности и определить пределы его полномочий.
- Составить список критичных процессов. Например, платежи, обработка заказов, хранение клиентской базы, кадровый учёт, работа сайта.
- Указать владельца каждой информационной системы и хранящихся в ней данных.
- Определить, какие риски требуют решения руководителя, а какие специалисты могут устранять самостоятельно.
- Установить резервного ответственного на время отпуска, болезни или недоступности основного сотрудника.
Отдельное внимание нужно уделить полномочиям. Сотрудник может отвечать за безопасность, но не иметь права отключить скомпрометированный сервер или заблокировать доступ подрядчика. При реальной атаке подобная неопределённость превращается в задержку, иногда критическую.
2. Какие организационные документы действительно нужны компании
Некоторые организации начинают внедрять безопасность с разработки десятков положений. Документы занимают сотни страниц, сотрудники подписывают листы ознакомления, а повседневная работа продолжается по старым правилам.
Количество документов не показывает уровень защищённости. Для обычной коммерческой компании практичнее создать компактный набор взаимосвязанных правил, охватывающих реальные процессы. Дополнительные обязательные документы определяются применимым законодательством, отраслью и типами информационных систем.
| Документ | Что регулирует | Как проверить исполнение |
|---|---|---|
| Политика информационной безопасности | Общие принципы, роли, цели защиты, ответственность | Каждая важная система имеет владельца и действующие правила |
| Регламент управления доступом | Выдачу, изменение, временное предоставление и отзыв прав | Для каждого доступа есть основание и согласование |
| Правила работы с информацией | Хранение, передачу, копирование, удаление и классификацию данных | Документы находятся в разрешённых хранилищах, а доступ ограничен |
| Правила работы с устройствами и сервисами | Удалённую работу, личные устройства, внешние носители, облака и программы | Сотрудники используют согласованные средства и знают ограничения |
| План реагирования на инциденты | Первые действия, полномочия, контакты, порядок уведомлений и восстановления | Учебный инцидент проходит без споров о распределении обязанностей |
| Порядок работы с подрядчиками | Внешние доступы, конфиденциальность, договорные обязанности, прекращение доступа | После завершения договора доступ подрядчика закрыт |
| Документы по персональным данным | Цели и основания обработки, сроки хранения, права субъектов, меры защиты | Фактические процессы соответствуют утверждённым документам и закону |
Документы можно объединять, если сотрудникам так проще находить правила. Например, порядок использования корпоративной почты, внешних носителей и облачных сервисов удобно разместить в одной инструкции. Главное, чтобы положения не противоречили друг другу и соответствовали техническим настройкам.
Как написать регламент, который действительно работает
Предположим, компании требуется управлять доступом к системе учёта клиентов.
Бесполезная формулировка выглядит примерно так. «Доступ предоставляется уполномоченным сотрудникам в соответствии с действующими требованиями информационной безопасности».
Фраза ничего не объясняет. Непонятно, кто уполномочен, кто согласовывает доступ, какие права получает работник и когда их отключают.
Рабочее правило гораздо конкретнее.
Руководитель отдела продаж направляет заявку на доступ к CRM. Владелец системы согласовывает роль пользователя. Системный администратор создаёт персональную учётную запись и фиксирует выполненное действие. Расширенные права выдаются отдельно на определённый срок. При увольнении доступ блокируется не позднее момента прекращения полномочий сотрудника.
Согласование можно организовать в существующей системе заявок, корпоративном документообороте или через установленный почтовый процесс. Для небольшой компании не обязательно покупать отдельную платформу управления идентификацией. Однако история решений должна сохраняться, а доступы нельзя выдавать на основании устной просьбы без подтверждения владельца данных.
Практический критерий качества регламента предельно прост. Новый сотрудник должен прочитать инструкцию и понять, что делать, к кому обратиться и какой результат ожидать. Проверяющий должен суметь восстановить историю принятого решения.
3. Организационные меры защиты информации на практике
После распределения ответственности и утверждения базовых правил начинается настоящая работа. Большинство мер затрагивает привычные операции, поэтому не требует радикально менять инфраструктуру. Но некоторые процедуры нужно подкреплять техническими ограничениями. Человек не должен иметь возможность случайно обойти установленное правило одним нажатием кнопки.
Управление правами доступа и привилегированными учётными записями
Представим менеджера по продажам. Для выполнения работы ему нужны контакты закреплённых клиентов, история сделок и возможность готовить коммерческие предложения. Полный доступ к кадровым документам, настройкам сервера и резервным копиям ему не требуется.
Подобное разграничение называют принципом минимальных привилегий. Сотрудник получает только необходимые полномочия, а расширение прав требует отдельного обоснования.
Для начала достаточно описать типовые роли.
| Роль | Разрешённые действия | Ограничения |
|---|---|---|
| Менеджер продаж | Работа с закреплёнными клиентами и сделками | Нет административных прав и массовой выгрузки базы без отдельного разрешения |
| Бухгалтер | Работа с финансовыми документами и учётной системой | Изменение реквизитов и платежи проходят установленный контроль |
| Руководитель отдела | Просмотр данных подразделения, согласование доступов | Нет автоматических прав администратора всей системы |
| ИТ-администратор | Настройка инфраструктуры и обслуживание систем | Повышенные права применяются только для административных задач |
| Подрядчик | Доступ к согласованным ресурсам на время работ | Нет постоянного доступа ко всей корпоративной сети |
Особое внимание уделяют привилегированным учётным записям. Администратор может изменять настройки безопасности, создавать пользователей, читать системные файлы и влиять на работоспособность инфраструктуры. Поэтому компрометация административной записи обычно опаснее взлома обычной пользовательской.
Минимальные правила управления привилегиями выглядят следующим образом.
- Администратор использует отдельные учётные записи для обычной работы и административных операций.
- Общие административные логины по возможности исключают. Если совместная запись технически неизбежна, фиксируют, кто и когда получил доступ, и защищают её секреты.
- Повышенные права предоставляют на обоснованный срок, а не бессрочно «на всякий случай».
- Административные входы защищают многофакторной аутентификацией там, где система поддерживает такую возможность.
- После увольнения, перевода или окончания договора права пересматривают, а ненужные учётные записи блокируют.
- Отдельно учитывают сервисные аккаунты, токены API, ключи автоматизации и аварийные учётные записи.
Для небольших организаций полезна ежемесячная проверка административных прав и регулярная ревизия остальных доступов. Частота зависит от риска. Для платёжных систем, персональных данных и удалённого администрирования проверки могут требоваться чаще.
Сервисные учётные записи особенно легко забыть. Сотрудник увольняется, его пользовательский аккаунт закрывают, но созданный им токен интеграции продолжает работать. Поэтому кадровые изменения должны запускать не только проверку персонального логина, но и поиск связанных ключей, внешних приглашений и предоставленных полномочий.
Обучение сотрудников против фишинга и социальной инженерии
Злоумышленникам необязательно искать сложную уязвимость, если сотрудника можно уговорить самостоятельно раскрыть пароль или отправить документ. Приёмы социальной инженерии используют доверие, страх, срочность и авторитет руководителя.
Обычные лекции раз в год плохо подходят для развития практических навыков. Сотрудники запоминают абстрактные советы, но не всегда узнают мошеннический запрос в привычной переписке.
Эффективнее разбирать реальные рабочие сценарии. Бухгалтерии показывают поддельный счёт, отделу кадров письмо с вредоносным резюме, менеджерам сообщение о срочной выгрузке клиентской базы, а руководителям попытку получить доступ через поддельное приглашение на встречу.
После каждого примера сотрудник должен знать конкретный порядок действий.
- Не выполнять рискованную просьбу автоматически, даже если сообщение выглядит знакомым.
- Проверить отправителя и запрашиваемое действие через ранее известный канал связи.
- Не сообщать пароли, коды подтверждения и резервные коды доступа.
- Не подтверждать неожиданные запросы многофакторной аутентификации.
- Переслать подозрительное сообщение в установленный канал безопасности или воспользоваться функцией жалобы в почтовой системе.
- Если пароль уже введён или файл запущен, немедленно сообщить о происшествии, не скрывая подробностей.
Отдельное правило нужно для финансовых операций. Любое изменение банковских реквизитов поставщика подтверждают через контакт, полученный ранее из доверенного источника. Номер телефона из подозрительного письма для проверки не подходит. Для значимых платежей можно использовать согласование двумя уполномоченными сотрудниками.
Голос директора, видеозвонок и сообщение с настоящего аккаунта не должны автоматически отменять финансовые процедуры. Злоумышленники способны подделывать голоса и получать доступ к реальной переписке.
Имитационные фишинговые рассылки допустимо использовать для обучения, но публичное наказание сотрудников приносит сомнительную пользу. После показательной «ловли нарушителей» люди могут начать скрывать ошибки. Лучше оценивать, насколько быстро работники сообщают о подозрительных событиях и правильно ли выполняют инструкции.
Правила работы с конфиденциальной информацией
Фраза «вся информация компании конфиденциальна» практически бесполезна. Сотрудники не понимают, чем отличается публичная презентация от базы клиентов или финансового отчёта, поэтому либо игнорируют ограничения, либо тратят время на избыточные согласования.
Проще разделить информацию на несколько категорий. Например, публичную, внутреннюю и ограниченного доступа. Отдельно учитывать сведения, для которых закон устанавливает специальный режим.
| Категория | Примеры | Правила работы |
|---|---|---|
| Публичная | Опубликованные новости, открытые каталоги, рекламные материалы | Разрешено распространение после установленного согласования публикации |
| Внутренняя | Рабочие инструкции, внутренние планы, организационная переписка | Доступ предоставляют сотрудникам по рабочей необходимости |
| Ограниченного доступа | Закрытые договоры, непубличные финансовые сведения, исходный код, клиентские базы | Ограниченные группы пользователей, контролируемая передача и хранение |
| Информация со специальным правовым режимом | Персональные данные, надлежащим образом защищённая коммерческая тайна, иные охраняемые законом сведения | Применяются специальные правовые и организационные требования |
Категории могут пересекаться. Например, клиентская база одновременно содержит персональные данные и коммерчески ценные сведения. В таком случае учитывают все применимые требования.
Регламент должен отвечать на повседневные вопросы. Можно ли отправить договор на личную почту? Разрешено ли загрузить клиентскую базу в сторонний облачный сервис? Допустимо ли использовать общедоступную нейросеть для анализа внутреннего документа? Кто согласовывает передачу файлов подрядчику?
Для закрытых данных разумно установить следующие правила.
- Хранить рабочие документы в одобренных корпоративных хранилищах с управляемыми правами доступа.
- Не пересылать клиентские базы и внутренние документы на личную почту без установленного разрешения.
- Не загружать конфиденциальную информацию в сторонние нейросети и облачные сервисы без оценки условий обработки и согласования.
- Передавать подрядчику только сведения, необходимые для выполнения конкретного задания.
- Ограничивать срок хранения и удалять информацию по установленным правилам, если отсутствуют законные основания для дальнейшего хранения.
- Учитывать бумажные документы, внешние носители и оборудование, отправляемое в ремонт или на утилизацию.
Запреты не должны парализовать работу. Если корпоративная система обмена файлами неудобна или регулярно недоступна, сотрудники начнут использовать личные облака и мессенджеры. Поэтому к каждому ограничению нужен разрешённый рабочий способ выполнить задачу.
Отдельный вопрос касается коммерческой тайны. Простого соглашения о неразглашении недостаточно для полноценного режима по Федеральному закону № 98-ФЗ. Статья 10 предусматривает перечень защищаемых сведений, порядок ограничения доступа, учёт лиц, получивших информацию, регулирование отношений с работниками и контрагентами, а также установленную маркировку документов и материальных носителей.
Не всякую информацию можно объявить коммерческой тайной. Закон устанавливает исключения, а сама информация должна отвечать критериям охраняемой законом тайны.
Реагирование на инциденты без собственного центра мониторинга
У небольшой компании может не быть круглосуточного центра информационной безопасности. Однако отсутствие дорогостоящей системы мониторинга не мешает заранее определить действия при подозрительном событии.
Предположим, менеджер случайно ввёл пароль от корпоративной почты на поддельном сайте. Если сотрудник немедленно сообщит о происшествии, администратор сможет заблокировать доступ, отозвать активные сеансы, проверить правила пересылки писем и оценить возможную компрометацию.
Если сотрудник промолчит, злоумышленники получат дополнительное время для изучения переписки и попыток проникнуть в другие системы.
Поэтому план реагирования должен быть коротким, конкретным и доступным даже при неработающей корпоративной почте.
| Этап | Действие | Ответственный |
|---|---|---|
| Обнаружение | Сотрудник сообщает о подозрительной активности или ошибке | Любой работник |
| Первичная оценка | Определяют затронутые системы, масштаб и срочность | Ответственный за ИБ совместно с ИТ |
| Сдерживание | Отключают подозрительные сеансы, ограничивают доступ, изолируют заражённые устройства при необходимости | Уполномоченный технический специалист |
| Расследование | Сохраняют необходимые журналы и следы событий, устанавливают причины и последствия | ИБ, ИТ, при необходимости внешние специалисты |
| Восстановление | Устраняют причину, возвращают системы к работе и проверяют результат | ИТ-служба и владельцы систем |
| Разбор | Фиксируют уроки, исправляют процедуры, проверяют исполнение | Ответственный за ИБ и руководство |
При серьёзном происшествии важно не уничтожить доказательства необдуманными действиями. Немедленная переустановка сервера может удалить журналы и следы компрометации. В то же время сохранение доказательств не должно автоматически задерживать меры по остановке продолжающейся атаки. Порядок действий зависит от характера инцидента и принимается уполномоченными специалистами.
Для первой версии плана достаточно указать контакты ответственных, их заместителей, способы экстренной связи, полномочия по изоляции систем, критерии серьёзности инцидента и порядок привлечения внешних специалистов.
Отдельно определяют, кому разрешено общаться с клиентами, подрядчиками, государственными органами и журналистами. Технический специалист не должен самостоятельно обещать, что утечки не произошло, пока расследование не установило факты.
Проверьте план простым упражнением. Сообщите команде, что корпоративная почта недоступна, а бухгалтерский компьютер подозревается в заражении. Попросите участников объяснить, как они свяжутся друг с другом, кто сможет заблокировать учётную запись, где находятся резервные копии и кто примет решение о восстановлении.
Если участники не могут согласовать действия без долгих обсуждений, план требует доработки. Для небольшой компании полезнее один реально отработанный сценарий, чем сложный документ, который никто не открывал.
Контроль подрядчиков и поставщиков
Компания может хорошо защищать собственных сотрудников, но предоставить внешнему разработчику постоянный административный доступ. После окончания проекта договор закрывается, а учётная запись остаётся активной.
Другой распространённый сценарий связан с облачными сервисами. Компания передаёт поставщику клиентскую базу, но не знает, кто из сотрудников подрядчика имеет доступ к сведениям, где данные хранятся и что произойдёт после расторжения договора.
Проверка контрагента должна соответствовать реальному риску. Поставщик офисной мебели и организация, обслуживающая корпоративные серверы, требуют разных уровней проверки.
Перед предоставлением доступа к критичной системе стоит выяснить, какие данные получит подрядчик, кто конкретно будет работать с системой, как защищаются учётные записи, допускается ли привлечение субподрядчиков, в какие сроки подрядчик сообщит об инциденте и как будут возвращены или удалены данные после окончания договора.
Договорные обязательства должны сопровождаться техническими ограничениями. Полезно выдавать персональные временные учётные записи, ограничивать доступ конкретными ресурсами и пересматривать полномочия при изменении состава команды подрядчика.
Самостоятельный отчёт поставщика о соответствии высоким стандартам не заменяет проверку. Для критичных услуг можно запросить подтверждение действующих процедур безопасности, результатов независимой оценки в допустимом объёме и порядка восстановления после сбоев.
Ещё один риск возникает, когда у компании имеется единственный поставщик критичной услуги. Даже добросовестный подрядчик может столкнуться с аварией. Поэтому заранее определяют, как получить данные, переключиться на резервный вариант или восстановить работу собственными силами.
4. Как проверить организационные меры и не нарушить российское законодательство
Организационная безопасность требует постоянной проверки. Компании меняются, сотрудники переходят между подразделениями, появляются новые облачные системы, а временные доступы незаметно становятся постоянными.
Внутренний контроль не обязательно начинать с дорогостоящего аудита. Для небольшой организации подходит регулярная проверка ключевых процессов по короткому списку вопросов.
Практическая матрица организационных мер
| Мера | Какую угрозу снижает | Сложность | Приоритет |
|---|---|---|---|
| Назначение владельцев систем и ответственных | Отсутствие контроля и несогласованные решения | Низкая | Высокий |
| Блокировка доступов при увольнении | Доступ бывших сотрудников и подрядчиков | Низкая или средняя | Критический |
| Разделение обычных и административных прав | Избыточные привилегии, расширение последствий взлома | Средняя | Критический |
| Независимое подтверждение изменения платёжных реквизитов | Мошеннические платежи | Низкая | Критический |
| Инструктаж и практическое обучение | Фишинг, ошибки сотрудников, сокрытие инцидентов | Низкая | Высокий |
| Классификация данных и правила их передачи | Случайное раскрытие информации | Средняя | Высокий |
| План реагирования с учебной проверкой | Задержка действий при кибератаке | Низкая или средняя | Высокий |
| Учёт и проверка подрядчиков | Компрометация через внешние доступы | Средняя | Высокий |
| Регулярный внутренний аудит | Накопление незамеченных нарушений | Средняя | Высокий |
Приоритеты в таблице предложены для типичной коммерческой компании и не заменяют оценку рисков. Например, для медицинской организации защита сведений пациентов может иметь более высокий приоритет, а для производственного предприятия критичнее доступность технологических систем.
Какие показатели действительно отражают уровень защиты
Проверять безопасность количеством утверждённых документов бессмысленно. Более полезны показатели, связанные с выполнением конкретных правил.
- Отзыв доступов. Сколько времени проходит от прекращения полномочий сотрудника до блокировки всех связанных учётных записей и токенов.
- Избыточные права. Сколько необоснованных или просроченных полномочий выявили при ревизии.
- Охват инвентаризацией. У какой доли критичных систем назначены владельцы и известны пользователи.
- Практическое обучение. Какая доля сотрудников умеет правильно проверять подозрительные запросы и сообщать об инцидентах.
- Скорость реагирования. Сколько времени занимает передача сообщения ответственному и начало необходимых действий.
- Устранение нарушений. Сколько серьёзных замечаний остаются открытыми сверх установленного срока.
- Проверка восстановления. Когда в последний раз действительно восстановили данные из резервной копии, а не просто убедились в существовании архивного файла.
Не все показатели стоит сводить к одному проценту. Например, большое количество сообщений о фишинге может означать как рост атак, так и улучшение внимательности сотрудников. Аналогично отсутствие зарегистрированных инцидентов не доказывает, что атак не было. Возможно, организация просто плохо обнаруживает нарушения.
Какие требования действуют в России
В российском законодательстве нет единого универсального перечня организационных мер, одинакового для каждой компании. Требования зависят от обрабатываемой информации, статуса организации, категории информационных систем и отраслевого регулирования.
Персональные данные. Федеральный закон № 152-ФЗ распространяется на операторов персональных данных в пределах установленной законом сферы действия. Для обычной компании обработка сведений сотрудников, клиентов или пользователей сайта уже может создавать обязанности оператора.
Статьи 18.1 и 19 предусматривают правовые, организационные и технические меры, документы по обработке персональных данных, внутренний контроль, обучение работников и защиту информационных систем. Юридическое лицо обязано назначить ответственного за организацию обработки персональных данных в соответствии со статьёй 22.1.
Отдельно нужно проверить обязанность уведомить Роскомнадзор об обработке персональных данных до её начала. Исключения предусмотрены законом, но сам факт обработки исключительно кадровых сведений не означает автоматического освобождения от уведомления.
Если выявлена неправомерная или случайная передача персональных данных, повлекшая нарушение прав субъектов, часть 3.1 статьи 21 устанавливает сроки уведомления Роскомнадзора. Первичное уведомление направляют в течение 24 часов, информацию о результатах внутреннего расследования в течение 72 часов. Отсчёт связан с выявлением соответствующего инцидента. Не каждый сбой информационной системы автоматически подпадает под указанную норму.
Дополнительно законодательство предусматривает взаимодействие с ГосСОПКА по отдельным компьютерным инцидентам. Порядок уведомлений зависит от обстоятельств и статуса оператора. Поэтому в плане реагирования необходимо заранее предусмотреть правовую оценку и определить, какие сообщения, кому и в какие сроки направлять.
Информационные системы персональных данных. Помимо закона № 152-ФЗ могут применяться постановление Правительства № 1119, приказ ФСТЭК России № 21 и соответствующие требования ФСБ России в области криптографической защиты. Конкретный набор мер зависит от уровня защищённости, угроз и особенностей системы. Для всех компаний нельзя автоматически назначить один и тот же набор средств и документов.
Государственные информационные системы. С 1 марта 2026 года действуют требования приказа ФСТЭК № 117, заменившие прежний приказ № 17. Документ регулирует защиту информации в предусмотренных им категориях государственных и иных информационных систем государственных органов, предприятий и учреждений. Распространять приказ № 117 на любую частную компанию только потому, что она использует компьютеры, неправильно.
Критическая информационная инфраструктура. Федеральный закон № 187-ФЗ распространяется на определённых субъектов и объекты КИИ. Применимость требований зависит не только от принадлежности к отрасли, но и от характера информационных систем, выполняемых функций и установленных законом критериев. Для значимых объектов действуют специальные требования, в том числе приказ ФСТЭК № 239. Могут возникать обязанности по категорированию, созданию системы безопасности и взаимодействию с уполномоченными органами.
Коммерческая тайна. Федеральный закон № 98-ФЗ определяет условия установления режима коммерческой тайны и минимальные меры защиты. Подписание соглашения о неразглашении без остальных предусмотренных законом действий не гарантирует, что компания сможет доказать наличие надлежащего режима.
Банки, операторы связи, организации финансового рынка, владельцы отдельных государственных систем и другие регулируемые участники также могут подпадать под специальные требования. Их нельзя заменить универсальным корпоративным регламентом.
Российское законодательство устанавливает не только правила защиты, но и ответственность за отдельные нарушения. В частности, предусмотрены существенные штрафы за нарушения в сфере персональных данных. Размер и основание ответственности зависят от состава правонарушения. Поэтому подход «сначала сделаем минимальные процедуры, а юридические вопросы решим потом» подходит не всем.
План внедрения организационной безопасности за 30 дней
Для компании, которая начинает с нуля, полезен короткий план с измеримыми результатами. Сроки ниже ориентировочные. При наличии серьёзных уязвимостей или специальных обязательных требований ждать окончания месяца нельзя.
| Период | Что сделать | Результат |
|---|---|---|
| Дни 1–7 | Назначить ответственных, определить критичные процессы, системы, данные и основных подрядчиков | Список активов, владельцев и первичных рисков |
| Дни 8–14 | Проверить учётные записи, отключить ненужные права, разделить административные доступы, установить правила кадровых изменений | Актуальные права и контролируемая процедура их выдачи |
| Дни 15–21 | Утвердить основные регламенты, организовать канал сообщений об инцидентах, обучить сотрудников рискованных подразделений | Рабочие инструкции, понятные сотрудникам |
| Дни 22–30 | Провести учебный инцидент, проверить подрядчиков, протестировать восстановление, составить план устранения оставшихся проблем | Подтверждение работоспособности процедур и список следующих задач |
Необязательно стремиться закрыть все обнаруженные проблемы за месяц. Более разумная цель заключается в том, чтобы выявить основные риски, устранить самые опасные пробелы, назначить владельцев нерешённых вопросов и определить реальные сроки исправления.
Если система не поддерживает нужное разграничение прав, нельзя объявлять проблему решённой после подписания инструкции. Приходится либо менять настройки и архитектуру, либо использовать обоснованные временные компенсирующие меры с понятными ограничениями.
Почему организационные меры часто существуют только на бумаге
Формальный подход легко распознать. Политика информационной безопасности утверждена, но директор использует общую административную учётную запись. Сотрудники подписали обязательство о конфиденциальности, но отправляют базы клиентов через личные мессенджеры. План реагирования существует, но указанный в нём ответственный давно уволился.
Подобные проблемы возникают по нескольким причинам.
- Документы не связаны с процессами. Регламент описывает желаемое состояние, а не реальный порядок действий.
- Нет владельцев решений. За нарушения формально отвечают все сотрудники, но никто не контролирует конкретную процедуру.
- Руководство делает исключения для себя. Работники видят, что правила можно игнорировать ради срочной задачи.
- Безопасность мешает работе без разумной альтернативы. Запреты провоцируют обходные решения и использование неконтролируемых сервисов.
- Проверяют документы вместо результатов. На аудит предъявляют подписи, но не могут показать историю выдачи прав или результаты учебных инцидентов.
- Не пересматривают процедуры. Компания меняет подрядчиков, облака и рабочие процессы, а регламент остаётся прежним.
Один из самых опасных мифов заключается в том, что организационные меры способны полностью заменить техническую защиту. Даже идеально обученный персонал не устранит уязвимость в доступном из интернета сервере. С другой стороны, дорогостоящая система защиты не исправит бесконтрольную выдачу полномочий.
Организационные и технические меры работают совместно. Регламент определяет правило, настройки системы обеспечивают его выполнение, а проверка показывает фактический результат.
Частые вопросы об организационных мерах информационной безопасности
Чем организационные меры отличаются от технических мер информационной безопасности?
Организационные меры определяют правила, полномочия и порядок действий сотрудников. Технические меры реализуют защиту средствами программного обеспечения, оборудования и настроек систем. Например, порядок выдачи доступа относится к организационным мерам, а техническое ограничение прав пользователя в операционной системе относится к техническим. Для надёжной защиты нужны оба механизма.
Нужен ли отдельный специалист по информационной безопасности в компании из десяти человек?
Для обычной небольшой компании не существует общего требования обязательно нанимать отдельного специалиста по ИБ только из-за численности персонала. Функции можно распределить между имеющимися сотрудниками и внешними исполнителями. Однако специальные законы и отраслевые требования могут предусматривать назначение ответственных или создание определённых функций безопасности. В частности, юридическое лицо, являющееся оператором персональных данных, должно назначить ответственного за организацию их обработки.
Достаточно ли подписать с сотрудниками соглашение о неразглашении информации?
Нет. Соглашение закрепляет договорные обязанности, но само по себе не устанавливает технические ограничения, порядок доступа и необходимые процедуры защиты. Для надлежащего режима коммерческой тайны также требуется выполнить меры, предусмотренные Федеральным законом № 98-ФЗ. Защита персональных данных регулируется отдельным законодательством.
Можно ли поручить всю информационную безопасность внешнему подрядчику?
Часть технических и организационных задач можно передать внешним специалистам. Однако компания сохраняет собственные обязанности в пределах применимого законодательства и договоров. Руководству всё равно приходится определять допустимые риски, контролировать подрядчика и обеспечивать выполнение требований. Передача функций не означает автоматического освобождения от ответственности.
Как защитить удалённых сотрудников, если у компании нет дорогой системы управления устройствами?
Начать можно с персональных учётных записей, многофакторной аутентификации, ограниченных прав доступа, шифрования рабочих устройств и правил хранения документов. Нужно определить порядок действий при потере ноутбука и запретить небезопасные способы передачи конфиденциальных данных. Однако при большом количестве устройств ручного контроля может оказаться недостаточно. Тогда потребуется централизованное управление.
Нужно ли запрещать сотрудникам пользоваться нейросетями?
Полный запрет не всегда оправдан. Полезнее определить разрешённые сервисы и категории информации, которые допускается передавать. Особого контроля требуют персональные данные, коммерческая тайна, исходный код и внутренние документы. Перед использованием сервиса нужно проверить условия обработки информации, настройки хранения, доступ поставщика к данным и применимые правовые ограничения.
Как часто нужно проводить обучение информационной безопасности?
Единой универсальной периодичности для всех компаний нет. Она зависит от законодательства, отрасли, должностей и рисков. Для обычной организации разумно обучать сотрудников при приёме на работу, периодически обновлять знания и проводить дополнительные занятия после существенных изменений или инцидентов. Короткие регулярные упражнения полезнее формального ежегодного просмотра презентации без практики.
Как понять, что организационные меры действительно работают?
Проверяйте реальные действия, а не наличие подписанных документов. Выберите несколько недавно уволившихся сотрудников и убедитесь, что связанные доступы закрыты. Проверьте согласования административных прав, проведите учебный инцидент, восстановите тестовые данные из резервной копии и попросите работников объяснить порядок сообщения о подозрительных событиях. Результаты таких проверок позволяют обнаружить недостатки процедур.
Вывод
Организационные меры информационной безопасности позволяют сократить значительную часть управленческих и человеческих рисков без покупки дорогостоящих защитных комплексов. Но экономия работает только там, где компания действительно контролирует выполнение установленных правил.
Я бы начинал не с разработки большой политики и не с очередного курса по киберграмотности. Первые задачи гораздо конкретнее. Найти все критичные системы, назначить владельцев, проверить административные полномочия, закрыть ненужные доступы, защитить финансовые операции от поддельных распоряжений и отработать действия при инциденте.
Дальше стоит привести документы в соответствие с реальными процессами, обучить сотрудников на рабочих примерах и установить регулярные проверки. Для небольшой компании перечисленные действия зачастую дают больше практической пользы, чем формальное внедрение сложной системы управления безопасностью без людей, способных ей пользоваться.
Однако организационные меры не исправляют технические уязвимости, не заменяют резервное копирование, многофакторную аутентификацию и другие защитные механизмы. При обработке персональных данных, эксплуатации регулируемых информационных систем или работе с критической инфраструктурой нельзя ограничиваться минимальным добровольным набором процедур.
Хорошая информационная безопасность начинается не с количества регламентов, а с управляемых действий. Компания должна знать, кто имеет доступ к ценным данным, почему получил соответствующие права, кто может изменить опасную настройку и что произойдёт, если завтра обнаружат атаку. Пока на подобные вопросы нет конкретных ответов, даже самая внушительная папка документов остаётся лишь видимостью защиты.
