От аудита соответствия к управлению ИТ-рисками

Международная группа ABB – известный поставщик оборудования и решений в области технологий для электроэнергетики и автоматизации. Офисы и производственные мощности концерна расположены более чем в ста странах, включая и Россию, где на восьми производственных площадках и более чем в десяти региональных отделениях работает около 2 тыс. сотрудников. К началу 2006 года у компании возникла потребность в серьезной переработке системы внутреннего контроля – с 2006 года иностранные эмитенты ценных бумаг, котирующихся на американских фондовых биржах, обязаны были соответствовать требованиям статьи 404 закона Сарбейнса-Оксли (Sarbanes-Oxley Act, SOX). Учитывая, что нормативы SOX 404 весьма жестки, ABB ожидал колоссальный объем работ. Кроме того, в течение 2005 года в ABB была разработана новая корпоративная стратегия, которая также требовала соответствующей комплексной коррекции процессов и подходов во всех функциональных областях.

Работа по достижению соответствия новым требованиям велась всеми подразделениями и региональными офисами, в том числе ИТ-департаментом российского подразделения компании.

Этапы большого пути

Обе задачи – достижение соответствия SOX 404 и разработка новой системы управления ИТ, по сути, тесно связаны и требовали совершенствования внутренних процессов и процедур, однако скорости внедрения изменений различались существенно. Задача соответствия SOX 404 требовала немедленного решения – достижения ключевых критериев в течение месяцев, а задача по разработке новой системы управления ИТ была сформулирована как «Совершенствование системы управления ИТ и ИТ-безопасности» (IT Governance & Security), что позволяло провести тщательную подготовку и спланировать работы на несколько лет вперед.

За четыре года была выстроена комплексная система внутреннего контроля и разработана стратегия перехода к непрерывному управлению ИТ-рисками, реализация которой началась в 2010 году.

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

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

Рассмотрим подробнее детали каждого этапа.

Аудиты соответствия

Объем и порядок работ по SOX 404 был вполне типичным. На уровне группы был определен подход к масштабу тестирования, составлены график подключения к проекту региональных подразделений и стандартный перечень процессных контролей, сформировано разбиение контролей на группы (контроли, относящиеся к ИТ, попали в выделенную группу с кодом Q), установлены роль подразделений внутреннего контроля и порядок привлечения внешних аудиторов и т.п.

На уровне страны стандартные контроли были локализованы, т.е. переформулированы и конкретизированы с учетом специфики существующих процессов, но с сохранением заложенного в контроль смысла. То есть, если в процессе Application Change Management (управление изменениями в бизнес-приложениях) один из стандартных контролей звучал как «Убедиться, что для каждого запроса на изменение выполнены категоризация и начальная оценка риска», то локализованный контроль звучал уже, например, как «Убедиться, что каждый запрос на изменение для приложения ABC в базе регистрации запросов XYZ утвержден менеджером изменений, который внес в поля X1 и X2 значения категории и риска предлагаемого изменения в соответствии с инструкцией DEF». Далее следовала коррекция существующей процессной документации, а недостающая заново разрабатывалась для включения контролей в соответствующие точки бизнес-процессов. Реально это вылилось в практически стопроцентную разработку новой процессной документации. Поскольку требования были жесткими, а сроки короткими, то на первой итерации документация готовилась исключительно с целью удовлетворения требований аудиторов SOX, и для реальной жизни ее ценность была неочевидной.

Третий и четвертый кварталы первого года были посвящены аудитам и коррекциям. Сначала было проведено внутреннее тестирование контролей, итоги тестирования задокументированы и подшиты в архив. Еженедельные отчеты отдела внутреннего контроля компании напоминали военные сводки: «Столько-то контролей протестировано, столько-то из них успешно, план выполнен на столько-то процентов – мы отстаем от графика!». Результаты тестирования были проверены внутренними аудиторами, приехавшими из штаб-квартиры ABB, а затем и внешними аудиторами компании Ernst & Young. По контролям, давшим негативный результат, были выполнены коррекции процессов и проведено повторное тестирование. Примерно четверть штатного персонала департамента ИТ была отвлечена только на эти работы. Часть проектов, в том числе инициированных основным бизнесом, была переведена на более низкий приоритет или приостановлена.

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

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

Можно ли что-то изменить? Ответ был связан со второй задачей – системой управления ИТ. На начальном этапе ИТ-аудиторы сосредоточились, что вполне естественно, на фундаментальных процессах управления инцидентами и изменениями, и эти же процессы покрывали львиную долю требований к ИТ-контролям, поэтому очевидным решением казалось проводить совершенствование базовых процессов с учетом требований и контролей SOX. Далее ИТ-аудиторы провели ревизию системы управления ИТ и ИТ-безопасности и сформулировали перечень областей для улучшения, начиная от внедрения процедур идентификации пользователя при сбросе пароля или ежегодного подписания бизнес-менеджерами соглашения по параметрам RPO/RTO для процесса резервного копирования и восстановления данных бизнес-приложений и заканчивая разработкой локальных политик по управлению документами или модификаций проектной методологии для разных категорий ИТ-проектов.

