Требования к доверенному программному обеспечению закреплены в двух нормативных документах: части 37 статьи 2 Федерального закона № 58-ФЗ и постановлении Правительства РФ № 1937 от 28 ноября 2025 года. Читать оба документа в оригинале — занятие для юристов: формулировки технические, отсылки множественные, исключения вложены в исключения. На практике разработчикам нужен структурированный ответ на вопрос: что именно должно быть у моего продукта, чтобы получить доверенный статус? Ниже — именно такой разбор, без лишних юридических конструкций, но с сохранением точности.
Полный перечень требований к доверенному ПО
Все требования можно разделить на три блока: требования к правообладателю, требования к самому продукту и требования к процедуре подтверждения. Ни одно из них не является опциональным — несоответствие любому критерию исключает возможность получения статуса.
Блок Требование Нормативная база Правообладатель Исключительные права принадлежат российскому лицу или организации ч. 37 ст. 2 № 58-ФЗ Организация находится под российским контролем (более 50% голосующих долей у российских лиц) ч. 37 ст. 2 № 58-ФЗ Для госкомпаний: не более 30% выручки от реализации ПО поступает от аффилированных лиц Постановление № 1937 Продукт Включён в реестр российского программного обеспечения и баз данных Минцифры ч. 37 ст. 2 № 58-ФЗ Совместим не менее чем с двумя доверенными ОС из перечня Минцифры Постановление № 1937 Не содержит сведений, составляющих государственную тайну ч. 37 ст. 2 № 58-ФЗ Процедура Прошёл экспертизу в аккредитованном центре тестирования Постановление № 1937 Получил положительное решение правительственной комиссии по цифровому развитию Постановление № 1937
Требование 1: российское правообладание
Исключительные права на программный продукт должны принадлежать одному из допустимых российских субъектов. Закон устанавливает закрытый перечень: Российская Федерация, субъект РФ, муниципальное образование, некоммерческая организация без иностранного управляющего влияния, гражданин России, а также коммерческая организация под российским контролем.
На практике большинство частных разработчиков — это коммерческие организации, и для них ключевой вопрос: что такое «российский контроль»? Российский контроль означает, что более 50% голосующих долей или акций компании прямо или косвенно принадлежат российским лицам. При этом корпоративный договор не должен давать иностранным участникам блокирующих полномочий, которые фактически означали бы контроль над компанией, противоречащий формальному распределению долей.
Распространённая ошибка при оценке правообладания
Наличие иностранного соучредителя с долей менее 50% само по себе не является препятствием для доверенного статуса — если выполняется критерий российского контроля. Ошибка в другом: компании нередко не проверяют, как оформлены права на конкретный программный продукт. Права на компанию и права на продукт — разные вещи. Если продукт создавался подрядчиком без договора об отчуждении прав, или разрабатывался иностранными сотрудниками без надлежащих трудовых договоров — исключительные права на него могут формально не принадлежать российской компании-заявителю, даже если сама компания на 100% российская.
Требование 2: включение в реестр российского ПО
Реестровая запись в ФГИС «Реестр программного обеспечения» Минцифры — обязательное предварительное условие. Без неё подача заявления на доверенный статус невозможна. Если продукт ещё не в реестре, это первый шаг, и его нужно пройти до начала процедуры по постановлению № 1937.
Важный нюанс: реестровая запись должна быть актуальной. Если с момента включения в реестр продукт существенно изменился — новая версия, изменение функциональности, смена правообладателя — сведения в реестре нужно актуализировать до подачи на доверенный статус. Расхождение между реальным продуктом и реестровой записью является основанием для вопросов со стороны центра тестирования.
Требование 3: совместимость с доверенными операционными системами
Продукт должен быть совместим не менее чем с двумя доверенными ОС из перечня Минцифры. Перечень формируется и обновляется регулятором — включает преимущественно отечественные Linux-дистрибутивы: Astra Linux, РЕД ОС, ROSA Linux, Alt Linux и ряд других.
Совместимость — не формальная. Центр тестирования проверяет, что заявленная функциональность продукта реально работает на выбранных доверенных ОС. Частичная работа, работа с критическими ошибками или работа только базовых функций при нефункционирующих остальных — основание для замечаний или отрицательного заключения.
✅ Исключение 1: ПО в составе ПАК
Если ПО является неотъемлемой частью программно-аппаратного комплекса и его работа технически обусловлена конкретной аппаратной платформой — требование двух ОС не применяется. Исключение нужно обосновать документально.
✅ Исключение 2: одна группа лиц с правообладателем ОС
Если правообладатель программного продукта и правообладатель операционной системы входят в одну группу лиц — требование также снимается. Аффилированность должна быть подтверждена документально.
Требование 4: соответствие требованиям информационной безопасности
Продукт должен пройти экспертизу в аккредитованном центре тестирования и получить положительное заключение по требованиям информационной безопасности. Конкретный перечень проверок зависит от категории и класса ПО, но общие направления единые для всех продуктов.
🔍
Отсутствие уязвимостей
Центр тестирования проверяет продукт на наличие известных уязвимостей и архитектурных проблем безопасности. Устаревшие зависимости с открытыми CVE, небезопасные API, отсутствие обновлений безопасности — типичные источники замечаний.
🚫
Отсутствие недокументированных функций
Скрытые каналы передачи данных, функции удалённого управления без документирования, несанкционированный сбор сведений о системе — любое из этого ведёт к отрицательному заключению. Особенно критично для ИБ-продуктов и серверного ПО.
🔐
Российская криптография
Для продуктов, использующих криптографические функции, — применение российских алгоритмов по ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012. Использование исключительно иностранных криптоалгоритмов при наличии криптографических функций в продукте является серьёзным препятствием.
📋
Документация безопасности
Наличие актуальной документации: модель угроз, описание механизмов безопасности, архитектурная документация. Для серверного ПО, СУБД и ИБ-продуктов требования к документации особенно детальные.
Специальное требование для государственных компаний: правило 30%
Постановление № 1937 содержит дополнительное требование для разработчиков, являющихся государственными компаниями или организациями с долей государственного участия. Не более 30% выручки от реализации программного продукта должно поступать от организаций из той же группы лиц. Это правило направлено против ситуации, когда госкомпания формально создаёт коммерческий продукт, но фактически продаёт его только аффилированным структурам, не имея реального рынка.
Расчёт ведётся по данным последнего завершённого финансового года. При подаче заявления необходимо документально подтвердить соответствие этому критерию — или заранее выявить проблему и проработать её с юридическими консультантами.
Требование 5: отсутствие сведений, составляющих государственную тайну
Программный продукт не должен содержать сведений, составляющих государственную тайну. На практике это требование редко создаёт проблемы для коммерческих разработчиков — оно актуально преимущественно для специализированных продуктов, разрабатывавшихся изначально в оборонном или силовом контексте и впоследствии переориентированных на гражданский рынок.
Как соотносятся требования с категорией и дедлайном продукта
Перечень требований единый для всех категорий ПО. Различается не набор требований, а их практическое содержание для конкретной категории продукта и дата, с которой отсутствие доверенного статуса начинает влиять на позицию в закупках.
Категория ПО Дедлайн Специфика требований Офисное ПО 1 сентября 2026 Совместимость с доверенными ОС через нативные приложения, работа с документными форматами Серверное ПО, СУБД, связующее ПО, мониторинг 1 января 2027 Повышенные требования ИБ, серверные конфигурации доверенных ОС, кластерная функциональность Прикладное ПО, средства ИБ 1 июня 2027 Для ИБ-продуктов — дополнительная проверка собственной безопасности; для прикладного — история прав на многолетний код Промышленное ПО, АСУТП, SCADA 1 января 2028 Аппаратные зависимости, возможность исключения ПАК, требования КИИ
Типичные причины несоответствия требованиям
По нашей практике работы с разработчиками ПО с 2015 года несоответствие требованиям доверенного статуса чаще всего обнаруживается в нескольких характерных ситуациях. Знание этих точек риска помогает правильно расставить приоритеты при подготовке.
⚖️ Неоформленные права на код
Договоры ГПХ с фрилансерами без условий об отчуждении прав, трудовые договоры без служебных заданий, подрядные договоры без передачи прав. Особенно часто у продуктов с многолетней историей разработки.
🌍 Сложная корпоративная структура
Иностранные соучредители, холдинговые структуры с офшорными элементами, корпоративные договоры с нестандартным распределением голосов. Каждая такая ситуация требует отдельного юридического анализа.
💻 Глубокая привязка к Windows-платформе
Продукты, разрабатывавшиеся под Windows без учёта кросс-платформенности. Перенос на доверенные Linux-дистрибутивы требует значительных технических работ.
🔗 Зависимости от иностранных компонентов
Коммерческие библиотеки с ограниченными лицензиями, иностранные облачные сервисы как неотъемлемые компоненты, иностранные API без которых продукт не функционирует.
🔓 Уязвимости в устаревших зависимостях
Продукты, не получавшие регулярных обновлений безопасности, используют компоненты с известными CVE. При экспертизе центр тестирования выявляет их как нарушение требований ИБ.
📄 Расхождение реестровой записи с продуктом
Функциональность реального продукта существенно отличается от описания в реестре российского ПО из-за обновлений за прошедшие годы. Требует актуализации перед подачей заявления на доверенный статус.
Вопросы о требованиях к доверенному ПО
Все ли требования нужно выполнить до подачи заявления или часть проверяется уже в ходе процедуры?
Требования к правообладанию и реестровой записи должны быть выполнены до подачи заявления — Минцифры проверяет их при регистрации. Требования к совместимости с ОС и ИБ проверяются в ходе экспертизы в центре тестирования. Но готовить продукт к этим требованиям нужно заранее: обнаружить несовместимость или уязвимость уже в центре тестирования — значит получить отрицательное заключение и потратить деньги на повторную экспертизу. Именно поэтому предварительный аудит существенно снижает риски.
Нужно ли выполнять требования к российской криптографии, если продукт не является средством криптографической защиты?
Требование применения российской криптографии по ГОСТ актуально для продуктов, которые реализуют криптографические функции — шифрование данных, электронную подпись, защищённые каналы связи. Если продукт не использует криптографические функции вообще, требование не применяется. Если использует частично — применяется к той части функциональности, которая связана с криптографией. Конкретный объём требований определяется при аудите.
Меняются ли требования при обновлении версии продукта после получения доверенного статуса?
Доверенный статус присваивается на три года конкретной версии или версионной линейке продукта в рамках реестровой записи. Незначительные обновления и патчи безопасности, как правило, не требуют переподтверждения. Существенные архитектурные изменения или новая версия с принципиально изменённой функциональностью — предмет отдельного разбора. При каждом значимом обновлении рекомендуем проконсультироваться с нами по вопросу необходимости переподтверждения.
Требования одинаковы для малого бизнеса и крупной корпорации?
Да, требования единые вне зависимости от размера компании. Постановление № 1937 не предусматривает упрощённых процедур для малого или среднего бизнеса. Для небольших компаний это означает, что относительная нагрузка выше — как по времени, так и по бюджету. Именно для таких компаний внешнее сопровождение особенно оправдано: оно позволяет команде оставаться сосредоточенной на разработке, пока регуляторную часть ведут специалисты.
Требования понятны — нужна оценка готовности вашего продукта
Знать перечень требований и понять, насколько ваш конкретный продукт им соответствует — разные задачи. Реестр Гарант проводит предварительный аудит, который даёт честную картину: что уже соответствует, что нужно исправить и сколько времени это займёт. С 2015 года мы провели аудиты сотен программных продуктов и видели все типичные ситуации.
5 ключевых требований к доверенному ПО 2+ доверенных ОС для подтверждения совместимости 3 года срок действия доверенного статуса от 30 000 ₽ стоимость аудита готовности продукта
Проверить соответствие вашего продукта требованиям доверенного статуса
Расскажите о продукте: категория ПО, текущий статус в реестре, корпоративная структура, платформа. Проведём аудит и скажем, что именно нужно подготовить для успешного прохождения процедуры.
Телефон / WhatsApp / Telegram: +7 920-898-17-18
Email: reestrgarant@mail.ru
Первичная консультация бесплатная в рабочее время.
Оригинальная статья
Полная версия статьи на нашем сайте: https://vnesenie-v-reestr.ru/news/title-trebovaniya-k-doverennomu-po-v-2026-godu-kriterii-i-usloviya-mintsifry-po-postanovleniyu-1937
Мы занимаемся включением в реестр Минпромторга
📞 Телефон: +7 920-898-17-18
✉️ Email: reestrgarant@mail.ru