Локальные регламенты КИИ без формализма: как актуализировать документы и не потерять соответствие 187‑ФЗ

Содержание

1. Краткое содержание
2. Введение: почему регламенты КИИ нельзя держать «в архиве»
3. Что такое локальные регламенты для объектов КИИ
4. Нормативная база: на что опираться при актуализации
5. Когда нужна актуализация регламентов КИИ
6. Как актуализировать регламенты КИИ: практический алгоритм
7. Какие регламенты нужно проверять в первую очередь
8. Какие решения помогают актуализировать регламенты КИИ
9. Архитектура процесса: как связать документы, активы и контроль
10. Практические примеры актуализации
11. Типичные ошибки при актуализации регламентов КИИ
12. Лучшие практики актуализации регламентов КИИ
13. Сравнение подходов: вручную, через СЭД или через SGRC
14. Чек-лист актуализации регламентов КИИ
15. FAQ: частые вопросы об актуализации регламентов КИИ
16. Основные выводы
17. Источники и полезные материалы

Краткое содержание

Актуализация регламентов КИИ — это регулярное приведение локальных нормативных актов, моделей угроз, технической документации, журналов, матриц доступа и процедур реагирования в соответствие с реальной инфраструктурой, требованиями 187-ФЗ, постановления № 127, приказов ФСТЭК № 235 и № 239, а также новыми изменениями регулирования. Это не «переписать дату на титульном листе». Это проверка того, совпадают ли документы, фактические настройки и процессы.

Главный практический принцип: регламент для объекта КИИ должен описывать то, что реально работает, а не то, что хотелось бы показать проверяющему. Зрелые компании ведут реестр объектов и документов, отслеживают изменения в инфраструктуре, связывают регламенты с активами и мерами защиты, назначают владельцев документов, фиксируют версии и проводят внутренний контроль. Вручную это часто превращается в хаос, поэтому помогают SGRC/GRC-платформы, системы учёта активов, SIEM/SOAR, ITSM, электронный документооборот и трекеры задач.

Введение: почему регламенты КИИ нельзя держать «в архиве»

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

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

187-ФЗ регулирует безопасность КИИ и вводит базовые понятия: субъект КИИ, объект КИИ, значимый объект, компьютерная атака, компьютерный инцидент [1]. Постановление № 127 устанавливает правила категорирования объектов КИИ [2]. Приказ № 235 описывает требования к созданию систем безопасности значимых объектов [3], а приказ № 239 — требования к обеспечению безопасности значимых объектов [4]. В 2025–2026 годах регулирование продолжило меняться: были внесены изменения в 187-ФЗ [5], скорректирован указ № 166 [6], утверждён перечень типовых отраслевых объектов КИИ распоряжением № 360-р [7]. Всё это напрямую влияет на локальные регламенты.

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

Риск: формальная актуализация создаёт ложное чувство безопасности. Документ вроде есть, но при инциденте по нему невозможно работать.

Что такое локальные регламенты для объектов КИИ

Локальные регламенты для объектов КИИ — это внутренние документы организации, которые описывают порядок обеспечения безопасности конкретных объектов КИИ и значимых объектов КИИ. Они связывают требования закона, категорию значимости, модель угроз, архитектуру объекта и реальные меры защиты.

К ним относятся не только «политика информационной безопасности». Обычно комплект шире:

• положение о системе безопасности значимых объектов КИИ;
• приказ о назначении ответственных лиц и комиссии;
• перечень объектов КИИ и материалы категорирования;
• модель угроз и модель нарушителя;
• регламент управления доступом;
• регламент регистрации событий безопасности;
• порядок реагирования на компьютерные инциденты и взаимодействия с ГосСОПКА/НКЦКИ;
• регламент управления изменениями и конфигурациями;
• порядок резервного копирования и восстановления;
• регламент управления уязвимостями и обновлениями;
• порядок внутреннего контроля и оценки эффективности мер защиты;
• инструкции администраторов, пользователей и операторов безопасности;
• порядок вывода объекта из эксплуатации, уничтожения или архивирования данных;
• документы по импортозамещению ПО и ПАК, если организация попадает под соответствующие требования.

