Публикация Risk Scenarios Using COBIT 5 for Risk существенно расширяет возможности COBIT 5 for Risk, предоставляя подробное описание ранее заявленных сценариев рисков в соответствии с шаблоном профиля риска (Risk Profile). Включает в себя конкретные примеры реализации рисков в организациях, детальное описание каждого из пяти компонентов структуры сценария, анализ влияния на три ключевые области (получение ценности от ИТ, выполнение программ и проектов, эксплуатация ИТ-услуг), указание применимых стратегий реагирования и применение семи факторов влияния для снижения рисков с оценкой их эффективности. Документ содержит почти двести страниц детального анализа, что делает его самым подробным и актуальным описанием типовых ИТ-рисков от ISACA.

Релевантность метрики означает её соответствие и полезность для достижения поставленных целей. Это проверка, действительно ли нужно измерять данный показатель, чтобы принимать управленческие решения. Если данные не используются для конкретных решений или действий, метрика теряет смысл и не соответствует критерию R из SMART. Например, отчётность без последующих действий — нерелевантна.

Для определения компонентов, влияющих на снижение производительности, следует сравнить текущие метрики с ранее зафиксированными baseline-данными. Если известно, как система вела себя раньше при аналогичной нагрузке, можно выявить те элементы, чьи характеристики изменились. Например, если ранее при 1000 операциях загрузка диска составляла 40%, а сейчас — 90%, это указывает на проблему в дисковой подсистеме. Важно учитывать влияние всех уровней: прикладного ПО, баз данных, серверного оборудования и сети.

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

Из-за накопления прав через систему запросов возникают проблемы, связанные с угрозой информационной безопасности. Уникальные пользователи и склонность людей сохранять избыточные права даже после того, как они перестают быть необходимыми, приводят к тому, что у пользователей накапливаются неактуальные права. Это делает их потенциальным источником угроз безопасности, так как наличие ненужных прав повышает риск несанкционированного доступа или утечки информации. Поэтому важно регулярно проводить аудиты прав доступа и отзывать те права, которые больше не требуются для выполнения служебных обязанностей.

Некоторые организации полагают, что управление проблемами избыточно, если отсутствуют повторяющиеся инциденты. Такое мнение возникает из-за узкого понимания проблемы только как следствия частых инцидентов. На самом деле, даже единичные серьезные инциденты или скрытые уязвимости в инфраструктуре могут требовать решения проблем. Игнорирование проактивного анализа приводит к тому, что организации сталкиваются с критическими сбоями, которые могли бы быть предотвращены.

Основные недостатки алгоритмов автоназначения внутри групп: не учитывают сложность задач (меньше задач не означает меньшую загрузку), зависят от точности учёта недоступности сотрудников (особенно краткосрочной, например на совещании или в обед), циклический алгоритм игнорирует различия в компетенции персонала, а алгоритмы выравнивания и профилирования нагрузки поощряют перегрузку более эффективных сотрудников («дурака работа любит»). Все эти факторы могут фактически увеличить время обработки задач, а не сократить его.

Оптимальный срок выдачи прав определяется бизнес-требованиями и анализом текущих возможностей ИТ-подразделения. Для его установления необходимо провести консультации с бизнес-подразделениями для понимания их ожиданий и оценки влияния задержек на операционную деятельность. Затем следует проанализировать текущие процессы выдачи прав, выявить узкие места (длинные цепочки согласований, ручная обработка заявок, нехватка персонала) и оценить возможности их устранения через оптимизацию или автоматизацию. На основе этого анализа устанавливается реалистичный срок, который постепенно можно сокращать при внедрении улучшений. Важно зафиксировать срок в SLA и организовать систему мониторинга выполнения.

Переход на подход Zero Known Defects представляет сложности для команд, потому что он требует значительных изменений в мышлении и процессах. Команды должны отказаться от традиционной парадигмы 'дефекты устраним когда-нибудь в зависимости от их критичности' и изменить приоритеты, ставя устранение дефектов выше разработки новых функций. Это приводит к таким сложностям, как отсутствие понятия приоритета дефекта, невозможность начинать новую разработку пока в бэклоге есть дефекты, и необходимость пересмотра планирования работы. Особенно сложно это реализовать на проектах, которые уже существуют долгое время, на 'чистом поле' (green field) переход проще.

При расчете Flow Efficiency возникает вопрос, какое рабочее время учитывать. Если команда состоит из сотрудников с разными графиками работы (например, аналитики в Новосибирске, разработчики в Москве, тестировщик на неполную ставку), возникает сложность выбора календаря. Можно было бы использовать календарь отдельного сотрудника, но в случае совместной работы над задачей это не отражает реальную ситуацию. В результате многие команды прибегают к упрощенным оценкам или договоренностям, которые дают неточные результаты, а не строгий расчет. Это приводит к ситуации, когда формально рассчитанная Flow Efficiency может отличаться от реальной эффективности в несколько раз.