С 1 сентября 2026 года государственную информационную систему можно строить на облачных технических средствах. Правила задало постановление Правительства РФ от 18.08.2026 № 1024. Они отвечают на вопрос, который до этого висел в воздухе: какой класс защищённости обязан иметь внешний сервис и что заказчик пишет в документацию о закупке. И кто отвечает, если что-то пойдёт не так. Отвечает заказчик.
Откуда взялись Правила и что они регулируют
Возможность использовать для государственных систем внешние технические средства, программы и базы данных ввёл 568-ФЗ. Он дополнил статью 13 149-ФЗ новой частью 5.1. Формулировка закона отсылала к порядку, который установит Правительство. Этот порядок и есть ПП № 1024. Постановление подписано 18 августа 2026 года, а Правила, утверждённые им, действуют с 1 сентября 2026 года: срок вступления в силу установлен пунктом 2 самого постановления и совпадает с датой, когда заработал целый пакет актов по защите государственных систем.
Кого касается
Правила адресованы тем, кто создаёт и эксплуатирует государственные информационные системы, а также иные информационные системы государственных органов, и именно эта пара категорий определяет границу их применения. Норма, во исполнение которой они приняты, это часть 5.1 статьи 13 149-ФЗ.
Обратите внимание на границу применения. Правила регулируют не любое использование облака госорганизацией. Речь про внешние средства для создания и функционирования информационной системы. Корпоративная почта или сервис видеосвязи, которые живут сами по себе и в состав системы не входят, под Правила не подпадают, и распространять требования пункта 5 на всю ИТ-инфраструктуру организации оснований нет. Но как только внешний сервис становится компонентом системы или обрабатывает информацию ограниченного доступа из неё, требования пункта 5 применяются полностью.
Что считается электронным сервисом
Правила пользуются собственным термином. Электронный сервис это получение услуг по предоставлению технических средств, программ для ЭВМ и баз данных, доступ к которым предоставляется с использованием информационно-телекоммуникационных сетей.
Определение шире привычного «облака». В него попадает аренда вычислительных мощностей и хранилищ, предоставляемое по сети прикладное программное обеспечение, а также внешние базы данных и справочники, к которым ваша система обращается по сети во время работы. Признак один: доступ идёт по сети, а средство используется для создания или функционирования системы. Форма договора и название услуги в прайсе поставщика значения не имеют: под Правила подпадает любая схема, где средство доступно по сети и участвует в работе вашей системы.
Требование первое: все компоненты на территории России
Подпункт «а» пункта 5 Правил: любые компоненты электронных сервисов, используемые для создания и функционирования государственных и иных информационных систем, должны размещаться на территории Российской Федерации. При эксплуатации не допускается использование размещённых за пределами России иных баз данных и технических средств.
Ключевое слово здесь «любые». Требование не сводится к тому, где стоит основной сервер, и охватывает всю обвязку сервиса, включая те её части, которые поставщик обычно не показывает в коммерческом предложении и держит во вспомогательной инфраструктуре. Служебная база, узел мониторинга, система управления ключами, резервная площадка: всё это компоненты сервиса. Схема, в которой основная нагрузка размещена в России, а телеметрия, каталог пользователей или система управления ключами обслуживаются площадкой за пределами страны, требованию подпункта «а» не соответствует, даже если сами данные систему формально не покидают.
Требование второе: класс защищённости сервиса не ниже класса системы
Это самый проверяемый пункт Правил. Читать его стоит дословно. Подпункт «б» пункта 5: защита информации в электронном сервисе, в котором обрабатывается информация ограниченного доступа из государственной информационной системы, должна соответствовать классу защищённости, определённому для этой системы или её сегмента, или превышать такой класс.
Смысл простой. Если ваша система отнесена к первому классу защищённости, то подключить к ней сервис второго или третьего класса нельзя, и это прямое нарушение Правил, а не риск, который можно закрыть компенсирующими мерами. Сравнивать нужно классы защищённости, и сравнивать именно с классом вашей системы или того сегмента, где сервис используется. Общие слова о защищённости провайдера и наличие у него сертификатов вообще этот вопрос не закрывают.
Отсюда следует порядок действий. Сначала класс. Потом сервис. При обратной последовательности выбранный сервис может не подойти, когда закупка уже проведена.
Здесь есть развилка, которую легко пропустить. Требование про класс защищённости адресовано сервисам из подпункта «а» пункта 3, то есть тем, что входят в состав системы как её элементы при создании. Для сервисов из подпункта «б», обеспечивающих функционирование уже введённой в эксплуатацию системы, подпункт «в» пункта 5 формулирует требование иначе: уровень защищённости сервиса должен соответствовать требованиям о защите информации, установленным в отношении обрабатываемой им информации. К какой из двух категорий относится ваш случай, стоит понять до разговора с поставщиком.
Есть и четвёртое требование, о котором забывают, потому что оно не про защиту. Подпункт «г» пункта 5: уровень доступности и отказоустойчивости сервиса не должен приводить к нарушению доступности или надёжности, определённой документацией на вашу систему. SLA поставщика сверяется с требованиями к вашей системе, а не принимается как есть.
Что обязан делать пользователь сервиса
Пункт 4 Правил перечисляет пять обязанностей организации, которая использует сервис в своей системе.
- Соблюдать требования о защите информации по статье 16 149-ФЗ. Это общее условие, продублированное в пункте 2 Правил.
- Обеспечить безопасное взаимодействие системы с сервисом: каналы связи по требованиям о защите информации, контроль состава передаваемых данных и недопущение передачи информации ограниченного доступа, если сервис для её обработки не предназначен.
- Предусмотреть при закупке требования к регламенту взаимодействия в документации о закупке и в проекте контракта.
- Сформировать и утвердить сам регламент взаимодействия, о котором говорит подпункт «в». Это отдельная обязанность по подпункту «г»: заложить требования в закупку мало, документ нужно принять.
- Контролировать выполнение требований пункта 5, в том числе для сервисов, предоставляемых безвозмездно по соглашениям и офертам поставщиков. Бесплатный сервис из-под Правил не выпадает.
Вторая обязанность на практике означает вот что. Нужно знать состав данных, уходящих в сервис. И уметь этот состав контролировать. Формулировка про недопущение передачи информации ограниченного доступа предполагает, что вы понимаете назначение сервиса и оно зафиксировано документально. Маркетингового описания здесь мало.
Регламент взаимодействия попадает в закупочную документацию
Подпункт «в» пункта 4 забывают чаще других, потому что он относится к закупочным процедурам и в чек-листы по защите информации обычно не попадает. Требования к регламенту взаимодействия по вопросам функционирования сервиса нужно предусмотреть в документации о закупке и в проекте контракта.
Значит, регламент нельзя дописать после заключения контракта. Его требования формулируются до объявления закупки. По пункту 6 Правил взаимодействие пользователя и поставщика идёт в сроки и порядке, установленные регламентом. Отдельно оговариваются действия сторон при сбоях и при нарушениях защиты информации, обрабатываемой сервисом. Если этих условий в контракте нет, требовать их исполнения будет не на основании чего, и разбираться со сбоем придётся в режиме переговоров без опоры на документ.
Что должно быть в регламенте взаимодействия
Пункт 6 задаёт три предмета регламента. Первый: сроки и порядок взаимодействия пользователя сервиса и его поставщика. Второй: действия сторон при сбоях. Третий: действия при нарушениях защиты информации, которая обрабатывается сервисом.
Последний предмет важнее, чем кажется. Он предполагает, что стороны заранее договорились, что именно считать нарушением защиты информации, кто кого уведомляет, в какой срок и что делает каждая сторона после уведомления. За инциденты в государственной системе отчитывается её оператор. Значит, срок уведомления со стороны поставщика должен быть таким, чтобы оператор государственной системы успевал выполнить собственные обязанности по информированию регулятора и узнавал о нарушении первым.
Требования к регламенту включаются в закупочную документацию, когда поставщик ещё не выбран. Практический выход простой: описывайте требования к содержанию регламента, оставляя конкретные формулировки на этап работы с выбранным поставщиком.
Как Правила соотносятся с общими требованиями к защите информации
Правила надстраиваются над действующими требованиями о защите информации и работают вместе с ними. Пункт 2 ставит общим условием использования сервисов соблюдение статьи 16 149-ФЗ. Подпункт «а» пункта 4 повторяет эту обязанность применительно к пользователю сервиса.
Вывод простой. Внешний сервис не сокращает объём ваших обязанностей по защите системы: класс защищённости определяется прежним порядком, меры защиты внедряются в прежнем объёме, а Правила добавляются сверху. Правила добавляют сверху три условия: размещение компонентов в России, класс сервиса не ниже класса системы, регламент взаимодействия в закупке.
Отвечает заказчик
Пункт 7 Правил: ответственность за их соблюдение несут руководители и уполномоченные лица пользователя электронного сервиса. Поставщик услуги в этой норме не назван. Совсем.
Это разворачивает привычную логику «мы перенесли систему в аттестованное облако, теперь за защиту отвечает облако». Правила устроены иначе. Провайдер даёт сервис. За соответствие требованиям отвечает организация, которая эксплуатирует государственную систему. Договорные гарантии провайдера полезны и нужны, они дисциплинируют обе стороны и дают основание для претензий, но ответственность по Правилам они не переносят и не делят между заказчиком и поставщиком.
Что сделать до закупки облачного сервиса
- Определить класс защищённости системы или того сегмента, где предполагается использовать сервис. Без неё остальные шаги бессмысленны.
- Запросить у поставщика класс защищённости его сервиса и подтверждающие документы. Сверить с классом своей системы по правилу «не ниже».
- Проверить размещение всех компонентов сервиса на территории России, включая вспомогательные.
- Определить состав данных, которые будут передаваться в сервис, и способ контроля этого состава.
- Сформулировать требования к регламенту взаимодействия и включить их в документацию о закупке и проект контракта до объявления закупки.
- Зафиксировать порядок действий при сбоях и при нарушениях защиты информации в сервисе.
Коротко: нормы и что они требуют
| Норма | Что требует |
|---|
| ч. 5.1 ст. 13 149-ФЗ | разрешает использовать внешние средства для ГИС в порядке, установленном Правительством |
| п. 2 постановления № 1024 | Правила действуют с 1 сентября 2026 года |
| подп. «а» п. 5 Правил | любые компоненты сервиса на территории России |
| подп. «б» п. 5 Правил | класс защищённости сервиса не ниже класса системы или её сегмента |
| подп. «б» п. 4 Правил | контроль состава передаваемых данных, защищённые каналы |
| подп. «в» п. 4 Правил | требования к регламенту в документацию о закупке и проект контракта |
| подп. «г» п. 4 Правил | сформировать и утвердить регламент взаимодействия |
| подп. «д» п. 4 Правил | контроль выполнения требований п. 5, включая безвозмездные сервисы |
| подп. «в» п. 5 Правил | уровень защищённости сервиса для уже эксплуатируемой системы |
| подп. «г» п. 5 Правил | доступность сервиса не ниже требуемой для системы |
| п. 6 Правил | сроки и порядок взаимодействия, действия при сбоях и нарушениях защиты |
| п. 7 Правил | ответственность несут руководители и уполномоченные лица пользователя сервиса |
Типичные ошибки
- Сравнивать сертификаты вместо классов. Сертифицированные средства защиты у провайдера не подтверждают соответствие класса его сервиса классу вашей системы.
- Считать, что требование касается только основной площадки. Норма говорит о любых компонентах сервиса.
- Оставлять регламент на потом. После заключения контракта требования к нему в документацию уже не вернуть.
- Переносить ответственность на провайдера. Пункт 7 закрепляет её за руководителями организации-пользователя.
- Путать ПП № 1024 с ПП № 1007. Второе постановление из того же пакета регулирует стандарты и учёт ИТ-активов информационных систем государственных органов. К защите информации оно отношения не имеет.
Что делать после
Требование к классу защищённости сервиса работает только тогда, когда класс вашей собственной системы определён и подтверждён. Порядок отнесения системы к классу и состав мер защиты задаёт приказ ФСТЭК России № 117. Об этом наш разбор требований к защите государственных информационных систем, а сами работы мы ведём как отдельную услугу. Если система подлежит аттестации, посмотрите изменения в Порядке аттестации по приказу ФСТЭК № 60: они вступили в силу в тот же день. Общая картина по всем актам этой даты в новости о том, что вступает в силу 1 сентября 2026.
Проверим облачный сервис до закупки
«Кредо-С» лицензиат ФСТЭК России. Определим класс защищённости вашей системы, сверим с ним класс сервиса и поможем сформулировать требования к регламенту взаимодействия для документации о закупке.
