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