Совместимость с доверенными ОС для доверенного ПО: реальные требования

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

Главное: постановление Правительства РФ №1937 от 28.11.2025 требует, чтобы продукт, претендующий на статус доверенного ПО, был совместим минимум с двумя операционными системами из перечня доверенных ОС, который ведёт Минцифры в ФГИС «Реестр программного обеспечения». По состоянию на начало 2026 года в перечень входят преимущественно отечественные дистрибутивы Linux — Astra Linux, РЕД ОС, ROSA Linux, Alt Linux и другие; актуальный список нужно проверять на момент подготовки, поскольку он может дополняться. Из требования есть два исключения: продукт в составе программно-аппаратного комплекса с технической привязкой к конкретной аппаратной платформе, и случай, когда правообладатель ПО и правообладатель ОС входят в одну группу лиц.

Что реально проверяется при оценке совместимости

Проверка совместимости — не формальный запуск продукта на доверенной ОС, а оценка того, что заявленная функциональность работает корректно в этой среде. Наиболее частые технические причины несовместимости у продуктов, изначально разработанных под Windows: зависимость от платформенно-специфичных компонентов (реестр Windows, COM/ActiveX, библиотеки, которых нет в Linux-среде), проблемы графического интерфейса, не учитывающего особенности Linux-графических систем, несовместимость драйверов и протоколов обмена данными (особенно актуально для промышленного ПО и систем управления оборудованием) и инсталляторы, рассчитанные исключительно на Windows.

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

Когда нужно завершить работы по совместимости

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

Логичная последовательность работ

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

Когда применимы исключения из требования

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

Что стоит учесть при планировании бюджета времени

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

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

Источники

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