Вместо таблиц Excel и переписки по почте — единый реестр недостатков (Issue), корректирующих планов (CAP) с вехами и оформленных исключений (Exception) с очередью согласования. Каждый переход по 48 статусам Issue, 30 статусам CAP и 24 статусам Exception требует подтверждения вторым лицом, 13 расчётных правил ежедневно пересчитывают просрочки и сроки, а закрытие проходит через проверку качества данных и независимую валидацию внутреннего аудита.
На демонстрации — путь одного недостатка от регистрации до закрытия: активация с обязательным согласованием, проверка качества данных, контур Required approver-ISO для источников информационной безопасности и независимая валидация внутреннего аудита — на статусах и сроках, как в продукте.
Источники недостатков разнесены по линиям защиты — базовые источники, вторая линия (комплаенс, операционные риски) и отдельная группа для информационной безопасности и оценки уязвимостей.
Для этой отдельной группы источников действует обязательный контур Обязательное согласование ответственного за ИБ — без технического согласования статус недостатка не продвинется.
Один контур недостатков закрывает отчётность в обе стороны — перед Банком России и перед регулятором страны материнской организации, без второго реестра.
Разделение полномочий и независимая валидация внутреннего аудита работают одинаково для обеих линий отчётности.
Тот же контур Issue → CAP и Issue → Exception, что и в банке — владелец платформы называет профессиональных участников рынка ценных бумаг отдельной категорией внедрений, наравне с банками.
Отраслевая специфика задаётся справочниками источников и ролями, без доработки кода.
Меньше ручной сверки реестров перед проверкой Банка России и меньше риска операционных убытков от недостатка, который закрыли с опозданием или без нужного согласования.
Разработано с учётом требований к разделению полномочий и независимой проверке, обязательных для организаций под надзором Банка России.
Прежде чем звонить — права доступа и разграничение полномочий и архитектура и внедрение. ISM — Issue Management, управление недостатками.
Основные показатели модуля.
Один реестр на каждую сущность, один статус, один ответственный и один срок. Ниже — реестры, колонки и статусы в том виде, в каком они заведены в продукте.
Таблица листается вбок — колонок больше, чем помещается на экране.
| № | Источник | Линия защиты | Существенность | Статус | Ответственный | Целевая дата |
|---|---|---|---|---|---|---|
| 412 | Информационная безопасность | 2 | 5 | На согласовании — обязательное согласование ответственного за ИБ | ИБ | 12.11.2026 |
| 411 | Регуляторное событие: проверка | Внешний | 4 | Открыто | Комплаенс | 03.11.2026 |
| 410 | Управление операционным риском | 2 | 3 | Закрыто — выполнено | Операционные риски | 20.10.2026 |
| 409 | Внешний аудит | 3 | 2 | Черновик | Внутренний аудит | 28.11.2026 |
| 408 | Оценка уязвимостей | 2 | 5 | Приостановлено — ожидается проверка внутренним аудитом | ИБ | 05.11.2026 |
Обязательное согласование ответственного за ИБ перехватывает переход отдельно от обычного согласования — только для источников Информационная безопасность и Оценка уязвимостей.
| № | Недостаток | Тип корректирующего плана | Статус | Цветовой индикатор | Целевая дата |
|---|---|---|---|---|---|
| CAP-118 | Issue №412 | Устранение недостатка | Изменение срока на согласовании | Красный | 30.11.2026 |
| CAP-117 | Issue №409 | Компенсирующие меры | Открыто | Жёлтый | 15.11.2026 |
| CAP-116 | Issue №405 | Обеспечение устойчивости результата | Закрыто — выполнено | Зелёный | 01.10.2026 |
| CAP-115 | Issue №398 | Планирование | Черновик | Жёлтый | 10.12.2026 |
цветовой индикатор состояния показывается словами Красный, Жёлтый, Зелёный, а не числом — так его невозможно перепутать при быстром просмотре реестра.
| № | Источник | Уровень | Статус | Согласующий сейчас | Срок действия |
|---|---|---|---|---|---|
| EXC-54 | Оценка уязвимостей | 4 | Повышение уровня исключения на согласовании | ISO | до 20.03.2027 |
| EXC-53 | Регуляторное событие: обязательство | 2 | Открыто | Бизнес-подразделение | до 15.09.2026 |
| EXC-52 | Информационная безопасность | 3 | Срок истёк | — | истёк 01.09.2026 |
| EXC-51 | Комплаенс | 5 | Экспертная проверка завершена | Координатор | до 10.04.2027 |
Согласующие утверждают исключение по порядку: ISO → Бизнес-подразделение → до трёх дополнительных → Координатор. Колонка показывает, чья очередь сейчас.
Состав колонок, этапов и статусов — как в продукте.
Разница не в том, что таблиц становится меньше. Разница в том, что у недостатка появляется единственная актуальная версия, статус и срок, который считает не человек.
Как обычно
Кто согласовал — видно только по переписке. Актуальная версия — у того, кто последним прислал файл.
В системе
История изменений · история статусов · очередь согласования · журнал уведомлений
Версия одна. У каждого недостатка — история, ответственный и срок, который пересчитывается сам.
Три роли, каждая из которых способна остановить переход недостатка по статусам, а не просто наблюдает за реестром.
Реестр недостатков и корректирующих планов, их сроки и согласование исполнителем и проверяющим ведутся в таблицах и переписке. Актуальный статус процесса приходится уточнять у сотрудника, который последним обновлял файл.
В системе руководитель — владелец Issue и CAP (ismIssueOwner / ismCapOwner) и видит просрочки автоматически, без ручной сверки перед проверкой.
Недостаток по информационной безопасности или оценке уязвимостей может закрыться без отдельного технического согласования, если оно не встроено в сам процесс.
Контур Обязательное согласование ответственного за ИБ блокирует переход таких недостатков без подтверждения Старший ответственный за ИБ — кнопки согласования не появятся, пока подтверждения нет.
Без независимой проверки закрытие значимого недостатка легко провести тем же кругом людей, что его выявил и устранял.
Часть недостатков не закрывается без Проверка внутренним аудитом — независимой валидации внутренним аудитом, зафиксированной отдельными полями карточки.
Не «система поддерживает контроль», а конкретные правила, заложенные в статусную модель. Их можно проверить на стенде за первые минуты показа.
Один человек не может завести недостаток, согласовать его и закрыть
Условия перехода isNotSubmitter, isNotSenderAction и isNotPreviousApproverIso не позволяют автору карточки или предыдущему согласующему подтвердить собственное действие — это встроено в статусную модель, а не оставлено на дисциплину сотрудников.
Недостатки, выявленные при проверке информационной безопасности или оценке уязвимостей, требуют отдельного подтверждения старшим сотрудником информационной безопасности. Без этого подтверждения переход к следующему статусу недоступен.
ISO → Бизнес-подразделение → до трёх дополнительных согласующих → Координатор. Текущим считается первый неодобренный по порядку — очередь нельзя пройти вне очереди.
Правило разделения полномочий запрещает сотруднику, отправившему Issue или CAP на активацию, самому провести проверку качества данных по этой же карточке.
Проверка качества данных проходит при открытии, изменении и закрытии недостатка — отдельными статусами и отдельной ролью, а не одной галочкой в форме.
Проверка внутренним аудитом — независимая валидация внутренним аудитом — зафиксирована отдельными полями карточки и останавливает закрытие недостатка до её прохождения.
13 расчётных правил для Issue, 5 для CAP и 6 для Exception запускаются по расписанию и пересчитывают просрочки без участия человека.
Матрица видимости полей строится по комбинации тип карточки × роль × группа источника недостатка — семь правил, включая составные условия.
Каждое изменение поля пишется в журнал; при отклонении согласования значения можно вернуть к состоянию до перехода — а не восстанавливать по памяти.
Интеграция идёт по уникальному ключу записи source_key: повторное сообщение о том же недостатке не создаёт вторую карточку.
Границы поставки — с обеих сторон, чтобы разговор о пилоте сразу шёл по существу.
Подходит
Не подходит
Отчётные шаблоны — под требования вашей организации
Разработано с учётом требований к разделению полномочий и независимой проверке, обязательных для организаций под надзором Банка России. Состав отчётных шаблонов и справочников источников настраивается под вашу организацию — без правки кода.
Разработчик — российская компания ООО «Ланселот-ИТ». Продукт разворачивается в инфраструктуре заказчика.
Платформа внедрена в банках и профессиональных участниках рынка под надзором Банка России
Перечень относится к платформе в целом; состав внедрённых продуктов у каждой организации свой.
Показываем работающий контур: регистрацию недостатка, обязательное согласование, контур Required approver-ISO, проверку качества данных и независимую валидацию внутреннего аудита. Состав показа согласуем заранее.
Обычный маршрут недостатка за пять шагов — на тех же статусах, что и в продукте. Ролик повторяется по кругу.
1 Регистрация недостатка
Сотрудник источника заводит недостаток и указывает владельца и координаторов.
2 Проверка качества данных
Сотрудник, отправивший недостаток на активацию, не может сам провести эту проверку — правило разделения полномочий.
3 Обязательное согласование ответственного за ИБ
Для этой группы источников переход недоступен без отдельного технического подтверждения.
4. Корректирующий план или исключение
Сценарий Принять риск/Устранить недостаток определяет, что происходит дальше — план устранения или оформленное исключение.
5 Независимая валидация и закрытие
Часть недостатков не закрывается без независимой валидации внутренним аудитом.
На демонстрации это показывается на живом стенде.
Запросить демонстрациюКак с нами связаться
Отвечаем в рабочие дни. Если удобнее письмом — напишите, приложив вопрос по существу.