Категорирование объектов критической информационной инфраструктуры (КИИ) после изменений в Постановлении №127 вызывает множество вопросов. На практике чаще всего ошибаются при применении пункта 13.1, особенно в отношении «пограничных» систем: 1С, СКУД, CAD.

📌 В этой статье вы получите:
  • понятное объяснение новой логики категорирования
  • практический алгоритм (как делать правильно)
  • типовые ошибки, за которые делают замечания
  • готовые формулировки, которые подходят для проверок (в том числе ФСТЭК)

Что изменилось: от критериев к роли субъекта

Ранее (пункт 13)
  • использовались пороговые критерии значимости
  • допускалась категория «0» (не значимый объект)
Сейчас (пункт 13.1)
  • критерии в явном виде исключены
  • введён принцип роли субъекта
  • установлено правило: если субъект КИИ является головным исполнителем, объекту КИИ присваивается не ниже 1 категории значимости

Ключевая ошибка: категорируют всё подряд

❌ После изменений многие делают вывод:

«Мы головной исполнитель → всем системам ставим 1 категорию»

Это методически неверно и часто становится причиной замечаний.

⚠️ Главное правило

Пункт 13.1 применяется только к объектам КИИ, а не ко всей ИТ-инфраструктуре.

Правильный алгоритм категорирования КИИ

Шаг 1

Инвентаризация информационных систем

Формируется полный перечень: ИС, АСУ, сетей и сервисов.

Шаг 2

Выделение критических процессов

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

Шаг 3

Определение объектов КИИ

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

Шаг 4

Применение пункта 13.1

Если система признана объектом КИИ и при статусе головного исполнителя → присваивается категория не ниже 1.

Практический разбор: 1С, СКУД, CAD

Это самые частые запросы:

  • «нужно ли категорировать 1С КИИ»
  • «СКУД категория КИИ»
  • «CAD объект КИИ или нет»
📊 1С (бухгалтерия, HR)

Типовая ситуация: не участвует в критических процессах, выполняет учётные функции.

✔ Вывод: не является объектом КИИ → не подлежит категорированию.
🚪 СКУД

Типовая ситуация: вспомогательная система, не влияет на технологические процессы.

✔ Вывод: не является КИИ.
❗ Исключение: если влияет на безопасность критического объекта.
📐 CAD-системы

Типовая ситуация: используются для проектирования, не участвуют в управлении процессами.

✔ Вывод: не являются КИИ.
❗ Исключение: если интегрированы в контур управления производством.

Формулировки для акта категорирования (как «любят» на проверках)

Можно использовать практически дословно.

Если система НЕ является КИИ

«Информационная система не участвует в выполнении критических процессов, не оказывает влияния на их результат и не приводит к значимым последствиям в случае нарушения функционирования.

На основании проведённого анализа система не отнесена к объектам критической информационной инфраструктуры и категорированию не подлежит.»

Если система является КИИ

«Информационная система участвует в выполнении критических процессов (указать каких), оказывает влияние на их результат и может привести к значимым последствиям при нарушении функционирования.

В связи с этим система отнесена к объектам КИИ.»

Применение пункта 13.1

«Организация является головным исполнителем в рамках выполняемых функций.

В соответствии с пунктом 13.1 Постановления №127 объекту КИИ присваивается категория значимости не ниже 1.»

Типичные ошибки (за которые делают замечания)

  • ❌ Категорирование всех систем подряд (1С, почта, видеонаблюдение и т.д.)
  • ❌ Отсутствие обоснования — нет ответа на вопросы: почему система КИИ или почему не КИИ
  • ❌ Игнорирование процессов — категорирование без привязки к бизнес-процессам и последствиям
  • ❌ Неправильное применение п.13.1 — использование его до определения объектов КИИ или вместо анализа

Как пройти проверку без проблем

  • ✔ Разделяйте: все системы и объекты КИИ
  • ✔ Фиксируйте: обоснование «не КИИ» и обоснование категории
  • ✔ Показывайте: связь системы с процессами
  • ✔ Применяйте п.13.1: только после отбора объектов КИИ

Краткий итог

  • Пункт 13.1 не отменяет этап определения КИИ
  • Не все системы подлежат категорированию
  • 1С, СКУД, CAD — чаще всего не КИИ
  • Если объект признан КИИ и вы головной исполнитель → категория не ниже 1

Вывод

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

Именно это отличает корректное категорирование от формального
— и позволяет уверенно проходить проверки.

Чек-лист: готовность к категорированию по п.13.1

Отметьте пункты, которые уже выполнены.

Выполнено: 0 из 12
  • Проведена инвентаризация всех информационных систем
  • Выделены критические процессы организации
  • Определены системы, участвующие в критических процессах
  • Сформирован перечень объектов КИИ
  • По каждой системе есть обоснование «КИИ» или «не КИИ»
  • Проверен статус головного исполнителя
  • Применён п.13.1 только к объектам КИИ
  • Оформлен акт категорирования
  • Акт утверждён руководителем
  • Сведения направлены во ФСТЭК
  • Проверены формулировки для акта
  • Внесены изменения во внутренние документы

Сохраните чек-лист, чтобы оценить готовность к категорированию по п.13.1.

Как МАСО ИТ помогает с категорированием КИИ

Что мы делаем в программах и курсах

Мы обучаем специалистов работе с новыми правилами категорирования, включая применение пункта 13.1. Наши курсы по КИИ и ЗОКИИ включают разбор практических кейсов по выделению объектов КИИ, обоснованию решений и оформлению актов категорирования.

Наш подход

  • Практическая направленность: отработка алгоритмов на реальных примерах.
  • Актуальная регуляторика: изучаем свежие изменения в ПП №127.
  • Разбор ошибок: на реальных кейсах показываем, как не попасть в ловушку формального подхода.
  • Готовые формулировки: даём шаблоны для актов категорирования.

Связанные материалы (статьи в блоге МАСО ИТ)

FAQ

Что изменилось в пункте 13.1 Постановления №127?
Ранее использовались пороговые критерии значимости. Теперь введён принцип роли субъекта: если субъект КИИ является головным исполнителем, объекту КИИ присваивается категория не ниже 1.
Нужно ли категорировать 1С как КИИ?
Чаще всего нет. 1С выполняет учётные функции и не участвует в критических процессах. Но если 1С участвует в критическом процессе — её нужно рассматривать как объект КИИ.
СКУД — это объект КИИ?
Обычно нет. СКУД — вспомогательная система. Исключение: если СКУД влияет на безопасность критического объекта.
CAD-системы нужно категорировать?
В большинстве случаев нет. CAD используются для проектирования, не управляют процессами. Исключение: если интегрированы в контур управления производством.
Можно ли применять пункт 13.1 ко всем системам?
Нет. Пункт 13.1 применяется только к объектам КИИ, а не ко всей инфраструктуре. Сначала нужно определить, что является объектом КИИ.
Какие формулировки использовать в акте категорирования?
В статье приведены готовые формулировки для случаев «система не КИИ», «система КИИ» и «применение п.13.1». Их можно использовать практически дословно.

Об авторе

Халяпин Владислав — эксперт в области информационной безопасности и преподаватель МАСО ИТ. Имеет практический опыт категорирования объектов КИИ в различных отраслях. Специализируется на вопросах регуляторного соответствия, категорировании объектов КИИ и обучении персонала.

Страница автора: https://maso-it.ru/author

Хотите разобраться с категорированием КИИ без ошибок?

Запишитесь на консультацию по обучению →