Облако для внутренних систем госорганизации: как проверить размещение по требованиям ПП № 884 с 1 сентября 2026 года

Проверка внутренних систем госорганизации, реестров провайдеров и безопасного переноса в облако
Содержание 22 разделов

Что делать, если ваша «не-ГИС» система тоже подпадает под спецперечень хостинг-провайдеров

С 1 сентября 2026 года действует Постановление Правительства РФ от 13.07.2026 № 884, которое расширяет правила включения хостинг-провайдеров в специальный перечень (ПП № 1144 от 24.08.2024). Раньше требование размещаться только у провайдеров из перечня касалось операторов государственных и муниципальных информационных систем, а также систем ГУП, МУП и госучреждений. Теперь в этот же круг добавлены внутренние системы, которые создают сами госорганы для организационного, информационного, документационного, финансового и технического обеспечения своей деятельности — даже если формально это не ГИС [1]. Практический вывод: ярлык «не ГИС» больше не гарантирует, что систему можно размещать где угодно. Нужно проверять каждую систему отдельно, сверяться со специальным перечнем провайдеров (а не с общим реестром хостинга) и закладывать эту проверку в закупки, продления договоров и подключение нового SaaS.

В чём проблема и кому полезна статья

У большинства госорганов и подведомственных организаций есть системы, которые никогда не проходили классификацию как ГИС: внутренний документооборот, HR-портал, система планирования бюджета, техническая CMDB, служба поддержки. До сих пор к ним часто применялся упрощённый подход — «раз не ГИС, значит требования по хостингу не про нас». После вступления в силу ПП № 884 эта логика перестаёт работать для той части таких систем, которые создавались самим госорганом именно для обеспечения его собственной деятельности.

Статья написана для тех, кто должен ответить на конкретный вопрос: наша система подпадает под требования к специальному перечню хостинг-провайдеров или нет, и что делать, если ответ — «да» или «не уверены». Материал полезен ИТ-директорам и юристам госзаказчиков, подведомственных организаций, а также поставщикам облачных услуг и ИТ-подрядчикам, которые обслуживают такие системы или участвуют в закупках.

Что изменилось: суть ПП № 884

Как было по ПП № 1144

Постановление Правительства РФ от 24.08.2024 № 1144 утвердило правила включения сведений о провайдере хостинга в специальный перечень провайдеров, которые вправе предоставлять вычислительные мощности для размещения информации операторам государственных информационных систем, муниципальных информационных систем, информационных систем государственных и муниципальных унитарных предприятий, государственных и муниципальных учреждений [2]. То есть исходный периметр требований был привязан к статусу системы (ГИС, МИС) или к статусу оператора (ГУП, МУП, учреждение).

Что добавило ПП № 884

ПП № 884 меняет и наименование, и пункт 1 правил, дополняя формулировку словами: требования теперь распространяются также на «информационные системы, созданные государственными органами в целях организационного, информационного, документационного, финансового и технического обеспечения своей деятельности, не являющиеся государственными информационными системами» [1]. Это дословная формулировка из текста постановления — она и есть новый критерий, по которому нужно проверять каждую систему.

Важно, что это изменение вносится сразу в двух местах — в наименование самого ПП № 1144 и в пункт 1 утверждённых им правил, а значит затрагивает всю логику документа, а не отдельную оговорку [1].

Процедурные новшества

Помимо расширения периметра, ПП № 884 вносит три технических изменения в процедуру работы с перечнем [1]:

  • при поступлении в Минцифры документов от провайдера хостинга (пункт 11 правил) министерство в течение 15 рабочих дней обязано уведомить об этом ФСБ России и ФСТЭК России — то есть силовые ведомства теперь информируются на более раннем этапе, до принятия решения;
  • добавлен новый пункт 13(1): если провайдер хостинга подтверждает соответствие требованиям после реорганизации, проект акта о внесении изменений в перечень вносится в Правительство по ускоренной процедуре — в течение 30 рабочих дней;
  • пункт 11 правил дополнен уточнением, что провайдер обязан уведомлять об изменениях в документах в связи с процедурой реорганизации.

