Электронные сервисы для государственных ИС с 1 сентября 2026 года: что добавить в ТЗ, SLA и договор с подрядчиком

Как закупить сервис так, чтобы не остаться без данных, без SLA и без возможности сменить подрядчика

С 1 сентября 2026 года действуют изменения, внесённые законом № 568-ФЗ в закон об информации. Если организация создаёт или сопровождает государственную информационную систему, важнее всего разобраться в своей роли: кто владелец системы, кто оператор, а что поручено подрядчику. После этого требования переводятся в конкретные документы и процедуры — техническое задание, права доступа, журнал изменений, резервное копирование, проверку восстановления и условия приёмки. Не всякое требование закона автоматически относится к любой корпоративной системе, поэтому сначала проверяйте область применения нормы.

Почему это актуально именно сейчас

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

• вступает в силу 568-ФЗ, официально закрепляющий обязанность операторов ГИС взаимодействовать с ГосСОПКА [1][3];
• с 1 марта 2026 года действует приказ ФСТЭК № 117 с обновлёнными требованиями защиты, включая облачные, контейнерные, веб-технологии, API и интернет вещей; обязательный пентест при аттестации вводит отдельный приказ ФСТЭК № 60 с 1 сентября 2026 года и только для ИС 1–2 классов, подключённых к интернету или взаимодействующих с иными ИС, с предусмотренным исключением для защищённых соединений;
• легализовано использование облачных технологий для ГИС, но по правилам, которые устанавливает Правительство, а не сам оператор или подрядчик [5].

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

Кого касается

Правила распространяются не только на органы власти напрямую. В зоне внимания:

• государственные и муниципальные заказчики — операторы ГИС и иных информационных систем госорганов;
• ГУПы и государственные учреждения — в части принадлежащих им информационных систем; сама по себе закупка по 223-ФЗ или форма госкорпорации ещё не означает автоматического применения всех перечисленных требований;
• интеграторы и разработчики, создающие или дорабатывающие такие системы;
• SaaS- и cloud-поставщики, чья инфраструктура используется для размещения ГИС или для обработки данных, поступающих из ГИС.

Что меняется с точки зрения закона, а что — вопрос договорной практики

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

Слой 1 — обязательные требования закона и подзаконных актов. Их нельзя «согласовать иначе» с подрядчиком:

• 568-ФЗ вводит разделение государственных информационных систем на федеральные и региональные, а также обязанность операторов подключаться к системе защиты от кибератак [1][5];
• 149-ФЗ содержит требование о размещении технических средств информационной системы на территории Российской Федерации — контроль осуществляется через реестр территориального размещения объектов контроля [6];
• Постановление Правительства № 676 устанавливает порядок создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации ГИС и прямо указывает: ввод системы в эксплуатацию не допускается при отсутствии действующего аттестата соответствия требованиям безопасности информации, а также при отсутствии сведений в реестре территориального размещения технических средств [7][8];
• приказ ФСТЭК № 117 действует с 1 марта 2026 года и обновляет требования защиты, в том числе для облачных и контейнерных сред; обязательное тестирование на проникновение при аттестации отдельных ИС 1–2 классов вводит приказ № 60 с 1 сентября 2026 года.

Слой 2 — параметры, которые стороны конкретизируют в договоре. С 1 сентября 2026 года постановление Правительства № 1024 уже требует включать порядок действий при сбоях и инцидентах, разграничение ответственности, допустимое время восстановления, резервное копирование, доступ пользователя к данным, их передачу по окончании услуг и мониторинг. Стороны по-прежнему определяют конкретные значения RTO/RPO, форматы передачи, глубину аудита и условия о принадлежности копий.

Что должно попасть в ТЗ ещё до закупки

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

В ТЗ на электронный сервис для ГИС до объявления закупки стоит включить:

• статус системы — федеральная или региональная ГИС [5];
• обязательное указание, что технические средства должны размещаться на территории РФ, со ссылкой на необходимость внесения сведений в реестр территориального размещения [6];
• требование о наличии (или получении к определённому сроку) аттестата соответствия требованиям безопасности информации [7][8];
• если планируется облачная инфраструктура — требование об использовании аттестованного облака или государственной единой облачной платформы (ГЕОП) с учётом требований к информационной безопасности, утверждённых Минцифры [10][11];
• конкретные, измеримые метрики доступности и восстановления;
• порядок и периодичность резервного копирования, срок хранения копий и указание, что копии — собственность заказчика;
• обязанность подрядчика взаимодействовать с ГосСОПКА и соблюдать сроки уведомления об инцидентах;
• условия выгрузки данных и формат передачи при расторжении договора;
• право заказчика на аудит и технический контроль подрядчика в период действия договора.

SLA: время реакции, время восстановления и что считать аварией

Государственный (и в целом B2G/B2B) SLA обычно проваливается не потому, что в договоре нет раздела «SLA», а потому что формулировки в нём слишком общие. Практический подход — фиксировать три отдельные метрики:

