Реестр отечественного ПО — это перечень программных продуктов, у которых подтверждено российское происхождение: правообладатель — российское лицо, права на продукт принадлежат ему, продукт правомерно распространяется в России. Всё. Реестр не проверяет, работает ли программа, защищена ли она и где физически лежат ваши данные. Он отвечает на вопрос о происхождении, и путать его с вопросом о качестве или о безопасности — самая частая ошибка в закупке.
Практическое значение у записи в реестре ровно два. Первое — закупка: для части заказчиков продукт без записи купить нельзя или можно только через процедуру обоснования. Второе — налоговый режим передачи прав на программу, где статус продукта одно из условий; эту часть мы разбираем отдельно в материале о налоговых льготах при покупке отечественного ПО, и она касается не всех покупателей. Если ни то, ни другое к вам не относится, реестр в вашем выборе системы не участвует, и ориентироваться на него при сравнении платформ не надо.
Дальше — чем реестр не является; три разных ответа для трёх типов покупателей; как проверить продукт за пятнадцать минут и какие три ловушки при этом срабатывают; отдельный случай с российским облаком без записи в реестре; что происходит с заказной разработкой; как записать требование в техническом задании, чтобы его можно было принять на приёмке; и расчёт того, во что обходится обнаружение несоответствия задним числом.
Чем реестр не является
Перечень программ и баз данных, у которых подтверждено российское происхождение и соблюдены требования к правообладателю. Ведётся Минцифры, каждая позиция имеет номер записи и дату включения. Проверяется по продукту, а не по компании: у одного вендора часть продуктов может быть в реестре, а часть — нет.
Три вещи, которые запись в реестре не означает, стоит проговорить вслух, потому что именно на них строятся неверные решения. Реестр не подтверждает информационную безопасность — за это отвечают сертификация и организационные меры, о которых мы пишем на странице безопасности. Реестр не подтверждает работоспособность и зрелость продукта: включение в перечень — административная процедура, а не испытание. И реестр не отвечает за то, где хранятся ваши данные: локализация баз персональных данных в России — требование 152-ФЗ, оно предъявляется к вам как к оператору и выполняется независимо от происхождения программы.
Отсюда и обратное утверждение, которое звучит непривычно: отсутствие продукта в реестре само по себе не говорит о нём ничего плохого. В реестре нет большинства библиотек, драйверов, утилит и почти всей инфраструктурной обвязки — не потому, что они иностранные, а потому, что их правообладатели никогда туда не подавались.
Три покупателя — три разных ответа
Правильный первый вопрос — не «есть ли продукт в реестре», а «кто вы как покупатель». От ответа зависит, будет ли реестр вообще участвовать в вашем выборе.
| Кто вы | Что означает реестр | Что будет, если продукта в реестре нет |
|---|---|---|
| Государственный или муниципальный заказчик | Жёсткое ограничение закупки: при наличии в реестре продуктов нужного класса иностранное ПО не закупается | Закупка либо невозможна, либо требует обоснования по установленной процедуре. Обоснование готовится заранее и проверяется контролем, а не подписывается задним числом |
| Компания с госучастием, субъект КИИ, подрядчик по госконтракту | Правило собственного положения о закупке или условие контракта. Формулировки у всех разные, и читать надо своё | Зависит от вашего же документа: где-то приоритет и ценовая преференция, где-то прямой запрет, где-то требование переходит от заказчика к вам вместе с контрактом |
| Обычное ООО без госзаказчиков и госучастия | Один из факторов налогового режима при передаче прав. На сам выбор системы, как правило, не влияет | Ничего. Систему выбирают по функциональности, стоимости владения и наличию людей, которые её поддержат |
Третья строка — самая массовая и самая недооценённая. Компания без государственных контрактов регулярно сужает себе шорт-лист до реестровых продуктов «на всякий случай», теряет функциональность и переплачивает, хотя ни одного основания для такого ограничения у неё нет. Кому обязанность переходить на отечественное ПО адресована прямо, а кому она достаётся через контрагента, мы разбирали отдельным материалом — там же тест из шести вопросов на десять минут.
Сравнение в три колонки. Первая, «Государственный заказчик»: подпись «запрет при наличии аналогов», под ней плашка «нужна процедура обоснования». Вторая, «Госучастие, КИИ, подряд по госконтракту»: подпись «правило своего положения о закупке», под ней плашка «читать свой документ, а не общие обзоры». Третья, «Обычное ООО»: подпись «на выбор системы не влияет», под ней плашка «остаётся только налоговая сторона». Под всеми тремя общая линия с надписью «152-ФЗ о локализации данных действует одинаково во всех трёх колонках и с реестром не связан». Чертёжный стиль, подписи по-русски.
Проверка за пятнадцать минут и три ловушки
Проверка карточки продукта — короткая процедура, которую надо делать своими руками, а не принимать на слово от поставщика. Формулировка «мы в реестре» на сайте вендора не документ; документ — номер записи, дата включения и наименование продукта, совпадающее с тем, что написано в вашей спецификации.
- 1Найдите карточку по точному наименованию продукта
Ищите не по названию компании, а по названию продукта из коммерческого предложения. Запишите номер записи, дату включения и полное наименование правообладателя. Пятнадцать минут — это вместе с чтением карточки, а не только с поиском.
- 2Ловушка первая: правообладатель в реестре, а продукт — нет
Реестр ведётся по продуктам. У вендора с десятью продуктами в перечне может быть три, и это нормально. Фраза «наш вендор в реестре» не означает ничего до тех пор, пока вы не увидели карточку именно того продукта, который покупаете.
- 3Ловушка вторая: модуль или редакция — отдельный продукт
Платформа в реестре, а нужный вам отраслевой модуль поставляется как самостоятельный продукт со своей записью или без неё. То же самое с редакциями: базовая версия и корпоративная нередко значатся раздельно. Сверяйте наименование посимвольно с тем, что в спецификации.
- 4Ловушка третья: запись меняется и исключается
Состав реестра не статичен: записи добавляют, изменяют и исключают. Значение имеет статус на дату заключения договора, поэтому проверку надо не только сделать, но и зафиксировать — датой и фамилией проверявшего. Через год восстановить, что было в реестре на день сделки, будет нечем.
Подписка на облачный сервис по своей природе ближе к услуге, чем к передаче прав на экземпляр программы, и это меняет и логику закупки, и вопрос о том, что вообще проверять в реестре. Если вы покупаете сервис, а не лицензию, спросите поставщика прямо: включён ли в реестр сам сервис, включён ли продукт, на котором он работает, и чем это подтверждается. Ответ «данные хранятся в России» на этот вопрос не отвечает.
Схема-маршрут сверху вниз из четырёх блоков со стрелками: «Взять наименование продукта из коммерческого предложения» → «Найти карточку в реестре» → «Сверить наименование посимвольно со спецификацией» → «Записать номер записи, дату включения и дату проверки». Справа от маршрута три отводящие стрелки-ловушки с подписями: «правообладатель в реестре, а продукт — нет», «модуль или редакция — отдельная позиция», «запись изменена или исключена». Под нижним блоком плашка «15 минут, около 300 ₽ рабочего времени». Чертёжный стиль, подписи по-русски.
Российское облако — ещё не запись в реестре
Самый показательный пограничный случай — Yandex DataLens. Данные лежат в российском облаке, с точки зрения локализации вопросов нет, компания российская, но самой записи в реестре отечественного ПО у сервиса, по состоянию на сентябрь 2026 года, нет. Для коммерческого ООО это обычно ничего не меняет: покупка идёт как обычная подписка на облачный сервис. Для государственного заказчика или компании, у которой требование по реестру прописано в положении о закупке либо в контракте, это блокер, который не обходится ни письмом вендора, ни фактом хранения данных в России.
Общий урок здесь важнее конкретного продукта: российское юридическое лицо, российское облако, российская поддержка и запись в реестре — четыре разные вещи, и наличие первых трёх ничего не говорит о четвёртой. Проверять надо именно четвёртую, если она вам нужна. Как это ограничение сужает шорт-лист на конкретном примере и во что обходится по стоимости владения, мы считали в разборе выбора российской BI-системы.
Заказная разработка в реестр не попадает
Вопрос звучит регулярно: «Мы заказываем систему под себя — попадёт ли она в реестр». Нет, и по устройству процедуры, а не по чьему-то нежеланию. Заявителем в реестр выступает правообладатель продукта, который распространяется на рынке; система, написанная под один заказ и никому больше не продаваемая, под эту логику не подходит. Если исключительные права по договору переходят к вам, правообладателем становитесь вы — и тогда речь идёт уже о том, чтобы вы сами вывели продукт на рынок, а это отдельный бизнес, а не побочный эффект внедрения.
Что это меняет на практике. Для обычной компании — почти ничего: внутренняя система не закупается по правилам, к которым реестр применяется. Для заказчика с требованием реестра — многое: заказная разработка и требование покупать из перечня плохо совмещаются, и решать это надо на этапе выбора подхода, а не на приёмке. И для всех — смещается фокус вопроса: вместо «будет ли система в реестре» правильно спрашивать «кому принадлежит результат работ». Эта развилка определяет, сможете ли вы через два года передать систему другому подрядчику, и она же задаёт порядок постановки на учёт.
Как записать требование в техническом задании
Требование, которое нельзя проверить на приёмке, — это не требование, а пожелание. Ниже четыре формулировки, которые встречаются чаще всего, и то, во что их стоит переписать.
| Как обычно пишут | Что с этим не так | Как записать проверяемо |
|---|---|---|
| «Система должна быть отечественной» | Слово «отечественная» не имеет проверяемого содержания: у продукта может быть российский правообладатель и не быть записи в реестре | «Продукт должен быть включён в единый реестр российского ПО на дату заключения договора; подрядчик указывает номер записи и наименование продукта в спецификации» |
| «Данные должны храниться на территории России» | Это требование о локализации из 152-ФЗ. Оно про место хранения, а не про происхождение продукта, и ему соответствуют системы, которых в реестре нет | Записать двумя отдельными пунктами: локализация — своим, реестр — своим. Смешанный пункт нельзя ни выполнить однозначно, ни принять |
| «Все компоненты решения должны входить в реестр» | Буквально невыполнимо: в любом решении есть библиотеки, драйверы и утилиты, которых в реестре нет и не будет | «Требование распространяется на прикладные продукты, перечисленные в приложении, с указанием класса ПО по классификатору» |
| «Подрядчик гарантирует соответствие требованиям импортозамещения» | Гарантия без критерия непроверяема: на приёмке неясно, что именно принимать и по какому документу | Указать документ-основание, класс ПО, перечень продуктов и момент, на который проверяется соответствие. Приёмка — по номерам записей |
Сравнение в две колонки по четыре строки. Левая колонка «Пожелание, которое нельзя проверить»: «система должна быть отечественной», «данные хранятся в России», «все компоненты из реестра», «подрядчик гарантирует импортозамещение». Правая колонка «Требование, которое принимается по документу»: «номер записи в реестре на дату договора», «локализация и реестр — два отдельных пункта», «перечень прикладных продуктов с классом ПО», «документ-основание и момент проверки». Между колонками вертикальная стрелка с подписью «переписывается за один вечер». Чертёжный стиль, подписи по-русски.
Цена позднего обнаружения
Теперь арифметика, ради которой всё это стоит делать заранее. Модельный случай: компания с госучастием внедряет систему учёта, требование реестра прописано в её собственном положении о закупке, но на этапе выбора платформы никто карточку не открывал. Несоответствие всплывает на приёмке, через пять месяцев после старта.
Соотношение получается почти неприличным: 700 000 ₽ против 300 ₽, то есть в две с лишним тысячи раз. Именно поэтому проверка реестра стоит в нашем чек-листе не на этапе договора, а на этапе, когда шорт-лист платформ ещё состоит из четырёх названий. Порядок работы над проектом мы описываем отдельно — проверка ограничений всегда идёт до сметы, а не после.
Диаграмма из четырёх столбиков с подписанными значениями в рублях: «Невозвратные лицензии — 180 000 ₽», «Повторная настройка — 320 000 ₽», «Перенос данных и прав — 145 000 ₽», «Переобучение и запуск — 55 000 ₽». Столбики охвачены общей скобкой с подписью «700 000 ₽ — 64 % бюджета 1 100 000 ₽». Справа отдельная тонкая полоска высотой почти в ноль с подписью «проверка карточки в реестре — 300 ₽, 15 минут». Под диаграммой подпись «плюс 7–9 недель срока». Ось в рублях, единицы подписаны. Чертёжный стиль, подписи по-русски.
Что проверить на дату чтения
Состав реестра и правила включения меняются, поэтому статья описывает механику, а не список продуктов. Маршрут проверки перед закупкой выглядит так и не устаревает.
- 1Откройте карточку конкретного продукта в реестре, а не страницу вендора. Запишите номер записи, дату включения и точное наименование.
- 2Сверьте наименование из карточки с наименованием в коммерческом предложении и в проекте спецификации. Расхождение в одном слове — повод остановиться и переспросить.
- 3Прочитайте своё положение о закупке или условие контракта и найдите точную формулировку требования. Общие обзоры здесь бесполезны: формулировки у всех разные.
- 4Зафиксируйте дату и автора проверки в файле решения по проекту. Статус проверяется на дату сделки, и восстановить его задним числом будет нечем.
- 5Отдельно проверьте требование о локализации данных: оно предъявляется к вам как к оператору персональных данных и выполняется независимо от того, что показала карточка.
Когда реестр вам ни на что не влияет
Честный раздел, который в статьях о реестре почти не встречается. Для большой части компаний правильный вывод — перестать смотреть на реестр и выбирать систему по существу.
- У вас нет государственных и муниципальных заказчиков, нет государственного участия в капитале, вы не субъект критической информационной инфраструктуры и не подрядчик по госконтракту, в котором требование передано вам. Тогда реестр в вашем выборе не участвует вовсе.
- Вы покупаете не лицензию, а работы: настройку, интеграцию, доработку. Реестр относится к продуктам, а не к услугам, и три четверти бюджета типового проекта автоматизации он не затрагивает в принципе.
- Вы заказываете систему под себя. Она в реестре не появится по устройству процедуры, и вместо этого вопроса надо решать вопрос о правах на результат работ.
- Продукта нужного класса в реестре просто нет, а задача есть. Такое встречается в отраслевом и инженерном ПО чаще, чем в офисном; выбор в этом случае делается по функциональности, а требование закрывается обоснованием, если оно к вам применимо.
Если вы работаете с госзаказчиком или у вас в положении о закупке требование прописано, проверка реестра перестаёт быть формальностью и становится первым фильтром шорт-листа — до сравнения функциональности, до демонстраций и до сметы. Пятнадцать минут в начале против 700 000 ₽ и девяти недель в конце — это вся суть вопроса, и никакой более сложной логики в нём нет.
Реестр отвечает на вопрос о происхождении продукта. На вопрос, решит ли эта система вашу задачу, он не отвечает и отвечать не должен.
