Модуль или отдельное ПО: как IT-компании не ошибиться с реестром Минцифры

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

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

Короткий ответ

По итогам проверки обычно возможны три сценария.

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

Точный вариант зависит от фактической архитектуры продукта, документов и коммерческой модели. Вывод требует экспертной проверки.

Почему тема важна после включения ПО в реестр

Многие ИТ-компании воспринимают реестр как разовую задачу: один раз включили продукт, получили запись и дальше развивают ПО без оглядки на нее.

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

Для бизнеса это может создать проблему в нескольких ситуациях:

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

Риск не в самом развитии продукта. Риск в разрыве между тем, что внесено в реестр, и тем, что компания фактически продает, внедряет и описывает клиентам.

Что говорит закон и регулятор

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

Для проверки обычно используют:

• Федеральный закон № 149-ФЗ «Об информации, информационных технологиях и о защите информации»;
• постановление Правительства РФ № 1236;
• правила формирования и ведения единого реестра российских программ для электронных вычислительных машин и баз данных;
• требования к сведениям и документам, которые подаются через официальный ресурс реестра;
• карточку конкретной реестровой записи.

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

Что может считаться модулем ПО

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

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

Примеры ситуаций, где новый функционал может быть похож на модуль:

• в системе управления клиентами добавили блок аналитики продаж;
• в платформе документооборота появился модуль согласования договоров;
• в системе управления проектами добавили модуль отчетности;
• в медицинской информационной системе появился блок записи пациентов;
• в платформе кибербезопасности добавили модуль мониторинга инцидентов.

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

Когда новый функционал может быть отдельным ПО

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

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

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

Когда может быть достаточно обновления сведений

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

Такой вариант возможен, если изменения не меняют сущность ПО. Например:

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

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

Когда может понадобиться внесение изменений или новая заявка

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

Признаки риска

Внесение изменений или отдельная заявка могут понадобиться, если:

• добавили новый модуль;
• изменилась архитектура;
• изменилось назначение продукта;
• появились новые классы ПО;
• модуль стал отдельным коммерческим продуктом;
• изменилась техническая документация;
• изменилась эксплуатационная документация;
• изменился правообладатель;
• появились новые компоненты с отдельными правами;
• продукт стал поставляться в новой конфигурации;
• старая реестровая запись не описывает то, что фактически продается заказчику.

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

Почему нельзя решать только по названию

Название «модуль» не решает вопрос. В договоре, маркетинговых материалах и технической документации один и тот же компонент может называться по-разному:

• модуль;
• компонент;
• подсистема;
• сервис;
• платформа;
• расширение;
• отдельное решение;
• новая версия продукта.

Для реестра Минцифры безопаснее смотреть не на слово, а на факты:

• как продукт работает;
• как поставляется;
• кому продается;
• как описан в документации;
• кто правообладатель;
• можно ли использовать компонент отдельно;
• какие сведения уже есть в реестровой записи.

Если факты показывают самостоятельный продукт, слово «модуль» не снимает риск.

Типичные ошибки ИТ-компаний

1. Считают, что любые доработки не нужно отражать

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

2. Называют отдельный продукт модулем

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

3. Не обновляют документацию

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

4. Не проверяют правообладателя по модулю

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

5. Не связывают изменения продукта с реестровой записью

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

6. Вспоминают о реестре перед закупкой или проверкой

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

Проверьте, относится ли это к вашему продукту

Ответьте на вопросы. Если хотя бы по нескольким пунктам ответ «да», реестровую запись лучше проверить.

• Появился ли новый функциональный блок?
• Можно ли его продавать отдельно?
• Изменилась ли документация?
• Изменилась ли архитектура?
• Изменились ли правообладатели?
• Появились ли новые классы ПО?
• Отличается ли текущий продукт от того, что был описан при подаче?
• Есть ли отдельный тариф или лицензия?
• Есть ли отдельная целевая аудитория?
• Можно ли использовать компонент без основного продукта?
• Обновлялась ли карточка реестра после последнего крупного релиза?
• Совпадает ли описание в реестре с тем, что показывает отдел продаж?

Что делать ИТ-компании пошагово

Шаг 1. Найти текущую реестровую запись

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

Шаг 2. Собрать список изменений

Зафиксируйте, что изменилось после подачи:

• новые версии;
• новые модули;
• новые компоненты;
• новые интеграции;
• новые тарифы;
• новые документы;
• изменения в архитектуре;
• изменения в правообладателях;
• новые сценарии использования.

Шаг 3. Сравнить продукт с исходной заявкой

Главный вопрос: описывает ли старая запись тот продукт, который компания продает и внедряет сейчас.

Шаг 4. Проверить модульность

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

Шаг 5. Проверить документы

Сверяются:

• техническое описание;
• эксплуатационная документация;
• пользовательская документация;
• лицензионные условия;
• договоры с клиентами;
• документы о правах;
• описание классов ПО;
• маркетинговые материалы, если они расходятся с заявкой.