1. Время реакции (Response Time) — интервал от регистрации обращения до подтверждения подрядчиком, что заявка принята.
2. Время восстановления (Recovery Time / RTO) — максимальное время от момента аварии до восстановления работоспособности сервиса.
3. Точка восстановления (RPO) — допустимый объём потери данных, выражаемый во времени; напрямую связан с периодичностью резервного копирования.

Отдельная и часто упускаемая часть SLA — чёткая граница между аварией и обычным обращением в техподдержку:

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

Где физически должны находиться данные и технические средства

Требование о размещении технических средств информационных систем на территории РФ закреплено в 149-ФЗ и контролируется через реестр территориального размещения объектов контроля [6]. Постановление № 676 прямо называет отсутствие сведений в этом реестре одним из оснований, по которым система не может быть введена в эксплуатацию [8].

Практический вывод для ТЗ:

• указать конкретную юрисдикцию и, если применимо, конкретный ЦОД;
• прописать обязанность подрядчика предоставить сведения, необходимые для внесения объекта в реестр [6];
• для облачной инфраструктуры — указать использование аттестованного облака либо ГЕОП, соответствующей утверждённым Минцифры требованиям к ИБ [10][11];
• закрепить запрет на перенос технических средств или данных за пределы согласованной юрисдикции без согласия заказчика.

Резервные копии: кому они принадлежат и как заказчик может это проверить

Показательный пример требований к оператору ГИС — обязанность обеспечивать резервное копирование программного обеспечения и информации, а также её долгосрочное хранение (в конкретном рассмотренном постановлении — не менее 5 лет со дня размещения информации), наряду с постоянным мониторингом состояния системы [12]. Дополнительный принцип, применяемый в требованиях ФСТЭК к защите персональных данных, — раздельное (в том числе географическое) хранение резервных копий вне основной информационной системы [13].

Что стоит перенести в договор:

• прямо указать, что резервные копии — собственность заказчика, а не подрядчика или облачного провайдера;
• зафиксировать периодичность резервного копирования и минимальный срок хранения;
• предусмотреть хранение копий на средствах, отдельных от основной ИС [13];
• закрепить право заказчика периодически запрашивать подтверждение факта создания копий и право инициировать тестовое восстановление без предупреждения подрядчика заранее.

Как заказчик получит данные при расторжении договора и в каком формате

Это один из наименее прямо регулируемых законом моментов, что делает договор единственным реальным механизмом защиты. Стоит закрепить:

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

Что считать инцидентом информационной безопасности и за сколько о нём уведомлять

Термин имеет чёткое определение в национальных стандартах. Согласно ГОСТ Р ИСО/МЭК 27001, событие информационной безопасности — идентифицированное возникновение состояния системы, услуги или сети, указывающее на возможное нарушение политики ИБ, отказ защитных мер или возникновение ранее неизвестной ситуации, связанной с безопасностью; инцидент информационной безопасности — любое непредвиденное или нежелательное событие, которое может нарушить деятельность организации или информационную безопасность [14]. ГОСТ Р 59709-2022 отдельно вводит понятие компьютерного инцидента применительно к ГосСОПКА как подмножества инцидентов ИБ, характеризующегося подтверждённым фактом компьютерной атаки [15].

Сроки уведомления регулятора закреплены нормативно:

• для операторов, перечисленных в части 7 статьи 16 закона № 149-ФЗ, приказ ФСБ № 297 с 1 сентября 2026 года устанавливает срок не позднее 24 часов с момента обнаружения; для субъектов КИИ параллельно применяются специальные правила;
• для значимых объектов критической информационной инфраструктуры новый порядок (приказ ФСБ № 547 от 25.12.2025) сокращает срок до 3 часов с момента обнаружения [18].

Для договора это означает: подрядчик обязан уведомить заказчика о подозрении на инцидент значительно быстрее, чем истекают регуляторные сроки — иначе заказчик не успеет соблюсти собственную обязанность перед НКЦКИ. Разумная практика — закреплять внутренний срок уведомления заказчика подрядчиком в пределах 1–2 часов.

Право заказчика на аудит и контроль подрядчика

Формальное наличие пункта «заказчик вправе проводить аудит» часто не работает без детализации. Стоит прописать:

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

Приказ ФСТЭК № 60 вводит с 1 сентября 2026 года тестирование на проникновение при аттестации ИС 1–2 классов, подключённых к интернету или взаимодействующих с иными ИС, с установленным исключением для отдельных защищённых соединений. Для подпадающей под правило системы в договоре стоит согласовать подготовку к испытаниям и сроки устранения выявленных уязвимостей.

Готовый чек-лист для ТЗ и договора