Параллельно проводилась вторая итерация коррекции процессной документации. В этот раз основное внимание было уделено не столько требованиям SOX, которые были в целом учтены на первой итерации, сколько попыткам увязать контроли SOX с логикой процессов. Теперь, когда набор требований стало возможно изложить в виде более взвешенного технического задания, к работе были подключены внешние силы – компания IT Expert. Благодаря помощи консалтинга удалось разработать детальные описания главных процессов?– управления инцидентами и управления изменениями, а также подготовить базовое описание процесса управления конфигурациями. Часть SOX-контролей вполне гармонично разместилась в узлах ИТ-процессов. Дополнительным плюсом использования консалтинга стала более логичная увязка базовых процессов с каталогом ИТ-сервисов. Вряд ли стоит говорить, что все процессы были не только формализованы, но и хорошо документированы, вплоть до детальных описаний отдельных процедур.

В это же время со стороны штаб-квартиры ABB был сделан еще один концептуальный шаг – принято решение о ежегодном проведении процедуры оценки рисков в области ИТ и утвержден формат ее проведения. Таким образом для бизнес-менеджмента оценка ИТ-рисков из разряда «перестраховочных прихотей ИТ-департамента» перешла в разряд обязательных процедур. Правда, на этом этапе оценка рисков была скорее однократным ежегодным упражнением, чем некой комплексной системой.

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

Система внутреннего контроля

Существование системы внутреннего контроля в ИТ (СВК ИТ) подразумевает наличие полной модели работы организации. При использовании процессного подхода это эффективно решается с помощью модели процессов ITIL. Идея наличия модели процессов совпадала у нас также и с рекомендацией аудиторов создать связную структуру ИТ-процессов IT Process Framework, которая позволила бы более осмысленно подойти к вопросам планирования дальнейшего развития процессов.

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

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

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

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

Благодаря комбинации COBIT/ITIL все существенные контроли изначально были интегрированы в модель управления, поэтому одновременно с системой управления сформировалась и СВК ИТ. Конечно, на начальном этапе обе системы еще далеки от идеала, однако уже соответствуют приемлемому для аудиторов уровню зрелости. Относительно зрелости системы управления можно судить по отзыву внутреннего ИТ-аудита, отметившего не только стройность и работоспособность системы, но и ее соответствие общему стратегическому подходу глобальной ИТ-организации. Что касается СВК ИТ, то здесь лакмусовой бумажкой выступил параллельно идущий проект соответствия SOX.

Говоря точнее, работы по SOX оставались «проектом» только на третьем году – параллельно с разработкой СВК ИТ было проведено комплексное перепроектирование процессных контролей с целью максимальной автоматизации их исполнения. Под автоматизацией в данном случае подразумевается не перекладывание работы с человека на компьютер, а встраивание контроля в бизнес-процесс, что делает его не столько дополнительной нагрузкой для человека, сколько логичной частью процесса проверки необходимых параметров, даже если реально контроль выполняется «вручную». Такой эффект может достигаться, например, благодаря соответствующему перераспределению обязанностей участников бизнес-процесса или изменению их бизнес-ролей (скажем, ролей в ERP-системе).

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

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

На четвертом году работ, когда перепроектированные контроли были включены в сформированную к тому времени СВК ИТ, заметно снизились затраты ресурсов на подтверждение соответствия SOX. Сначала это проявилось в том, что для ежегодного тестирования ИТ-контролей уже не выделялась группа специалистов?– теперь достаточно выделить лишь координатора работ на 40% его рабочего времени. Количество участников тестирования уменьшилось, и к работам они привлекались уже не по плану проекта, а по обычным заявкам координатора, т.е. снизились и требования к квалификации участников тестирования. А уверенность в выполнимости работ возросла настолько, что приоритетность данной категории работ перешла к обычным уровням SLA.

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

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

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

Управление ИТ-рисками

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

• анализ статистики реализации рисков;
• проактивная оценка факторов, влияющих на уровень риска (вероятность реализации риска и степень его влияния);
• анализ эффективности мер контроля по минимизации риска;
• формализованная оценка зрелости процессов предоставления ИТ-сервисов.

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

От перехода к системе непрерывного управления ИТ-рисками в ABB ожидают получить следующие результаты:

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

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

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

Управление ИТ-рисками и сервисный подход

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

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

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

При обсуждении подходов к управлению рисками в ИТ нельзя не затронуть вопрос о его месте по отношению к ИТ- и бизнес-процессам. Высокий уровень зрелости системы управления ИТ характеризуется интеграцией процесса управления ИТ-рисками с процессами предоставления ИТ-сервисов. В такой модели каждый тип ИТ-риска «курирует» отдельный ИТ-процесс. В частности, риски снижения результативности интегрированы с процессом управления уровнем услуг, риски нарушения доступности – с процессом управления производительностью и т.д. При этом подходе достаточно легко скоординировать процессы повышения зрелости сервисной модели и системы управления рисками. Целевую модель системы управления можно выразить в виде профиля уровней зрелости (например, по шкале COBIT) связанных ИТ-процессов, поддерживающих бизнес-процессы в рамках ИТ-сервиса. Тогда стратегия перехода от текущего состояния к целевому уровню определит темпы дальнейшего развития системы управления рисками в привязке к темпам совершенствования процессов предоставления ИТ-сервисов.

Владимир Шевченко (vladimir.shevchenko@ru.abb.com)  – директор по ИТ, ABB Russia (Москва).