Набор документов зависит от категории объекта, отрасли, архитектуры, применяемых СЗИ, наличия АСУ ТП, персональных данных, гостайны и требований смежных регуляторов.

Почему это важно? Регламент — это мост между нормой и исполнением. Закон говорит «обеспечить безопасность», а регламент отвечает: кто, как, где и с какой периодичностью это делает.

Типичная ошибка: взять шаблон из интернета и заменить название компании. Такой документ редко отражает реальную инфраструктуру и почти всегда разваливается при первом серьёзном вопросе.

Нормативная база: на что опираться при актуализации

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

Ключевые источники:

Документ	Что регулирует	Как влияет на регламенты
187-ФЗ	Основы безопасности КИИ, понятия, обязанности субъектов	Определяет общий контур обязанностей и взаимодействия
ПП РФ № 127	Категорирование объектов КИИ	Влияет на перечень объектов, акты категорирования, категорию значимости
Приказ ФСТЭК № 235	Создание систем безопасности ЗОКИИ	Требует описать процессы создания, функционирования и контроля системы безопасности
Приказ ФСТЭК № 239	Меры защиты значимых объектов КИИ	Влияет на регламенты доступа, аудита, управления изменениями, защиты носителей, реагирования
58-ФЗ 2025 года	Изменения в 187-ФЗ	Требует пересмотреть отраслевые особенности, переход на российские решения и связанные документы
Указ № 214	Корректировка требований к применению иностранного ПО на ЗОКИИ	Влияет на планы импортозамещения и технические регламенты
Распоряжение № 360-р	Перечень типовых отраслевых объектов КИИ	Требует сопоставить собственные объекты с типовыми отраслевыми объектами

Международные фреймворки тоже полезны, но как методическая опора. Например, NIST CSF 2.0 выделяет функции Govern, Identify, Protect, Detect, Respond, Recover [8]. Для КИИ это удобно переводится в понятный цикл: управлять требованиями, знать активы, защищать, обнаруживать, реагировать и восстанавливаться. NIST SP 800-53 полезен как каталог контролей: управление конфигурациями, аудит, инциденты, доступы, непрерывность [9]. Но международные документы не заменяют российские нормативные требования.

Как поступают зрелые компании? Они ведут матрицу соответствия: «нормативное требование → локальный документ → техническая мера → владелец → доказательство исполнения». Это сильно упрощает проверку и актуализацию.

Когда нужна актуализация регламентов КИИ

Регламенты нужно актуализировать не только раз в год. Формальная ежегодная ревизия полезна, но для КИИ этого недостаточно. Документы должны обновляться при каждом значимом изменении.

Основные триггеры актуализации:

1. Изменения законодательства. Новая редакция 187-ФЗ, приказов ФСТЭК, отраслевых требований, перечней типовых объектов.
2. Изменение состава объектов КИИ. Появилась новая информационная система, АСУ ТП, сеть, облачный сервис или интеграция с подрядчиком.
3. Изменение категории значимости. Пересмотр категорирования напрямую влияет на состав мер защиты и локальные регламенты.
4. Изменение архитектуры. Сегментация сети, удалённый доступ, новая DMZ, новая SIEM, IDS/IPS или DLP.
5. Инцидент или серьёзное событие ИБ. Если регламент не помог быстро отработать инцидент, его нужно менять.
6. Результаты внутреннего контроля или внешнего аудита. Замечания должны превращаться не только в отчёт, но и в изменения процедур.
7. Изменение ответственных лиц. Уволился администратор безопасности, поменялся владелец процесса, изменилось подразделение.
8. Истечение сертификатов СЗИ или замена средства защиты. Меняются инструкции, порядок эксплуатации, журналы и правила контроля.
9. Переход на российское ПО и ПАК. Нужно обновить регламенты эксплуатации, планы миграции, матрицу зависимостей.
10. Появление типовых отраслевых объектов КИИ в перечнях. После распоряжения № 360-р нужно сопоставить свои объекты с перечнем и зафиксировать выводы.

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

Правильный подход: обновлять документы пакетами. Если меняется архитектура объекта, нужно смотреть не один документ, а весь связанный набор.

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

Ниже — рабочий алгоритм, который подходит для большинства организаций. Его можно адаптировать под отрасль, масштаб и категорию значимости объекта.

