Перед закрытием инцидента согласно ITIL необходимо выполнить следующие процедуры: указать код закрытия инцидента, провести опрос удовлетворенности пользователя, документировать процесс закрытия инцидента, определить наличие связи с текущей проблемой для предотвращения повторения инцидента в будущем, и формально закрыть инцидент, изменяя его статус на «закрыто».

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

Уровень Resource Capacity Management определяется как управление мощностью на уровне физических и виртуальных ресурсов (например, вычислительных мощностей, каналов связи, хранилищ данных). Независимо от того, как определена ИТ-услуга (ресурс, система или бизнес-процесс), Resource Capacity Management остается необходимым, поскольку в конечном итоге все услуги требуют выделения и управления конкретными ресурсами. Однако его роль может варьироваться от основной (при предоставлении услуг как ресурсов) до поддерживающей (при управлении бизнес-процессами).

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

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

При правильно организованном процессе учета времени на саму процедуру учета тратится значительно меньше времени, чем многие предполагают. По приведенным данным, за весь 2014 год на учет времени ушло 6 часов 4 минуты, что составляет 0,32% всего рабочего времени за год. Это означает, что даже при тщательном учете по множеству категорий временные затраты на ведение учета минимальны и составляют доли процента.

Нисходящая ветка V-модели представляет процесс декомпозиции бизнес-требований на технические спецификации — от определения бизнес-процессов в желаемых условиях ('to-be') к проектированию конкретных компонентов инфраструктуры. Восходящая ветка модели демонстрирует обратный процесс интеграции и проверки, где происходит тестирование технических компонентов и постепенное подтверждение соответствия системы исходным бизнес-требованиям. Каждый уровень нисходящей ветки имеет соответствующий уровень проверки на восходящей ветке, что обеспечивает полное покрытие требований проверками на всех уровнях

Ловушка локальной оптимизации — это сосредоточение исключительно на скорости реакции на инциденты при игнорировании мер по профилактике и сокращению их количества. Чтобы избежать этой ловушки, необходимо установить целевое время решения, которое значительно короче текущих показателей. Это стимулирует поиск решений не только на уровне оперативной реакции, но и на уровне системы мониторинга, предотвращения и подготовки обходных решений. В этом помогает метод Expanded incident lifecycle.

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

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