Реестр отечественного ПО — это перечень программ и баз данных, у которых подтверждено российское происхождение: правообладатель является российским лицом, права на продукт принадлежат ему, продукт правомерно распространяется в стране. Ведёт его Минцифры, у каждой позиции есть номер записи и дата включения. Больше запись не означает ничего: ни того, что программа работает хорошо, ни того, что она защищена, ни того, где физически лежат ваши данные.
Офисная аналогия — перечень аккредитованных поставщиков, который ведёт отдел закупок. Попадание в него означает ровно одно: компания подала пакет документов и он прошёл формальную проверку. Оно ничего не говорит о том, привезёт ли поставщик вовремя и как он поведёт себя при рекламации. И наоборот: подрядчик, который возит вам десять лет и ни разу не подвёл, в перечне может отсутствовать просто потому, что никогда туда не подавался. Реестр устроен точно так же, и обе половины этой аналогии одинаково важны.
Дальше — четыре термина, которые с реестром постоянно путают, кому он на самом деле обязателен, во что превращается в смете замена одного компонента и четыре вопроса подрядчику. Модель по состоянию на сентябрь 2026 года: проектно-инжиниринговая компания, 120 человек, часть выручки — контракты с заказчиками, у которых требование по реестру записано в договоре. Проект автоматизации на 1 800 000 ₽: сводная отчётность на 14 витринах, 26 дашбордов для 40 пользователей, CRM и хранилище документов. Ставка инженера — 3 000 ₽/час, полная стоимость часа аналитика — 900 ₽.
Четыре разные вещи, которые называют одним словом
Почти все неверные решения вокруг реестра растут из того, что четыре независимых требования сливаются в голове в одно «российское». Они предъявляются разными сторонами, проверяются по-разному и выполняются отдельно друг от друга.
| Требование | Что подтверждает | Кто предъявляет | Чем проверяется |
|---|---|---|---|
| Запись в реестре отечественного ПО | Происхождение продукта и права на него | Правила закупки заказчика | Карточка продукта: номер записи и дата включения |
| Локализация по 152-ФЗ | Что база с персональными данными находится в России | Закон, к вам как к оператору | Договор с площадкой и фактическое место обработки |
| Российское облако | Что серверы стоят в стране | Никто напрямую; следствие предыдущего пункта | Адрес площадки и юрлицо оператора |
| Сертификация средств защиты | Что средство защиты прошло испытания | Отраслевые требования и требования к защищаемым системам | Сертификат на конкретную версию продукта |
Практический вывод из таблицы один: российское юрлицо, российское облако, российская поддержка и запись в реестре — четыре разные вещи, и наличие первых трёх не даёт четвёртой. Самый показательный случай на сентябрь 2026 года — Yandex DataLens: данные лежат в российском облаке, компания российская, а записи в реестре у сервиса нет. Для обычного ООО это ничего не меняет — покупка идёт как подписка на облачный сервис. Для государственного заказчика или компании, у которой требование прописано в положении о закупке, это блокер, который не обходится ни письмом вендора, ни фактом хранения данных в России.
Четыре вертикальные колонки одинаковой ширины с заголовками «Запись в реестре», «Локализация по 152-ФЗ», «Российское облако», «Сертификация средств защиты». В каждой колонке три строки: «что подтверждает», «кто требует», «чем проверяется» — с короткими значениями. Между колонками нет соединительных стрелок, вместо них перечёркнутые тонкой линией связки с подписью «одно из другого не следует». Внизу под всеми колонками выносная подпись: «Yandex DataLens — галочки во второй и третьей колонке есть, в первой нет». Тонкие чертёжные линии, все подписи по-русски.
Обязателен не продукту, а покупателю
Правильный первый вопрос — не «есть ли эта система в реестре», а «влияет ли реестр на меня вообще». Ответ зависит только от того, кто вы как покупатель, и почти никогда — от отрасли или размера компании.
- Государственный или муниципальный заказчик. Реестр работает как жёсткое ограничение закупки и становится первым фильтром шорт-листа — до демонстраций, сравнения функций и сметы. Отклонение возможно только через установленную процедуру обоснования, которая готовится заранее, а не подписывается задним числом.
- Компания с госучастием, субъект критической информационной инфраструктуры, подрядчик по госконтракту. Требование приходит не из общего закона, а из собственного положения о закупке или из условий контракта, и формулировки у всех разные. Читать надо свой документ: где-то это прямой запрет, где-то приоритет с ценовой преференцией.
- Обычное ООО без государственных заказчиков и госучастия. Реестр в выборе системы, как правило, не участвует вовсе. Самая массовая ошибка здесь — сузить шорт-лист до реестровых продуктов «на всякий случай», потерять функциональность и переплатить, не имея ни одного основания для такого ограничения.
- Частная компания, у которой требование пришло вместе с контрактом. Самый недооценённый случай: обязанность передаётся вам вместе с подрядом и живёт ровно столько, сколько живёт этот контракт. Отсюда правильный вопрос при планировании: что произойдёт, если через год такой заказчик появится или, наоборот, уйдёт.
Развёрнутый разбор этой развилки — с таблицей по типам покупателей, порядком проверки карточки продукта и формулировками требования для технического задания — есть в отдельном материале про реестр отечественного ПО и выбор системы. Здесь мы дальше говорим только о деньгах: во что превращается требование, когда оно всё-таки к вам относится.
Во что превращается в смете
Замена «одного компонента на реестровый» звучит как строка в счёте, а является сменой архитектуры. В модельном проекте нереестровым оказался слой отчётности: витрины и дашборды были спроектированы на свободной платформе, которую в реестр никто не подавал. Функционально она устраивала всех.
Обратите внимание, что самая крупная строка — не лицензии, а перенос: модель данных у BI-систем разная, и 26 дашбордов не переезжают выгрузкой. Это общее свойство слоя отчётности, и оно же объясняет, почему требование по реестру дешевле обнаружить до выбора платформы, чем после. Что именно живёт в этом слое и почему его переделка стоит дороже, чем кажется, разобрано в статье про BI-систему и дашборд.
Столбчатая диаграмма из двух столбцов, ось Y в рублях. Левый столбец «Исходный проект — 1 800 000 ₽» сплошной. Правый столбец «После замены слоя отчётности — 2 618 400 ₽» состоит из того же основания 1 800 000 ₽ и надстройки из четырёх подписанных сегментов: «лицензии 480 000 ₽», «перенос витрин и дашбордов 270 000 ₽», «проведение обучения 36 000 ₽», «время аналитиков 32 400 ₽». Надстройка охвачена скобкой с подписью «818 400 ₽, это 45 %». Сбоку отдельная пометка «плюс 5 недель срока и 96 000 ₽ в год на поддержку лицензий». Тонкие чертёжные линии, подписи по-русски.
Теперь то же самое, но с опозданием. Если требование приходит через год после запуска — вместе с новым заказчиком или после смены положения о закупке, — к тем же 818 400 ₽ добавляются два месяца параллельной работы двух контуров (50 000 ₽ администрирования), перенос накопленной истории и сверка расхождений (40 часов инженера — 120 000 ₽) и повторное обучение с периодом недоверия к цифрам (6 аналитиков × 10 часов — 54 000 ₽). Итого 1 042 400 ₽ — на 224 000 ₽, или на 27 %, дороже.
Покупать реестровый продукт заранее, не имея требования, — плохое решение: вы платите 480 000 ₽ и год поддержки за то, что может не понадобиться. Хорошее решение — заложить в архитектуру точку замены слоя: витрины отделены от инструмента визуализации, доступ к данным идёт через собственный слой представлений. Это 24 часа инженера на этапе проектирования, 72 000 ₽, или четыре процента сметы. С ней будущая замена BI стоит 552 000 ₽ вместо 1 042 400 ₽: лицензии плюс 24 часа на пересборку представлений. Та же логика применима к выбору между своим размещением и облаком — там точка замены проходит по данным, а не по слою отчётности.
Три горизонтальные полосы одинаковой высоты, ось X в рублях. Полоса 1 «Требование известно до выбора платформы — 818 400 ₽». Полоса 2 «Требование пришло через год после запуска — 1 042 400 ₽», рядом выносная подпись «+224 000 ₽, это 27 %». Полоса 3 «Через год, но с заложенной точкой замены — 552 000 ₽», она самая короткая и выделена рамкой, под ней подпись «точка замены стоила 72 000 ₽ на этапе проектирования». Слева вертикальная подпись оси «сценарий». Тонкие чертёжные линии, подписи по-русски.
Чего запись в реестре не даёт
Четыре ожидания, которые не оправдываются, и каждое из них регулярно становится основанием для выбора системы.
- Не гарантирует качества и зрелости. Включение — административная процедура по документам, а не испытание продукта. В перечне есть и платформы с сотнями внедрений, и продукты, которые никто никогда не видел в эксплуатации.
- Не гарантирует поддержки и живого рынка внедренцев. Спрашивать надо отдельно: сколько компаний умеет внедрять этот продукт, есть ли они в вашем регионе и что произойдёт, если ваш подрядчик уйдёт. Реестр на этот вопрос не отвечает вовсе.
- Не означает, что внутри нет зарубежного открытого кода. Требование относится к правам на продукт и к правообладателю, а не к происхождению каждой библиотеки в его составе. Российские СУБД, BI-платформы и серверы приложений часто собраны на открытых зарубежных основаниях — это законно и нормально, но ожиданию «полностью своё» не соответствует.
- Не защищает от исключения записи. Реестр живой: записи меняются, продукты переименовываются и исключаются. Если требование для вас существенно, статус проверяется на дату закупки, а не на дату, когда подрядчик прислал коммерческое предложение.
Четыре вопроса подрядчику до подписания
- 1Какие компоненты решения есть в реестре, а какие нет? Правильный ответ — список всех компонентов с номерами записей и датами, включая СУБД, платформу отчётности и средства интеграции. Фраза «мы работаем на отечественном стеке» списком не является.
- 2Что придётся заменить, если требование появится через год, и во что это обойдётся? Ответ должен быть в рублях и неделях по каждому нереестровому компоненту. Отсутствие оценки означает, что риск просто не считали.
- 3Есть ли в архитектуре точка замены и сколько она стоит на этапе проектирования? Это вопрос про то, отделены ли данные и логика от конкретного инструмента. Если ответ «всё делается средствами платформы», замена компонента будет означать переделку решения.
- 4Как требование записано в техническом задании и как оно проверяется на приёмке? Формулировка «использовать отечественное программное обеспечение» непроверяема; проверяема формулировка со списком компонентов и номерами записей. Как вообще устроено проверяемое требование, разобрано в статье про техническое задание на автоматизацию.
Когда про реестр можно забыть
Честный раздел, и для большинства читателей — главный. Три признака того, что реестр в вашем случае не участвует в решении и смотреть на него не надо.
- Среди ваших заказчиков нет государственных и муниципальных, нет госучастия в капитале, вы не субъект критической инфраструктуры и не подрядчик по госконтракту с переданным требованием. Тогда система выбирается по функциональности, стоимости владения и наличию людей, которые её поддержат.
- Вы покупаете не лицензию, а работы. Реестр относится к продуктам, а не к услугам: настройка, интеграция и доработка — три четверти бюджета типового проекта — им не затрагиваются в принципе.
- Продукта нужного класса в реестре просто нет. В отраслевом и инженерном ПО это встречается заметно чаще, чем в офисном. Тогда выбор делается по существу, а требование, если оно к вам применимо, закрывается процедурой обоснования — и готовить её надо до закупки.
И обратный случай, который стоит назвать прямо: если требование к вам всё-таки относится, проверка реестра перестаёт быть формальностью и становится первым фильтром — раньше демонстраций и раньше сметы. Как это сочетается с общим движением рынка и что менялось в требованиях последние годы, разобрано в материале про вторую волну импортозамещения; там же — почему замена ради замены обходится дороже, чем осознанное сохранение работающего контура.
Реестр отвечает на вопрос о происхождении продукта. На вопрос, будет ли он работать у вас и найдётся ли кому его поддерживать, не отвечает никто, кроме вас.
