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

С 2026 года для реестра российского ПО появляется новый практический блок: совместимость программного продукта с доверенными операционными системами. Это не просто техническая рекомендация и не маркетинговая отметка. Для ряда классов ПО совместимость становится частью требований к реестровой записи.

Главная ошибка - считать, что правило уже одинаково обязательно для всех продуктов. На самом деле Постановление №1937 ввело поэтапный график применения по классам программного обеспечения. Поэтому правообладателю важно сначала определить класс продукта, а уже потом оценивать сроки, риски и объем работ. В исходной статье эта мысль выделена как основная: без правильной классификации оценка будет слишком общей.

Что означает совместимость с доверенной ОС

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

Для бизнеса это означает, что недостаточно просто написать в документации «поддерживает российские ОС». Нужно подтвердить, что заявленная функциональность действительно работает в выбранных окружениях. Если продукт сложный, имеет клиентские приложения, серверные компоненты, агенты, консоли администрирования или модули интеграции, проверять нужно не только запуск, но и нормальное выполнение основных сценариев.

Почему правило вводится поэтапно

Норма не применяется ко всем классам ПО в один день. Законодатель разделил продукты на группы, чтобы разные сегменты рынка получили разный срок подготовки. Раньше всего требование затрагивает офисное ПО, затем инфраструктурные и системные решения, потом прикладные и ИБ-продукты, а позднее - промышленное ПО и средства управления процессами организации.

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

График применения по классам ПО

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

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

Если продукт находится на стыке классов, не стоит выбирать дату «по ощущениям». Лучше отдельно проверить классификацию, потому что от нее зависит не только срок, но и стратегия подготовки. Для пограничных продуктов может понадобиться правовая квалификация и сопоставление функциональности с классификатором.

Когда допускается одна доверенная ОС

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

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

Почему SaaS и веб-продукты тоже нужно проверять

Иногда компании считают, что веб-продукт или SaaS автоматически не попадает под требование, потому что пользователь работает через браузер. Такой подход слишком упрощает вопрос. Нужно смотреть, где фактически выполняется функциональность: серверная часть, desktop-клиент, агент, локальный модуль, консоль администрирования, интеграционный компонент или иной исполняемый элемент.

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

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

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

1. Определить класс ПО по классификатору и дату начала применения требования.
2. Выбрать две доверенные ОС, которые подходят под архитектуру продукта и целевой рынок.
3. Провести технический аудит зависимостей, библиотек, драйверов, контейнеров, сервисов и клиентских компонентов.
4. Подготовить тестовые стенды и матрицу поддерживаемых версий продукта и ОС.
5. Проверить основные сценарии работы, интеграции, обновления, установку, администрирование и восстановление после сбоев.
6. Собрать доказательства совместимости: протоколы тестирования, описание окружения, скриншоты, логи, инструкции и технические заключения.
7. Проверить, нужно ли обновлять сведения в реестровой записи или готовить отдельную стратегию для ПАК.

Такой комплект нужен не только для подачи в реестр. Он помогает отделу продаж и тендерной команде уверенно отвечать на вопросы заказчиков. Если совместимость подтверждена документально, запись в реестре становится сильнее для закупок и переговоров.

Чем опасно откладывание

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

Если продукт уже продается крупным заказчикам, проблема может проявиться в самый неудобный момент: при закупке, обновлении реестровой записи или запросе подтверждений. Тогда совместимость с доверенными ОС превращается из плановой технической задачи в срочный коммерческий риск.

Как выстроить процесс внутри компании

Работу лучше начинать с совместной встречи юристов, продуктовой команды, архитекторов, DevOps и тендерного блока. Юристы отвечают за правила, сроки, класс ПО и реестровую стратегию. Техническая команда определяет реальную архитектуру и зависимые компоненты. Продуктовая команда фиксирует поддерживаемые сценарии. Тендерный блок объясняет, какие подтверждения спрашивают заказчики.

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

Вывод

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

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