Шаг 1. Соберите полный реестр документов

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

Минимальные поля реестра:

• название документа;
• тип документа;
• объект КИИ или процесс, к которому относится документ;
• владелец документа;
• дата утверждения;
• текущая версия;
• основание для актуализации;
• связанные нормативные требования;
• дата следующей проверки;
• статус: актуален, требует обновления, архивирован.

Шаг 2. Проверьте нормативные изменения

Сверьте документы с текущими версиями 187-ФЗ, ПП № 127, приказов № 235 и № 239, изменениями 2025 года и перечнем типовых отраслевых объектов. Особенно внимательно смотрите требования, которые затрагивают категорирование, переход на российское ПО, взаимодействие с ГосСОПКА, внутренний контроль и эксплуатацию СЗИ.

Шаг 3. Сверьте документы с реальной инфраструктурой

Это самый важный этап. Документ может быть юридически аккуратным, но бесполезным, если он описывает несуществующую архитектуру.

Проверяйте:

• перечень серверов и сетевых сегментов;
• состав СЗИ;
• фактические каналы удалённого доступа;
• интеграции с подрядчиками и смежными системами;
• учётные записи администраторов;
• маршруты передачи событий в SIEM и ГосСОПКА;
• актуальность резервного копирования;
• журналы событий и сроки хранения;
• фактические роли и ответственных лиц.

Шаг 4. Проведите gap-анализ

Сравните «как должно быть» и «как есть». Результат удобно оформить таблицей.

Проверяемый элемент	Требование	Что есть сейчас	Риск	Действие
Регламент управления доступом	Разграничение прав по ролям	Есть общая админская учётная запись	Невозможно установить ответственного	Ввести персональные админские учётные записи
Модель угроз	Актуальная схема объекта	Не учтён новый VPN	Ошибка в выборе мер защиты	Обновить модель и техпроект
Регламент реагирования	Указаны ответственные и сроки	Контакт НКЦКИ устарел	Задержка уведомления	Обновить контакты и провести тренировку
Журналирование	События передаются в SIEM	Часть Linux-серверов не подключена	Потеря следов инцидента	Подключить источники и проверить нормализацию

Шаг 5. Обновите документы и согласуйте изменения

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

Шаг 6. Проверьте внедрение изменений

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

Как поступают зрелые компании? Они проводят контрольную проверку через 30–60 дней после утверждения изменений и фиксируют результат.

Какие регламенты нужно проверять в первую очередь

Не все документы одинаково критичны. Если времени мало, начинайте с тех, которые чаще всего проверяются и напрямую влияют на устойчивость объекта.

Приоритет	Документ	Что проверить
Высокий	Перечень объектов КИИ и документы категорирования	Соответствие ПП № 127 и типовым отраслевым объектам
Высокий	Модель угроз и модель нарушителя	Учет актуальной архитектуры, удалённого доступа, подрядчиков
Высокий	Положение о системе безопасности ЗОКИИ	Роли, состав мер, ответственность, порядок контроля
Высокий	Регламент реагирования на инциденты	ГосСОПКА/НКЦКИ, контакты, сроки, сценарии
Высокий	Регламент управления доступом	Роли, админские учётные записи, MFA, пересмотр прав
Средний	Регламент журналирования и аудита	Состав событий, SIEM, целостность журналов, сроки хранения
Средний	Управление изменениями	Порядок согласования изменений, тестирование, откат
Средний	Управление уязвимостями	Сканирование, приоритизация, сроки устранения
Средний	Резервное копирование и восстановление	RPO/RTO, тесты восстановления, изоляция копий
Средний	Обучение персонала	Периодичность, программы, подтверждение прохождения

Почему это важно? Эти документы покрывают самые уязвимые точки: доступы, изменения, инциденты, журналы и соответствие категории значимости.

Частая ошибка: обновлять «политику ИБ» и не трогать рабочие инструкции. В итоге политика говорит правильные вещи, но администратор продолжает работать по старой инструкции.

Какие решения помогают актуализировать регламенты КИИ

Актуализация регламентов вручную возможна, но плохо масштабируется. Для одной системы и десяти документов Excel ещё работает. Для десятков объектов КИИ, сотен мер защиты и нескольких регуляторов — уже нет.

