Главная страница категории

Всё о получении статуса доверенного ПО: этапы, требования, сроки и наши услуги.

Перейти на страницу

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

Главное: требования к доверенному ПО закреплены в части 37 статьи 2 федерального закона №58-ФЗ и постановлении Правительства РФ №1937 от 28.11.2025. Продукт должен одновременно соответствовать пяти условиям: российское правообладание под контролем более 50% голосующих долей, действующая запись в реестре российского ПО, совместимость минимум с двумя доверенными операционными системами, соответствие требованиям информационной безопасности и отсутствие сведений, составляющих государственную тайну. Перечень требований единый для всех категорий ПО — различается их практическое содержание и дата, с которой отсутствие статуса начинает влиять на позицию в закупках.

Утверждение из старой версии статьиРеальное положение дел
«По нашей практике работы с разработчиками ПО с 2015 года», «с 2015 года провели аудиты сотен программных продуктов» применительно к доверенному статусуСтатус доверенного ПО существует с марта 2026 года; такая многолетняя практика по нему физически невозможна
Цена «от 30 000 ₽»Не подтверждается официальными источниками; стоимость определяется индивидуально

Требование 1: российское правообладание

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

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

Требование 2: включение в реестр российского ПО

Реестровая запись в ФГИС «Реестр программного обеспечения» Минцифры — обязательное предварительное условие, без которого подача заявления на доверенный статус невозможна. Важный нюанс: запись должна быть актуальной. Если с момента включения в реестр продукт существенно изменился — новая версия, изменение функциональности, смена правообладателя, — сведения нужно актуализировать до подачи на доверенный статус: расхождение между реальным продуктом и реестровой записью становится основанием для вопросов при экспертизе.

Требование 3: совместимость с доверенными ОС

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

Требование 4: соответствие требованиям информационной безопасности

Продукт должен пройти экспертизу и получить положительное заключение по нескольким направлениям: отсутствие известных уязвимостей и архитектурных проблем безопасности (устаревшие зависимости с открытыми CVE, небезопасные API — типичные источники замечаний), отсутствие недокументированных функций (скрытые каналы передачи данных, недокументированное удалённое управление, несанкционированный сбор сведений о системе), применение российских криптоалгоритмов по ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012 для продуктов с криптографическими функциями, и наличие актуальной документации по безопасности — модели угроз, описания механизмов защиты, архитектурной документации.

Дополнительное требование для государственных компаний

Для разработчиков — государственных компаний или организаций с долей государственного участия действует правило: не более 30% выручки от реализации программного продукта должно поступать от организаций из той же группы лиц. Правило направлено против ситуации, когда госкомпания формально создаёт коммерческий продукт, но фактически продаёт его только аффилированным структурам, не имея реального рынка. Расчёт ведётся по данным последнего завершённого финансового года.

Требование 5: отсутствие сведений, составляющих гостайну

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

Как требования соотносятся с категорией и дедлайном

Набор требований единый, но их практическое содержание и дата вступления обязательности различаются по категориям: для офисного ПО (с 1 сентября 2026 года) акцент на совместимость через нативные приложения и работу с документными форматами; для серверного ПО, СУБД и связующего ПО (с 1 января 2027 года) — повышенные требования ИБ и кластерная функциональность на серверных дистрибутивах; для прикладного ПО и средств информационной безопасности (с 1 июня 2027 года) — для ИБ-продуктов дополнительная проверка собственной безопасности, для прикладного — история прав на многолетний код; для промышленного ПО, АСУТП и SCADA (с 1 января 2028 года) — аппаратные зависимости, возможное исключение по ПАК и требования критической информационной инфраструктуры.

Вопросы и ответы

Короткие ответы на вопросы, которые чаще всего возникают при подготовке документов и подаче заявки.

Какие пять требований должен одновременно выполнить продукт для доверенного статуса?

Российское правообладание под контролем более 50% голосующих долей, действующая запись в реестре российского ПО, совместимость минимум с двумя доверенными ОС, соответствие требованиям информационной безопасности и отсутствие сведений, составляющих гостайну.

Достаточно ли, чтобы компания-заявитель была на 100% российской?

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

Какие два исключения снимают требование совместимости с доверенными ОС?

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

Отличается ли перечень требований в зависимости от категории продукта?

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

Источники