В 2026 году реестр российского ПО становится более требовательным к продукту, правообладателю и доказательной базе. Компании нужно проверять не только сам факт включения в реестр, но и совместимость с доверенными ОС, структуру контроля, финансовые показатели и готовность к ежегодному обновлению сведений.
Реестр российского ПО постепенно превращается из инструмента подтверждения происхождения программы в полноценный контур регулярного комплаенса. Для IT-компаний это означает, что после включения продукта в реестр работа не заканчивается. Запись нужно сопровождать, сведения обновлять, документы держать в актуальном состоянии, а технические и финансовые показатели проверять заранее.
Изменения 2026 года особенно важны для продуктовых компаний, которые участвуют в госзакупках, работают с крупными заказчиками, продают ПО через SaaS-модель, развивают программно-аппаратные комплексы или входят в группы с государственным участием. Формально продукт может уже быть в реестре, но этого может оказаться недостаточно, если запись не содержит нужных сведений или компания не готова подтвердить новые требования.
Главное изменение - реестровая запись становится более содержательной. Раньше для бизнеса ключевым вопросом часто был сам факт включения продукта в реестр. Теперь важнее становится то, какие сведения есть внутри записи и насколько они подтверждены документами.
Постановление №1937 меняет подход к оценке российского ПО. В фокусе не только права на продукт и российский правообладатель, но и совместимость с доверенными операционными системами, соответствие требованиям к доверенному ПО, структура контроля, выручка, внутригрупповые продажи и пригодность продукта для закупок. В исходной статье этот переход описан как смена логики: от разового включения к постоянному подтверждению соответствия.
Для первичной оценки компании нужно посмотреть не на один пункт, а на несколько связанных блоков. Если один из них не закрыт, запись в реестре может стать слабее в закупках или при проверке заказчиком.
Эти изменения нельзя закрыть одной правкой в карточке продукта. Нужно синхронизировать юристов, продуктовую команду, технических специалистов, бухгалтерию и коммерческий блок. Иначе компания может подготовить формально правильные документы, но не увидеть риск в архитектуре продукта, модели продаж или структуре владения.
Самый заметный блок изменений связан с доверенными операционными системами. Для включения и сохранения ПО в реестре вводится требование совместимости минимум с двумя ОС, которые соответствуют требованиям к доверенному ПО. В отдельных случаях возможны исключения, например когда правообладатель ПО и правообладатель ОС входят в одну группу лиц или когда программа используется только в составе ПАК.
Для бизнеса это означает, что совместимость нужно планировать заранее. Недостаточно написать, что продукт теоретически может работать на российской ОС. Нужно понимать, с какими ОС он реально совместим, какие тесты проведены, какие документы это подтверждают и когда сведения можно будет внести в реестр.
Особенно внимательно нужно смотреть ПАК-сценарий. Если компания использует исключение и заявляет совместимость только с одной доверенной ОС из-за работы в составе программно-аппаратного комплекса, сам ПАК тоже придется включить в реестр в установленный срок. Иначе появляется риск для уже включенного ПО.
После изменений становится важен не только статус «ПО включено в реестр», но и наполнение записи. Для закупок это критично. Если у одного участника в записи есть сведения о соответствии требованиям к доверенному ПО, а у другого их нет, позиции в закупке могут оказаться разными, даже если оба продукта формально находятся в реестре. Исходная статья отдельно отмечает, что отсутствие нужной отметки может ухудшить закупочную позицию продукта.
Это меняет работу отдела продаж и тендерного блока. Раньше они могли использовать сам факт включения в реестр как универсальный аргумент. Теперь нужно понимать, какие именно сведения есть в записи, подходят ли они под требования закупки и не нужно ли заранее обновить данные.
Еще один важный блок - структура владения и контроля правообладателя. Для российской коммерческой организации значение имеет не только формальный состав участников, но и возможность контролировать решения через более чем 50% голосов. Это особенно важно для компаний со сложной холдинговой структурой, иностранными элементами, несколькими уровнями владения или корпоративными соглашениями.
Если компания давно включила продукт в реестр, это не значит, что старые документы автоматически подходят под новую формулировку. Корпоративная структура могла измениться, появились новые участники, преобразования, опционы или внутригрупповые договоренности. Поэтому правообладателю нужно заново проверить, можно ли уверенно подтвердить российский контроль.
Для компаний с ограниченным доступом к сведениям ЕГРЮЛ предусмотрена возможность подтверждения через аудиторскую организацию. Такой сценарий тоже лучше планировать заранее, потому что аудиторское подтверждение нельзя подготовить за один день перед подачей или закупкой.
Для компаний с государственным участием и связанных с ними групп появляется отдельный финансовый риск: выручка от реализации ПО внутри одной группы лиц не должна превышать установленный порог. Смысл требования - показать, что продукт имеет рыночное использование, а не существует только для внутригруппового оборота.
Даже если это правило не касается всех правообладателей, оно показывает общую тенденцию. Реестр начинает смотреть на коммерческую модель внимательнее. Важны не только права и технические характеристики, но и то, кто покупает продукт, как считается выручка, как она распределяется внутри группы и можно ли подтвердить эти показатели документами.
Для уже включенного ПО сохраняется и усиливается обязанность ежегодно актуализировать сведения. В исходной статье отдельно указано, что не позднее 1 июня нужно уведомлять оператора об изменении отдельных сведений, включая сведения по подпункту «н», с указанием выручки за истекший календарный год.
На практике это означает, что реестр должен появиться в календаре компании как регулярная обязанность. К 1 июня нужно не вспоминать о записи, а уже иметь готовые данные от бухгалтерии, юристов и продуктовой команды. Особенно если у компании несколько продуктов, разные модели лицензирования, SaaS, открытая лицензия, ПАК или выплаты иностранным лицам.
Формально изменения важны для всех правообладателей ПО в реестре и для новых заявителей. Но на практике сильнее всего они затронут компании, для которых реестр используется в продажах, закупках и подтверждении статуса продукта.
Для небольших продуктовых компаний риск тоже есть. Если продукт развивается быстро, а реестровая запись не обновляется, к моменту закупки или проверки заказчиком сведения могут уже не соответствовать реальности.
Проверку лучше начинать не с формы заявления, а с внутренней диагностики продукта. Нужно понять, какие изменения применяются именно к вашему классу ПО, какие сведения уже есть в реестре и каких подтверждений не хватает.
Определить класс ПО и дату, с которой новые требования начинают применяться к продукту.
Проверить совместимость с доверенными ОС и документы, которые это подтверждают.
Разобрать ПАК-сценарий, если продукт поставляется вместе с аппаратной частью.
Проверить структуру владения и контроля правообладателя.
Для компаний с госучастием рассчитать внутригрупповую выручку по продукту.
Сверить сведения о стоимости, порядке определения стоимости или открытой лицензии.
Назначить ответственного за ежегодное обновление сведений до 1 июня.
Проверить, не нужно ли обновить тендерные материалы и аргументы отдела продаж.
Итогом такой проверки должен быть не общий вывод «мы в реестре», а карта конкретных действий. Например: провести тестирование с доверенными ОС, подготовить документы по совместимости, обновить сведения по подпункту «н», подтвердить структуру контроля, пересчитать выручку или подготовить экспертную процедуру.
Часть изменений требует времени. Совместимость с доверенными ОС нужно не только заявить, но и подтвердить. Экспертная процедура тоже занимает время. Финансовые показатели нужно получить из учета, а при нескольких продуктах или смешанной выручке их еще нужно корректно разделить.
Если компания начнет готовиться только перед 1 июня или перед крупной закупкой, она может не успеть закрыть технические и документальные вопросы. Тогда запись будет формально существовать, но коммерчески работать слабее: заказчик увидит неполные сведения, тендерный блок не сможет подтвердить статус, а юристы будут собирать документы в авральном режиме.
Реестр 2026 года требует совместной работы нескольких функций. Юристы проверяют правообладателя, структуру контроля, договоры и реестровые сведения. Продуктовая команда отвечает за функциональность, версии и документацию. Архитекторы и разработчики проверяют совместимость с доверенными ОС и техническую инфраструктуру. Бухгалтерия готовит выручку, выплаты и финансовые показатели. Тендерный блок понимает, какие отметки в реестре нужны для закупок.
Лучше назначить одного владельца процесса. Он не обязан сам закрывать все вопросы, но должен видеть общую картину: какие продукты есть в реестре, какие требования к ним применяются, кто готовит документы, какие сроки приближаются и где есть риск для продаж.
Изменения 2026 года делают реестр российского ПО более строгим и более практичным. Теперь важно не только попасть в реестр, но и поддерживать запись в состоянии, которое выдерживает проверку, закупку и запрос заказчика.
Компании нужно заранее проверить доверенные ОС, отметки о доверенном ПО, структуру контроля, финансовые показатели, внутригрупповую выручку, ПАК-сценарий и ежегодное обновление сведений до 1 июня. Тогда реестр будет работать как коммерческое преимущество, а не как формальная запись, к которой появляются вопросы в самый неудобный момент.
В 2026 году наличие продукта в реестре само по себе уже не закрывает все риски. Нужно проверить, какие сведения есть в записи, какие требования применяются к классу ПО и готова ли компания подтвердить их документами.