SGRC/GRC-платформы

SGRC-платформы помогают связать требования, активы, меры защиты, документы, риски и задачи. На российском рынке есть решения, которые поддерживают работу с ИСПДн, КИИ, ГИС, СМИБ/СУИБ и банковскими системами защиты. Например, SECURITM позиционируется как SGRC-система для управления ИСПДн, КИИ, ГИС, СМИБ/СУИБ и банковскими системами защиты [11]. R-Vision SGRC содержит предустановленные ИБ-стандарты, нормативные требования и методики оценки, а также связывает требования с ИТ- и ИБ-активами [10]. Интеграторы и центры кибербезопасности также предлагают подбор SGRC-решений под задачи бизнеса [12].

Что дают SGRC:

• реестр активов и документов;
• матрицу требований и мер;
• контроль версий локальных нормативных актов;
• управление замечаниями и планами устранения;
• планирование внутреннего контроля;
• отчёты для руководства и аудита;
• связь между рисками и конкретными объектами КИИ.

SIEM, SOAR и IRP

SIEM фиксирует события безопасности, SOAR автоматизирует часть реакций, IRP помогает управлять инцидентами. Для актуализации регламентов они нужны не вместо документов, а как источник фактов. Если регламент говорит, что события отправляются в SIEM, SIEM должна это подтверждать.

CMDB и системы учёта активов

Без актуального реестра активов невозможно поддерживать актуальные регламенты. CMDB помогает понимать, какие серверы, сети, сервисы и СЗИ относятся к объекту КИИ.

Сканеры уязвимостей и средства контроля конфигураций

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

СЭД и трекеры задач

Электронный документооборот нужен для утверждения и ознакомления, а трекеры — для контроля устранения замечаний. Хорошо, когда замечание внутреннего контроля превращается в задачу с владельцем, сроком и доказательством выполнения.

Важно: автоматизация не отменяет экспертизу. SGRC не скажет сама, правильно ли вы определили объект КИИ. Она поможет не потерять связи и сроки, но содержание всё равно должно проверяться специалистами.

Архитектура процесса: как связать документы, активы и контроль

Рабочая архитектура управления регламентами КИИ выглядит так:

1. Реестр объектов КИИ. Содержит объекты, категории, владельцев, критические процессы, связи с активами.
2. Реестр нормативных требований. 187-ФЗ, ПП № 127, приказы ФСТЭК, отраслевые требования, внутренние политики.
3. Матрица соответствия. Каждое требование связано с документом, мерой защиты и доказательством.
4. Реестр локальных нормативных актов. Версии, статусы, владельцы, даты пересмотра.
5. Реестр замечаний. Результаты аудитов, внутреннего контроля, тестирования, инцидентов.
6. План корректирующих мероприятий. Задачи, сроки, ответственные, подтверждающие артефакты.
7. Мониторинг исполнения. SIEM, сканеры, отчёты СЗИ, журналы, результаты тестов.

В идеале всё это не должно жить в разных Excel-файлах. Минимальная зрелость — единый каталог документов и задач. Более высокий уровень — SGRC, связанный с CMDB, SIEM и ITSM.

Почему это важно? Когда регулятор или аудитор спрашивает: «почему мера реализована именно так?», зрелая организация показывает цепочку: требование → категория объекта → модель угроз → регламент → настройка → журнал/отчёт.

Практические примеры актуализации

Пример 1. Внедрили новый удалённый доступ

Компания добавила VPN для подрядчика, обслуживающего технологическую систему. Что нужно обновить:

• модель угроз;
• схему сетевого взаимодействия;
• регламент управления доступом;
• правила межсетевого экранирования;
• инструкцию администратора;
• порядок журналирования;
• сценарий реагирования на компрометацию учётной записи подрядчика;
• матрицу доступа.

Если обновить только сетевую схему, остаётся риск: доступ вроде появился, а процесс контроля и реагирования не изменился.

Пример 2. Объект попал в типовой отраслевой перечень

После выхода перечня типовых отраслевых объектов субъект КИИ сопоставляет свои системы с перечнем. Если объект соответствует типовому, нужно:

