Открыть меню

Критичные процессы и непрерывность деятельности

Создано 28 мая 2026 г. Обновлено 28 мая 2026 г. 3 мин чтения

Критичные процессы банка по 716-П и 850-П: как их определять, требования к планам непрерывности деятельности, тестированию BCP и DRP.

Актуальность проверена: 2026-05-28

Кратко

Критичные процессы - это процессы, прерывание которых влияет на выполнение банковских услуг, обязательств перед клиентами и контрагентами, учет, отчетность и устойчивость банка. 716-П требует учитывать критически важные процессы в СУОР и планах непрерывности, а 850-П задает требования к технологическим процессам и допустимому простою/деградации. Банк должен понимать, какие процессы действительно критичны, и не превращать перечень в формальность. Непрерывность должна проверяться тестами и инцидентами.

Нормативная база

  • Положение Банка России № 716-П от 08.04.2020.
  • Положение Банка России № 850-П от 13.01.2025.
  • Ответы Банка России по 716-П.

Суть требования

Банк должен определить критичные процессы, связанные системы, объекты инфраструктуры, подрядчиков, допустимые параметры простоя и восстановления. Для этих процессов должны быть планы непрерывности и восстановления, а также процедуры быстрого реагирования.

Практическое значение для банка

  • Владельцы процессов определяют бизнес-критичность.
  • ИТ задает RTO/RPO, архитектуру восстановления и мониторинг.
  • ИБ учитывает угрозы и требования защиты информации.
  • СУР связывает сбои с операционным риском и базой событий.
  • Аудит проверяет тестирование планов и устранение замечаний.

Типовые ситуации

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

Что должен сделать банк

  • Утвердить перечень критичных процессов.
  • Связать процессы с ИС, инфраструктурой и подрядчиками.
  • Определить допустимый простой, деградацию и время восстановления.
  • Разработать и тестировать планы непрерывности.
  • Связать инциденты с базой событий и КПУР.
  • Пересматривать критичность при изменении процессов и продуктов.

Риски неправильного применения

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

Связанные заметки

Вопросы для самопроверки

  1. Какие банковские услуги зависят от процесса?
  2. Какие ИС и подрядчики критичны?
  3. Когда последний раз тестировался план восстановления?
  4. Есть ли сценарий деградации, а не только полного отказа?
  5. Как событие отражается в СУОР?

Источники

Живой сад

Этот текст можно улучшать вместе

Нашёл опечатку?

Выдели фрагмент в заметке и нажми «Сообщить» — откроется короткая форма с контекстом.

Хочешь обсудить?

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

Telegram-комментарии

Добавь `telegramPostId` в публичную заметку, чтобы здесь появился виджет обсуждения.

Источник: публичный слой Obsidian Vault.