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

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

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

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

Процессы EDM01 и EDM05 вызывают вопросы, так как следуют той же структуре практик (оценка, направление, мониторинг), что и процессы руководства системы управления ИТ (EDM02–EDM04), в то время как согласно принципу COBIT 5, эти процессы должны описывать управление системой руководства. Если EDM01 и EDM05 — процессы управления, то их структура должна быть больше похожа на управленческий цикл PDCA. Если же они относятся к руководству, тогда возникает вопрос: кем и на каком уровне осуществляется руководство над самой системой руководства, что представляется избыточным и противоречащим логике разделения функций руководства и управления.

Чтобы выявить и использовать стереотипы клиентов (Юг) для улучшения ИТ-услуг, следует: 1) Провести исследования и собрать информацию о существующих установках клиентов посредством опросов, интервью и анализа обратной связи. Например, для ИТ-поддержки стереотипом может быть мнение, что служба медленно реагирует на запросы. 2) Определить, какие из этих стереотипов негативны и влияют на восприятие услуги. 3) Разработать специальные мероприятия для разрушения негативных стереотипов: например, внедрить систему отслеживания времени ответа и гарантировать ответ в течение 15 минут. 4) Создать коммуникацию, демонстрирующую клиентам, что негативные стереотипы не соответствуют реальности вашей услуги. Например, сообщать клиентам при обращении в поддержку: "Спасибо за обращение, ваш запрос будет обработан в течение 15 минут". 5) Регулярно измерять, как изменяются восприятие и стереотипы после внедрения изменений. Это позволит целенаправленно улучшать восприятие вашей ИТ-услуги.

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

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

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

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