• пересмотреть перечень объектов КИИ;
• проверить материалы категорирования;
• обновить обоснование категории;
• проверить модель угроз;
• скорректировать регламенты защиты;
• при необходимости направить актуализированные сведения.

Пример 3. Сменили SIEM

Организация перешла на отечественную SIEM. Обновляются:

• регламент журналирования;
• перечень источников событий;
• инструкции операторов SOC;
• правила корреляции;
• регламент реагирования;
• порядок хранения и защиты журналов;
• отчёты внутреннего контроля.

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

Типичные ошибки при актуализации регламентов КИИ

1. Актуализация только ради даты. Меняют титульный лист, но не проверяют содержание.
2. Отрыв документов от инфраструктуры. В регламенте один состав систем, в CMDB и сети — другой.
3. Нет владельцев документов. Непонятно, кто отвечает за пересмотр и согласование.
4. Не учитываются изменения законодательства. Особенно опасно после 58-ФЗ, указа № 214 и появления перечней типовых отраслевых объектов.
5. Нет связи с моделью угроз. Меры защиты описаны, но не понятно, какие угрозы они закрывают.
6. Не проводится контроль исполнения. Документ утверждён, но настройки не изменились.
7. Регламенты написаны слишком общо. «Обеспечить контроль доступа» — это не процедура. Нужны роли, сроки, действия и доказательства.
8. Не фиксируются версии. Невозможно понять, какая редакция действовала в момент инцидента.
9. Игнорируются подрядчики. У подрядчика есть доступ, но в регламенте его нет.
10. Не обучают сотрудников. Новый порядок есть, но пользователи и администраторы о нём не знают.

Как избежать? Работать через реестр документов, матрицу соответствия и процесс управления изменениями. Любая правка должна иметь причину, владельца и доказательство внедрения.

Лучшие практики актуализации регламентов КИИ

• Вести единый реестр объектов, активов и документов.
• Привязать каждый регламент к конкретному объекту КИИ или процессу.
• Пересматривать документы после каждого существенного изменения, а не только раз в год.
• Создать матрицу «требование → мера → документ → доказательство».
• Утверждать версионность и хранить архив предыдущих редакций.
• Проводить внутренний контроль исполнения после актуализации.
• Использовать SGRC или хотя бы централизованный реестр с ответственными и сроками.
• Не использовать шаблоны без адаптации.
• Разделять документы для руководства, ИБ, ИТ и пользователей: у них разная глубина детализации.
• Проводить короткие тренировки по критичным регламентам: инцидент, отказ, компрометация доступа.

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

Сравнение подходов: вручную, через СЭД или через SGRC

Подход	Когда подходит	Плюсы	Минусы
Excel и папки	Малое число объектов и документов	Дёшево, быстро стартовать	Высокий риск ошибок, нет связей, сложно контролировать версии
СЭД + трекер задач	Средняя зрелость, много согласований	Есть маршруты согласования и контроль задач	Нет встроенной матрицы требований и активов
SGRC/GRC	Несколько объектов КИИ, аудит, регуляторика	Матрицы соответствия, риски, контроль, отчёты	Нужно внедрение и методическая настройка
Полный контур SGRC + CMDB + SIEM + ITSM	Зрелые компании, SOC, много объектов	Фактическая картина, автоматизация, доказательства исполнения	Требует архитектуры и зрелых процессов

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

Чек-лист актуализации регламентов КИИ

Проверьте:

• Есть актуальный перечень объектов КИИ.
• Объекты сопоставлены с типовыми отраслевыми объектами.
• Материалы категорирования соответствуют текущей инфраструктуре.
• Модель угроз обновлена после архитектурных изменений.
• Назначены владельцы всех документов.
• У каждого регламента есть версия, дата и основание изменения.
• Регламенты доступа соответствуют фактическим ролям.
• Все административные учётные записи персонализированы или обоснованы.
• Источники событий подключены к SIEM согласно регламенту.
• Сценарии реагирования проверены тренировкой.
• Контакты НКЦКИ/ГосСОПКА и внутренних ответственных актуальны.
• Замечания аудита переведены в задачи с ответственными и сроками.
• После утверждения документов сотрудники ознакомлены с новой редакцией.
• Есть архив предыдущих версий.
• Проведена проверка исполнения после актуализации.

FAQ: частые вопросы об актуализации регламентов КИИ

