От разрозненных таблиц и писем — к единому реестру: сбой проходит подтверждение ИТ-валидатором и ИТ-менеджером, зависшие более 24 дней инциденты эскалируются автоматически, формы ф.0409072 и ф.0420523 собираются с выбором актуальной версии по дате отчёта, а 15 ролей разводят права вместо общего доступа ко всем карточкам.
Справочник типов инцидентов делит банки по величине активов и виду лицензии — коды DT_BAC_BANK_1..6 с порогами простоя и деградации от 2 до 24 часов.
Весь текущий список внедрений платформы, указанный на этом сайте, — банки.
Отдельные коды MTR_OPDS_1..4 — переводы по несанкционированно изменённому распоряжению клиента ОПДС и несанкционированный доступ к объектам информационной инфраструктуры.
Точечные инциденты по каналу платежей, а не по кредитной организации целиком.
Клиринговые организации, НПФ, операторы цифровых финансовых активов и финансовых платформ — отдельные коды DT_FS_CC / NGPF / OEDFA / OFP / OIDFA в том же справочнике.
Тот же реестр сбоев и инцидентов, другой профиль регуляторной отчётности и надзора.
На демонстрации — реестр сбоев со статусами двойного ИТ-подтверждения, карточка инцидента операционной надёжности с автоматическим расчётом простоя и деградации и формирование ф.0409072 на тех же данных.
Если нужны детали раньше демонстрации — сбои и инциденты и требования к развёртыванию. ф.0409072 и ф.0420523 — формы регуляторной отчётности перед Банком России; ФинЦЕРТ — контур Банка России, куда уходит выгрузка по инцидентам; СУОР — смежный модуль управления операционным риском.
Сокращение трудозатрат на подготовку к проверкам Банка России и защита от операционных убытков — за счёт того, что сбой, инцидент и отчётность ведутся в одном реестре, а не собираются вручную из писем и разрозненных таблиц.
Разработано с учётом требований Банка России: справочник типов инцидентов дословно воспроизводит формулировки регулятора, а формы ф.0409072 и ф.0420523 формируются в версиях, привязанных к дате отчёта.
Не «система поддерживает контроль», а конкретные правила в коде — их можно показать на стенде и проверить в первые минуты.
Один человек не может завести сбой, подтвердить его и закрыть инцидент
Сбой проходит верификацию ИТ-валидатором, а затем ИТ-менеджером — это два разных статуса и два разных перехода. Если подтверждение сбоя информационной системы не проставлено, система сама возвращает сбой в статус «Возвращенный» с примечанием, а не оставляет его висеть на согласовании.
На переходе сбоя в статус «Подтвержден ИТ менеджером» система сама создаёт инцидент операционной надёжности, переносит поля сбоя и считает фактический простой и процент деградации технологического процесса — без повторного ввода тех же данных.
Инциденты в статусах ожидания подтверждения старше 24 дней с даты создания автоматически формируют email- и push-уведомление ИТ-валидаторам, ИТ-менеджерам и ИТ риск-менеджерам — фоновая проверка работает без участия человека.
16 типов объектов безопасности и 15 предопределённых ролей делят права не «на модуль целиком», а до вкладки карточки инцидента, сбоя, объекта и поставщика и до каждой из шести статусных моделей.
Инцидент распределяется по осям классификации (тип события, категория риска, бизнес-линия и другие) в процентах, и сумма долей по каждой оси обязана равняться 100% — иначе выводится предупреждение.
Журнал смены статусов и вкладка «История изменений» — на карточке сбоя, инцидента, объекта инфраструктуры и поставщика. Вопрос «кто и когда изменил статус» закрывается записью, а не памятью сотрудника.
Ф.0409072 существует в трёх версиях XML-схемы; система выбирает нужную по дате отчёта и готовит CSV-выгрузку в ФинЦЕРТ по утверждённому формату — без ручного слежения за тем, какая версия формы актуальна.
Сценарий «сбой → инцидент → отчётность» в СУОН ведут три роли — у каждой своя боль и своё следствие.
Риск-координатор процесса операционной надёжности ведёт весь цикл наравне с бизнес-мейкером, ИТ-валидатором и ИТ-менеджером. Его боль — разрозненность процесса и срывы сроков отчётности, когда сбой, инцидент и форма для Банка России живут в разных файлах и у разных людей.
Получает автоматическую эскалацию по зависшим инцидентам и участвует в передаче данных в СУОР. Его боль — узнать о просроченном инциденте от проверяющего, а не от системы; следствие пропущенного срока — регуляторный и репутационный риск, а не просто неудобство.
Единственная роль с доступом к отдельному контуру администрирования — ролям, правам, фильтрам безопасности и выгрузке EERS. Его боль — невозможность доказать, кто и на каком основании видит карточку инцидента; без этого контура внедрение не пройдёт проверку служб ИБ.
Сбой регистрируется один раз и без повторного ввода проходит путь до формы для Банка России — двумя ИТ-подтверждениями, автоматическим порождением инцидента и фоновым контролем сроков.
Таблица листается вбок — колонок больше, чем помещается на экране.
| № | Дата регистрации | Описание | Статус | Подтверждение ИС |
|---|---|---|---|---|
| 214 | 03.03.2026 | Недоступность процессингового шлюза | На подтверждении ИТ менеджера | Да |
| 213 | 28.02.2026 | Деградация канала связи с ЦОД | Подтвержден ИТ валидатором | Да |
| 212 | 21.02.2026 | Ошибка синхронизации реестра объектов | Возвращенный | Нет |
| 211 | 14.02.2026 | Плановое отключение резервного оборудования | Создан | — |
Колонка «Подтверждение ИС» — это подтверждение сбоя информационной системы; без него верификация не проходит.
| № | Техпроцесс | Простой, ч | Деградация, % | Статус |
|---|---|---|---|---|
| 96 | Обработка платежей | 3.5 | 40 | На подтверждении ИТ валидатора |
| 95 | Ведение реестра клиентов | 1.2 | 15 | Закрыт |
| 94 | Обработка платежей | 6.0 | 100 | Подана первичная форма |
| 93 | Валютный контроль | 0.8 | 10 | Передано в СУОР |
Простой и деградация технологического процесса считаются автоматически на переходе сбоя в статус «Подтвержден ИТ менеджером».
Данные для всех форм берутся из тех же карточек сбоев и инцидентов — без повторной сборки в таблицах.
Состав разделов, статусов и колонок — как в продукте.
Разница не в том, что файлов становится меньше. Разница в том, что у сбоя и у инцидента появляется единственная актуальная версия, статус и ответственный, а не переписка с вложениями.
Как обычно
Кто подтвердил сбой — видно только по переписке. Сколько инцидентов ждут дольше 24 дней, нужно посчитать вручную.
В СУОН
История изменений · журнал уведомлений · выгрузка в ФинЦЕРТ
Простой и деградация посчитаны системой на дате перехода. Зависший инцидент виден в реестре и в уведомлении — не только тому, кто о нём вспомнил.
Границы поставки — с обеих сторон, чтобы разговор о пилоте сразу шёл по существу.
Отчётность — под требования вашей организации
СУОН разработан с учётом требований Банка России: справочник типов инцидентов дословно воспроизводит формулировки регулятора, а формы ф.0409072 и ф.0420523 формируются в версиях, привязанных к дате отчёта. Точный перечень применимых нормативных актов и состав ролевой матрицы под структуру вашей организации согласуются при внедрении.
Разработчик — российская компания ООО «Ланселот-ИТ». Продукт разворачивается в инфраструктуре заказчика, интерфейс и справочники — на русском языке.
Платформа внедрена в банках и профессиональных участниках рынка под надзором Банка России
Перечень относится к платформе в целом; состав внедрённых продуктов у каждой организации свой.
Показываем реестр сбоев, карточку инцидента с автоматическим расчётом простоя и деградации и формирование ф.0409072 — на живом стенде, на данных, близких к вашим техпроцессам.
Путь одного сбоя до отчёта в Банк России — на тех же экранах, что и на странице.
1 Сбой зарегистрирован
Заполняются описание, дата регистрации и дата, когда процесс перестал работать.
2 Подтверждение ИТ-валидатором
Без подтверждения сбоя информационной системы переход не проходит — сбой автоматически возвращается в статус «Возвращенный».
3 Подтверждение ИТ-менеджером — рождается инцидент
Поля сбоя переносятся в инцидент без повторного ввода; инцидент связывается с объектами и процессами.
4 Фоновая проверка сроков
Проверка идёт по расписанию, без участия человека.
5 Отчётность в Банк России
Данные для отчёта берутся из карточки инцидента — без повторной сборки в таблицах.
На демонстрации это показываем на живом стенде.
Записаться на демонстрациюКак с нами связаться
Отвечаем в рабочие дни. Если удобнее письмом — напишите, приложив вопрос по существу.