26 февраля 2026 года правительство выпустило распоряжение № 360-р с единым перечнем типовых отраслевых объектов КИИ, а в силу документ вступил уже 27 февраля. Для многих компаний это неприятное, но полезное прояснение: спорить, субъект КИИ вы или нет, теперь заметно сложнее, потому что перечень насчитывает 397 позиций и сильно сужает поле для вольных трактовок.
Как пишет IT-World, раньше бизнес часто жил по удобной логике: закон 187-ФЗ есть, но наши системы якобы не дотягивают до критических, значит, и категорирование можно не форсировать. Новый перечень эту тактику ломает. Если информационная система, сеть или АСУ ТП совпадает с описанием из документа, комиссия по категорированию должна учитывать ее как объект КИИ, а не спорить с очевидным.
Здесь важна одна деталь, о которую многие будут спотыкаться еще не раз. Субъект КИИ определяется не только отраслью в уставе и не вывеской на входе в офис. Формально закон охватывает 14 сфер из статьи 2 187-ФЗ: от здравоохранения, связи и транспорта до финансового рынка, ТЭК, металлургии и регистрации прав на недвижимость. Но решает не сам факт работы в отрасли, а наличие у организации систем, которые обеспечивают критические процессы. До февраля 2026 года эту грань можно было трактовать в свою пользу. После выхода перечня пространство для самодиагностики в стиле «у нас ничего критичного нет» заметно сузилось.
Практический смысл нововведения довольно жесткий. Если объект найден, его нужно включать в контур категорирования. А дальше начинается не абстрактная бумажная работа, а вполне конкретная процедура со сроками. По правилам категорирования перечень объектов направляется во ФСТЭК в течение пяти рабочих дней после утверждения, акт категорирования — в течение десяти рабочих дней после утверждения, а максимальный срок самой процедуры составляет один год. На бумаге срок выглядит щедро, но на практике регулятор, как правило, не ждет, пока компания неторопливо проживет еще один бюджетный цикл.
Что меняется для ИТ и ИБ-команд
Даже если по итогам категорирования объект не получит категорию значимости, обязанности у субъекта КИИ все равно появляются. Во-первых, нужно провести само категорирование и юридически оформить результат, включая сценарий, когда объект признан незначимым. Во-вторых, нужно уведомлять о компьютерных инцидентах. По приказу ФСБ № 282 информация о компьютерном инциденте на значимом объекте должна уйти в НКЦКИ не позднее трех часов с момента обнаружения, по иным объектам КИИ — не позднее 24 часов. В-третьих, необходимо выстроить взаимодействие с ГосСОПКА и хотя бы на базовом уровне определить регламент реагирования, ответственных и каналы связи. В-четвертых, субъект КИИ обязан содействовать ФСБ, включая доступ к ресурсам для мониторинга защищенности.
Если же хотя бы один объект получает I, II или III категорию значимости, жизнь становится еще интереснее. Тогда уже недостаточно просто завести папку с актами и назначить ответственного письмом по организации. Нужно строить систему безопасности значимого объекта по требованиям ФСТЭК, подключаться к ГосСОПКА в режиме непрерывного взаимодействия — через собственный аккредитованный центр мониторинга или через внешний — и поддерживать актуальные сведения для регулятора. С 1 сентября 2025 года действует расширенная форма направления сведений о результатах категорирования: в ней требуется больше технических деталей, вплоть до доменных имен, внешних сетевых адресов, сведений о версиях ПО и применяемых средствах защиты.
Для разработчиков, инфраструктурных инженеров и ИТ-руководителей это означает простую вещь: тема перестает быть делом только юристов и compliance-специалистов. Как только компания признает, что у нее есть объект КИИ, в повестку попадают архитектура системы, состав серверов, сетевое окружение, администрирование, резервирование, журналирование, схемы доступа, цепочки обновлений и даже рабочие места операторов. И если внутри компании кто-то по привычке считает, что КИИ — это исключительно про АСУ ТП на заводе, ему стоит быстро обновить картину мира.
Главная ошибка — защищать систему, а не ее контур
Самый неприятный просчет, на который обращает внимание источник, выглядит знакомо для любого ИБ-аудита. Организация находит «главную» систему, признает ее объектом КИИ и начинает строить защиту вокруг нее, будто все остальное — просто фон. Но объект не существует в вакууме. Его работу обеспечивают серверы, гипервизоры, СУБД, сетевое оборудование, каналы связи, средства удаленного доступа, рабочие станции операторов и администраторов. Компрометация этого контура по факту бьет по объекту не хуже прямой атаки на саму систему.
Отсюда и неприятный для бизнеса вывод: инвентаризация должна охватывать не только то, что хочется показать комиссии, но и весь технологический контур, без которого объект не функционирует. Это уже вопрос не формального соответствия, а реальной устойчивости. И именно здесь многие компании рискуют обнаружить, что у них давно накопился технический долг: старые сегменты сети, плохо учтенные интеграции, сервисные учетные записи без нормального контроля, теневые админские каналы и подрядчики с доступом, про которых помнят только в момент инцидента.
Параллельно действует и указ президента № 250, который для субъекта КИИ добавляет организационные требования: нужен заместитель руководителя, отвечающий за ИБ, с подтвержденной квалификацией, а также профильное подразделение или формально закрепленные функции безопасности. Иными словами, государство постепенно убирает лазейку, когда критичная по сути инфраструктура существовала на правах «обычного ИТ-хозяйства», а отвечал за нее в лучшем случае перегруженный директор по инфраструктуре.
На рынке это, скорее всего, приведет не к громким заявлениям, а к тихой волне внутренних проверок. Компании будут пересматривать перечни систем, сверяться с типовыми объектами, переписывать регламенты и заново считать, где у них проходит реальный контур КИИ. Для одних это закончится дополнительной бюрократией, для других — затратами на перестройку процессов и защиты. Но главный эффект уже случился: вопрос «мы точно субъект КИИ?» перестал быть удобной философской дискуссией и все больше становится вопросом качественной инвентаризации и готовности отвечать за свои системы по-взрослому.