Виды тестирования и что каждый проверяет
| Вид | Что проверяет | Что остается непроверенным | Длительность | Риск для продуктива |
|---|---|---|---|---|
| Проверка оповещения | Актуальность контактов, скорость сбора штаба | Все остальное | 30 минут | Нет |
| Настольный разбор сценария | Знание ролей, порядок решений, узкие места в процедурах | Готовность техники | 2-3 часа | Нет |
| Частичное натурное переключение | Работоспособность одного резервного элемента: канал, площадка, копия | Взаимодействие элементов | От 4 часов | Умеренный |
| Комплексное учение | Процесс целиком в резервном режиме с участием подразделений | Редкие сценарии | День | Высокий, нужно окно |
| Сценарный анализ | Устойчивость показателей к гипотетическим событиям, качественная оценка операционного риска | Практическая готовность | Неделя кабинетной работы | Нет |
Виды дополняют друг друга. Банк, который делает только настольные разборы, знает, что люди понимают план, и ничего о том, переключится ли ЦОД. Банк, который делает только натурные переключения, проверяет технику раз в год и пропускает то, что замещающее лицо уволилось в марте.
Программа тестирования на год
Периодичность в положениях задана как «установленная внутренними документами», то есть организация назначает ее сама и затем обязана соблюдать. Рабочая программа для банка среднего размера:
| Квартал | Тест | Модуль плана | Участники |
|---|---|---|---|
| I | Проверка оповещения | Все | Штаб, секретарь |
| I | Настольный разбор | Кибератака с шифровальщиком | Штаб, ИБ, ИТ, операции |
| II | Частичное натурное переключение | Отказ ЦОД: переключение АБС на резервную площадку | ИТ, операции, наблюдатель от аудита |
| II | Проверка оповещения | Все | Штаб |
| III | Настольный разбор | Недоступность офиса | Штаб, АХО, HR, розница |
| III | Проверка оповещения | Все | Штаб |
| IV | Комплексное учение или настольный разбор | Сбой критичного поставщика | Штаб, закупки, ИТ |
| IV | Проверка оповещения | Все | Штаб |
| IV | Сценарный анализ и пересмотр целевых показателей | Все | Риски, владельцы процессов |
Программа утверждается правлением или уполномоченным комитетом до начала года и прикладывается к плану ОНиВД как приложение. Перенос теста оформляется решением с новой датой: пропущенный без следа тест на проверке выглядит хуже перенесенного.
Сценарий настольного разбора: пример
Вводная выдается участникам по частям, чтобы проверить решения, а не чтение плана. Пример сценария «шифровальщик» на два часа.
- 10:00. Дежурный администратор сообщает: на трех рабочих станциях операционного департамента файлы переименованы, на экране требование выкупа. Вопрос штабу: что делаем в первые 15 минут, кто принимает решение об изоляции сегмента?
- 10:20. Вводная: АБС недоступна, причина выясняется. Вопрос: активируем ли модуль «отказ информационной системы», кто объявляет, как фиксируем время?
- 10:40. Вводная: резервные копии за последние сутки недоступны, доступна копия трехдневной давности. Вопрос: что это значит для RPO переводов, какие операции восстанавливаем вручную, кто считает объем?
- 11:10. Вводная: звонок журналиста. Вопрос: кто говорит, что говорит, когда уведомляем Банк России и клиентов?
- 11:40. Вводная: ИБ подтверждает, что атака остановлена, системы можно восстанавливать. Вопрос: порядок возврата к штатной работе, кто подписывает акт восстановления, что в разбор инцидента?
Руководитель тестирования фиксирует в хронометраже время каждого решения и отклонения от плана. Отклонение это не провал: именно ради них тест проводится.
Критерии успешности
Критерии назначаются до теста и записываются в программу, иначе любой результат объявляется успешным. Типовой набор:
- Решение об активации принято в пределах срока из раздела 5 плана, например 30 минут.
- Оповещены 100 процентов участников штаба, из них ответили в течение 15 минут не менее 80 процентов.
- Переключение завершено в пределах RTO процесса; для настольного разбора: последовательность действий соответствует модулю.
- Потеря данных в пределах RPO.
- Клиентское уведомление подготовлено в пределах часа, уведомление регулятора в установленный срок.
Итог формулируется одним из трех слов: пройден, пройден с замечаниями, провален. Провал тоже результат, он дает основание для бюджета на устранение.
Протокол тестирования: шаблон
Скачать шаблон. Программа конкретного теста, хронометраж, таблица критериев с плановыми и фактическими значениями, перечень недостатков с ответственными и сроками, подписи. Формат docx, 4 страницы.
Один файл на одно тестирование; заполненные протоколы хранятся как приложение к плану ОНиВД и предъявляются при проверке. Файл отдается без регистрации и форм. Если шаблон нужно адаптировать под вашу организацию или пройти с ним проверку, напишите: как мы это делаем и сколько занимает.
Ошибки, которые видит проверяющий
- Программа есть, протоколов нет. Или протоколы есть, но на каждом «замечаний нет», что само по себе замечание.
- Тестируется один и тот же сценарий каждый год, остальные модули плана никогда никто не открывал.
- Недостатки выявлены, план устранения составлен, выполнение никто не проверил; на следующем тесте те же недостатки.
- Натурное переключение заменено записью «проверено ИТ в рабочем порядке» без даты, участников и результата.
- Участники получают сценарий заранее и репетируют: тест превращается в спектакль, план остается непроверенным.
Общий формат учений для нефинансовых компаний описан на странице «Учения по непрерывности», а проверка плана в программе BCM под ключ — на странице «Проверка плана непрерывности».
Частые вопросы
Периодичность организация устанавливает во внутренних документах и обязана соблюдать. Рабочий минимум: ежеквартальная проверка оповещения, два-три настольных разбора и одно натурное переключение в год, плюс ежегодный сценарный анализ при пересмотре целевых показателей.
Проверка того, что план обеспечения непрерывности и восстановления деятельности работает: люди знают роли, резервные схемы включаются, сроки восстановления выполняются. Виды: проверка оповещения, настольный разбор, натурное переключение, комплексное учение, сценарный анализ.
Руководит ответственный за непрерывность или назначенный руководитель тестирования, участвуют кризисный штаб и владельцы процессов, наблюдателем выступает внутренний аудит или служба управления рисками. Внешний консультант полезен как разработчик сценария и независимый наблюдатель.
От требований стандарта к работающей системе
Диагностика показывает разрыв между документами и реальностью. Дальше система строится вашими руками в программе или нашими под ключ.