+7 (901) 499-39-49

Реестр российского ПО 2026: что меняется для IT-компаний

Реестр российского ПО

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

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

Изменения 2026 года особенно важны для продуктовых компаний, которые участвуют в госзакупках, работают с крупными заказчиками, продают ПО через SaaS-модель, развивают программно-аппаратные комплексы или входят в группы с государственным участием. Формально продукт может уже быть в реестре, но этого может оказаться недостаточно, если запись не содержит нужных сведений или компания не готова подтвердить новые требования.

Что меняется по сути

Главное изменение - реестровая запись становится более содержательной. Раньше для бизнеса ключевым вопросом часто был сам факт включения продукта в реестр. Теперь важнее становится то, какие сведения есть внутри записи и насколько они подтверждены документами.

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

Главные изменения для IT-компаний

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

  • Появляется требование по совместимости ПО с доверенными российскими ОС. Для многих продуктов это будет не только юридический, но и технический проект.
  • В реестровую запись добавляются сведения о совместимости с доверенными ОС и соответствии требованиям к доверенному ПО.
  • Для заявителей увеличивается объем подтверждающих документов. Недостаточно описать продукт, нужно подтвердить ключевые сведения.
  • Уточняется подход к структуре контроля правообладателя. Значение имеет возможность прямо или косвенно распоряжаться более чем 50% голосов.
  • Для отдельных компаний с государственным участием появляется ограничение по внутригрупповой выручке.
  • Ежегодное уведомление до 1 июня становится частью обязательного сопровождения записи.

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

Доверенные ОС и доверенное ПО

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

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

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

Почему меняется значение реестровой записи

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

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

Структура контроля и корпоративные риски

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

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

Для компаний с ограниченным доступом к сведениям ЕГРЮЛ предусмотрена возможность подтверждения через аудиторскую организацию. Такой сценарий тоже лучше планировать заранее, потому что аудиторское подтверждение нельзя подготовить за один день перед подачей или закупкой.

Финансовые показатели и внутригрупповая выручка

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

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

Ежегодное уведомление до 1 июня

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

На практике это означает, что реестр должен появиться в календаре компании как регулярная обязанность. К 1 июня нужно не вспоминать о записи, а уже иметь готовые данные от бухгалтерии, юристов и продуктовой команды. Особенно если у компании несколько продуктов, разные модели лицензирования, SaaS, открытая лицензия, ПАК или выплаты иностранным лицам.

Кого изменения затронут сильнее всего

Формально изменения важны для всех правообладателей ПО в реестре и для новых заявителей. Но на практике сильнее всего они затронут компании, для которых реестр используется в продажах, закупках и подтверждении статуса продукта.

  • Правообладатели ПО, которое уже включено в реестр и требует ежегодного сопровождения.
  • Новые заявители, которым придется готовить более доказательную заявку.
  • Вендоры, участвующие в госзакупках и закупках по 223-ФЗ.
  • Производители и поставщики ПАК, где нужно правильно связать ПО, ОС и аппаратную часть.
  • Компании с государственным участием и группы лиц, где нужно проверять внутригрупповую выручку.
  • Компании со сложной структурой владения, ограниченным раскрытием данных или иностранными элементами.

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

Что проверить уже сейчас

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

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

Проверить совместимость с доверенными ОС и документы, которые это подтверждают.

Разобрать ПАК-сценарий, если продукт поставляется вместе с аппаратной частью.

Проверить структуру владения и контроля правообладателя.

Для компаний с госучастием рассчитать внутригрупповую выручку по продукту.

Сверить сведения о стоимости, порядке определения стоимости или открытой лицензии.

Назначить ответственного за ежегодное обновление сведений до 1 июня.

Проверить, не нужно ли обновить тендерные материалы и аргументы отдела продаж.

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

Почему нельзя ждать дедлайна

Часть изменений требует времени. Совместимость с доверенными ОС нужно не только заявить, но и подтвердить. Экспертная процедура тоже занимает время. Финансовые показатели нужно получить из учета, а при нескольких продуктах или смешанной выручке их еще нужно корректно разделить.

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

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

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

Лучше назначить одного владельца процесса. Он не обязан сам закрывать все вопросы, но должен видеть общую картину: какие продукты есть в реестре, какие требования к ним применяются, кто готовит документы, какие сроки приближаются и где есть риск для продаж.

Вывод

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

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

Важно

В 2026 году наличие продукта в реестре само по себе уже не закрывает все риски. Нужно проверить, какие сведения есть в записи, какие требования применяются к классу ПО и готова ли компания подтвердить их документами.

Услуги к статье
IT-компаниям
Плановое обновление сведений в реестре ПО до 1 июня
IT-компаниям
Включение ПО в реестр Минцифры
IT-компаниям
Внесение изменений в реестр ПО Минцифры
IT-компаниям
Аккредитация IT-компаний

Возврат к списку