• статус ГИС (федеральная/региональная) и применимый порядок ввода в эксплуатацию;
• размещение технических средств на территории РФ с указанием юрисдикции/ЦОДа и обязанностью подтвердить сведения для реестра;
• наличие или срок получения аттестата соответствия;
• для облачной инфраструктуры — аттестованное облако либо ГЕОП с соблюдением требований к ИБ;
• раздельные метрики SLA: время реакции, RTO, RPO по категориям критичности;
• письменное разграничение «аварии» и «обращения в техподдержку»;
• периодичность резервного копирования, срок хранения, принадлежность копий заказчику;
• право на плановое и внеплановое тестовое восстановление из копии;
• полный перечень данных для выгрузки при расторжении, срок и открытый формат передачи;
• обязательство уничтожить копии данных после передачи с подтверждающим актом;
• определение инцидента ИБ со ссылкой на ГОСТ и внутренний срок уведомления заказчика короче регуляторных 24 или 3 часов;
• право на плановый и внеплановый аудит с последствиями его непрохождения.

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

• SLA формулируется одной общей фразой без разделения на время реакции, RTO и RPO;
• требования к размещению и резервному копированию появляются в договоре, а не в ТЗ на этапе закупки;
• в договоре нет пункта о принадлежности резервных копий заказчику;
• формат выгрузки при расторжении не оговорён заранее — данные технически «предоставлены», но нечитаемы без дорогостоящей обратной инженерии;
• срок внутреннего уведомления заказчика подрядчиком превышает регуляторные сроки уведомления ГосСОПКА;
• право на аудит закреплено формально, без конкретики.

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

Как может помочь «Пятый фактор»

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

Вывод

568-ФЗ не пишет SLA и договор за заказчика — он закрепляет то, что де-факто уже требовалось. Реальная защита интересов заказчика происходит в тексте технического задания и договора: там определяются цифры RTO и RPO, судьба резервных копий, формат данных при расторжении и объём права на аудит.

Источники

[1] alta.ru — Федеральный закон от 29.12.2025 № 568-ФЗ — https://www.alta.ru/tamdoc/25fz0568/

[2] garant.ru — Федеральный закон от 29.12.2025 № 568-ФЗ (ПРАЙМ) — https://www.garant.ru/products/ipo/prime/doc/413278472/

[3] tadviser.ru — Требования к защите информации в государственных информсистемах — https://www.tadviser.ru/index.php/Статья:Требования_к_защите_информации_в_государственных_информсистемах

[4] securitymedia.org — Аттестация ГИС и КИИ по новым правилам 2026 (Приказ ФСТЭК №117) — https://securitymedia.org/info/attestatsiya-gis-i-kii-po-novym-pravilam-2026-polnyy-razbor-prikaza-fstek-117.html

[5] ppt.ru — Федеральный закон от 29.12.2025 № 568-ФЗ о новых правилах для ГИС — https://ppt.ru/obzory/vstupaet-v-silu/federalnyy-zakon-29-12-2025-568-fz-o-novykh-pravilakh-dlya-gosudarstvennykh-informatsionnykh-sistem

[6] normativ.kontur.ru — ПП РФ от 06.07.2015 №676 (реестр территориального размещения по ПП №675) — https://normativ.kontur.ru/document?documentId=334191&moduleId=1

[7] hub.zlonov.ru — ПП РФ №676 от 06.07.2015 — https://hub.zlonov.ru/laws/Постановления-Правительства-РФ/ПП-676-от-06.07.2015

[8] garant.ru — ПП РФ от 06.07.2015 №676 (основания отказа во вводе в эксплуатацию) — https://base.garant.ru/71120998/

[9] consultant.ru — Обновление требований ФСТЭК с 1 марта 2026 г. — https://www.consultant.ru/law/hotdocs/89683.html

[10] cyberkit.tech — Обзор изменений в законодательстве за май 2026 года (Приказ Минцифры №1106, ГЕОП) — https://cyberkit.tech/blog/overviewmay2026

[11] anti-malware.ru — Аттестованное облако: требования, провайдеры и выбор для госсектора — https://www.anti-malware.ru/analytics/Market_Analysis/Certified-cloud

[12] government.ru — Постановление Правительства РФ от 20.05.2022 №913 — http://government.ru/docs/all/141106/?page=2

[13] fstec21.blogspot.com — Приказ ФСТЭК №21: ОДТ.4, периодическое резервное копирование — https://fstec21.blogspot.com/2017/08/periodic-backup-personal-data-on-backup.html

[14] docs.cntd.ru — ГОСТ Р ИСО/МЭК 27001-2006 — http://docs.cntd.ru/document/gost-r-iso-mek-27001-2006

[15] garant.ru — ГОСТ Р 59709-2022 — https://base.garant.ru/406006283/

[16] cert.gov.ru — Приказ ФСБ России от 24.07.2018 №367 — https://cert.gov.ru/materialy/pravovye-osnovaniya/prikaz-fsb-rossii-ot-24-07-2018-g-367-ob-utverzhdenii-perechnya-informatsii-predstavlyaemoy-v-gossop/

[17] regulhub.kaspersky.ru — Приказ №367 (порядок и сроки представления информации в ГосСОПКА) — https://regulhub.kaspersky.ru/decrees/prikaz-367

[18] credos.ru — Взаимодействие с НКЦКИ и ГосСОПКА: порядок и сроки (Приказ ФСБ №547) — https://www.credos.ru/articles-info/vzaimodeystvie-nkcki-poryadok/