Государственные системы на единой технологической платформе: что изменится для заказчиков и подрядчиков
Содержание 22 разделов
Единый порядок создания, эксплуатации и допуска — вместо ведомственной самостоятельности
С 1 сентября 2027 года вступает в силу Федеральный закон от 10.06.2026 №166-ФЗ, который впервые на уровне закона закрепляет единую технологическую платформу для создания, развития и эксплуатации государственных, муниципальных и иных информационных систем [1][2]. Документ был принят Государственной думой 26 мая 2026 года и одобрен Советом Федерации 3 июня 2026 года [2]. С момента вступления закона в силу статус технологической платформы автоматически получает уже действующая единая цифровая платформа «ГосТех» [1][11], на которой на данный момент работает более трети федеральных органов власти и ряд пилотных региональных проектов [12]. Для заказчиков это означает обязательную оценку целесообразности разработки «с нуля» вместо использования готовых компонентов; для подрядчиков — новый статус «участника» или «владельца компонентов» платформы с конкретными обязанностями по защите информации, непрерывности сервисов и прохождению приёмки.
Почему это важно именно сейчас
До сих пор каждое ведомство и регион в основном строило свою информационную систему самостоятельно: выбирало архитектуру, закупало инфраструктуру, заключало отдельные контракты на поддержку. Такой подход давал гибкость, но приводил к дублированию функционала, удорожанию межведомственной интеграции и росту расходов на сопровождение множества параллельных инфраструктур [9]. Теперь на уровне федерального закона закрепляется противоположный принцип: не отдельная система, а общая технологическая среда становится объектом регулирования [9]. Для интеграторов и разработчиков, работающих с госзаказчиками, это означает изменение самого предмета проектов — от «создать систему под ключ» к «сконфигурировать её на платформе из готовых компонентов» [10].
Что такое технологическая платформа по 166-ФЗ
От отдельных ГИС — к единой среде
Закон устанавливает организационно-правовые основы создания, развития и эксплуатации государственных, муниципальных и иных информационных систем на технологической платформе [3]. Сама платформа определена широко: в неё входят информационные технологии, базы данных, технические, программные и программно-аппаратные средства, которые предоставляются участникам платформы через уполномоченный орган [4].
Конкретные требования к компонентам платформы, порядок оценки целесообразности новых разработок, права и обязанности сторон, а также ответственность каждого участника закон делегирует отдельному Положению, которое утверждает Правительство РФ [4]. Это значит, что закон задаёт рамку, а практическое содержание реформы будет формироваться позже — через подзаконные акты, которые нужно отслеживать отдельно.
Кто есть кто: уполномоченный орган, владельцы компонентов, участники
Закон вводит четыре типа субъектов с разным объёмом ответственности.
Уполномоченный орган — федеральный орган исполнительной власти по выработке политики в сфере ИТ (фактически Минцифры). Он оценивает целесообразность создания новых систем, заключает договоры с владельцами компонентов и соглашения с участниками платформы, контролирует их исполнение, организует оценку защищённости платформы и обеспечивает её непрерывное взаимодействие с государственной системой обнаружения и предупреждения компьютерных атак [5]. Отдельные его полномочия правительство может передать специально определённой организации [5].
Владельцы компонентов — самостоятельный правовой статус, которого раньше в законодательстве не было: не владелец информационной системы и не оператор, а именно владелец технической и программной инфраструктуры, на которой строятся чужие системы [10].
Участники платформы — заказчики: органы власти всех уровней плюс, отдельно, коммерческие и некоммерческие организации, допущенные решением правительственной комиссии [6].
Какие системы обязаны использовать платформу, а какие — нет
Что обязательно
Сам закон не формулирует единой безусловной обязанности «все госсистемы переносить на платформу» — вместо этого он вводит презумпцию использования платформы: перед созданием новой системы уполномоченный орган и заказчик обязаны совместно оценить экономическую и технологическую целесообразность её создания именно на платформе [5][6], то есть по умолчанию нужно обосновывать, почему существующие компоненты не подходят, а не наоборот. Прямая обязанность создавать систему на платформе без права выбора закреплена только для отдельных категорий — см. ниже.
Жёсткие исключения
Закон прямо выводит из-под платформенной модели системы, содержащие определённые категории чувствительной информации. На платформе не могут создаваться, развиваться и эксплуатироваться системы, содержащие сведения, составляющие государственную тайну, служебную тайну в области обороны, тайну следствия и судопроизводства, а также сведения о лицах, в отношении которых применяются меры государственной защиты, и о самих этих мерах [4]. Это единственная категория систем, для которых платформенная модель закрыта полностью и безусловно.
Особый порядок для чувствительных ведомств
Отдельно закон описывает категорию систем, для которых переход на платформу не запрещён и не является выбором заказчика — решение принимается индивидуально, на уровне руководителя ведомства или высшего должностного лица субъекта. Речь идёт об объектах критической информационной инфраструктуры, системах федеральных органов исполнительной власти, руководство которыми осуществляет Президент РФ (и подведомственных им служб и агентств), системах Федеральной налоговой службы, а также системах органов власти Москвы [6]. Для проектной команды это означает, что до старта работ по такой системе нужно выяснить, принято ли соответствующее решение руководителя, — иначе формального основания для использования платформенных компонентов может не быть вовсе.
Как подрядчик получает доступ и допуск
Путь коммерческой организации: от решения комиссии до соглашения
Для коммерческой или некоммерческой организации участие в платформе не наступает автоматически. Правительственная комиссия по представлению уполномоченного органа принимает отдельное решение о допуске такой организации в качестве участника, а состав и порядок работы комиссии утверждает Правительство [6]. После допуска с участником заключается соглашение о предоставлении компонентов платформы; типовую форму и порядок заключения такого соглашения также определит Правительство [8]. Для таких организаций Правительство вправе установить дополнительные требования — вплоть до соображений защиты конституционного строя и безопасности государства — а также определить случаи и размер платы за пользование компонентами платформы [6].
Отдельная категория подрядчиков — потенциальные владельцы компонентов. Ими могут быть только российские юридические лица, находящиеся под контролем РФ, субъекта РФ, муниципального образования или гражданина РФ без иностранного гражданства (с правом распоряжаться более чем 50% голосов), при этом располагающие инфраструктурой, которая соответствует требованиям к государственным информационным системам, к защите персональных данных и — если речь о значимых объектах КИИ — требованиям безопасности критической инфраструктуры [7]. Правительство вправе устанавливать дополнительные требования к таким организациям [7].
Тестовый стенд и каталог цифровых продуктов
Ещё до принятия закона на практике «ГосТеха» сложился рабочий механизм допуска разработчиков, который, вероятнее всего, продолжит применяться и после вступления закона в силу. Формальной сертификации подрядчиков не предусмотрено; вместо неё поставщику на время подготовки и прохождения технической проверки цифрового продукта предоставляется тестовый стенд («песочница») [15]. Включение продукта в каталог цифровых продуктов платформы само по себе не создаёт для поставщика гражданско-правовых обязательств — оно сопровождается декларацией о соответствии продукта требованиям платформы [14]. Для оценки объёма собственных затрат на создание или доработку системы на платформе в открытом доступе размещается техническая документация о сервисах платформы, и по мере накопления опыта эксплуатации объём документации будет расширяться [13].
Кто за что отвечает: инфраструктура, приложение, данные
Закон впервые распределяет ответственность между тремя разными субъектами, а не концентрирует её на одном заказчике, как было в модели госконтракта. За работоспособность и безопасность самой технологической инфраструктуры отвечают владельцы компонентов — они обязаны предоставлять компоненты по договорам с уполномоченным органом, обеспечивать защиту информации в пределах своих полномочий и взаимодействие с государственной системой обнаружения компьютерных атак [7]. За разработку приложения, данные и корректность их обработки в рамках создаваемой системы отвечает участник платформы (заказчик) — он обязан использовать компоненты в соответствии с законодательством об информации и персональных данных, а при создании значимого объекта КИИ — и с требованиями безопасности критической инфраструктуры [6]. Отдельно и владельцы компонентов, и участники платформы обязаны обеспечивать непрерывность функционирования систем — это закреплено как самостоятельное обязательство каждой из сторон [7].
На практике для подрядчика это означает, что при заключении договора нужно чётко зафиксировать в приложении к контракту или ТЗ, какая часть стека — зона ответственности оператора платформы (инфраструктура, сеть, базовые сервисы), а какая — зона ответственности разработчика (бизнес-логика приложения, качество данных, корректность интеграций).
Как строится приёмка
Приёмка системы, создаваемой на технологической платформе, складывается из нескольких обязательных элементов, часть которых унаследована от действующей практики «ГосТеха», а часть — прямо предусмотрена законом.
- Оценка целесообразности до начала разработки. Совместно с уполномоченным органом заказчик обязан подтвердить, что задачу нельзя решить существующими компонентами платформы, — это происходит до заключения контракта, а не на этапе сдачи результата [5][6].
- Техническая проверка продукта на тестовом стенде. Поставщик апробирует решение на выделенной «песочнице» до того, как продукт попадёт в контур эксплуатации [15].
- Декларация о соответствии и включение в каталог. По итогам проверки продукт вносится в каталог цифровых продуктов платформы вместе с декларацией поставщика о соответствии требованиям платформы [14].
- Аттестация ГИС. Для государственных информационных систем аттестация остаётся обязательным условием ввода в эксплуатацию: она подтверждает способность системы противостоять внешним и внутренним угрозам и проводится с учётом класса защищённости, определяемого по уровню значимости обрабатываемой информации и масштабу системы [18].
- Подписание соглашения о предоставлении компонентов. Формальным основанием для промышленной эксплуатации служит соглашение между уполномоченным органом и участником платформы, типовую форму которого утвердит Правительство [8].
Для подрядчика практический вывод — закладывать в план проекта все пять этапов заранее, а не только финальную техническую сдачу: значительная часть согласований (пп. 1 и 5) происходит на организационном, а не техническом уровне и может занимать больше времени, чем сама разработка.
Как выполняются требования ИБ
Требования по информационной безопасности к государственным информационным системам регулируются отдельно от закона о платформе и не зависят от того, работает система на единой платформе или автономно. С 1 марта 2026 года действует приказ ФСТЭК России от 11.04.2025 №117, который изменил правила аттестации ГИС и объектов КИИ [16]. Помимо классической аттестации приказ вводит регулярный расчёт показателя состояния технической защищённости, который нужно проводить не реже раза в полгода по отдельной утверждённой методике [17]. Отдельный блок требований касается работы именно с подрядными организациями: теперь подрядчики обязаны соблюдать политики и организационно-распорядительные документы самого оператора информационной системы, а не только собственные внутренние регламенты [16]. Для подрядчика это значит, что перед началом работ стоит запросить у заказчика действующую модель угроз и внутренние регламенты по ИБ — соответствие им станет частью приёмки.
Если создаваемая система относится к объектам критической информационной инфраструктуры, добавляется ещё один пласт требований. С 1 января 2025 года для перечисленных в Указе Президента РФ № 250 органов и организаций, включая субъектов КИИ, действует запрет на использование средств защиты информации из недружественных государств и продукции связанных с ними производителей. Это не общий запрет на любые иностранные средства и не правило для каждой системы только по признаку её отнесения к КИИ [22]. Приказ №117 при этом даёт регулятору право отзыва сертификата средства защиты при обнаружении уязвимостей ещё до официального отчёта вендора [20] — это стоит учитывать при выборе конкретных средств защиты информации для проекта.
Как переносить существующую систему на платформу
Закон не описывает пошаговый регламент миграции — этот вопрос также отнесён к будущему Положению Правительства. Но по общей логике облачной и платформенной миграции процесс обычно строится волнами: перенос функциональности поэтапными группами, а не «одним рывком», с обязательным циклом проверок после каждой волны — функциональное тестирование, нагрузочное тестирование, проверка безопасности конфигурации и соблюдения SLA [23]. После технического переноса обычно следует самая длительная фаза — оптимизация и стабилизация, которая может занимать месяцы [23].
Применительно к переходу на единую технологическую платформу к этому добавляются два обязательных шага, прямо предусмотренных законом: совместная с уполномоченным органом оценка экономической и технологической целесообразности сохранения или переноса системы [6], а также заключение соглашения о предоставлении компонентов до фактического начала работ [8]. Практический вывод для заказчика: закладывать в план миграции время не только на техническую часть, но и на согласовательные процедуры, которые пока формально не описаны детально.
Как минимизировать жёсткую зависимость от конкретных платформенных компонентов
Прямых опубликованных рекомендаций именно по архитектуре, снижающей зависимость от компонентов «ГосТеха», в открытых источниках найти не удалось — эта практика ещё формируется вместе с самим законом. Однако общие принципы снижения вендор-лока, которые сейчас применяются при импортозамещении корпоративных систем, применимы и здесь. Один из подходов, описанных отраслевыми экспертами, предполагает разделение проекта на несколько независимых слоёв: сохранение модели данных и графа связей отдельно от бизнес-логики; воссоздание бизнес-процессов как самостоятельная задача, а не механический перенос схем; работа с контентом и метаданными как отдельный слой; и интеграционный контур, спроектированный без жёстких точечных сцепок с конкретным поставщиком [19].
Применительно к технологической платформе это означает практические шаги на этапе проектирования: выносить бизнес-логику и данные в слои, описанные открытыми контрактами (API, схемы данных), которые не зависят от внутренней реализации конкретного компонента платформы; документировать все точки интеграции отдельно от самого приложения; заранее закладывать в архитектуру возможность замены отдельного компонента без переписывания всей системы. Отдельно стоит учитывать требования к реестру отечественного ПО, если предполагается тиражирование продукта за пределы конкретного проекта: включение возможно только для решений, правообладателем которых является российское юридическое лицо или гражданин РФ, а доля российских участников должна составлять не менее 50% [21].
Стоит также реалистично оценивать стоимость соответствия новым требованиям безопасности — по оценке отраслевых консультантов, приведение информационной системы в соответствие с актуальными требованиями оценивается от нескольких миллионов рублей единовременно, а ежегодное поддержание взаимодействия с государственной системой обнаружения компьютерных атак требует отдельного бюджета [20]. Эти цифры относятся к общей практике соответствия требованиям ИБ, а не конкретно к работе на технологической платформе, — но их стоит учитывать при бюджетировании проекта.
Что писать в закупочной и архитектурной документации
Пока Положение о платформе не принято, в техническое задание и проектную документацию имеет смысл закладывать формулировки «с запасом»:
- прямое указание, относится ли создаваемая или дорабатываемая система к категориям, для которых закон предусматривает жёсткое исключение (гостайна, служебная тайна в обороне, тайна следствия) или особый порядок принятия решения (КИИ, ведомства при Президенте, ФНС, Москва) [4][6];
- порядок и сроки прохождения оценки целесообразности использования существующих компонентов платформы совместно с уполномоченным органом — до начала разработки, а не после [5][6];
- разграничение зон ответственности за инфраструктуру, приложение и данные между владельцем компонентов и участником платформы отдельным разделом, а не общей фразой «стороны несут ответственность в соответствии с законодательством» [6][7];
- требования к защите информации со ссылкой на актуальную редакцию приказа ФСТЭК №117 и обязательство подрядчика соблюдать внутренние регламенты заказчика по ИБ [16];
- условие о совместимости выбираемых компонентов с реестром отечественного ПО, если предполагается тиражирование решения [21];
- отдельный раздел про интеграционные контракты (API, форматы обмена) как условие приёмки — это облегчает последующую независимость от конкретного поставщика компонента [19].
Типичные ошибки и риски
Наиболее частые риски, которые стоит закрывать заранее: недооценка времени на согласовательные процедуры с уполномоченным органом, которых не было в прежней модели госконтракта [5][6]; отсутствие в договоре чёткого разграничения ответственности за инфраструктурный слой, из-за чего в случае сбоя стороны спорят, кто отвечает — оператор платформы или разработчик приложения [6][7]; выбор архитектуры без учёта требований к аттестации ГИС и к взаимодействию с ГосСОПКА, из-за чего доработки под ИБ-требования всплывают на этапе приёмки, а не проектирования [18]; и, наконец, работа с подрядчиками без включения требования соблюдать внутренние политики ИБ заказчика, что стало отдельным пунктом приказа ФСТЭК №117 [16].
Что зафиксировать в техническом задании
До выбора архитектуры зафиксируйте границы системы, роли владельца компонентов и участника платформы, перечень обязательных компонентов, схему обмена, требования к приёмке, журналированию, восстановлению и защите информации. Если проект затрагивает СМЭВ, API, персональные данные или КИИ, эти контуры нужно описать отдельно и сверить с актуальными подзаконными актами к моменту закупки.
Вывод
Закон о технологической платформе меняет не столько технологии, сколько модель ответственности в государственных цифровых проектах: вместо одного заказчика, который отвечает за всё, появляются три отдельных субъекта с разным кругом обязанностей. Практическое содержание реформы — конкретные требования к компонентам, порядок допуска и типовые формы соглашений — будет определяться отдельным Положением Правительства, которого на момент публикации ещё нет. До 1 сентября 2027 года у заказчиков и подрядчиков есть время подготовить архитектуру и документацию так, чтобы переход на новую модель не потребовал полной переделки проекта. Чтобы обсудить конкретную задачу или получить консультацию, свяжитесь с командой «Пятого фактора» любым удобным способом.
Источники
[1] consultant.ru — Обзор ФЗ №166-ФЗ — https://www.consultant.ru/law/hotdocs/94442.html
[2] consultant.ru — Текст ФЗ от 10.06.2026 №166-ФЗ — https://www.consultant.ru/document/cons_doc_LAW_536484/
[3] consultant.ru — Статья 1 (сфера действия) — https://www.consultant.ru/document/cons_doc_LAW_536484/314a79f49a806b40b413fda2b160c63163cb3d6d/
[4] consultant.ru — Статья 2 (технологическая платформа, исключения) — https://www.consultant.ru/document/cons_doc_LAW_536484/d715a06842d9cd2428508a37c0c40b79f3351a7e/
[5] consultant.ru — Статья 3 (уполномоченный орган) — https://www.consultant.ru/document/cons_doc_LAW_536484/b42d51e7165f324fabe2b84f2db09ab3a59138d2/
[6] consultant.ru — Статья 4 (участники платформы) — https://www.consultant.ru/document/cons_doc_LAW_536484/b15710455d578cc96dc2fbac46c08864182fe05e/
[7] consultant.ru — Статья 5 (владельцы компонентов) — https://www.consultant.ru/document/cons_doc_LAW_536484/0fa80ef7c5779adcd408eba654fc03a3a73b0216/
[8] consultant.ru — Статья 6 (соглашение о предоставлении компонентов) — https://www.consultant.ru/document/cons_doc_LAW_536484/f672964e9a982d93bed57bc9d3120755d14549bc/
[9] alrf.ru — Новая архитектура государственных информационных систем — https://alrf.ru/articles/novaya-arkhitektura-gosudarstvennykh-informatsionnykh-sistem/
[10] alrf.ru — Как будет работать технологическая платформа — https://alrf.ru/articles/kak-budet-rabotat-tekhnologicheskaya-platforma/
[11] alrf.ru — Что изменится для государства, бизнеса и юридического сообщества — https://alrf.ru/articles/chto-izmenitsya-dlya-gosudarstva-biznesa-i-yuridicheskogo-soobshchestva/
[12] tadviser.ru — Гостех (Единая цифровая платформа РФ) — https://www.tadviser.ru/index.php/Статья:Гостех_(Единая_цифровая_платформа_Российской_Федерации)
[13] platform.digital.gov.ru — FAQ по платформе «ГосТех» — https://platform.digital.gov.ru/faq.html
[14] platform.gov.ru — Требования к цифровому продукту — https://platform.gov.ru/faq_category/trebovaniya-k-produktu-ru/
[15] platform.gov.ru — Общие вопросы (тестовый стенд) — https://platform.gov.ru/faq_category/obshhie-voprosy/
[16] securitymedia.org — Аттестация ГИС и КИИ по новым правилам 2026: приказ ФСТЭК №117 — https://securitymedia.org/info/attestatsiya-gis-i-kii-po-novym-pravilam-2026-polnyy-razbor-prikaza-fstek-117.html
[17] softline.ru — Приказ ФСТЭК №117: как выполнить новые требования к защите ГИС — https://softline.ru/about/blog/prikaz-fstek-117-kak-vypolnit-novye-trebovaniya-k-zashchite-gis
[18] is.astral.ru — Аттестация ГИС по безопасности информации ФСТЭК — https://is.astral.ru/services/podklyuchenie-k-gis/attestatsiya-gosudarstvennykh-informatsionnykh-sistem-gis/
[19] tadviser.ru — Вендорлок по-русски — https://www.tadviser.ru/index.php/Статья:Вендорлок_по-русски:_как_не_попасть_в_кабалу_к_отечественному_разработчику_при_импортозамещении
[20] delprof.ru — Импортозамещение ПО: выбор и интеграция — https://delprof.ru/press-center/open-analytics/importozameshchenie-po-vybor-i-integratsiya/
[21] platforms.su — Импортозамещение ПО (реестр отечественного ПО) — https://platforms.su/glossary/importozameshchenie-po
[22] belinfonalog.ru — Импортозамещение в ИБ 2026 (Указ №250) — https://belinfonalog.ru/company/news/aktualnoe/importozameshchenie-v-ib-kak-ne-ostatsya-bez-zashchity-posle-1-yanvarya-2026-goda/
[23] cloud4y.ru — Облачная миграция 2026: пошаговый гайд — https://www.cloud4y.ru/blog/cloud-migration-2026/
[24] 5factor.ru — ФГИС «Семеноводство» и 1С: обмен и ошибки — https://5factor.ru/resources/integracziya-fgis-semenovodstvo-s-1s-kak-perestat-vnosit-dannye-dvazhdy
[25] 5factor.ru — True API «Честного знака»: подключение и УКЭП — https://5factor.ru/resources/true-api-chestnogo-znaka-podklyuchenie-avtorizacziya-i-obmen-dannymi