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

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

Что регулирует Постановление №1236

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

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

Почему компания может получить отказ

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

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

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

Права и контроль - центральный блок проверки

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

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

Экономика продукта и правило 30%

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

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

Техническая независимость и инфраструктура

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

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

Документы должны быть связаны между собой

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

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

Как проходит рассмотрение

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

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

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

Что изменилось в 2025-2026 годах

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

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

Как подготовиться к подаче

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

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

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

Почему сопровождение важно после включения

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

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

Вывод

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

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