Для госзаказчика это означает практическую вещь: если ваш провайдер хостинга проходит реорганизацию (смену юрлица, слияние, присоединение), стоит заранее уточнить у него, подана ли соответствующая информация в Минцифры — иначе есть риск, что сведения о провайдере временно выпадут из актуального перечня.

Как работает система требований к хостингу для госорганов

Два разных списка: общий реестр и специальный перечень

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

Общий реестр провайдеров хостинга. Ведётся в соответствии с Правилами формирования и ведения реестра провайдеров хостинга (ПП от 28.11.2023 № 2008) и фактически администрируется Роскомнадзором. Это базовая регистрация: любой провайдер хостинга, работающий в России, обязан быть включён в этот реестр, в котором на определённый момент числилось порядка 265 компаний [11]. Наличие компании в этом реестре — необходимое, но не достаточное условие для работы с госсистемами.

Специальный перечень для госсистем. Формируется отдельно, на основании ст. 13 149-ФЗ, и утверждается не приказом ведомства, а актом Правительства — сейчас это Распоряжение Правительства РФ от 04.10.2024 № 2753-р [6]. Именно этот документ, а не общий реестр, определяет, у кого госорган вправе размещать системы, подпадающие под требования ПП № 1144/884. Список короткий и штучный: с момента утверждения в октябре 2024 года в него вносились изменения как минимум четыре раза — распоряжениями от 28.02.2025, 11.04.2025, 09.06.2025 и 15.09.2025 [6]. Известный пример включённого провайдера — «РТК-ЦОД» (группа «Ростелеком») [10].

Что это означает на практике. Если поставщик услуг хостинга говорит «мы в реестре Роскомнадзора, у нас всё в порядке» — этого недостаточно для систем, подпадающих под ПП № 1144/884. Нужно смотреть именно действующую редакцию распоряжения о перечне и искать в ней конкретное юрлицо провайдера.

Требования к провайдеру для попадания в перечень

Чтобы провайдер хостинга был включён в специальный перечень, он должен соответствовать пяти требованиям ч. 2.1-2 ст. 13 149-ФЗ [3; 4]:

  1. быть российским юридическим лицом;
  2. использовать для предоставления вычислительных мощностей технические средства, расположенные на территории РФ (с проверкой адреса их фактического размещения);
  3. соблюдать требования к защите информации, в том числе иметь план или акт внедрения технических средств для проведения оперативно-разыскных мероприятий (в соответствии с ПП от 22.11.2023 № 1952), локальный акт о должностном лице, ответственном за защиту информации, и соглашение о взаимодействии с государственной системой обнаружения, предупреждения и ликвидации последствий компьютерных атак (ГосСОПКА) [2; 10];
  4. для систем, требующих аттестации, — иметь аттестат соответствия информационной системы требованиям защиты информации, не составляющей гостайну [2];
  5. быть включённым в общий реестр провайдеров хостинга (тот самый реестр Роскомнадзора) [3].

Проверка проходит через Минцифры совместно с ФСБ и ФСТЭК, а окончательное решение о включении провайдера в перечень оформляется отдельным актом Правительства [2].

Российская специфика: кто подпадает под требования

Не только ГИС: новая категория систем

До 1 сентября 2026 года периметр требований был относительно понятным: смотрели на формальный статус системы (ГИС/МИС) или на организационно-правовую форму оператора (ГУП, МУП, учреждение). ПП № 884 вводит четвёртую категорию — системы, которые:

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

Это типично «внутренние» системы: электронный документооборот госоргана, система кадрового учёта, финансово-бюджетная система для собственных нужд, система технической поддержки, внутренний портал. Раньше статус «не ГИС» часто снимал вопрос о хостинге вовсе — теперь для этой конкретной категории это не так.

Как трактовать формулировку «созданы в целях обеспечения деятельности»

Формулировка постановления не даёт закрытого перечня видов систем — она описывает функциональное назначение (организационное, информационное, документационное, финансовое, техническое обеспечение) применительно к деятельности самого государственного органа. Официальных разъяснений Минцифры или профильных ведомств по трактовке этой нормы на момент подготовки статьи в открытых источниках найти не удалось — это стоит иметь в виду при принятии решений и, где это возможно, запрашивать позицию курирующего ведомства или регулятора по конкретной системе.

