Обеспечение непрерывности и восстановления деятельности
Планы непрерывности, тесты восстановления и годовая аттестация — в одном контуре, где просроченный тест не теряется, а согласовать сам себе никто не может
Вместо десятков таблиц и переписки — реестр критичных процессов, планов и тестов со статусной моделью из семи состояний, ежедневной проверкой сроков в полночь, автоматически созданным повторным тестом после провала и эскалацией ответственному с пятой попытки. Каждое изменение поля и каждый переход статуса записаны с автором, датой и обязательным комментарием при возврате на доработку.
Показываем реестр планов, карточку теста с автоматическим повтором и годовую аттестацию подразделения — около 40 минут по видеосвязи. ОНиВД — обеспечение непрерывности и восстановления деятельности; англоязычное обозначение — Continuity of Business (CoB). Статусные модели, права и журналы разобраны в разделе «Права доступа и аудит».
Универсальные и розничные банки. Сеть офисов и локаций с отдельным тестом восстановления по каждой площадке и резервной стратегии. Годовая аттестация подразделений, которая закрывает план последними согласованными тестами. Отчётные формы за произвольный диапазон месяцев для надзорной отчётности.
Дочерние банки международных групп. Двуязычный контур: наименование и описание на русском и английском хранятся у каждой сущности, роли имеют английские названия, а язык интерфейса по умолчанию — английский. Отчёты формируются на языке сеанса, поэтому одна и та же форма уходит и в надзор, и в головную организацию.
Профессиональные участники рынка ценных бумаг и брокерские компании. RTO и RPO торговых и расчётных приложений в карточке плана. Тестирование DR-переключения систем и приложений с фиксацией начала и окончания переключения. Отдельный контур тестов и аттестации поставщиков, от которых зависит расчётный цикл.
Подготовка к проверке перестаёт быть отдельным проектом: реестр, сроки и доказательства собираются по ходу работы. Это сокращает трудозатраты на сбор подтверждений и закрывает операционный риск «тест был просрочен, и об этом никто не знал».
Четыре вида тестирования восстановления — офис или площадка, поставщик, аттестация поставщика, система или приложение — и три вида кризисных учений. Права выдаются шестью действиями на 13 типов объектов защиты, вплоть до отдельной вкладки карточки и отдельного статуса.
Один экран вместо десятка таблиц
Один и тот же набор данных: сначала — как он живёт в файлах и переписке, затем — как он выглядит, когда у каждой строки есть статус, срок, ответственный и история.
Файлы и переписка
- Тесты_восстановления_2026_итог_финал_2_правки.xlsx
- Аттестация_подразделений_v7 (копия).xlsx
- Планы_RTO_RPO_последняя_версия.xlsx
- Согласование_тестов_март.msg
- Напоминание_проверить_сроки.ics
Просроченный тест виден только тому, кто открыл нужную вкладку и вспомнил про фильтр.
Реестр в системе
Пример заполнения. Отметки сроков расставляет ежедневная проверка в полночь.
Каждая строка — карточка с журналом изменений по полям и отдельным журналом переходов статусов.
Рабочий экран: реестр, карточка плана, уведомления
Три вкладки — три места, где живёт непрерывность: список тестов со сроками, карточка плана с целевыми показателями, лента событий, которые система рассылает сама.
Таблица прокручивается вбок.
| Тест | Объект | Подразделение | Дата | Попытка | Результат | Отметка срока | Статус |
|---|---|---|---|---|---|---|---|
| Т-114 | Офис: основная площадка | Операционное управление | 12.03.2026 | 1 | Пройден | — | Согласован |
| Т-118 | Поставщик: провайдер каналов связи | Управление ИТ-инфраструктуры | 27.04.2026 | 1 | Не пройден | — | Согласован |
| Т-119 | Поставщик: провайдер каналов связи | Управление ИТ-инфраструктуры | 05.06.2026 | 2 | — | Просрочен | Ожидание |
| Т-123 | Система: расчётное приложение | Управление сопровождения | 07.09.2026 | 1 | — | Истекает сегодня | На согласовании |
| Т-127 | Система: платёжный шлюз | Управление сопровождения | не назначена | 2 | — | Повтор без даты | Создан |
| Т-131 | Офис: резервная площадка | Казначейство | 19.02.2026 | 1 | Не пройден | — | На доработке |
Полный набор состояний теста: создан, ожидание, на согласовании, на доработке, согласован, повторное тестирование, в архиве.
Таблица прокручивается вбок.
| Поле карточки | Значение | Заполнение |
|---|---|---|
| Критичный процесс | Расчёты по операциям с ценными бумагами | из справочника процессов |
| Подразделение | Управление расчётов | наследуется от процесса |
| Координатор плана | Координатор восстановления подразделения | роль в системе |
| RTO — целевое время восстановления | 4 часа | обязательно |
| RPO — целевая точка восстановления | 15 минут | обязательно |
| Оценка ущерба и её обоснование | расчёт по методике организации | отдельные поля |
| Нематериальный ущерб | репутационные последствия простоя | отдельное поле |
| Уровень внедрения | полная резервная схема | из справочника |
| Порядок перехода на резервную схему | текст регламента | обязательно |
| Порядок возврата к штатной работе | текст регламента | обязательно |
| Критичный сотрудник | назначается по процессу | обязательно |
| Статус плана | На согласовании | меняется переходом, а не правкой поля |
Поставщики и системы попадают в план связанными строками при его создании, а не переносятся руками.
Таблица прокручивается вбок.
| Событие | Кому уходит | Канал | Когда |
|---|---|---|---|
| Тест просрочен | Ответственный за тест | В приложении и на почту | Ежедневно в 00:00 |
| Тест истекает сегодня | Ответственный за тест | В приложении и на почту | Ежедневно в 00:00 |
| У повторного теста не назначена дата | Ответственный за тест | В приложении и на почту | Ежедневно в 00:00 |
| Превышено число попыток | Ответственный по корневому тесту цепочки | В приложении и на почту | С пятой попытки |
| Смена статуса плана | Координаторы непрерывности, кроме автора изменения | В приложении и на почту | В момент перехода |
| Годовая аттестация завершена | Координаторы непрерывности | В приложении и на почту | В момент закрытия плана |
Из уведомления открывается прямая ссылка на карточку — искать запись в реестре не нужно.
Состав колонок, полей, этапов и статусов — как в продукте: семь состояний теста, счётчик попыток, отметка срока от ежедневной ночной проверки. Данные в строках — пример заполнения.
Кому адресован продукт
Владелец процесса
Руководитель подразделения и координатор восстановления отвечают за план критичного процесса и за то, чтобы тесты по нему были проведены в срок.
Боль. План живёт в файле, срок очередного теста помнит один человек, а состав подтверждений собирается заново перед каждой проверкой.
Технический согласователь
Координатор непрерывности, менеджер приложения и DR-координатор приложения принимают результат теста и решают, засчитан он или отправляется на доработку.
Боль. Согласование идёт письмами: кто именно принял результат и на каком основании — восстанавливается по переписке.
Тот, кто платит
Директор по рискам и ИТ-директор отвечают за операционный риск целиком и защищают состояние непрерывности перед правлением и надзором.
Боль. Единой картины по подразделениям нет: сводка собирается вручную и устаревает в день сборки.
Механизмы, которые проверяющий может потрогать
Ниже — не список функций, а правила, которые система применяет сама, без дисциплины исполнителя.
Один человек не может отправить на согласование и сам же согласовать
При переходе в статус «Согласован» система читает последнюю запись журнала статусов — того, кто отправил запись на согласование, — и сравнивает её автора с текущим пользователем. Совпали — кнопка согласования недоступна. Правило работает одинаково для планов и для тестов.
Статус не сдвинуть без права именно на этот статус
Переход выполняется, только если у пользователя есть право на выполнение по целевому статусу и право на чтение по исходному. Каждый статус — самостоятельный объект защиты, поэтому «согласовать» можно выдать отдельно от «отправить на доработку».
Тест не уедет по маршруту без результата
Пока результат теста не внесён, переходы по статусной модели недоступны. Запись нельзя провести до согласования, оставив поле результата пустым.
Копия теста не наследует чужое согласование
При копировании сбрасываются идентичность и признаки согласования: ответственным становится тот, кто копировал, статус — «создан», дата согласования и согласовавший очищены.
Сроки, повторы и эскалация
Провал теста сам заводит повторный
Отрицательный результат при согласовании создаёт дочернюю запись: счётчик попыток увеличивается на единицу, связи с планом, объектом, стратегией восстановления и составом участников переносятся в новую запись.
С пятой попытки узнаёт не только исполнитель
Как только номер попытки превышает четыре, уведомление уходит ответственному по корневому тесту цепочки — в приложение и на почту. Порог одинаков во всех четырёх видах тестов.
Сроки проверяются каждую ночь в 00:00
Ежедневное сканирование идёт по трём условиям: дата в прошлом и результата нет; дата наступает сегодня; автоматически созданный повтор, которому никто не назначил дату.
Номер повтора виден целиком
У кризисных учений первичное получает номер N, повторное — N.M, и в карточке отображается вся цепочка повторов: сколько раз возвращались к этому учению и с каким результатом.
Арифметика учения сходится или не сохраняется
Участники плюс неучаствовавшие обязаны сойтись с заявленным составом — иначе сохранение блокируется. При отрицательном результате обязательна причина, при внесённом результате — место хранения подтверждений.
Закрытое учение больше не переписать
После завершения или провала карточка учения закрывается на запись. Задним числом поправить состав, дату или результат нельзя.
Кто что видит
Каждый видит своё поддерево оргструктуры
Руководитель подразделения и координатор восстановления подразделения получают строки только по своему узлу оргструктуры и его дочерним узлам. Фильтр применяется к реестру планов, к дереву структур и к реестру тестов.
Право выдаётся на объект и на вкладку, а не только на тип
Шесть действий — добавление, удаление, выполнение, фильтрация, чтение, запись — на 13 типов объектов защиты. Непустой фильтр превращает право в фильтрующее с сохранённым выражением отбора.
Чего нельзя читать — того не видно
Недоступные вкладки карточки и узлы навигатора не отображаются вовсе, а не показываются серым. Пользователь, у которого нет ни одной читаемой секции карточки, попадает на страницу отказа в доступе.
След, который остаётся
Возврат на доработку не бывает молчаливым
Переход «отправить на доработку» открывает форму с обязательным комментарием, и этот комментарий попадает в журнал переходов статусов рядом с автором и датой. Причина возврата остаётся в записи, а не в чужой почте.
Сквозная история по каждому полю
Журнал изменений хранит было и стало, автора и дату, а ссылки на другие записи разыменовываются в наименования. Рядом — отдельный журнал переходов статусов с комментариями.
Отдельная выгрузка для процессов управления доступом
События администрирования доступа — создание, изменение и удаление учётной записи, назначение и снятие ролей — выгружаются отдельным файлом за выбранный период для процессов IAM.
Годовая аттестация закрывает план сама
Аттестация подразделения подтягивает последний согласованный тест по каждому поставщику, системе и локации и закрывает план. Результат аттестации и сведения об обучении — обязательные поля.
Отчёт за любой диапазон месяцев
Период задаётся парой «месяц-год — месяц-год», годы доступны с 2018-го. Десять форм собираются из шаблонов; в самой крупной, по планам и критичным процессам, — 47 колонок.
Согласование ставит дату и имя
Перевод теста в статус «согласован» проставляет дату согласования и согласовавшего сотрудника. Это те самые два поля, которые запрашивают при проверке.
Восемь ролей в поставке
Руководитель подразделения, координатор восстановления подразделения, координатор непрерывности, менеджер приложения, DR-координатор приложения, менеджер поставщика, администратор безопасности и системная роль — с русскими и английскими наименованиями.
Из чего состоит система
Восемь разделов, которые покупатель узнаёт в своей работе. Каждый разобран отдельной страницей — со статусами, полями и правами.
- Планы непрерывности Критичные процессы, RTO и RPO, оценка ущерба, порядок перехода на резервную схему и возврата к штатной работе.
- Тестирование восстановления Офисы и площадки, поставщики, аттестация поставщиков, системы и приложения. Повторы, попытки, согласование.
- Кризисные учения Тест системы оповещения, оповещение кризисной команды и тренировка команды. Состав, явка, причина провала.
- Годовая аттестация Подтверждение готовности подразделения по последним согласованным тестам поставщиков, систем и локаций.
- Сроки и уведомления Ночная проверка по трём условиям, уведомления в приложение и на почту, календарь собственных тестов.
- Отчётность Десять форм из шаблонов за произвольный диапазон месяцев и выгрузка любого реестра в таблицу.
- Права доступа и аудит Шесть действий на 13 типов объектов защиты, построчная видимость, журналы изменений и переходов.
- Архитектура и внедрение Из чего собран продукт, как он встаёт в контур организации и что настраивается под её оргструктуру.
Кому подходит и кому хватит таблицы
Область поставки честнее любого списка преимуществ: она сразу показывает, ваш это инструмент или избыточный.
Подходит
- Сеть офисов, площадок и подразделений, по каждому из которых нужен свой тест восстановления и своя аттестация.
- Регулярная отчётность о непрерывности — внутренняя, надзорная или в головную организацию.
- Критичные процессы с заданными RTO и RPO и зависимостью от внешних поставщиков и приложений.
- Требование разделять исполнителя и согласующего и предъявлять след согласования по запросу.
- Несколько ролей с разными правами: то, что видит координатор подразделения, не должно быть видно всем.
Хватит таблицы
- Три сотрудника и один реестр: разделять полномочия не между кем, а статусная модель добавит шагов, а не порядка.
- Один офис, ни одного внешнего поставщика в критичном пути и ни одного приложения с целевым временем восстановления.
- План непрерывности пишется раз и не проверяется: без тестов и учений заполнять реестр нечем.
- Нужен только текстовый документ для проверки, а не рабочий контур, в котором этот документ живёт.
Система разворачивается в контуре организации и настраивается на её оргструктуру, справочники подразделений и состав ролей.
Опыт внедрений
Платформа внедрена в банках и профессиональных участниках рынка под надзором Банка России
- Ситибанк
- Дойче Банк
- Банк Русский Стандарт
- ОТП Банк
- Тойота Банк
- Industrial and Commercial Bank of China
- SBI Bank
- Mizuho Bank
- Кредит Европа Банк
- Международный Банк Азербайджана
- Нокс Банк
- Банк РостФинанс
- Славянбанк
- БелгородСоцБанк
- Банк Долинск
- Петербургский социальный коммерческий банк
- БрокерКредитСервис Банк
- Юг-Инвестбанк
- Синко-Банк
Как это работает: от просроченного теста до эскалации
Пять шагов на тех же данных, что и в рабочем контуре выше.
1 Ночная проверка помечает срок
Проверка идёт каждый день в 00:00 по трём условиям и рассылает уведомления ответственным — в приложение и на почту.
2 Без результата тест не двигается
Переходы по статусной модели открываются только после того, как результат внесён.
3 Отправивший не согласует сам себе
Система сравнивает автора последней записи журнала статусов с текущим пользователем. Пример заполнения.
4 Провал сам заводит повторный тест
Дочерняя запись создаётся с увеличенным счётчиком попыток и связями родителя.
5 С пятой попытки уходит эскалация
Цепочка повторов разматывается вверх до первичного теста, и уведомление получает ответственный по нему.
Посмотреть, как это работает на ваших регламентах
Приносите один критичный процесс и один просроченный тест — на демонстрации проведём их через план, согласование, повтор и годовую аттестацию.