Совместимость российского ПО с операционными системами: как подготовить продукт к требованиям реестра

Что делать разработчику, чтобы не потерять запись в реестре из-за требований к совместимости

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

В чём проблема и кому это полезно

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

Материал будет полезен четырём группам читателей:

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

Что изменилось и почему это не разовая проверка

28 ноября 2025 года Правительство РФ приняло пакет постановлений, поправляющих правила ведения реестра отечественного ПО, — нововведения вступили в силу 1 марта 2026 года [1]. Ключевое системное изменение — обязанность обеспечить совместимость ПО с двумя доверенными операционными системами [1]. Под совместимостью понимается возможность выполнения программным обеспечением своих функций под управлением операционной системы общего назначения при совместном использовании с техническими средствами без нарушения их корректного функционирования [2].

ПО может быть совместимо всего с одной доверенной ОС только в двух случаях: если правообладатель ПО и правообладатель ОС входят в одну группу лиц, либо если ПО используется исключительно в составе программно-аппаратного комплекса (ПАК), сведения о котором также включены в реестр [1]. При этом заявитель обязан включить сведения о таком ПАК в реестр не позднее 6 месяцев с момента включения сведений о самом ПО — иначе ПО будет исключено из реестра [2].

Отдельно уполномоченному органу поручено в шестимесячный срок утвердить план проверок уже включённого в реестр ПО на соответствие новому критерию совместимости [3]. Это значит, что даже давно внесённые в реестр продукты не защищены от повторной проверки — совместимость нужно поддерживать постоянно, а не подтвердить один раз при первичной подаче. Масштаб реестра при этом уже значительный: на день публикации одного из постановлений в нём числилось более 28,9 тысячи программных продуктов от 10,8 тысячи правообладателей [4] — то есть новое требование затронет заметную часть отрасли.

Поэтапное введение по классам ПО: не путать сроки

Ошибка, которую легко допустить, — применить к своему продукту дату другого класса ПО. Обязательное подтверждение совместимости с двумя ОС вводится поэтапно:

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

Эта же разбивка по датам подтверждается независимым источником [5], что снижает риск ошибки, но не отменяет необходимости сверки с действующей редакцией правил перед принятием решения — в публикациях переходного периода (осень 2025 — начало 2026 года) встречались более ранние проектные даты, которые впоследствии были скорректированы.

Практический вывод: прежде чем что-либо планировать, нужно точно определить класс продукта по классификатору реестра — а не по бытовому пониманию категории. Классификатор периодически меняется: часть разделов из него убирали (например, отдельный раздел «Операционные системы»), другие добавляли — «Офисные приложения», «Средства анализа данных» [6], а позднее вводился целый новый раздел «Отраслевое прикладное программное обеспечение» с двумя десятками новых классов [7], включая, например, класс «Системы роботизации процессов (RPA)» [8]. Если продукт формально относится сразу к нескольким классам (скажем, содержит и офисный модуль, и серверный компонент), применимый срок нужно определять для каждой функциональной части отдельно, а не переносить самый поздний или самый ранний срок на весь продукт целиком.

Что такое доверенная ОС и доверенное ПО

Появилась новая сущность — «доверенное ПО»: программное обеспечение, сведения о котором включены в специальный перечень, ведущийся Минцифры в электронной форме через ФГИС «Реестры программ для ЭВМ и БД» [9]. Перечень доверенного ПО — не отдельный реестр, а дополнительный список внутри реестра отечественного ПО [15].

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

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

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

Как подтверждается совместимость: документы и тестирование

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

Решение о включении, отказе или дальнейшей судьбе записи принимает экспертный совет, и оформляется оно протоколом заседания [13]. Одно из оснований для последующего исключения ПО из реестра — экспертное заключение о выявленном несоответствии установленным требованиям, утверждённое в порядке, определённом положением об экспертном совете [12]. То есть отрицательный итог проверки совместимости — это не предупреждение, а прямое основание для исключения записи.

Для программно-аппаратных комплексов (ПАК) действует похожая, но отдельная логика: совместимость ПО и технических средств в составе ПАК подтверждается протоколом совместных испытаний, актом или иным документом производителя, и без этого документа экспертный совет вернёт заявление как неполное [14]. Типичные причины отказа по ПАК включают, среди прочего, некорректно выбранный класс и отсутствие документа о функциональной совместимости ПО и технических средств [14].

Практические этапы подготовки продукта

Шаг 1. Определить класс ПО и применимый этап требований

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

Шаг 2. Построить матрицу «версия продукта → ОС → архитектура → СУБД → дополнительные компоненты»

Матрица — рабочий инструмент, а не формальность для отчёта. Для каждой поддерживаемой связки фиксируется:

• точная версия продукта (не «текущая», а номер релиза, дата сборки, хэш коммита);
• название и версия ОС из актуального перечня доверенных на момент испытания;
• аппаратная архитектура (x86-64, ARM и т. д.), включая совместимость с отечественными процессорами, если это применимо к классу ПО;
• версия и производитель СУБД, если продукт с ней работает;
• дополнительные компоненты — среда выполнения, драйверы, специфичные библиотеки, брокеры сообщений, серверы приложений.

Матрица должна расти вместе с продуктом: при выпуске новой мажорной версии старые строки не удаляются, а помечаются как неактуальные — так проще объяснить проверяющему, какая версия к какому периоду относится.

Шаг 3. Определить перечень проверяемых операций

Для каждой ячейки матрицы важно проверять не факт запуска, а полный жизненный цикл использования продукта в целевом окружении:

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

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

Шаг 4. Учесть ограничения сторонних библиотек, драйверов и серверных компонентов

Совместимость самого продукта не гарантирует совместимость его окружения. Нужно отдельно проверять:

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

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