Как часто нужно актуализировать регламенты КИИ?

Минимально — по утверждённому графику внутреннего контроля. Практически — при каждом существенном изменении: новая система, изменение доступа, инцидент, новый нормативный акт, изменение категории, замена СЗИ.

Можно ли использовать типовые шаблоны?

Можно как основу, но нельзя без адаптации. Шаблон должен быть привязан к реальной архитектуре, категории объекта, модели угроз и конкретным мерам защиты.

Нужно ли обновлять модель угроз при каждом изменении?

Не при каждом мелком изменении, но при любом изменении, которое влияет на угрозы, границы объекта, каналы доступа, состав активов или сценарии атак.

Что важнее: документ или техническая настройка?

В КИИ важны оба. Документ показывает управляемость, настройка показывает исполнение. Если одно противоречит другому, это риск.

Какие решения помогают быстрее всего?

Для начала — реестр документов, задач и активов. Для зрелого процесса — SGRC/GRC, CMDB, SIEM, ITSM, системы электронного документооборота и средства контроля конфигураций.

Что делать, если документов много и они устарели?

Начать с инвентаризации, выделить критичные документы, связать их с объектами КИИ и требованиями, провести gap-анализ, затем обновлять пакетами по приоритету риска.

Основные выводы

Актуализация регламентов для объектов КИИ — это не формальная обязанность, а рабочий механизм управления безопасностью. Документы должны отражать реальную инфраструктуру, актуальную категорию значимости, действующие угрозы, применяемые СЗИ и порядок реагирования. Новые требования 2025–2026 годов усилили необходимость регулярного пересмотра локальных нормативных актов: изменения в 187-ФЗ, корректировка режима использования иностранного ПО, появление перечня типовых отраслевых объектов КИИ — всё это влияет на внутренние документы.

Ключевая мысль простая: если регламент нельзя применить во время инцидента, проверки или изменения инфраструктуры, он не выполняет свою функцию. Зрелая организация рассматривает регламенты как живую систему: у каждого документа есть владелец, версия, привязка к требованиям и доказательства исполнения. Автоматизация через SGRC, SIEM, CMDB, ITSM и электронный документооборот помогает удерживать этот процесс под контролем.

Кратко: сначала инвентаризация, потом сопоставление с требованиями, затем gap-анализ, обновление документов, внедрение изменений и контроль исполнения. Именно такая последовательность делает актуализацию регламентов КИИ практической, а не бумажной.

Источники

1. Федеральный закон № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации». https://publication.pravo.gov.ru/Document/View/0001201707260023
2. Постановление Правительства РФ № 127 «Об утверждении Правил категорирования объектов КИИ...». https://government.ru/docs/all/115353/
3. Приказ ФСТЭК России № 235 «Требования к созданию систем безопасности значимых объектов КИИ...». https://publication.pravo.gov.ru/Document/View/0001201802220016
4. Приказ ФСТЭК России № 239 «Требования по обеспечению безопасности значимых объектов КИИ...». https://legalacts.ru/doc/prikaz-fstek-rossii-ot-25122017-n-239-ob-utverzhdenii/
5. Федеральный закон № 58-ФЗ от 07.04.2025 о внесении изменений в 187-ФЗ. https://publication.pravo.gov.ru/document/0001202504070004
6. Указ Президента РФ № 214 от 07.04.2025 о внесении изменения в Указ № 166. https://publication.pravo.gov.ru/document/0001202504070002
7. Распоряжение Правительства РФ № 360-р от 26.02.2026 о перечне типовых отраслевых объектов КИИ. https://publication.pravo.gov.ru/document/0001202602260020
8. NIST Cybersecurity Framework 2.0. https://www.nist.gov/publications/nist-cybersecurity-framework-csf-20
9. NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations. https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
10. R-Vision SGRC — описание продукта. https://rvision.ru/products/sgrc
11. SECURITM: контроль соответствия по приказу ФСТЭК № 239. https://service.securitm.ru/docs/fstec-239/aud
12. Центр кибербезопасности УЦСБ: SGRC-решения. https://sec.ussc.ru/solutions/sgrc

Автор: Филиппова Анастасия Вячеславовна, специалист по информационной безопасности.