Доверенное ПО: что проверить перед подачей и когда это обязательно

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

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

Что нужно понять о своём продукте до обращения куда-либо

Прежде чем оценивать готовность продукта к процедуре, стоит ответить на несколько вопросов. Продукт уже включён в реестр российского ПО (базовый реестр по постановлению №1236) или в перечень ПО для собственных нужд — без этого статус доверенного ПО получить нельзя, это обязательное предварительное условие. К какой категории ПО относится продукт и когда для этой категории наступает обязательность по графику постановления №1937: у офисного ПО, серверного ПО и СУБД, прикладного и отраслевого ПО, промышленного ПО разные сроки, растянутые с сентября 2026 по январь 2028 года. Совместим ли продукт как минимум с двумя операционными системами, отвечающими требованиям к доверенным ОС: это отдельное техническое требование, которое может потребовать доработки, а не только оформления документов.

Частая ошибка — воспринимать «готовность к доверенному ПО» как разовую проверку документов, аналогичную обычному включению в реестр российского ПО. На деле требование совместимости с доверенными операционными системами — техническое условие, которое либо выполняется в архитектуре продукта, либо нет, и никакая консультация не заменяет реальную работу по тестированию и, при необходимости, адаптации кода под конкретные ОС.

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

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

Что можно оценить самостоятельно, а что требует специалиста

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

Где на практике теряют время при подготовке

Поскольку механизм доверенного ПО новый, типовая практика ошибок по нему ещё не сложилась так же чётко, как для давно действующего реестра российского ПО. Но по аналогии с базовым реестром и общей логикой постановления №1937 можно выделить закономерные точки риска. Первая: продукт подают на статус доверенного ПО раньше, чем у его категории вообще наступила обязательность, — это не ошибка в документах, а просто преждевременное обращение, которое не решает реальную бизнес-задачу компании (участие в конкретной закупке с требованием доверенного статуса). Вторая: компания узнаёт о требовании совместимости с двумя доверенными операционными системами уже после того, как архитектура продукта спроектирована под одну ОС, и адаптация требует значительно больше времени, чем ожидалось. Третья: структура владения компанией-правообладателем не проверена заранее, и вопрос об иностранном контроле всплывает уже на этапе рассмотрения, а не на этапе подготовки.

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

Источники

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