Практические этапы проверки

Шаг 1. Составление реестра систем и владельцев

Первый и самый трудоёмкий шаг — собрать реестр, в котором по каждой системе зафиксированы:

  • название и краткое описание функций;
  • владелец (структурное подразделение) и ответственный за эксплуатацию;
  • статус: ГИС / МИС / система ГУП, МУП, учреждения / внутренняя система госоргана / иное;
  • фактическое место размещения — какой ЦОД, какой провайдер, юрлицо провайдера, договор;
  • используемые SaaS-сервисы и облачные компоненты (часто именно они выпадают из поля зрения);
  • результат проверки провайдера (в перечне / не в перечне / требует уточнения) и дата проверки — это поле и делает реестр практическим результатом всей работы, а не просто описью систем.

Без такого реестра невозможно ответить на вопрос применимости требований — система должна быть учтена «по факту», а не по формальному документу о её создании.

Шаг 2. Определение применимости требований к конкретной системе

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

  • является ли оператор системы государственным органом, ГУП, МУП или учреждением;
  • является ли система ГИС или МИС по формальному статусу;
  • если нет — создана ли она именно государственным органом и служит ли она целям организационного, информационного, документационного, финансового или технического обеспечения его собственной деятельности (новый критерий ПП № 884);
  • подключена ли система постоянно к интернету (требование ст. 13 149-ФЗ касается именно систем, «постоянно подключённых» к сети) [2].

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

Шаг 3. Проверка провайдера, услуги и субподрядчиков

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

  • запросить у провайдера точное юридическое наименование и ИНН, которые фигурируют в его карточке в перечне;
  • сверить их с действующей редакцией распоряжения о перечне (2753-р с учётом всех внесённых изменений) [6];
  • уточнить, какая именно услуга оказывается под требования — часто у провайдера в перечень включена не вся линейка услуг, а конкретный ЦОД или продукт;
  • отдельно проверить субподрядчиков: если провайдер размещает часть мощностей у другого хостера или партнёра, этот партнёр тоже должен быть в перечне применительно к соответствующей услуге, иначе цепочка размещения формально нарушает требование.

Шаг 4. Встраивание проверки в закупку, продление договора и подключение нового SaaS

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

  • закупка — техническое задание и критерии допуска участников закупки должны прямо требовать подтверждения включения провайдера (и субподрядчика, если он есть) в специальный перечень на дату подачи заявки;
  • продление действующего договора — статус провайдера в перечне может измениться (исключение возможно, например, при ликвидации, реорганизации без своевременного уведомления или несоблюдении требований защиты информации) [2], поэтому продление стоит сопровождать повторной проверкой;
  • подключение нового SaaS-сервиса — часто именно облачные сервисы для внутренних нужд (документооборот, HR, финансовый учёт) подключаются в обход классического ИТ-контура и без проверки размещения; это как раз тот случай, который прямо касается новой категории систем из ПП № 884.

Шаг 5. Перенос, резервное копирование и проверка системы после миграции

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

  • зафиксировать текущую архитектуру и зависимости системы (интеграции, каналы связи, точки входа);
  • согласовать план переноса с владельцем системы и, если применимо, с провайдером — включая окно недоступности;
  • обеспечить резервное копирование данных до начала переноса и хранение резервных копий отдельно от целевой инфраструктуры на период миграции;
  • после переноса — провести проверку целостности данных, работоспособности интеграций и соответствия нового размещения требованиям (адрес технических средств на территории РФ, соответствие провайдера актуальной редакции перечня);
  • задокументировать результат проверки в реестре систем — по итогам должна получиться строка «система → место размещения → провайдер → статус проверки провайдера → дата проверки».