Шаг 5. Зафиксировать воспроизводимый протокол испытаний

Протокол должен позволять постороннему специалисту повторить проверку и получить тот же результат. Практический минимум:

• точное описание тестового стенда (образ ОС, конфигурация оборудования или виртуальной машины, версии всех значимых компонентов);
• последовательность действий по каждой проверяемой операции из шага 3;
• ожидаемый и фактический результат, включая скриншоты или логи там, где это уместно;
• дата проведения испытания и указание, что тестировалась именно выпущенная (релизная), а не экспериментальная или тестовая (nightly/beta) сборка.

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

Шаг 6. Встроить процесс в релизный цикл и документацию

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

Практический результат

После прохождения описанных шагов у компании должно быть два связанных результата:

1. План испытаний совместимости — зафиксированный перечень версий продукта, ОС, архитектур, СУБД и компонентов, которые нужно проверить, с перечнем операций для каждой связки и датами, к которым проверка обязательна по классу ПО.
2. Доказательная папка для актуализации сведений о продукте — комплект документов и протоколов (лицензионные договоры, протоколы испытаний, сертификаты совместимости, акты приёмки, воспроизводимые протоколы собственных испытаний), которые можно приложить к заявлению об актуализации реестровой записи или предъявить по запросу при проверке.

Ограничения, ошибки и риски

• Перенос сроков одного класса на другой. Самая частая логическая ошибка — считать, что раз «похожий» класс ПО получил определённый срок, то и ваш продукт под него подпадает. Классификатор реестра не всегда совпадает с бытовым пониманием категории продукта, и относить продукт к классу нужно по официальному классификатору.
• Устаревшие даты в открытых источниках. Публикации переходного периода могут содержать даты из проектной, а не финальной редакции постановления. Перед планированием стоит свериться с действующей редакцией правил реестра.
• Тестирование не той сборки. Прогон испытаний на dev- или staging-версии вместо реально распространяемого релиза создаёт разрыв между документами и фактическим состоянием продукта.
• Игнорирование зависимости от сторонних компонентов. Продукт может формально запускаться на целевой ОС, но одна из интеграций, драйверов или серверных компонентов не будет работать в продуктивном сценарии — это выявляется только при проверке полного набора операций, а не факта запуска.
• Расчёт на бессрочность статуса. Ни включение в реестр, ни присвоение статуса доверенного ПО не гарантированы на неопределённый срок — предусмотрены плановые проверки и обязанность подтверждать сведения повторно. Одна успешно пройденная внутренняя проверка не заменяет соответствие требованиям на момент возможной внешней проверки.
• Неполный комплект для ПАК. Если продукт распространяется в составе программно-аппаратного комплекса, отсутствие отдельного документа о совместимости ПО и технических средств — частая причина возврата заявления как неполного.

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

Когда достаточно своими силами, а когда нужна помощь

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

Вывод

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

Источники

[1] pgplaw.ru — Правила ведения реестра российского ПО: что изменится? — https://www.pgplaw.ru/analytics-and-brochures/alerts/pravila-vedeniya-reestra-rossiyskogo-po/

[2] government.ru — текст поправок в Правила реестра (определение совместимости, п. 5 Правил) — https://government.ru/docs/all/162383/

[3] ru-bezh.ru — Правительство ужесточает критерии включения ПО в реестр — https://ru-bezh.ru/gossektor/news/25/12/10/pravitelstvo-uzhestochaet-kriterii-vklyucheniya-po-v-reestr-potr

[4] d-russia.ru — Правило двух ОС – постановление ужесточает требования к реестру отечественного ПО — https://d-russia.ru/pravilo-dvuh-os-postanovlenie-uzhestochaet-trebovaniya-k-reestru-otechestvennogo-po.html

[5] vnesenie-v-reestr.ru — Доверенное ПО: статус по ПП №1937 под ключ — https://vnesenie-v-reestr.ru/doverennoe-po

[6] tadviser.ru — Классификатор российского программного обеспечения — https://www.tadviser.ru/index.php/Статья:Классификатор_российского_программного_обеспечения

[7] pro-tim.ru — Новые классы в Едином реестре российских программ — https://pro-tim.ru/news/20-klassov-v-klassifikator-ros-po/

[8] pro-ability.ru — Перечень классов ПО в реестре российского программного обеспечения расширен — https://www.pro-ability.ru/tpost/vxmoceki51-perechen-klassov-po-v-reestre-rossiiskog

[9] antishtraf.ru — Доверенное ПО и доверенные ОС: что нужно знать разработчику — https://antishtraf.ru/blog/doverennoe-po/

[10] vnesenie-v-reestr.ru — Доверенные операционные системы: список и требования совместимости — https://vnesenie-v-reestr.ru/news/doverennye-operatsionnye-sistemy-spisok-trebovaniya-sovmestimosti-i-kak-ih-podtverdit

[11] habr.com — Реестр российского ПО: изменения, которые нельзя пропустить в 2025-2026 — https://habr.com/ru/articles/891876/

[12] government.ru — Постановление Правительства РФ от 16.11.2015 № 1236 (основания исключения из реестра) — http://government.ru/docs/all/104296/?page=5

[13] inilaw.com — Как внести ПО и ПАК в реестр отечественного ПО — https://inilaw.com/blog/programmnoe-obespechenie-i-evm/kak-vnesty-po-i-pak-v-reestr-otechestvennogo-po/

[14] intellectprava.ru — Регистрация ПАК в реестре Минцифры — https://intellectprava.ru/pak

[15] zarlaw.ru — Реестр доверенного ПО и ПО для собственных нужд 2026 — https://zarlaw.ru/articles/reestr-doverennogo-po-i-reestr-po-dlya-sobstvennykh-nuzhd-organizatsiy-chto-eto-takoe-kak-tuda-popas/