Что такое ОНиВД и ПОНиВД, расшифровка
ОНиВД — обеспечение непрерывности и (или) восстановления деятельности. Это термин Банка России для того, что в международной практике называется управлением непрерывностью бизнеса, business continuity management. ПОНиВД — план обеспечения непрерывности и (или) восстановления деятельности, главный документ этой системы.
Аббревиатуры выглядят громоздко, но за ними стоит простая идея. Регулятор хочет, чтобы банк заранее знал ответ на три вопроса. Какие процессы нельзя останавливать. Сколько времени организация может без них прожить. Что конкретно и в каком порядке делают люди, когда процесс все-таки встал.
Отличие ОНиВД от «обычного» плана непрерывности не в содержании, а в статусе. Для поднадзорных организаций это не добрая воля, а надзорное требование с проверяемыми параметрами. Регулятор смотрит не только на наличие документа, но и на даты его актуализации, результаты тестирований, зафиксированные инциденты и фактическое время восстановления.
Нормативная база на 2026 год
Здесь чаще всего и возникает ошибка. В большинстве статей и во многих действующих внутренних документах банков до сих пор стоит ссылка на Положение 787-П. Положение Банка России от 12.01.2022 № 787-П утратило силу 3 мая 2025 года. Его заменило Положение № 850-П. Если во внутреннем документе организации есть ссылка на 787-П, документ нужно пересматривать.
| Документ | О чем | На кого распространяется |
|---|---|---|
| Положение № 850-П от 13.01.2025 | Требования к операционной надежности в целях обеспечения непрерывности оказания банковских услуг. Действует с 3 мая 2025 года, отдельные нормы — с 1 октября 2025 года. Заменило 787-П | Кредитные организации, включая небанковские, и филиалы иностранных банков в России |
| Положение № 779-П от 15.11.2021 | Требования к операционной надежности некредитных финансовых организаций | НФО, страховые, профучастники рынка ценных бумаг |
| Положение № 716-П от 08.04.2020 | Система управления операционным риском, база событий операционного риска, контрольные показатели уровня операционного риска. В нем же — требование к плану ОНиВД | Кредитные организации и банковские группы |
| Положение № 851-П | Защита информации при осуществлении банковской деятельности. Заменило 683-П, на него ссылается 850-П в части критичной архитектуры | Кредитные организации |
| ГОСТ Р 57580.3 и 57580.4 | Конкретные меры, которыми реализуются требования по операционной надежности и управлению риском информационной безопасности | Применяются как способ выполнения требований положений |
| Указание № 3439-У | Порядок признания организации значимой на рынке платежных услуг. От этого статуса зависят повышенные требования | Операторы по переводу денежных средств |
Состав нормативной базы приведен по состоянию на 21 августа 2026 года. Перед подготовкой внутренних документов проверяйте действующую редакцию на сайте Банка России, регулирование в этой области меняется примерно раз в два-три года.
Кому это обязательно
Требования в разном объеме распространяются на кредитные организации, филиалы иностранных банков в России, некредитные финансовые организации, страховые компании, профессиональных участников рынка ценных бумаг, операторов платежных систем и значимых поставщиков платежных услуг.
Объем требований зависит от двух вещей. Первое — размер организации, для банков с активами свыше пятисот миллиардов рублей пороговые значения жестче. Второе — признание значимой на рынке платежных услуг, такой организации дается шесть месяцев с даты признания на то, чтобы установить сигнальные и контрольные значения, а требования по платежным технологическим процессам приравниваются к требованиям для крупнейших банков.
Отдельно стоит сказать про подрядчиков. Если ваша компания обслуживает поднадзорную организацию — предоставляет ИТ-сервис, обрабатывает данные, обеспечивает связь — требования непрерывности придут к вам через договор. Банк обязан управлять зависимостью от поставщиков, а значит будет требовать от вас целевое время восстановления, порядок уведомления об инцидентах и участие в тестированиях.
Логика формирования плана
План ОНиВД строится не «от разделов», а от процессов. Последовательность такая.
Шаг 1. Выделить технологические процессы
Регулятор оперирует не подразделениями и не системами, а технологическими процессами. Это сквозные цепочки, в результате которых клиент получает услугу: прием и обработка платежа, выдача наличных, дистанционное обслуживание, кредитование, обслуживание счетов. Перечень процессов и пороговые значения по ним заданы в приложениях к 850-П, и это не тот список, который организация придумывает сама.
Шаг 2. Определить допустимое время простоя
Для каждого технологического процесса устанавливается пороговое допустимое время простоя. Это верхняя граница, дальше начинается нарушение. Внутри этой границы организация ставит собственные целевые показатели, обычно более жесткие, потому что попадание в норматив впритык означает, что первый же сбой станет нарушением.
Шаг 3. Определить допустимую долю деградации
Это второй показатель, и он важнее, чем кажется. Доля деградации — отношение количества операций, проведенных или не проведенных в период инцидента, к плановому количеству операций в нормальном режиме. Иначе говоря, процесс может формально работать, но обслуживать не сто процентов клиентов, а тридцать. Для этого показателя устанавливаются сигнальное и контрольное значения в соответствии с контрольными показателями уровня операционного риска.
Шаг 4. Настроить порог фиксации инцидента
Инцидент операционной надежности фиксируется, когда превышение сигнального значения доли деградации длится более пяти минут. Короткие всплески инцидентом не считаются. Это важная деталь для настройки мониторинга: если система оповещения срабатывает на любое отклонение, служба тонет в ложных срабатываниях, если реагирует медленнее пяти минут — организация пропускает подлежащий фиксации инцидент.
Шаг 5. Связать с базой событий операционного риска
Все инциденты, повлекшие потери, регистрируются в базе событий операционного риска по 716-П. Фиксируется фактическое время простоя, доля деградации в период инцидента, суммарное время простоя и результаты восстановления работоспособности. Отсюда же берутся данные для отчетности и для пересмотра целевых показателей.
Шаг 6. Описать сценарии и действия
Только на этом шаге появляется собственно текст плана. Сценарии пишутся под уже известные процессы и их пороговые значения, а не наоборот. Именно поэтому планы, начатые с шаблона разделов, почти всегда получаются нерабочими: в них есть красивые процедуры, но нет ответа на вопрос, за сколько минут нужно уложиться и по какому признаку понять, что не уложились.
Структура ПОНиВД, одиннадцать разделов
Рабочая структура, которая закрывает требования и при этом остается пригодной для использования в реальном кризисе, а не только для проверки.
- Область действия и перечень технологических процессов. Какие процессы охватывает план, их владельцы, пороговое допустимое время простоя и целевые показатели по каждому.
- Целевые показатели операционной надежности. Допустимое время простоя, сигнальные и контрольные значения доли деградации, порядок их пересмотра.
- Критичная архитектура. Объекты информационной инфраструктуры, обеспечивающие процессы, зависимости между ними, единые точки отказа.
- Сценарии нарушений. Отказ информационной системы, недоступность помещения, потеря ключевого персонала, сбой поставщика, компьютерная атака, отказ каналов связи, отказ энергоснабжения.
- Порядок активации плана. Кто, при каких признаках и в какой срок объявляет режим нарушения, кто замещает это лицо в его отсутствие, как фиксируется момент активации.
- Процедуры восстановления. Пошаговые действия по каждому сценарию с указанием исполнителей, сроков и точки, в которой принимается решение о переходе на резервную схему.
- Коммуникации. Оповещение сотрудников, информирование клиентов, уведомление Банка России, взаимодействие со СМИ, шаблоны сообщений.
- Резервные ресурсы. Резервные площадки, каналы связи, резервное копирование, порядок и время переключения, кто имеет право его инициировать.
- Зависимость от поставщиков и ключевых сотрудников. Перечень критичных внешних зависимостей, требования к ним в договорах, порядок работы при потере сотрудника с уникальными компетенциями, включая период удаленной работы.
- Порядок тестирования. Виды проверок, периодичность, программа тестирования, критерии успешности, порядок оформления результатов.
- Порядок актуализации. Регулярный пересмотр и события, при которых план пересматривается внепланово.
Примеры формулировок, хорошо и плохо
Разница между планом, который проходит проверку, и планом, который ее не проходит, обычно видна на уровне отдельных фраз. Проверяющий ищет проверяемость: срок, ответственного, признак наступления события. Ниже пары формулировок из реальной практики, обезличенные.
| Так не надо | Так надо |
|---|---|
| «В случае возникновения нештатной ситуации подразделение принимает необходимые меры для восстановления работоспособности в кратчайшие сроки.» | «При недоступности процесса приема платежей более 5 минут дежурный администратор в течение 10 минут переводит нагрузку на резервный контур и уведомляет руководителя службы операционных рисков. Целевое время восстановления — 30 минут.» |
| «Ответственным за непрерывность деятельности является служба информационных технологий.» | «Ответственным за ОНиВД является заместитель председателя правления, курирующий операционную деятельность. Владельцем технологического процесса ТП-4 является руководитель управления расчетов, он принимает решение об активации плана в части этого процесса.» |
| «План подлежит регулярному пересмотру.» | «План пересматривается не реже одного раза в год до 1 марта, а также в течение 20 рабочих дней после каждого из событий: изменение перечня технологических процессов, изменение критичной архитектуры, инцидент с превышением контрольного значения, изменение нормативных требований.» |
| «Резервное копирование осуществляется на регулярной основе.» | «Полное резервное копирование базы АБС выполняется ежедневно в 02:00, хранение копий — 30 суток, ежеквартально проводится контрольное восстановление из копии с оформлением протокола.» |
| «Сотрудники оповещаются доступными средствами связи.» | «Оповещение выполняется по схеме каскадного обзвона, первый круг — 12 человек кризисного штаба, срок сбора подтверждений — 20 минут. Контактные данные хранятся в двух местах, включая распечатанный экземпляр в сейфе дежурной смены.» |
| «Проводятся периодические тестирования плана.» | «Ежегодно проводится не менее одного натурного переключения на резервную площадку и не менее двух настольных разборов сценариев. Результаты оформляются протоколом с перечнем выявленных недостатков и сроками их устранения.» |
| «Взаимодействие с поставщиками осуществляется в рамках заключенных договоров.» | «Для критичных поставщиков в договоре зафиксировано время реакции 30 минут, время восстановления 4 часа и обязанность участвовать в ежегодном тестировании. Перечень таких поставщиков приведен в приложении 3 и пересматривается ежегодно.» |
| «Информация об инцидентах доводится до руководства.» | «Инцидент операционной надежности регистрируется в базе событий операционного риска в течение одного рабочего дня. О превышении контрольного значения доли деградации председатель правления информируется немедленно, совет директоров — в составе ежеквартальной отчетности.» |
Общее правило простое. Если из фразы нельзя понять, кто именно, в какой срок и по какому признаку действует — фраза нерабочая, даже если написана грамотно.
Ответственность внутри банка
Второй по частоте вопрос после расшифровки термина: кто отвечает за ОНиВД и кто активирует план. Ответ должен быть в документе поименно, а не по подразделениям.
| Роль | За что отвечает |
|---|---|
| Совет директоров | Утверждает подход к управлению операционным риском и допустимый уровень риска, рассматривает отчетность о нарушениях непрерывности, оценивает достаточность принимаемых мер |
| Правление | Утверждает план ОНиВД и целевые показатели, обеспечивает ресурсы, отвечает за фактическое состояние системы перед советом директоров и регулятором |
| Куратор ОНиВД, уровень заместителя председателя правления | Единая точка ответственности за систему в целом. Именно это лицо указывается в документах как ответственное, замещение определено приказом |
| Служба управления рисками | Методология, реестр рисков непрерывности, база событий операционного риска, расчет показателей, отчетность, координация тестирований |
| Владелец технологического процесса | Знает допустимое время простоя своего процесса, принимает решение об активации плана в его части, отвечает за актуальность процедур восстановления |
| Информационные технологии | Резервирование, восстановление систем и данных, переключение на резервный контур, техническая часть тестирований |
| Информационная безопасность | Сценарии компьютерных атак, взаимодействие с 851-П и ГОСТ Р 57580, реагирование на инциденты информационной безопасности |
| Служба внутреннего аудита | Независимая проверка того, что система работает, а не описана. Проверяет фактические тестирования, а не протоколы |
| Кризисный штаб | Оперативное управление в период нарушения. Состав, заместители и порядок сбора зафиксированы в плане |
Практическая проверка распределения ответственности занимает пять минут. Откройте план и найдите, кто объявляет режим нарушения в 3 часа ночи в выходной день, если основное ответственное лицо недоступно. Если ответа нет — распределение ролей формальное.
Как часто обновлять и тестировать
Периодичность в положениях задана не одной цифрой, а набором требований к разным элементам системы. Сводим их в календарь, по которому удобно жить.
| Что | Как часто | Основание и смысл |
|---|---|---|
| Расчет продолжительности функционирования технологических процессов, включая плановые простои | Ежеквартально | Данные для контроля соблюдения пороговых значений и для обоснования целевых показателей |
| Пересмотр значений целевых показателей операционной надежности | Не реже одного раза в год | С учетом контрольных показателей уровня операционного риска. Основание для пересмотра — накопленная статистика инцидентов |
| Оценка и пересмотр в системе управления операционным риском | Не реже одного раза в год | 716-П, поддержание системы в актуальном состоянии |
| Тестирование операционной надежности | По установленной программе и периодичности, закрепленной во внутренних документах | Сценарный анализ плюс качественная оценка уровня операционного риска. Периодичность организация устанавливает сама, но она должна быть определена и соблюдаться |
| Пересмотр плана ОНиВД | Не реже одного раза в год плюс внепланово | Внепланово — при изменении перечня процессов, критичной архитектуры, оргструктуры, состава критичных поставщиков, после значимого инцидента и при изменении требований |
| Актуализация контактных данных и схем оповещения | Ежеквартально | Формально не выделено отдельным требованием, но это самая быстро устаревающая часть плана |
| Установка сигнальных и контрольных значений при признании организации значимой на рынке платежных услуг | Не позднее 6 месяцев с даты признания | Указание 3439-У во взаимосвязи с 850-П |
Отдельно про виды тестирований. Настольный разбор сценария силами кризисного штаба закрывает вопрос готовности людей, но ничего не говорит о готовности техники. Натурное переключение на резервную площадку отвечает на технический вопрос, но проводится редко из-за риска для продуктива. Рабочая комбинация для банка среднего размера — несколько настольных разборов и одно натурное переключение в год, с обязательным протоколом и планом устранения выявленных недостатков.
Хорошая и плохая практика разработки
Что работает
Начинать с процессов, а не с оглавления. Сначала перечень технологических процессов, их владельцы и пороговые значения. Текст плана пишется последним и занимает меньше времени, чем кажется.
Писать план руками владельцев процессов. Консультант дает структуру, требования и модерирует, но процедуру восстановления описывает тот, кто будет ее выполнять. План, написанный целиком внешним подрядчиком, при первом же инциденте оказывается непонятным исполнителям.
Держать план коротким. Двести страниц никто не откроет в момент аварии. Рабочая форма — компактный основной документ и приложения с картами действий на одну страницу для каждого сценария, которые можно распечатать и положить в дежурную смену.
Считать деньги. Стоимость часа простоя каждого критичного процесса превращает спор о бюджете на резервирование в расчет. Без этой цифры любой запрос на резервную площадку выглядит как прихоть подразделения.
Проверять план на реальном инциденте. После каждого сбоя, даже мелкого, полезно сверить, совпали ли фактические действия с описанными. Это дает больше, чем плановое учение.
Что не работает
Шаблон без внедрения. Купленный или скачанный шаблон ускоряет старт, но проверку проходит не документ, а система. Признаки внедрения — свежие даты, поименные роли, протоколы тестирований, зафиксированные инциденты.
План как проект службы информационных технологий. Если план разрабатывает только ИТ, в нем будут системы и не будет процессов, клиентов и коммуникаций. Регулятор смотрит на непрерывность оказания услуг, а не на доступность серверов.
Целевые показатели, взятые из норматива впритык. Если организация установила себе ровно то время, которое задано как пороговое, то любое отклонение сразу становится нарушением. Внутренний целевой показатель должен иметь запас.
Тестирование без выводов. Учение, после которого не появился перечень недостатков со сроками, было имитацией.
Ссылки на отмененные документы. Проверка внутренних документов на актуальность нормативных ссылок занимает час, а найденная в плане ссылка на 787-П обесценивает документ целиком в глазах проверяющего.
На чем спотыкаются при проверках
План есть, системы нет. Документ написан три года назад, телефоны устарели, часть названных сотрудников уволилась. Формально требование выполнено, фактически при инциденте план бесполезен, и проверка видит это по датам актуализации и по отсутствию протоколов тестирований.
Тестирования на бумаге. Протоколы учений составляются без самих учений. Риск двойной, и надзорный, и реальный: первый настоящий сбой становится первым тестом.
Показатели не считаются. Целевые значения записаны в документе, но фактические не измеряются, потому что мониторинг не настроен на пятиминутный порог и на долю деградации. В результате инциденты не фиксируются, база событий пустая, отчетность формальная.
Нет связи с деньгами. План не отвечает, сколько стоит час простоя каждого критичного процесса, а значит невозможно обоснованно выбирать, что восстанавливать первым.
Зависимость от поставщиков не описана. Организация знает свои системы, но не знает, что будет, если недоступен внешний процессинг или канал связи единственного оператора.
Частые вопросы
Как расшифровывается ОНиВД? Обеспечение непрерывности и (или) восстановления деятельности. ПОНиВД — план обеспечения непрерывности и (или) восстановления деятельности.
Чем ПОНиВД отличается от BCP? По содержанию почти ничем, это план непрерывности в терминологии Банка России. Отличие в обязательности состава разделов, в привязке к технологическим процессам с заданными пороговыми значениями и в надзорной отчетности. Действующий BCP обычно не переписывают с нуля, а достраивают до требований. Подробнее о различиях планов — в разборе BCM, BCP и DRP.
Действует ли еще 787-П? Нет. Положение 787-П утратило силу 3 мая 2025 года, действует Положение 850-П от 13.01.2025. Для некредитных финансовых организаций сохраняет силу 779-П.
Кто активирует план ОНиВД? Лицо, определенное внутренним документом, обычно владелец технологического процесса или руководитель дежурной смены при достижении заданных признаков, с немедленным уведомлением куратора ОНиВД. Ключевое требование — чтобы порядок активации и замещения был описан и работал в нерабочее время.
Как часто нужно тестировать план? Периодичность организация устанавливает сама во внутренних документах, но она должна быть определена, соблюдаться и подтверждаться протоколами. Рабочий ориентир для банка среднего размера — несколько настольных разборов и одно натурное переключение в год.
Что такое доля деградации? Отношение количества операций, проведенных или не проведенных в период инцидента, к плановому количеству операций в нормальном режиме. Показывает, что процесс может формально работать, но обслуживать лишь часть клиентов.
Сколько времени занимает разработка? Для организации среднего размера — от шести до десяти недель до работающей первой версии: описание технологических процессов, целевые показатели, план, первое тестирование. Приведение уже существующего плана к актуальной нормативной базе — обычно три-четыре недели.
Можно ли использовать готовый шаблон? Шаблон полезен как каркас, но проверку проходит не документ, а система. Наши структуры плана и чек-листы имеет смысл брать как отправную точку, а не как готовый результат.
Какие ситуации входят в периметр ОНиВД? Отказ информационных систем и каналов связи, недоступность офиса или площадки, потеря значимой части персонала, отказ ключевого поставщика или контрагента, кибератака, а также события, влияющие на непрерывность платежей. Перечень фиксируется в положении и пересматривается ежегодно.
Что должно быть в плане ОНиВД банка? Перечень критических процессов и допустимого времени простоя, сценарии, порядок оповещения и эскалации, роли и заместители, порядок перехода на резервные площадки, требования к тестированию и порядок отчетности перед руководством.
От требований стандарта к работающей системе
Диагностика показывает разрыв между документами и реальностью. Дальше система строится вашими руками в программе или нашими под ключ.