Причины исключения из реестра ПО: как не потерять статус

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

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

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

Причина 1. Недостоверные сведения и неактуальная запись

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

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

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

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

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

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

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

Причина 3. Новые требования 2026 года по доверенным ОС и ПАК

Третья зона риска появилась из-за новых правил 2026 года. Постановление №1937 усилило требования к реестру российского ПО и ввело новый технологический контур, связанный с доверенным ПО, доверенными ОС и ПАК. Требование совместимости с доверенными ОС вводится не для всех продуктов одновременно, а поэтапно по классам ПО.

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

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

Какие признаки говорят о риске исключения

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

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

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

Что происходит перед исключением

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

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

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

Чем опасно исключение для бизнеса

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

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

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

Как не вылететь из реестра

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

1. Назначьте владельца реестровой записи по каждому продукту.
2. Сверьте карточку ПО с сайтом, документацией, договорами, тарифами и фактической функциональностью.
3. Проверьте правообладателя, цепочку прав, структуру владения и отсутствие критичной иностранной зависимости.
4. Настройте учет выручки по каждому реестровому продукту отдельно.
5. Проверьте выплаты иностранным лицам и связанным структурам по конкретному ПО.
6. Готовьте ежегодное уведомление по подпунктам «н» и «у» заранее, а не в последние дни перед 1 июня.
7. Определите класс ПО и дату применения требований по доверенным ОС.
8. Разберите ПАК-сценарий, если продукт используется в составе программно-аппаратного комплекса.
9. Храните реестровую папку с актуальными документами, расчетами, пояснениями и прошлой перепиской.

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

Что делать, если риск уже обнаружен

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

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

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

Вывод

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

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