В COBIT5 for Risk ИТ-риск определен как бизнес-риск, связанный с приобретением, адаптацией, использованием, владением, функционированием и эксплуатацией информационных технологий в организации. Это определение подчеркивает, что ИТ-риски не изолированы от бизнеса, а являются частью общей системы управления бизнес-рисками. ИТ-риски могут влиять на достижение бизнес-целей и поэтому должны рассматриваться и управляться в контексте бизнес-потребностей и требований.

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

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

Устранением последствий разового негативного события занимается практика управления инцидентами. Она направлена на оперативное восстановление нормального функционирования услуги после её прерывания или ухудшения качества, вызванных реализовавшимся риском.

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

При использовании дорожной карты сроки реализации требований определяются иначе, чем при работе только с бэклогом. Сначала обозначаются конкретные целевые состояния и сроки, в которые необходимо достичь этих состояний. Затем определяется состав работ по достижению каждого целевого состояния, включая не только список требований, но и всю деятельность, необходимую для движения к этому состоянию. Под этот состав работ намечается календарь конкретных действий, основанный на опыте команды. Этот подход учитывает не только сложность самих задач, но и дополнительные факторы: время на уточнение требований, согласования, синхронизацию со смежными командами, организацию поставок, согласование приёмочных работ, резервирование ресурсов сервисных команд. Благодаря такому подходу удается дать более точные прогнозные сроки реализации запросов бизнеса, так как виден полный контекст работы над достижением целевого состояния, а не только отдельная задача из бэклога.

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

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

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

Группа 'б' включает проблемы, закрытые без решения, но с непродуктивной тратой ресурсов. Такие случаи попадают в знаменатель формулы, но не учитываются в числителе, что приводит к снижению значения метрики. Это необходимо для того, чтобы действия, имитирующие активность без реального результата (например, массовое закрытие проблем с кодом 'Решение нецелесообразно'), отрицательно сказывались на оценке продуктивности.