Сроки вступления требований к доверенному ПО по категориям

Материал давал подробный и в целом точный график дедлайнов доверенного статуса по волнам — с разбором специфики подготовки для каждой категории и реалистичным обратным отсчётом сроков. Портили его вымышленная статистика «95% успешных включений» и фраза о сопровождении разработчиков «с 2015 года» применительно к механизму, которому несколько месяцев. Оставляем график и расчёт сроков, убираем недоказуемые цифры.

Главное: постановление №1937 вступило в силу 1 марта 2026 года, но обязательность доверенного статуса по категориям ПО вводится четырьмя волнами: офисное ПО: 1 сентября 2026; серверное ПО/СУБД/связующее ПО/мониторинг: 1 января 2027; прикладное ПО и средства ИБ: 1 июня 2027; промышленное ПО и АСУТП: 1 января 2028. Дата дедлайна — не день, когда нужно получить статус, а день, с которого реестровое ПО без отметки этой категории начинает приравниваться к иностранному при наличии в закупке доверенного конкурента.

Полный график дедлайнов по категориям ПО

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

Первая волна: офисное ПО, дедлайн 1 сентября 2026

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

К офисному ПО относят текстовые редакторы и процессоры, электронные таблицы, почтовые клиенты, корпоративные мессенджеры, платформы видеоконференций, системы управления документами и контентом. Специфика этого сегмента в том, что он исторически Windows-ориентирован: совместимость с Astra Linux и РЕД ОС нередко требует доработки именно нативных компонентов, а не только серверной части, и отдельным блоком проверки становится взаимодействие с доверенными браузерами при работе с документными форматами.

Вторая волна: серверное ПО, СУБД, связующее ПО, мониторинг — дедлайн 1 января 2027

Четыре категории с одним дедлайном создают концентрированный спрос на экспертизу центров тестирования во второй половине 2026 года. Разработчики, подавшие заявления в первом полугодии, скорее попадут в менее загруженный период с предсказуемыми сроками.

Третья волна: прикладное ПО и средства ИБ — дедлайн 1 июня 2027

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

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

Четвёртая волна: промышленное ПО — дедлайн 1 января 2028

Последний по дате дедлайн приходится на самый технически сложный сегмент. АСУТП, SCADA и DCS-системы работают с аппаратными зависимостями и протоколами реального времени, а проверка совместимости с доверенными ОС на работающем производственном объекте невозможна — нужен отдельный стенд, разработка и развёртывание которого само по себе занимает месяцы. Для продукта с глубокими аппаратными зависимостями подготовка к экспертизе может потребовать 6–12 месяцев доработки, и вместе с официальными сроками процедуры это означает, что начинать разумно уже в 2026 году, несмотря на формально далёкий дедлайн.

Отдельный технический нюанс для этой волны — исключение для программно-аппаратных комплексов. ПО, являющееся неотъемлемой частью ПАК с технической привязкой к конкретной аппаратной платформе, может быть освобождено от требования совместимости с двумя доверенными ОС при документальном обосновании этой привязки. Важно не путать это узкое исключение внутри постановления №1937 с отдельным статусом доверенного программно-аппаратного комплекса по постановлению №1912 — это разные механизмы с разными критериями и адресатами.

Когда начинать подготовку: обратный отсчёт

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

Почему реальный срок длиннее регламентного

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

Как определить категорию своего продукта

Правильная классификация — первый практический шаг: от неё зависят дата дедлайна и специфика требований при экспертизе. Классификатор программного обеспечения Минцифры содержит несколько десятков классов, и один продукт иногда формально подходит под несколько из них. Ошибка в классификации может стоить дорого: продукт проходит реестровую запись как средство мониторинга с дедлайном в январе 2027 года, хотя заказчики фактически воспринимают его как ИБ-инструмент с дедлайном в июне 2027 года. Или наоборот, разработчик опаздывает, потому что неверно определил категорию на старте. Правильный класс определяется по основной функциональности продукта и согласуется с классификатором Минцифры.

Источники

• КонсультантПлюс, порядок формирования перечня доверенного ПО: график вступления требований по категориям постановления №1937.
• Реестр российского программного обеспечения, Минцифры России: классификатор категорий ПО и порядок реестровой записи.