Регуляторные требования

ОНиВД и ПОНиВД: требования ЦБ и как составить план

Банк России требует от финансовых организаций не «папку с планами», а работающую систему обеспечения непрерывности и восстановления деятельности. Разбираем, кому это обязательно, что должно быть в ПОНиВД и на чем чаще всего спотыкаются при проверках.

Опубликовано: 18 июля 2026 г. · Автор: Евгений Теленков · ≈ 9 мин чтения
ОНиВД и ПОНиВД: требования ЦБ к непрерывности деятельности

Что такое ОНиВД и ПОНиВД

ОНиВД — обеспечение непрерывности и (или) восстановления деятельности. Так Банк России называет то, что в международной практике известно как управление непрерывностью бизнеса (BCM). ПОНиВД — план обеспечения непрерывности и восстановления деятельности, главный документ этой системы.

Разница с «обычным» BCM — в статусе. Для банков, страховых, НФО и участников платежных систем непрерывность — не добрая воля, а надзорное требование: регулятор проверяет наличие плана, его актуальность, результаты тестирований и то, как быстро организация возвращается к работе после сбоя.

Кому это обязательно

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

Практический ориентир: если ваша организация поднадзорна Банку России — у вас должен быть ПОНиВД, назначенные ответственные, регулярные тестирования и отчетность по инцидентам. Если вы обслуживаете такую организацию как подрядчик — будьте готовы, что требования непрерывности придут к вам через договор.

Что требует регулятор

Смысл требований сводится к пяти вещам:

Структура ПОНиВД: 9 разделов

Рабочая структура плана, которая закрывает требования и остается пригодной для реального кризиса:

  1. Область действия: перечень критичных процессов и систем с целевым временем восстановления.
  2. Роли и полномочия: кризисный штаб, заместители, порядок принятия решений.
  3. Сценарии нарушений: отказ ИТ, недоступность офиса, потеря персонала, сбой подрядчика, кибератака.
  4. Порядок активации плана: кто, при каких условиях и как объявляет режим нарушения.
  5. Действия по восстановлению: пошаговые процедуры для каждого сценария.
  6. Внутренние и внешние коммуникации: сотрудники, клиенты, регулятор, СМИ.
  7. Резервные ресурсы: площадки, каналы связи, резервирование данных и мощностей.
  8. Порядок тестирования: виды учений, периодичность, критерии успеха.
  9. Порядок актуализации: когда план пересматривается и кто за это отвечает.

Типичные ошибки при проверках

План есть — системы нет. Документ написан консультантом три года назад, телефоны устарели, половина названных сотрудников уволилась. Формально требование выполнено, фактически при инциденте план бесполезен — и проверка это видит по датам актуализации и результатам тестирований.

Тестирования на бумаге. Протоколы учений составляются без самих учений. Риск двойной: и надзорный, и реальный — первый настоящий сбой становится первым тестом.

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

Как сделать план работающим

Наш подход — измеримая непрерывность. Вместо толстого документа «для проверки» — компактный план плюс управленческий дашборд: индекс устойчивости 0-100, стоимость часа простоя по критичным процессам, светофоры по слабым местам. Такой контур закрывает требования регулятора автоматически — потому что система реально работает, а не изображается. Посмотрите живое демо дашборда — это то, что видит правление.

Частые вопросы

Чем ПОНиВД отличается от BCP? По сути ничем: это план непрерывности, названный в терминологии Банка России. Если у вас уже есть работающий BCP — его нужно привести к требованиям регулятора по составу разделов и порядку тестирований.

Можно ли купить готовый шаблон? Шаблон ускоряет старт, но проверку проходит не документ, а система: назначенные роли, свежие тестирования, актуальные контакты. Шаблон без внедрения — риск, а не защита.

Сколько времени занимает построение? Для средней организации — 4-8 недель до работающего плана первой версии: анализ критичных процессов, план, первое тестирование.