Обратился недавно к моему коллеге один из руководителей службы внутреннего аудита крупной компании с вопросом - для чего нужны аудиторы ИТ? Ситуация вроде бы даже забавная - кому, как не руководителю функции лучше знать зачем ему те или иные специалисты? Но, на самом деле, случай этот не единственный. Ко мне с таким же вопросом неоднократно обращались коллеги по ремеслу - руководители внутреннего аудита различных компаний.
За свою карьеру я успел и позаниматься ИТ-аудитом и поруководить внутренним аудитом, состоящим в том числе и из ИТ аудиторов. Поэтому я решил набросать свое видение - для чего все-таки ИТ-аудиторы нужны и какая от них польза. Наверное, правильно было бы назвать пост "Зачем нужен ИТ-аудитор руководителю функции внутреннего аудита?".
Как получается, что у руководителя есть ИТ-аудиторы, но он не знает зачем? Чаще всего такая ситуация происходит, когда руководитель внутреннего аудита приходит на данную позицию из внешнего финансового аудита, а аудит ИТ уже есть в структуре. И новоиспеченный руководитель думает - стандарты и "ведущие практики" говорят, что "должны быть". Опять же аргумент, "у других компаний есть, а мы не хуже". В общем, пригодится. Но потом начинают всплывать различия внешнего финансового аудита и внутреннего. В финансовом, с точки зрения вовлечения аудиторов ИТ - все просто. Привлекаем спецов из соседнего подразделения для оценки общих ИТ-контролей, "потому, что требование 315 стандарта". Найдут что-то - напишем рекомендации "не делайте так, потому, что это риск для финансовой отчетности". Не найдут - ну и славненько. При подаче результатов руководству главное - дать мнение о финансовой отчетности. А информационные технологии - дело десятое. Во внутреннем аудите все чуть-чуть по-другому. Помимо целостности и достоверности финансовой отчетности, которая немного уходит на второй план (ведь есть внешний аудит - зачем дублировать усилия?), появляется обширный круг вопросов по эффективности и результативности операционных процессов. Объем работ огромный, ресурсов - как всегда мало. Приходится жертвовать проверками определенных областей, оставляя в плане самое важное. И нужно все рисковые зоны закрыть и хотелки акционеров, аудиторского комитета и менеджмента постараться учесть и обосновать почему это будем смотреть, а это - нет... А тут аудитор ИТ. Текст отчета - черт ногу сломит. Сплошные технические термины и аббревиатуры, понятные только специалистам ИТ и иногда информационной безопасности. Из рисков - несоблюдение стандартов с непонятными названиями вроде Cobit или ITIL и рекомендации срочно привести все в соответствие. Или результаты проверки систем с точки зрения безопасности и результат - найдено 1658 уязвимостей на каждом(!) компьютере - компания в опасности! Срочно все исправить! Ответ руководства ИТ и безопасности достаточно однообразны: "все сделаем за пару лет, если выделить 100500 млн. денег и утроить штат". Такие отчеты приводят руководителя внутреннего аудита в ужас. Кто вообще такой этот Cobit и почему ему нужно соответствовать? Как такие результаты показывать руководству компании и аудиторскому комитету? Для них такой отчет прозвучит как "бла-бла-бла ненужные затраты". И возникнет вопрос к компетенции уже руководителя внутреннего аудита - зачем потратил дефицитный ресурс на ерунду? Возникает жгучее желание рубануть шашкой аудитора ИТ и взять на освободившееся место простого и понятного операционного аудитора.
Обычно такая ситуация возникает с начинающими ИТ аудиторами, имеющими неплохой технических бэкграунд, но недостаточно опытными как аудиторы. Типичные ошибки, которые они делают, описаны тут и тут. Там же можно почитать что с этим делать. Конечно, переобучение ИТ аудитора - дело ресурсоемкое и возникает соблазн все-таки его уволить. Почему этого делать скорее всего не нужно? Поменять ИТ аудитора на "правильного" - задача очень непростая. Представьте себе человека, который не только хороший специалист в ИТ, но и отлично понимает бизнес-процессы, а главное - может говорить с бизнесом на понятном языке. Достаточно редкая ситуация, не так ли? Если учесть, что такие люди предпочитают работать в бизнесе, а не в ИТ. А теперь добавляем к этим качествам еще и хорошее знание аудиторских процедур и стандартов, и мы получим специалиста, встречающегося в природе чуть-чуть чаще, чем невидимый розовый единорог. Спрос на аудиторов ИТ появился относительно недавно, поэтому специалистов на рынке крайне мало. Избавившись от неопытного можно остаться вообще без никакого.
Так зачем он все-таки нужен? Информационные технологии должны интересовать главу внутреннего аудита как минимум по двум причинам:
Непонятно что смотрели и зачем.
Наиболее вероятно, что проблема в чересчур большой автономии ИТ аудита в вопросах планирования. Как годового, так и при составлении программы каждой отдельной проверки. Если годовая программа уже составлена - нужно срочно ее пересмотреть.
В годовом плане для каждой проверки, которую будет делать аудит ИТ (как и для любой другой), должен быть четко сформулирован риск, который обосновывает необходимость проверки. При этом формулировка должна быть понятной не только аудитору ИТ, но и для Вас, как руководителя функции.
Но как я пойму, если ИТ - это адское мракобесие, в котором я ничего не понимаю, и ИТ аудитор может навешать лапши? Способность объяснять технические вещи простым языком, понятным нетехническим специалистам - одна из ключевых компетенций ИТ аудитора. Если ты что-то не можешь объяснить своей бабушке - ты это не до конца понимаешь. Не помню кому принадлежит фраза, но полностью с ней согласен.
Еще в плане необходимо высокоуровнево определить объем аудиторских процедур. Это позволит в дальнейшем снизить риск "растекания" аудиторских процедур, делающего проверку бесконечной. В процессе составления рабочей программы нужно снова вернуться к этой теме и проработать более детально три вопроса:
За свою карьеру я успел и позаниматься ИТ-аудитом и поруководить внутренним аудитом, состоящим в том числе и из ИТ аудиторов. Поэтому я решил набросать свое видение - для чего все-таки ИТ-аудиторы нужны и какая от них польза. Наверное, правильно было бы назвать пост "Зачем нужен ИТ-аудитор руководителю функции внутреннего аудита?".
Как получается, что у руководителя есть ИТ-аудиторы, но он не знает зачем? Чаще всего такая ситуация происходит, когда руководитель внутреннего аудита приходит на данную позицию из внешнего финансового аудита, а аудит ИТ уже есть в структуре. И новоиспеченный руководитель думает - стандарты и "ведущие практики" говорят, что "должны быть". Опять же аргумент, "у других компаний есть, а мы не хуже". В общем, пригодится. Но потом начинают всплывать различия внешнего финансового аудита и внутреннего. В финансовом, с точки зрения вовлечения аудиторов ИТ - все просто. Привлекаем спецов из соседнего подразделения для оценки общих ИТ-контролей, "потому, что требование 315 стандарта". Найдут что-то - напишем рекомендации "не делайте так, потому, что это риск для финансовой отчетности". Не найдут - ну и славненько. При подаче результатов руководству главное - дать мнение о финансовой отчетности. А информационные технологии - дело десятое. Во внутреннем аудите все чуть-чуть по-другому. Помимо целостности и достоверности финансовой отчетности, которая немного уходит на второй план (ведь есть внешний аудит - зачем дублировать усилия?), появляется обширный круг вопросов по эффективности и результативности операционных процессов. Объем работ огромный, ресурсов - как всегда мало. Приходится жертвовать проверками определенных областей, оставляя в плане самое важное. И нужно все рисковые зоны закрыть и хотелки акционеров, аудиторского комитета и менеджмента постараться учесть и обосновать почему это будем смотреть, а это - нет... А тут аудитор ИТ. Текст отчета - черт ногу сломит. Сплошные технические термины и аббревиатуры, понятные только специалистам ИТ и иногда информационной безопасности. Из рисков - несоблюдение стандартов с непонятными названиями вроде Cobit или ITIL и рекомендации срочно привести все в соответствие. Или результаты проверки систем с точки зрения безопасности и результат - найдено 1658 уязвимостей на каждом(!) компьютере - компания в опасности! Срочно все исправить! Ответ руководства ИТ и безопасности достаточно однообразны: "все сделаем за пару лет, если выделить 100500 млн. денег и утроить штат". Такие отчеты приводят руководителя внутреннего аудита в ужас. Кто вообще такой этот Cobit и почему ему нужно соответствовать? Как такие результаты показывать руководству компании и аудиторскому комитету? Для них такой отчет прозвучит как "бла-бла-бла ненужные затраты". И возникнет вопрос к компетенции уже руководителя внутреннего аудита - зачем потратил дефицитный ресурс на ерунду? Возникает жгучее желание рубануть шашкой аудитора ИТ и взять на освободившееся место простого и понятного операционного аудитора.
Обычно такая ситуация возникает с начинающими ИТ аудиторами, имеющими неплохой технических бэкграунд, но недостаточно опытными как аудиторы. Типичные ошибки, которые они делают, описаны тут и тут. Там же можно почитать что с этим делать. Конечно, переобучение ИТ аудитора - дело ресурсоемкое и возникает соблазн все-таки его уволить. Почему этого делать скорее всего не нужно? Поменять ИТ аудитора на "правильного" - задача очень непростая. Представьте себе человека, который не только хороший специалист в ИТ, но и отлично понимает бизнес-процессы, а главное - может говорить с бизнесом на понятном языке. Достаточно редкая ситуация, не так ли? Если учесть, что такие люди предпочитают работать в бизнесе, а не в ИТ. А теперь добавляем к этим качествам еще и хорошее знание аудиторских процедур и стандартов, и мы получим специалиста, встречающегося в природе чуть-чуть чаще, чем невидимый розовый единорог. Спрос на аудиторов ИТ появился относительно недавно, поэтому специалистов на рынке крайне мало. Избавившись от неопытного можно остаться вообще без никакого.
Так зачем он все-таки нужен? Информационные технологии должны интересовать главу внутреннего аудита как минимум по двум причинам:
- Информационные технологии - это не вещь в себе. Они являются важной частью большинства операционных процессов компании. И несут с собой не только преимущества автоматизации, но и целый букет рисков. Правильно ли работает та часть процесса, которая выполняется системой? Надежно ли защищены данные в системе от неавторизованных изменений? А от утечки? Как будут работать процессы, если система перестанет работать в результате непредвиденных обстоятельств? Сможет ли компания выполнять основные операции, пока систему будут восстанавливать? Правильно ли распределены доступы в системе? Нельзя ли их обойти и нарушить правила разделения обязанностей для каких-нибудь своих выгод?
- Информационные технологии имеют паскудную привычку стоить дорого. Не только с точки зрения капитальных инвестиций, но и операционная поддержка обходится компании в копеечку. Если копания потратила очередные $10,000,000 на новую CRM-систему, DWH или еще Бог знает какую систему - наверняка она должна была что-то весомое получить взамен? Например, рост продаж или скорость обслуживания клиентов. Наверняка есть смысл оценить бизнес-кейс для новой системы и понять получила ли компания ожидаемые выгоды от потраченных ресурсов. Удовлетворяют ли используемые решения текущим потребностям бизнеса? Смогут ли удовлетворить будущим? Ведь бизнес развивается, и то решение, которое подходило сегодня, завтра может повиснуть жерновом на шее и завалить все усилия стратегов и маркетологов.
Непонятно что смотрели и зачем.
Наиболее вероятно, что проблема в чересчур большой автономии ИТ аудита в вопросах планирования. Как годового, так и при составлении программы каждой отдельной проверки. Если годовая программа уже составлена - нужно срочно ее пересмотреть.
В годовом плане для каждой проверки, которую будет делать аудит ИТ (как и для любой другой), должен быть четко сформулирован риск, который обосновывает необходимость проверки. При этом формулировка должна быть понятной не только аудитору ИТ, но и для Вас, как руководителя функции.
Но как я пойму, если ИТ - это адское мракобесие, в котором я ничего не понимаю, и ИТ аудитор может навешать лапши? Способность объяснять технические вещи простым языком, понятным нетехническим специалистам - одна из ключевых компетенций ИТ аудитора. Если ты что-то не можешь объяснить своей бабушке - ты это не до конца понимаешь. Не помню кому принадлежит фраза, но полностью с ней согласен.
Еще в плане необходимо высокоуровнево определить объем аудиторских процедур. Это позволит в дальнейшем снизить риск "растекания" аудиторских процедур, делающего проверку бесконечной. В процессе составления рабочей программы нужно снова вернуться к этой теме и проработать более детально три вопроса:
- Почему мы будем делать данную процедуру? (риск),
- Как мы будем делать данную процедуру?
- Что мы в результате хотим получить?
Академический аудит. Основной признак такого "полезного" аудита - риски в отчете - это несоответствие мифическим "ведущим практикам". Частный случай тех же проблем планирования. Возникает, когда ИТ аудитор проводит проверку на соответствие какого-нибудь стандарта из серии "ведущих мировых практик", которые часто ошибочно называют "лучшими". Причем годовое планирование могло быть выполнено корректно, а "практики" выползли при подготовке аудиторской программы. Или аудитор начал пасти бумажных тигров при выполнении процедур. В таких случаях рекомендую поработать над восприятием ИТ аудитора целей и задач аудита. Объяснить, кто является основным получателем отчета, образ мышления
руководства и подходы к принятию решения. ИТ - поддерживающая функция и
риски должны оцениваться не с точки зрения "ИТ и лучшие практики", а "ИТ и
потребности бизнеса". То, что какой-то консультант где-то написал, что "так делают многие компании", абсолютно не значит, что ваша компания должна делать точно также. Если нет понятных рисков - необходимости внедрять "практики" или что-то еще весьма сомнительна. Оцифровка технологических рисков в понятные для бизнеса метрики - одна из самых сложных задач. Но никто ведь не говорил, что будет просто? Если что-то кажется неправильным - сколько бизнес от этого потеряет? Или недополучит? Это, кстати, поможет и в исправлении следующей, достаточно распространенной ситуации.
100500 копеечных рисков. Сейчас достану костюм Капитана Очевидность и сообщу, что аудит ИТ ничем не отличается от обычного операционного аудита с точки зрения материальности и концепции управления рисками. Нужно объяснять концепт материальности и
отношение руководства к копеечным проблемам в отчетах. Соотношения
"зарплата аудитора ИТ и отвлеченных им от работы сотрудников" к "польза
от устранения выявленных проблем для бизнеса". Соотношение "польза от
устранения выявленных проблем для бизнеса" к "риски, неохваченные
аудитом по причине недостатка ресурсов".
В общем, главное помнить, что ИТ - это не высшая магия, а поддерживающий бизнес процесс. Точнее набор процессов. И оценивать их с точки зрения пользы для бизнеса. И тогда польза от ИТ аудитора станет более очевидной. И это далеко не вся польза, которую может принести аудитор ИТ. Например, его можно использовать для улучшения качества аналитики данных и CAATS процедур. Но об этом как-нибудь в другой раз.
Комментариев нет:
Отправить комментарий