Жизненный цикл недостатка

Недостаток попадает в реестр либо вручную, либо из внешней системы-источника, и с этого момента живёт по одному и тому же контуру: карточка держит источник выявления, линию защиты, рейтинг существенности, владельца, координаторов и один из двух сценариев обработки — Accept (принять риск через исключение) или Remediate (устранить через корректирующий план). Пока сценарий не выбран и не подтверждён, недостаток не открывается.

У каждого недостатка есть источник выявления (Issue Source Level) и линия защиты — 1-я, 2-я, 3-я или внешняя. От комбинации источника и линии защиты зависит, что видно в карточке и какие согласования потребуются дальше — это не декоративная классификация, а входные данные для матрицы видимости и для контура Required approver-ISO.

• База (BASE)Самостоятельно найденные недостатки: внутренний мониторинг, наблюдения руководства, проверки поставщиков, внешний аудит
• 2-я линия защиты (LOD2)Комплаенс, независимый риск-контроль, операционные риски — контролирующие функции поверх бизнеса
• Регуляторная (REGULATORY)Предписания, действия и проверки регулятора — Commitment, Enforcement Action, Exam, Regulatory Interaction
• ИБ и уязвимости (IS/VA)Информационная безопасность и Оценка уязвимостей — источники с обязательным контуром Обязательное согласование ответственного за ИБ

Рейтинг существенности — шкала от 1 (самый значимый) до 5. Он не просто описательное поле: от него зависит, можно ли вообще принять риск, и нужна ли дополнительная проверка качества данных при активации.

Смена линии защиты на 1-ю или внешнюю (4), а также переход рейтинга через границы 1–4 ⇄ 5, включает дополнительную проверку качества данных при активации — карточка не откроется без прохождения Data Quality Review.

Собственный движок статусов ISM ведёт недостаток через 48 статусов, сгруппированных в четыре стадии: Draft, Открыто, Closed, Cancelled. Каждый переход описан декларативно — откуда, куда, какая форма подтверждения (с обязательным или необязательным комментарием) и какой список условий должен выполниться целиком, прежде чем кнопка перехода вообще появится в интерфейсе.

Основной сценарий выглядит так: активация из Draft требует подтверждения владельцем или координатором и, если рейтинг или линия защиты того требуют, — прохождения проверки качества данных ещё до открытия. Закрытие возможно только когда все связанные CAP закрыты, все находки (Finding) по недостаткам источника Vulnerability Assessment закрыты, и — если включена — пройдена независимая валидация внутреннего аудита. Изменение полей у активного недостатка источника ИБ/уязвимостей проходит отдельным контуром Required approver-ISO с автоматическим откатом значений при отклонении.

Правило простое и применяется на каждом шаге без исключений: тот, кто отправил недостаток на согласование, не может сам себя одобрить, а тот, кто только что подтвердил один шаг, не может тут же подтвердить следующий за тем же недостатком.

Правило действует на уровне журнала переходов, а не только на уровне ролей: система хранит, кто именно выполнил последнее действие, и не даёт тому же человеку выполнить следующее — даже если формально у него есть право на обе роли.

Прежде чем недостаток откроется, изменится в контролируемых полях или закроется, координатор качества может потребовать доработки: по каждому проверяемому атрибуту (существенности, риску, описанию проблемы, причине, последствию, контексту) выставляется статус — доработка рекомендована или доработка выполнена. Пока хотя бы один атрибут в статусе «доработка рекомендована», переход дальше закрыт.

Для источников информационной безопасности и уязвимостей действует отдельная роль координатора качества (IS Quality Coordinator) — обычная роль координатора качества к таким недостаткам доступа не имеет.

Закрыть недостаток нельзя одним кликом владельца. Система проверяет всю цепочку целиком: если сценарий — устранение, должен быть хотя бы один корректирующий план, и он должен быть закрыт; если принятие риска — связанное исключение должно быть закрыто (либо оставаться открытым только потому, что оно относится и к другим, ещё не закрытым, недостаткам); для источника уязвимостей — обязаны быть закрыты все находки (Finding).

Если для недостатка включена независимая валидация (IA Validation), закрытие проходит через отдельный контур: внутренний аудит проверяет готовность, утверждает валидацию, затем — при условии, что все корректирующие планы закрыты — подтверждает завершение. Только после этого доступна кнопка закрытия, и её тоже подтверждает не тот, кто её нажал на предыдущем шаге.

• ✓ Все корректирующие планы закрыты
• ✓ Находки (Finding) по недостаткам источника Оценка уязвимостей закрыты
• ✓ Связанное исключение закрыто — или остаётся открытым по другим недостаткам
• ✓ Независимая валидация внутреннего аудита пройдена — если она требуется для этого недостатка

Подробнее о том, кто именно валидирует закрытие и как устроена независимость этого контроля — на странице прав доступа и разграничения полномочий.