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

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

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

Особенности модели SaaS

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

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

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

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

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

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

В итоге SaaS — это не проблема, а просто другой формат продукта, который требует более внимательной подготовки заявки. И на практике большинство сложностей возникает не из-за самой модели, а из-за того, что команды не до конца понимают, как правильно описать архитектуру, инфраструктуру и функциональность.

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