Включение промышленной продукции в реестр Минпромторга - важная процедура для российских производителей.
Процедура получения доверенного статуса устроена так, что ошибки обходятся дорого — и деньгами, и временем. Замечание в центре тестирования означает повторную экспертизу за отдельную плату и 1–2 месяца задержки. Возврат заявления Минцифры из-за неполного пакета документов — ещё несколько недель на устранение и повторную подачу. Ошибка при определении категории продукта — риск пропустить дедлайн. За десять лет сопровождения разработчиков через реестровые процедуры мы видели одни и те же ошибки у компаний самого разного масштаба. Большинство из них можно было избежать при наличии системной подготовки.
Ошибки на этапе подготовки
Большинство проблем при экспертизе закладываются задолго до подачи заявления — в период, когда компания ещё только оценивает ситуацию или откладывает начало работ. Эти ошибки самые дорогие, потому что к моменту их обнаружения времени на исправление остаётся мало.
⏰
Ошибка 1: слишком поздний старт
Самая распространённая и самая критичная ошибка. Процедура занимает 4–6 месяцев при готовом продукте — и это без учёта времени на техническую доработку, которая нередко добавляет ещё 2–4 месяца. Компании, начинающие работу за 3 месяца до дедлайна, физически не успевают. Для офисного ПО с дедлайном 1 сентября 2026 года старт в апреле — уже с высоким риском опоздания.
🗂️
Ошибка 2: пропуск предварительного аудита
Компании подают заявление, не проверив заранее ни юридическую позицию по правам, ни техническую готовность продукта. Проблемы обнаруживаются в центре тестирования — когда их исправление стоит уже в несколько раз дороже, чем если бы они были выявлены на этапе внутреннего аудита.
🏷️
Ошибка 3: неверное определение категории ПО
Ошибка в классификации продукта по классификатору Минцифры влечёт ошибку в определении дедлайна. Продукт, классифицированный как «серверное ПО» вместо «связующее ПО», может оказаться в другой группе с другими требованиями при экспертизе. Пограничные случаи — SIEM/мониторинг, ERP/отраслевое ПО — требуют отдельного анализа.
📄
Ошибка 4: устаревшая реестровая запись
Продукт за несколько лет после включения в реестр существенно изменился, а реестровая запись отражает старую версию. Центр тестирования проверяет актуальный продукт, а документы описывают другой. Расхождение выявляется при экспертизе и требует остановки, актуализации записи и возобновления процедуры.
Ошибки при работе с документами
Документальные ошибки — вторая по частоте причина задержек. Они не означают принципиальной непригодности продукта, но создают техническое препятствие для прохождения процедуры.
Ошибка Последствие Как избежать Устаревшая выписка из ЕГРЮЛ — старше 30 дней Возврат пакета Минцифры, задержка 1–2 недели Получать выписку непосредственно перед подачей Договоры с разработчиками без условия о служебных произведениях Права на продукт формально не принадлежат компании — отказ или возврат на доработку Юридический аудит прав до начала процедуры Отсутствие корпоративного договора при его фактическом наличии Вопросы к структуре контроля, задержка при рассмотрении Предоставить все корпоративные документы, а не только устав Неполный перечень компонентов и зависимостей Центр тестирования запрашивает дополнение, задержка 1–3 недели Полная инвентаризация стека до подачи документации в центр Расхождение версии дистрибутива и документации Замечание на экспертизе, повторная проверка Синхронизировать версии дистрибутива и документов перед передачей Отсутствие документации по информационной безопасности Запрос дополнительных материалов от центра, задержка 2–4 недели Подготовить описание архитектуры безопасности как отдельный документ
Ошибки при технической подготовке продукта
Технические ошибки — наиболее дорогостоящие по последствиям. Они обнаруживаются в центре тестирования и требуют доработки продукта с последующей повторной экспертизой. Каждый такой цикл добавляет 1–2 месяца к сроку и значительные расходы к бюджету.
🔴 Не проверяли на доверенных ОС до экспертизы
Команда тестировала продукт на Windows и Ubuntu, но не на Astra Linux или РЕД ОС. Специфика этих дистрибутивов — иные версии компонентов, политики безопасности, особенности инициализации служб — нередко создаёт проблемы, которых нет в стандартных Linux-средах.
🔴 Устаревшие зависимости с известными CVE
Продукт использует библиотеки, обновления к которым выходили год или более назад. Центр тестирования сверяет компонентный стек с базой CVE — и выявляет уязвимости, которые компания просто не отслеживала. Обновление зависимостей кажется простым, но нередко влечёт цепочку несовместимостей.
🔴 Несанкционированная сетевая активность
Продукт отправляет телеметрию разработчику, обращается к внешним серверам без действия пользователя или использует иностранные облачные сервисы как неотъемлемые компоненты. Центр тестирования фиксирует сетевую активность продукта — и каждое недокументированное внешнее соединение вызывает вопросы.
🔴 Инсталлятор, не работающий на Linux
Установка продукта на доверенную ОС требует ручного редактирования конфигурационных файлов, недокументированных шагов или специфических системных зависимостей. Центр тестирования устанавливает продукт штатным способом по документации — нестандартная установка фиксируется как замечание.
🔴 Использование Wine или эмуляции Windows-среды
Разработчик считает, что совместимость с доверенными ОС обеспечена через Wine. Постановление требует нативной работы продукта — эмуляция не засчитывается. Продукт, запускающийся только через Wine, формально несовместим с доверенными ОС.
🔴 Отсутствие российской криптографии при наличии криптофункций
Продукт реализует шифрование, электронную подпись или защищённые каналы связи — но только на иностранных алгоритмах (AES, RSA, SHA). Для продуктов с криптографическими функциями применение ГОСТ-алгоритмов является требованием, не рекомендацией.
Ошибки при работе с юридическими требованиями
Юридические ошибки нередко выявляются позже всего — на этапе детального анализа при подготовке к подаче. К этому моменту времени на их исправление остаётся меньше всего.
Путаница между правами на компанию и правами на ПО
Компания полностью российская, но права на программный продукт оформлены некорректно — созданы подрядчиком без договора об отчуждении, или разработаны иностранными сотрудниками без надлежащих трудовых договоров.
- Права на компанию и права на продукт — разные юридические объекты
- Нужно проверять каждый компонент продукта отдельно
- Исторические подрядчики без договоров — самый частый источник проблем
- Решение: дополнительные соглашения об отчуждении прав
Нераскрытый корпоративный договор с нестандартными правами
Иностранный миноритарный акционер с долей 20% имеет право вето на стратегические решения по корпоративному договору — что фактически означает контроль, несмотря на формальное меньшинство.
- Корпоративный договор нужно предоставлять при его наличии
- Скрытие договора при последующем выявлении — серьёзный риск
- Нестандартные права нужно проработать до подачи
- Решение: пересмотр договора или реструктуризация
Неправильный расчёт правила 30% для госкомпаний
Компания с государственным участием включила в расчёт только прямых «дочек», не учитывая «сестринские» структуры холдинга и организации, связанные через общих руководителей.
- Группа лиц по 135-ФЗ шире, чем очевидные аффилированные
- Необходим полный анализ структуры холдинга
- Занижение числителя в расчёте — ошибка, которая выявляется при проверке
- Решение: корректный юридический анализ границ группы
Ошибки при работе с центром тестирования
Отдельная категория ошибок связана не с содержательной готовностью продукта, а с организацией взаимодействия с центром тестирования.
📅
Начало переговоров с центром после регистрации заявления
Компания подаёт заявление в Минцифры и только после этого начинает искать центр тестирования. В периоды пиковой нагрузки центры заполнены на месяцы вперёд — и часть 30-дневного срока уходит просто на ожидание ответа и согласование условий.
🎯
Выбор центра без учёта специализации
Центр выбран по географическому принципу или по минимальной цене, но не имеет опыта с данной категорией ПО. Непрофильный эксперт может выдать нерелевантные замечания или пропустить реальные проблемы — и то и другое создаёт риски.
🔧
Не согласована конфигурация тестовой среды
Внутреннее тестирование проводилось в одной конфигурации, центр использует другую — и результаты расходятся. Предварительное согласование программы тестирования и конфигурации среды исключает этот риск.
💬
Медленные ответы на вопросы экспертов
В ходе экспертизы эксперты задают уточняющие вопросы. Если разработчик отвечает с задержкой в несколько дней — это напрямую удлиняет экспертизу. Назначить ответственного за коммуникацию с центром на время экспертизы — простое организационное решение с реальным эффектом на сроки.
Ошибки в оценке ситуации
Помимо конкретных операционных ошибок есть стратегические заблуждения, которые приводят к тому, что компании вообще не начинают подготовку вовремя или движутся в неверном направлении.
Распространённые заблуждения и реальность
Заблуждения
- «Мы уже в реестре российского ПО — это почти то же самое»
- «У нас Linux-продукт — совместимость с доверенными ОС не проблема»
- «Наш конкурент пока тоже без статуса — не срочно»
- «Есть сертификат ФСТЭК — блок ИБ закрыт»
- «SaaS-продукты не могут получить доверенный статус»
- «Дедлайн через год — у нас ещё много времени»
Реальность
- Реестр — предварительное условие, доверенный статус — отдельная сложная процедура
- Не все Linux-дистрибутивы одинаковы; Astra Linux SE имеет специфику, которая создаёт проблемы даже для нативных Linux-продуктов
- Первый получивший статус получает конкурентное преимущество во всех последующих тендерах
- Сертификат ФСТЭК помогает, но не заменяет процедуру — требования пересекаются, но не совпадают
- SaaS может получить статус при российской инфраструктуре — зависит от архитектуры
- Год при наличии технических проблем — это только подготовка, без официальных этапов
Как проверить себя перед подачей
Короткий чек-лист, позволяющий выявить наиболее критичные риски до начала официальной процедуры.
Проверочный вопрос Что означает «нет» Реестровая запись актуальна и отражает текущую функциональность? Нужна актуализация до подачи — отдельная процедура через Минцифры Для всех значимых создателей кода оформлены договоры с условием о служебных произведениях? Юридический риск по правам — нужна проработка до подачи Продукт протестирован на Astra Linux и/или РЕД ОС и работает корректно? Техническая доработка — добавьте 1–4 месяца к сроку Компонентный стек проверен на уязвимости — нет открытых CVE в используемых версиях? Обновление зависимостей — нередко влечёт цепочку несовместимостей Вся сетевая активность продукта задокументирована — нет недокументированных внешних соединений? Замечание на экспертизе — нужна доработка и документирование Документация по безопасности (архитектура, модель угроз) подготовлена? Центр тестирования запросит — добавьте 2–3 недели Переговоры с центром тестирования начаты? В пиковый период — риск очереди на несколько месяцев
Вопросы об ошибках при получении доверенного статуса
Что происходит после отказа или возврата на доработку — нужно начинать процедуру заново?
Зависит от этапа, на котором возникла проблема. Возврат заявления Минцифры из-за неполного документального пакета — это не отказ в статусе, а техническое возвращение. После исправления и повторной подачи процедура продолжается. Отрицательное заключение центра тестирования — более серьёзная ситуация: требуется доработка продукта, повторная экспертиза (с дополнительной оплатой), и только после положительного заключения — направление в правкомиссию. Полный отказ в статусе со стороны правкомиссии — редкая ситуация при корректно пройденной экспертизе.
Можно ли повторно подать заявление после отказа?
Да, ограничений на повторную подачу нет. После устранения причин отказа или замечаний заявление подаётся заново. Важно понимать, что повторная процедура занимает столько же времени, что и первичная — сокращённых сроков для повторных заявителей не предусмотрено. Именно поэтому качественная подготовка к первой подаче экономически оправдана: цена ошибки — полный дополнительный цикл.
Наш продукт частично не прошёл тестирование на совместимость. Можно ли получить статус на ту часть функциональности, которая работает?
Нет — доверенный статус присваивается продукту в целом, а не отдельным его функциям. Если часть заявленной функциональности не работает на доверенных ОС, центр тестирования не может подтвердить совместимость продукта с этими ОС. Выход — либо устранить несовместимость, либо исключить нефункционирующую часть из заявленной функциональности (с соответствующей актуализацией реестровой записи) и подать на статус для скорректированного описания продукта.
Если мы нашли ошибки в документах уже после подачи заявления — что делать?
Если ошибки обнаружены до того, как Минцифры начал рассмотрение — есть возможность отозвать заявление, исправить и подать повторно. Если рассмотрение уже идёт — нужно как можно скорее связаться с Минцифры и уточнить возможность предоставления дополнительных или исправленных материалов. Чем раньше ошибка обнаружена — тем меньше потери. Именно поэтому мы рекомендуем финальную проверку пакета непосредственно перед подачей, а не только на этапе его формирования.
Главный вывод: большинство ошибок предотвратимы
Из всего перечисленного выше практически нет ситуаций, которые нельзя было бы выявить и устранить при качественной предварительной подготовке. Неоформленные права на код? Обнаруживается при аудите за 2 месяца до подачи, а не в центре тестирования. Несовместимость с Astra Linux? Выявляется на внутреннем стенде за месяц до экспертизы. Устаревшие зависимости? Инвентаризируются за неделю. Единственная ошибка, которую невозможно исправить постфактум — пропущенный дедлайн.
95% наших клиентов проходят экспертизу с первого раза 1–2 мес. стоит каждый цикл доработки после замечания от 30 000 ₽ стоимость предварительного аудита 10 лет опыт сопровождения реестровых процедур
Проверить готовность продукта и избежать ошибок при подаче
Расскажите о продукте и текущей ситуации — проведём аудит, выявим риски и составим план их устранения до начала официальной процедуры.
Телефон / WhatsApp / Telegram: +7 920-898-17-18
Email: reestrgarant@mail.ru
Первичная консультация бесплатная в рабочее время.
Оригинальная статья
Полная версия статьи на нашем сайте: https://vnesenie-v-reestr.ru/news/osnovnye-oshibki-pri-poluchenii-doverennogo-statusa-po-prichiny-otkaza-i-kak-ih-izbezhat
Мы занимаемся включением в реестр Минпромторга
📞 Телефон: +7 920-898-17-18
✉️ Email: reestrgarant@mail.ru