Шаг 6. Выбрать безопасный порядок действий

По итогам проверки возможны варианты:

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

Какие документы обычно нужны для проверки

Для первичной диагностики лучше подготовить:

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

Если часть документов не готова, можно начать с диагностики. Антиштраф покажет, каких данных не хватает для вывода.

Как помогает Антиштраф

Антиштраф помогает ИТ-компаниям проверить, как правильно оформить новый модуль или продукт в реестре ПО Минцифры. Работа строится по трем этапам: проверка, подготовка и сопровождение.

Проверка: анализируем запись, продукт и изменения

Мы анализируем:

• текущую реестровую запись;
• описание ПО;
• новые функции и модули;
• архитектуру;
• документацию;
• сведения о правообладателе;
• классы ПО;
• коммерческую модель;
• риски расхождения между записью и фактическим продуктом.

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

Подготовка: собираем документы и порядок действий

Если нужно действовать, мы помогаем подготовить:

• уведомление или заявление;
• пакет для внесения изменений;
• обновленную техническую и эксплуатационную документацию;
• описание модуля;
• документы по правообладателю;
• пакет для новой заявки по отдельному ПО;
• внутренний план исправлений перед подачей.

Результат: у компании появляется не общий совет, а рабочий пакет действий под конкретную ситуацию.

Сопровождение: контролируем запись после изменений

После разовой проверки продукт продолжает развиваться. Поэтому мы можем сопровождать реестровую запись:

• напоминать о контрольных изменениях;
• проверять крупные релизы;
• оценивать новые модули до запуска продаж;
• помогать при запросах Минцифры;
• обновлять документы при изменении продукта;
• снижать вероятность типовых ошибок перед закупками и проверками.

Результат: реестровая запись не живет отдельно от продукта. Она поддерживается вместе с развитием ПО.

Когда обращаться в Антиштраф

Обратитесь за проверкой, если:

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

Проверьте, как правильно оформить новый модуль или продукт

Пришлите название ПО или ссылку на реестровую запись. Мы проверим, относится ли изменение к модулю, обновлению сведений или отдельной заявке.

Получить диагностику реестровой записи

Частые вопросы

Нужно ли подавать новую заявку, если мы просто добавили новую функцию?

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

Если мы называем новый блок модулем, этого достаточно?

Нет. Название не решает вопрос. Нужно смотреть, как блок работает, продается, лицензируется, документируется и кому принадлежат права.

Что опаснее: не обновить сведения или подать лишнюю заявку?

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

Может ли модуль иметь отдельную документацию?

Может. Но отдельная документация усиливает вопрос: это часть основного продукта или самостоятельное ПО. Нужно смотреть на содержание документов и способ поставки.

Что делать, если модуль продается только в составе основного продукта?

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

Что делать, если модуль уже продали заказчику отдельно?

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

Нужно ли обновлять техническую документацию после каждого релиза?

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

Можно ли сначала получить консультацию без подготовки полного пакета документов?

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

Поможет ли Антиштраф понять, подавать один продукт или несколько?

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

Связанные материалы и услуги

Основные услуги

• Сопровождение включения ПО в реестр Минцифры
• Проверка реестровой записи ПО
• Подготовка документов для реестра российского ПО

Связанные статьи

• Как подготовить документацию для включения ПО в реестр Минцифры
• Почему ИТ-компании получают вопросы по заявке в реестр ПО
• Как подтвердить права на программное обеспечение для реестра Минцифры
• Классы ПО в реестре Минцифры: как не ошибиться при подаче

Источники для проверки

Перед публикацией и перед применением статьи к конкретной ситуации нужно проверить актуальную редакцию нормативных источников.

• Федеральный закон № 149-ФЗ «Об информации, информационных технологиях и о защите информации»
• Постановление Правительства РФ № 1236
• Официальный сайт единого реестра российских программ для электронных вычислительных машин и баз данных
• карточка конкретной реестровой записи клиента;
• техническая и эксплуатационная документация продукта.

Автор: редакция Антиштраф

Проверяющий эксперт: указать ФИО юриста или эксперта по реестру ПО

Дата подготовки: 22 июня 2026 года

Дата экспертной проверки: заполнить после проверки

Что проверить эксперту перед публикацией

• Корректность ссылок на 149-ФЗ и постановление Правительства РФ № 1236.
• Нужны ли более точные формулировки по обновлению сведений, внесению изменений и новой заявке.
• Можно ли использовать термин «модуль» в выбранной редакции без дополнительного определения.
• Не нужно ли добавить конкретные основания из правил ведения реестра.
• Не изменились ли требования Минцифры к составу документов.
• Не нужно ли уточнить порядок действий для случаев смены правообладателя.
• Не нужно ли добавить отдельный блок про исключительные права и компоненты с открытым исходным кодом.
• Не содержит ли статья выводов, которые могут трактоваться как гарантия результата.