На онлайн-ресурсе ISACA – «COBIT FOCUS» Питер С. Тессин (CISA, CRISC, CISM, CGEIT) делится своим опытом применения руководства корпоративными ИТ (Governance of Enterprise IT – GEIT). В серии из 6 статей рассматривается кейс по решению управленческой проблемы.
Эта вторая статья, в которой основное внимание уделяется планированию решения проблемы, указанной в части 1. В первой части рассматривалась проблема, связанная с контролями, разработанными руководством, без привлечения ответственного за управление системы внутреннего контроля на предприятии. Отсутствие системы внутреннего контроля привело к риску, что предприятие может не соответствовать нормативным требованиям. В этой статье объясняется, как разработать план решения с позиции GEIT для устранения выявленных недостатков, кто должен принять участие и каких результатов ожидать по результатам реализации плана.
Основной проблемой, выявленной командой внутреннего аудита (Internal Audit – IA), является отсутствие надлежащего контроля. Это говорит о недостаточном понимании потребностей заинтересованных сторон; отсутствие сопоставления этих потребностей с целями предприятия, связанных с ИТ-целями. Разработка показателей системы внутреннего контроля позволяет гарантировать соблюдение требований предприятия.
Теперь необходимо формализовать структуру руководства, чтобы требования заинтересованных сторон соответствовали целям предприятия и ИТ-целям. При правильной реализации заинтересованные стороны могут быть уверены, что в охват войдут все идентифицированные требования (внешние и внутренние), позволяющие выявить недостатки. Создание этой формальной структуры обеспечит полное представление о среде внутреннего контроля, которая в настоящее время отсутствует. Напомним, что в COBIT заинтересованные стороны взаимодействуют в первую очередь с советом директоров и CEO.
В условиях ограниченности ресурсов всегда есть конкурирующие проекты или приоритеты, в которых они могут быть задействованы. Поэтому заинтересованные стороны должны определить, как ресурсы распределить для достижения целей. Такой подход позволит создавать ценность заинтересованным сторонам, обеспечивая при этом соблюдение всех требований.
Проектирование структуры GEIT
COBIT 5 используется в качестве основы для проектирования структуры управления. COBIT 5 показывает, как сформировать структуру управления и определить роли, необходимые для ее поддержки. Процесс проектирования начинается с понимания потребностей заинтересованных сторон. В COBIT 5 разработана «Таблица соответствия потребностей заинтересованных сторон с бизнес-целями» (COBIT5: Бизнес-модель по руководству и управлению предприятием, рис. 24).
Первая задача – определить, какие потребности заинтересованных сторон соотносятся с бизнес-целями предприятия, и на чем сконцентрироваться в первую очередь. Для упрощения процесса, уделим внимание удовлетворению одной из потребностей заинтересованных сторон. Она ляжет в основу при проектировании структуры управления для реализации мероприятий по внедрению системы внутреннего контроля. На рис. 1 представлен мэппинг потребности заинтересованных сторон «Прозрачны ли за затраты и инвестиции в ИТ?» с бизнес-целями предприятия.
Рассмотрим бизнес-цель «5. Финансовая прозрачность» и сопоставим ее с ИТ-целями, которые смогут поддержать достижение выбранной бизнес-цели.
На рисунке 2 представлена, разработанная COBIT5, таблица соответствия бизнес-целей с ИТ-целями предприятия.
Как мы видим, бизнес-цели предприятия «5. Финансовая прозрачность» соответствует ИТ-цель «06. Прозрачность ИТ-затрат, выгод и рисков».
Окончательное сопоставление, которое необходимо сделать, – определить, какие ресурсы будут поддерживать ИТ-цель. На рисунке 3. Представлен мэппинг ИТ-целей с ИТ-процессами, которые являются основным фактором, определяющим ресурсы в структуре GEIT.
ИТ-цель «06. Прозрачность ИТ-затрат, выгод и рисков» в основном поддерживается 8-ю различными ИТ-процессами, входящими в эталонную модель процессов.
Для начала выберем ИТ-процесс «APO13. Управление безопасностью», т.к. в прошлом году предприятие сделало значительные инвестиции в область обеспечения ИБ. APO13 в первую очередь ориентирован на управление системой информационной безопасности (Information Security Management System – ISMS).
Определение ролей
Детальное описание каждого процесса содержится в публикации COBIT 5: Enabling Processes . Деятельность внутри процессов разделены на практики. Это уровень, на котором в большинстве случаев фактически выполняется работа. Каждая практика рассказывает, какие ресурсы необходимы (входы), что делать (описание деятельности) и что будет производиться (выходы).
Первая задача – понять, какие роли будут участвовать в практике этого процесса на предприятии. Каждый процесс содержит матрицу RACI (Responsible, Accountable, Consulted, Informed), в которой по каждой практике распределяются роли по ответственности, исполнению, консультированию и информированию. Основное внимание при распределении ролей мы уделим на исполнение и ответственность по работам в рамках практик.
Матрица RACI для процесса APO13 показывает, что директор по ИБ (Chief Information Security Officer – CISO) является ответственным по каждой практике. Обратите внимание, что только одна роль может быть назначена за несение ответственности. Это обеспечивает последовательное направление и разработку KPI, что будет очень важно позже. Есть две роли, которые разделяют ответственность за исполнение трех практик в APO13 – директор по ИТ (Chief Information Officer – CIO) и менеджер по ИБ.
Как выглядят конечные результаты
Определите, какие роли будет задействованы при создании рабочих продуктов.
Процесс APO13 «Управление безопасностью» имеет 3 связанные практики:
- APO13.01 Создание и поддержка ISMS
- APO13.02 Определение плана работ по рискам ИБ и управление ими
- APO13.03 Мониторинг и проверка ISMS
Для понимания общих потребностей в ресурсах для каждой практики необходимо определить рабочие продукты. В COBIT 5: Enabling Processes описывает результаты работы практик. На рисунке 4 представлены выходы для практик процесса APO13.
Рисунок 4 – Практика управления и связанные с ней результаты
| Практика | Выходы |
| APO 13.01 | Политика в отношении ISMS, заявление о сфере действия ISMS |
| APO 13.02 | План работы с рисками ИБ, бизнес-обоснование по ИБ |
| APO 13.03 | Отчеты о проведении аудита ISMS, рекомендации по совершенствованию ISMS |
Для облегчения идентификации и создания документов, каждый рабочий продукт должен быть дополнительно описан. Описание рабочих продуктов содержатся в Модели оценки процессов COBIT5 PAM (Process Assessment Model (Приложение B.2 Рисунок 19 «Результаты рабочих продуктов для уровня 1». Рабочие продукты для практик процесса APO13 представлены на Рисунке 5.
Рисунок 5 – Выходы из рабочих продуктов
| Рабочий продукт | Описание |
| Политика ISMS | Политика, стандартная или операционная практика, которая является частью ISMS |
| Заявление о сфере действия ISMS | Часть документации по стратегии и планированию ISMS или план программы ISMS |
| План работы с рисками ИБ | Часть процесса оценки рисков ISMS, основанная на профиле риска |
| Бизнес-обоснование ИБ | Только в случае необходимости для проекта или программы проектов в области ИБ |
| Отчеты о проведении аудита ISMS | Часть отчетности внутреннего аудита или ежемесячной отчетности по ИБ, которая также будет интегрирована в систему отчетности по реагированию на инциденты, вызванные нарушением ИБ |
| Рекомендации по совершенствованию ISMS | Часть стандартного мониторинга и отчетности по ISMS. Оценщики просматривают или запрашивают эту информацию. |
Планирование проекта
В следующей части мы обсудим создание плана проекта с шаблонами, в зависимости от возникающих ситуаций, а также какой объем и время выполнения работ потребуется для решения проблемы.
