```html

Облачный сервис и реестр российского ПО: как описать продукт и подтвердить права

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

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

Из-за этого у разработчиков возникают вопросы: что именно указывать в заявке в качестве программного продукта, как предоставить экземпляр ПО, к какому классу отнести облачный сервис, кому должны принадлежать права на backend и frontend, где могут находиться серверы и как описать жизненный цикл продукта.

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

Компания «МинпромХелп» подготовила практическое руководство о том, как описать SaaS-продукт, подтвердить права и подготовить техническую документацию для включения облачного сервиса в реестр российского ПО.

Актуальность информации: 1 октября 2026 года.

Можно ли включить SaaS в реестр российского ПО

Да.

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

Правила ведения реестра определяют программное обеспечение как программу для электронных вычислительных машин или базу данных.

Поэтому программный продукт может распространяться по различным моделям:

• коробочная лицензия;
• электронная лицензия;
• On-Premise;
• SaaS;
• веб-приложение;
• облачная платформа;
• смешанная модель SaaS + On-Premise.

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

Главное — правильно идентифицировать объект: в реестр включается программное обеспечение, а не абстрактная услуга доступа к сайту.

Что именно включать в реестр: сервис или программу

Для SaaS это один из основных вопросов.

Предположим, компания предоставляет сервис мониторинга промышленного оборудования.

В его состав входят:

• веб-интерфейс;
• backend;
• база данных;
• API;
• модуль аналитики;
• сервис уведомлений;
• мобильное приложение;
• внешняя СУБД;
• операционная система;
• облачная инфраструктура.

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

Например, объект можно описать как:

«Программная платформа промышленного мониторинга PlantMonitor — программа для сбора, обработки, хранения и визуализации телеметрических данных промышленного оборудования».

После этого необходимо определить архитектурные границы продукта.

Пример структуры продукта

Компонент	Роль
Web-клиент	Собственная часть продукта
Backend	Собственная часть продукта
Модуль аналитики	Собственная часть продукта
API	Собственная часть продукта
Мобильный клиент	Может входить в состав продукта
PostgreSQL	Сторонний программный компонент
Linux	Среда исполнения
Nginx	Сторонний компонент инфраструктуры
Дата-центр	Техническая инфраструктура

Конкретная структура зависит от архитектуры продукта.

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

Ошибка: подавать в реестр просто «облачный сервис»

Формулировка:

«Облачный сервис автоматизации бизнеса»

слишком общая.

Из неё невозможно понять:

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

Лучше описывать конкретную программу.

Например:

«Информационная система управления производственными заявками FactoryFlow».

Далее раскрывается функциональность:

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

SaaS не означает автоматически класс «облачное ПО»

Это очень важное различие.

В классификаторе российского ПО существует класс:

«Средства обеспечения облачных и распределённых вычислений».

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

Типичный пример — инфраструктурное ПО для организации облачной среды.

Если же компания разработала CRM, MES, сервис аналитики или систему документооборота, которая просто работает по SaaS-модели, класс необходимо определять по функциональному назначению продукта.

Продукт	Возможная логика классификации
Облачная CRM	Прикладное ПО соответствующего функционального класса
SaaS-сервис промышленной аналитики	Средства анализа данных или отраслевое/промышленное ПО
Облачная система документооборота	Средства управления процессами организации
Облачная инфраструктурная платформа	Средства обеспечения облачных и распределённых вычислений
Система управления контейнерами	Системы контейнеризации и контейнеры

Модель предоставления доступа и класс программного обеспечения — разные характеристики продукта.

Как определить класс облачного продукта

Рекомендуем начинать не с маркетингового названия, а с ответа на вопрос:

«Какую основную функцию выполняет программа?»

Например, сервис работает через браузер и размещён в облаке, но его основная функция — управление производственными процессами.

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

При выборе класса необходимо сопоставить:

• функциональные характеристики продукта;
• описание классов в классификаторе Минцифры;
• ОКПД2;
• аналогичные продукты в действующем реестре;
• фактическую архитектуру и назначение системы.

Кому должны принадлежать права на SaaS-продукт

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

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

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

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

Что проверить перед подачей

Вопрос	Что установить
Кто разработал frontend	Работники или подрядчики
Кто разработал backend	Есть ли права у заявителя
Кто создал базу данных	Кому принадлежат соответствующие права
Кто написал мобильное приложение	Входит ли оно в заявляемый продукт
Кому принадлежит документация	Есть ли ограничения на использование
Как оформлены подрядчики	Перешли ли необходимые исключительные права
Есть ли несколько правообладателей	Соответствует ли каждый требованиям

Если SaaS разрабатывался несколькими подрядчиками

Для облачных продуктов это распространённая ситуация.

Например:

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

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

Нужно установить:

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

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

Подробнее этот вопрос рассмотрен в статье «Реестр российского ПО: как подготовить подтверждение прав на программный продукт».

Нужно ли владеть правами на PostgreSQL, Linux и Open Source

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

Однако использование каждого такого компонента должно быть законным.

Для SaaS рекомендуется сформировать перечень внешних зависимостей.

Компонент	Что проверить
Open Source библиотека	Лицензию и условия использования
СУБД	Правомерность использования и распространения
Операционная система	Лицензионную модель
Сторонний API	Условия договора и зависимость продукта
Коммерческий SDK	Права на использование в продукте
Шрифт или интерфейсный компонент	Лицензионные ограничения

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

Что делать с иностранными программными компонентами

Само использование иностранного программного компонента не означает автоматического отказа во включении всей программы в реестр.

Но необходимо проверить:

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

Статья 12.1 Федерального закона №149-ФЗ устанавливает ограничение по определённым выплатам иностранным лицам.

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

Поэтому SaaS-компании особенно важно проверить платежи за:

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

Облачная инфраструктура: обязательно ли всё размещать в России

Здесь важно не смешивать разные требования законодательства.

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

На территории Российской Федерации должны находиться технические средства:

• хранения исходного текста;
• хранения объектного кода;
• компиляции исходного текста в объектный код.

Также технические средства, необходимые для:

• активации;
• выпуска;
• распространения;
• управления лицензионными ключами,

должны находиться на территории Российской Федерации и контролироваться российскими организациями либо гражданами РФ.

Однако из этого правила нельзя автоматически делать вывод, что ПП №1236 требует размещения в России абсолютно каждого рабочего сервера SaaS и всех пользовательских данных.

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

Их необходимо анализировать отдельно.

Что проверить у SaaS-разработчика по инфраструктуре

Перед подачей рекомендуется составить архитектурную карту.

Элемент	Что проверить
Git-репозиторий	Где физически находятся технические средства хранения
CI/CD	Где происходит сборка продукта
Registry артефактов	Где хранится объектный код
Release-сервер	Где формируется и распространяется релиз
License server	Где и кем управляется
Система активации	Кто контролирует инфраструктуру
Рабочий SaaS-кластер	Проверить применимые требования в зависимости от данных и отрасли

GitHub и зарубежные Git-сервисы: где возникает риск

Для российского реестра важен вопрос расположения технических средств хранения исходного и объектного кода.

Если основной репозиторий проекта размещён только на иностранной облачной инфраструктуре, это необходимо проанализировать до подачи заявки.

Аналогично необходимо проверить:

• облачный CI/CD;
• artifact repository;
• Docker registry;
• систему выпуска релизов;
• систему управления ключами.

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

Как описать инфраструктуру в документах

ПП №1236 предусматривает представление документации, описывающей:

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

Практически рекомендуем подготовить таблицу.

Процесс	Система	Местонахождение	Ответственный
Хранение исходного кода	Git-система компании	РФ	Правообладатель
Сборка	CI/CD	РФ	Правообладатель
Хранение сборок	Artifact repository	РФ	Правообладатель
Формирование релиза	Release pipeline	РФ	Правообладатель
Активация аккаунтов	Собственный сервис	РФ	Правообладатель

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

Как описать активацию, если у SaaS нет лицензионных ключей

У SaaS-продукта может отсутствовать классический серийный номер.

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

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

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

Не стоит искусственно придумывать «лицензионный ключ», если продукт его не использует.

Нужно показать:

• как создаётся доступ;
• какой сервер участвует в процессе;
• кто управляет системой;
• как определяется доступный функционал;
• как прекращается право доступа.

Как описать модель коммерциализации SaaS

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

Для облачного продукта необходимо обеспечить понятную юридическую модель.

Например:

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

Особенно внимательно необходимо относиться к ситуации, когда вся документация компании называет продукт исключительно «информационной услугой», а в заявку реестра подаётся программа для ЭВМ.

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

Как подтвердить права, если SaaS никогда не передаётся пользователю

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

Необходимо установить происхождение прав на программный код.

Для штатной разработки проверяются:

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

Для подрядной разработки:

• договор;
• техническое задание;
• условия о правах;
• акт;
• передача исходников;
• выполнение условий перехода исключительного права.

Нужно ли регистрировать SaaS в Роспатенте

Нет универсального требования сначала зарегистрировать программу в Роспатенте.

Государственная регистрация программы для ЭВМ является добровольной.

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

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

Как предоставить экземпляр SaaS-продукта

ПП №1236 предусматривает приложение к заявлению экземпляра программного обеспечения без технических средств защиты авторских прав либо со средствами законного устранения соответствующих ограничений.

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

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

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

В зависимости от архитектуры продукта это может потребовать подготовки:

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

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

Конкретный способ необходимо определять исходя из архитектуры продукта и требований формы заявления.

Какая техническая документация нужна для облачного продукта

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

Для SaaS формулировку «установка» необходимо адаптировать под фактическую модель эксплуатации.

Если пользователь ничего не устанавливает, документация может описывать:

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

Рекомендуемая структура документа

Раздел	Содержание
Назначение	Для чего предназначен продукт
Архитектура	Основные функциональные компоненты
Функциональность	Основные возможности
Доступ	Как пользователь начинает работу
Системные требования	Браузер, клиентское ПО, сеть
Роли	Администратор, пользователь и другие роли
Интеграции	API и внешние системы
Эксплуатация	Основные сценарии использования

Документация жизненного цикла SaaS

ПП №1236 требует также описать процессы, обеспечивающие поддержание жизненного цикла ПО.

Для постоянно работающего облачного сервиса этот документ особенно важен.

Рекомендуется раскрыть:

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

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

Кто должен осуществлять поддержку SaaS

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

Эти работы должны осуществляться российской коммерческой или некоммерческой организацией без преобладающего иностранного участия либо гражданином Российской Федерации в соответствии с действующими требованиями.

Для SaaS рекомендуется проверить:

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

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

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

Такую модель необходимо анализировать до подачи.

Отдельно следует проверить:

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

Может ли зарубежный облачный провайдер стать проблемой

Необходимо анализировать конкретную функцию такого провайдера.

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

Другая — размещение на иностранной инфраструктуре:

• единственного Git-репозитория;
• CI/CD;
• сервера сборки;
• релизного хранилища;
• системы лицензирования.

Во втором случае возникают прямые вопросы о соответствии требованиям ПП №1236.

Поэтому инфраструктуру следует анализировать не по названию провайдера, а по роли конкретного сервиса в жизненном цикле программного продукта.

Нужен ли русскоязычный интерфейс

Да.

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

Для SaaS это означает необходимость проверить:

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

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

Совместимость с российскими операционными системами: что меняется в 2027 году

С 2026–2028 годов новое требование о совместимости с доверенными операционными системами вводится поэтапно.

Для класса «Средства обеспечения облачных и распределённых вычислений» соответствующее требование начинает применяться с 1 января 2027 года.

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

Срок зависит от фактического класса программного обеспечения.

Класс/группа	Начало применения
Средства облачных и распределённых вычислений	1 января 2027 года
Серверное и связующее ПО	1 января 2027 года
СУБД	1 января 2027 года
Прикладное ПО	1 июня 2027 года
Отраслевое прикладное ПО	1 июня 2027 года
Промышленное ПО	1 января 2028 года

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

Как SaaS подтвердить совместимость с ОС, если пользователь работает через браузер

Это отдельный практический вопрос.

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

Например:

• серверная часть;
• агент;
• desktop-клиент;
• локальный коннектор;
• сервис интеграции.

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

Не рекомендуется механически переносить сценарии тестирования desktop-программы на браузерный SaaS.

Подробнее о доказательной базе читайте в статье «Совместимость российского ПО с отечественными ОС: как собрать доказательства для реестра».

Как подготовить страницу продукта на сайте

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

Для SaaS на странице рекомендуется разместить:

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

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

Если на сайте маркетинговое название «CloudPro», а в заявке используется «Информационная система автоматизации процессов версии 4.2», необходимо обеспечить понятную связь между этими обозначениями.

Что делать с версиями SaaS, если сервис обновляется каждую неделю

Это типичная особенность облачной модели.

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

Поэтому разработчику необходимо организовать управление версиями.

Рекомендуется фиксировать:

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

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

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

Когда облачный продукт становится фактически другим ПО

Постоянное обновление SaaS постепенно может привести к тому, что продукт существенно отличается от версии, первоначально включённой в реестр.

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

Изменились:

• назначение;
• архитектура;
• модули;
• класс ПО;
• набор функций;
• модель коммерциализации.

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

Какие документы подготовить для SaaS: итоговый чек-лист

Блок	Что подготовить
Правообладатель	Корпоративные сведения и структура контроля
Исключительные права	Документы разработки и перехода прав
Программный продукт	Чёткое описание границ и состава ПО
Класс	Обоснование функциональной классификации
Экземпляр ПО	Технически пригодный экземпляр для процедуры
Функциональная документация	Описание возможностей и эксплуатации
Жизненный цикл	Поддержка, обновления и персонал
Исходный код	Описание российского хранения
Сборка	Описание российского CI/CD и компиляции
Релизы	Описание выпуска и распространения
Активация	Фактический механизм предоставления доступа
Open Source	Перечень критичных компонентов и лицензий
Иностранные договоры	Проверка выплат и зависимостей
Интерфейс	Русскоязычная версия
Сайт	Открытая документация продукта

Пошаговая подготовка облачного продукта к реестру

1. Определить объект. Какую именно программу компания включает в реестр.
2. Зафиксировать архитектурные границы. Отделить собственный продукт от внешней инфраструктуры и сторонних компонентов.
3. Определить класс. Исходить из функции, а не из слова SaaS.
4. Проверить правообладателя. Установить соответствие требованиям статьи 12.1 №149-ФЗ.
5. Проверить права. Восстановить цепочку создания frontend, backend, БД и других собственных компонентов.
6. Проверить Open Source. Сформировать перечень ключевых зависимостей.
7. Провести инфраструктурный аудит. Репозитории, CI/CD, объектный код, релизы и лицензирование.
8. Подготовить экземпляр. Продумать технический способ предоставления SaaS для процедуры.
9. Подготовить функциональную документацию.
10. Описать жизненный цикл.
11. Подготовить страницу продукта.
12. Проверить коммерческую модель. Договоры должны соответствовать фактическому предоставлению прав на ПО.
13. Проверить будущие требования совместимости.
14. Подать заявление через официальный портал реестра.

Частые ошибки SaaS-разработчиков при подаче

• В заявке описана услуга, а не конкретный программный продукт.
• Класс «облачное ПО» выбран только потому, что продукт работает через браузер.
• Не определены архитектурные границы продукта.
• Часть backend принадлежит подрядчику.
• Основной Git-репозиторий и сборка находятся на иностранной инфраструктуре.
• Компания не может объяснить механизм выпуска SaaS-релиза.
• Отсутствует экземпляр ПО, пригодный для установленной процедуры.
• В документации указано только «откройте сайт» без описания функционала.
• Не описан жизненный цикл продукта.
• На сайте, в договорах и заявке используются разные названия сервиса.
• Не проанализированы иностранные библиотеки и платежи.
• Правообладатель путает хранение пользовательских данных и требование к инфраструктуре исходного кода.

FAQ: облачные сервисы и реестр российского ПО

Можно ли включить SaaS в реестр Минцифры?

Да. Облачная модель предоставления доступа сама по себе не препятствует включению. Необходимо идентифицировать программу для ЭВМ или базу данных и подтвердить её соответствие требованиям.

Обязательно ли давать пользователю дистрибутив?

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

Любой SaaS относится к классу «Средства обеспечения облачных и распределённых вычислений»?

Нет. Класс определяется функциональным назначением. CRM, ERP, аналитическая или промышленная система не становится инфраструктурным облачным ПО только из-за работы через браузер.

Должны ли все серверы SaaS находиться в России?

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

Можно ли использовать иностранный Open Source?

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

Нужно ли иметь права на PostgreSQL или Linux?

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

Нужно ли регистрировать SaaS в Роспатенте?

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

Когда для облачного ПО потребуется совместимость с двумя российскими ОС?

Дата зависит от класса продукта. Для средств обеспечения облачных и распределённых вычислений новое требование применяется с 1 января 2027 года. Для ряда прикладных программ — с 1 июня 2027 года, для промышленного ПО — с 1 января 2028 года.

Помощь МинпромХелп при включении SaaS в реестр российского ПО

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

Компания «МинпромХелп» помогает разработчикам подготовить облачные сервисы к включению в реестр российского программного обеспечения.

Мы помогаем:

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

Разработали облачный сервис и хотите включить его в российский реестр ПО?

Направьте специалистам «МинпромХелп» описание SaaS, схему архитектуры, сведения о разработчиках, используемых компонентах и текущей инфраструктуре.

Мы поможем определить, что именно следует подавать в качестве программного продукта и какие документы необходимо подготовить.

Получить консультацию по включению облачного ПО в реестр Минцифры →

Нормативные документы и официальные источники

• Федеральный закон №149-ФЗ «Об информации, информационных технологиях и о защите информации», статья 12.1.
• Постановление Правительства РФ №1236 — Правила формирования и ведения реестра российского программного обеспечения.
• Постановление Правительства РФ №1937 от 28.11.2025 — изменения требований к российскому ПО с 2026 года.
• Приказ Минцифры России №486 — классификатор программ для ЭВМ и баз данных.
• Официальный портал Единого реестра российских программ для ЭВМ и баз данных.

```