Банки несут полный набор обязанностей субъекта критической информационной инфраструктуры, а облака, DNS и хостинг, на которых фактически работают их клиентские сервисы, сопоставимых обязанностей не несут.
О самом этом разрыве сказано уже немало. Куда меньше написано о том, что происходит, когда его пытаешься закрыть штатными инструментами: постатейными поправками на общественном обсуждении, предложениями регуляторам, работой с профильным комитетом Госдумы. Последний год я занимался именно этим, и часть моих предложений уже получила в сводках обсуждения статус «учтено». Поэтому дальше пишу о том, что проверил на себе: какие документы нужно править, что регуляторы готовы принимать и что банк может сделать сам, не дожидаясь нормативных изменений.
Где заканчиваются требования
Кредитные организации давно прошли весь путь субъекта КИИ: объекты выявлены и откатегорированы по критериям постановления Правительства №127, значимые объекты защищаются по приказам ФСТЭК №235 и №239, сведения об инцидентах уходят в ГосСОПКА и Банк России. Поверх этого действует собственный контур регулятора: положение 716-П об операционном риске, включая риск аутсорсинга, положение 850-П об операционной надежности, а с 2023 года еще и ГОСТ Р 57580.3 и 57580.4 об управлении риском реализации информационных угроз. По плотности надзора банковский сектор опережает любую другую отрасль из числа субъектов КИИ.
Но все эти документы адресованы банку и системам банка. Арендованные облачные мощности, DNS-резолвинг, хостинг, каналы связи принадлежат провайдерам, и обязанности по защите значимого объекта не переходят на провайдера вместе с договором. Сам провайдер нередко является субъектом КИИ, скажем, как оператор связи, но обязанность отнести коммерческое облако к значимым объектам из этого не следует. Возникает зона, где банк уже не хозяин, а требования еще не действуют. Насколько она реальна, показал январь 2024 года, когда из-за проблемы с ключами DNSSEC в зоне .ru клиенты крупнейших банков часами не могли попасть в приложения и на сайты, притом что значимые объекты самих банков работали штатно и докладывать по 187-ФЗ было формально не о чем.
У разрыва есть и второй слой, информационный. Когда в марте 2025 года авария энергоснабжения остановила одну из зон доступности крупного российского облака, каждый участник видел только свой фрагмент: провайдер разбирался с собственным событием, его клиенты фиксировали недоступность сервисов, регуляторы получали сведения лишь от поднадзорных и лишь по своим формам. Точки, где эти сведения складываются в общую картину, в нынешней конструкции нет. За рубежом картина та же: пятнадцатичасовой отказ AWS в октябре 2025 года оставил клиентов британских банков без онлайн-банкинга, а неудачное изменение конфигурации Cloudflare в ноябре 2025 года сделало недоступными тысячи сервисов, хотя никакой атаки не было.
Что показала практика подач
За год мои предложения прошли по четырем адресам. К трем проектам Минцифры на regulation.gov.ru (переиздание приказа о национальной системе доменных имен, использование облачных мощностей для государственных систем, требования к предоставлению вычислительных мощностей) я подавал постатейные поправки: числовые показатели качества DNS-резолвинга (пороги, перцентили) вместо общих формулировок о надежности, поддержка современных защищенных протоколов, а также обязанность провайдера, который обслуживает инфраструктуру финансового сектора, сообщать о событиях безопасности в ГосСОПКА и центр мониторинга Банка России. К проекту ФСТЭК о метриках защищенности КИИ ушли четыре предложения, два из них получили в сводке обсуждения статус «учтено», в том числе предложение распространить методику оценки на финансовые организации. Тем же разрывом я занимался и вне общественных обсуждений: направил обращение в Департамент информационной безопасности Банка России, а поправки к антифрод-законопроекту №1110676-8 передал через профильный комитет Госдумы. Часть думских поправок учтена в работе комитета, закон принят и подписан 26 июня 2026 года как 210-ФЗ.
Формат везде один, взятый из практики общественного обсуждения: конкретный пункт проекта, предлагаемая редакция, короткое обоснование. Такие подачи разработчик отражает в сводке предложений, и по сводке потом видно, что принято и почему. Вывод из этой работы у меня простой: регуляторы отсекают абстрактные призывы, зато предметный текст с обоснованием рассматривают всерьез, независимо от статуса заявителя. Предложения независимого эксперта попадают в те же сводки, что и позиции крупных корпоративных игроков, и рассматриваются в том же порядке.
Что реально изменить за год
Из этой практики следует и ответ на вопрос о реализуемости. Новый федеральный закон не нужен, вопрос закрывается правками в документы, которые уже действуют или уже разрабатываются.
Начать логично с положения 850-П. Реестр технологических процессов с участием поставщиков услуг уже обязателен, с октября 2025 года действуют сигнальные и контрольные значения допустимой доли деградации процессов. Естественным развитием было бы требование включать в договоры с облачными, DNS- и хостинг-провайдерами фиксированные сроки, в которые провайдер обязан сообщить банку об инцидентах и сбоях, затронувших обслуживаемые системы. Это правка одного положения Банка России.
Дальше форма сведений о категорировании. Сегодня она не содержит данных о внешних зависимостях объекта. Дополнение ее перечнем внешних сервисов, от которых объект фактически зависит, дало бы регуляторам карту опорной инфраструктуры финансового сектора, которой сейчас нет ни у одного из них. Технически это изменение приложения к приказу ФСТЭК.
Третий адрес, акты Минцифры о доменной системе, облаках и хостинге. Все три проекта прошли общественное обсуждение, итоговые редакции пока не приняты, так что пространство для доработки формулировок сохраняется. Принципиальное требование к ним одно: качество опорных сервисов должно задаваться проверяемыми метриками.
И последнее, подзаконная база к 210-ФЗ, нормы которого вступают в силу поэтапно с сентября 2026 года. Именно здесь решится, будут ли ГосСОПКА и ФинЦЕРТ узнавать о событиях у провайдеров, обслуживающих банки, или полная картина инцидента останется недостижимой.
Что банк может сделать сам
Ждать регулятора при этом незачем. Провести инвентаризацию внешних зависимостей каждого значимого объекта, вписать в договоры с провайдерами фиксированные сроки уведомления об инцидентах, подготовить честный план миграции на резервную площадку можно уже сейчас, в рамках действующих 850-П и 716-П. Когда нормативные требования появятся, а движение идет именно в эту сторону, банки с готовой картой зависимостей выполнят их без аврала.
Разрыв между периметром требований и фактической инфраструктурой сам не закроется: доля арендованных мощностей в банковских ландшафтах только растет. Закрыть его можно согласованными правками в положение Банка России, форму сведений о категорировании и акты Минцифры. Все эти документы уже лежат на столах регуляторов, и практика показывает, что предметные предложения там читают. Лучше внести туда чужую инфраструктуру, на которой работают банки, сейчас, чем возвращаться к этому вопросу после очередного крупного сбоя.