Ограничения, ошибки и риски

  • Ошибка «по ярлыку». Самая частая ошибка — делать вывод о неприменимости требований только на основании того, что система формально не зарегистрирована как ГИС, без анализа её функционального назначения и статуса оператора.
  • Смешение реестра и перечня. Вторая по частоте ошибка — принимать включение провайдера в общий реестр Роскомнадзора за достаточное подтверждение допустимости размещения. Для систем, подпадающих под ПП № 1144/884, нужен именно специальный перечень, утверждённый распоряжением Правительства [3; 6].
  • Забытые SaaS и субподрядчики. Внутренние облачные сервисы, подключаемые в обход основного ИТ-контура, и субподрядчики провайдера — типичные слепые зоны при проверке.
  • Не подтверждено. Официальная методика или разъяснение по трактовке новой категории систем («созданные в целях обеспечения деятельности госоргана») в открытых источниках на дату подготовки статьи не найдены; при спорных случаях целесообразно запрашивать позицию курирующего ведомства.
  • Ограничение по теме. Специальные требования к специальному перечню провайдеров хостинга не распространяются на частный бизнес — это отдельная история от вопросов SLA с облачным провайдером; здесь речь именно о допустимости самого факта размещения информации в конкретной инфраструктуре.

Рекомендации по выбору решения

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

Вывод

ПП № 884 не вводит принципиально новую систему регулирования — оно расширяет периметр уже действующих правил на категорию систем, которая раньше часто оставалась вне поля зрения из-за формального статуса «не ГИС». Главный практический вывод: с 1 сентября 2026 года недостаточно смотреть на юридический статус системы — нужно смотреть на её функциональное назначение и на фактическое место размещения, сверяя провайдера именно со специальным перечнем, а не с общим реестром хостинга. Результатом такой проверки должен стать не разовый отчёт, а рабочий реестр систем и размещения, который обновляется при каждой закупке, продлении договора и подключении нового облачного сервиса.

Источники

[1] ppt.ru — Постановление Правительства РФ от 13.07.2026 № 884 — https://pravo.ppt.ru/postanovlenie/pravitelstvo/n-884-344437

[2] government.ru — Постановление Правительства РФ от 24.08.2024 № 1144 (текст Правил) — http://government.ru/docs/all/154892/

[3] garant.ru — ст. 13 Федерального закона от 27.07.2006 № 149-ФЗ — https://base.garant.ru/12148555/4d6cc5b8235f826b2c67847b967f8695/

[4] consultant.ru — ст. 13 149-ФЗ, действующая редакция — https://www.consultant.ru/document/cons_doc_LAW_61798/41021e09a57b2db1834266a1635d5a7a7a9e7ce9/

[5] consultant.ru — ст. 10.2-1 149-ФЗ «Особенности регулирования деятельности провайдера хостинга» — https://www.consultant.ru/document/cons_doc_LAW_61798/b99fcec60c7460838ae71cdd49a1bac4332fcb12/

[6] base.garant.ru — Распоряжение Правительства РФ от 04.10.2024 № 2753-р и история изменений — https://base.garant.ru/410487110/

[7] consultant.ru — карточка распоряжения № 2753-р, ред. от 22.07.2026 — https://www.consultant.ru/document/cons_doc_LAW_487378/

[8] d-russia.ru — «Утверждены правила включения провайдеров хостинга в реестр хостеров для размещения ГИС и ИС госучреждений» — https://d-russia.ru/utverzhdeny-pravila-vkljuchenija-provajderov-hostinga-v-reestr-hosterov-dlja-razmeshhenija-gis-i-is-gosuchrezhdenij.html

[9] d-russia.ru — «Минцифры официально наделили полномочиями для регулирования деятельности хостинг-провайдеров» — https://d-russia.ru/mincifry-oficialno-nadelili-polnomochijami-dlja-regulirovanija-dejatelnosti-hosting-provajderov.html

[10] company.rt.ru — «Ростелеком» вошёл в перечень провайдеров хостинга для ГИС — https://www.company.rt.ru/press/news/d472941/

[11] tadviser.ru — карточка «Реестр провайдеров хостинга в России» — https://www.tadviser.ru/index.php/Продукт:Реестр_провайдеров_хостинга_в_России

Быстрые вопросы и ответы

Требования касаются только государственных информационных систем?

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

Почему важно различать два перечня провайдеров?

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

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

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

Что проверять у облачного провайдера?

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

Как переносить систему без потери контроля?

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

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