Экспертиза доверенного ПО: что проверяют и как готовиться в 2026 году

Материал повторял вымышленный кейс екатеринбургского разработчика SCADA-систем и подавал подготовку к экспертизе доверенного ПО как рутинную услугу с многолетней практикой. На деле сама процедура появилась только с 1 марта 2026 года. Разбираем, что реально происходит на этапе рассмотрения заявления и как к нему готовиться по существу, а не на бумаге.

Главное: с 1 марта 2026 года действует постановление Правительства РФ №1937 от 28.11.2025, вводящее статус доверенного ПО. Рассмотрение заявления проверяет и комплектность документов, и содержательное соответствие продукта требованиям: права на российское юрлицо без иностранного контроля, наличие записи в реестре российского ПО, соответствие требованиям информационной безопасности для категории доверенного ПО и совместимость минимум с двумя операционными системами, отвечающими требованиям к доверенным ОС. Подготовка к этому этапу — это в первую очередь техническая работа, а не сбор бумаг сам по себе.

Что именно проверяется при рассмотрении заявления

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

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

Как готовиться к рассмотрению содержательно

Разумная последовательность подготовки начинается не с сбора документов, а с проверки самой применимости процедуры: относится ли продукт к категории, для которой уже наступила или скоро наступит обязательность по графику постановления №1937. Дальше стоит проверить формальные предварительные условия: наличие записи в базовом реестре российского ПО, корректность оформления прав. Затем идёт техническая часть: реальное тестирование совместимости с доверенными операционными системами, а не предположение о ней на основе общей архитектуры продукта. И только после этого имеет смысл переходить к формированию пакета документов на подачу.

Где чаще всего расходятся ожидания с реальностью

Разработчики нередко ожидают, что статус доверенного ПО оформляется примерно так же, как обычная запись в реестре российского ПО, — через комплект документов и относительно предсказуемые сроки. На практике требование совместимости с доверенными ОС — новый для многих продуктов технический барьер, особенно для решений, которые исторически разрабатывались и тестировались под одну конкретную операционную систему. Разрыв между документальной готовностью (права оформлены, продукт в реестре) и технической готовностью (продукт реально работает на нужных ОС) чаще всего и объясняет, почему процедура занимает больше времени, чем ожидалось изначально.

Почему требование доверенных ОС — не формальность

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

Начать стоит с консультации: специалисты, которые следят за практикой применения постановления №1937, помогут заранее сопоставить архитектуру конкретного продукта с актуальным перечнем доверенных операционных систем и оценить реальный объём технической доработки, а не только состав документов для заявления.

Что происходит после положительного решения

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

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

Источники

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