Вместо вступления
Сразу оговорюсь, что речь пойдет о внутренних ИТ аудиторах. Внешние ИТ-аудиторы - это совсем другая история.
Пролог
Профессия ИТ-аудитора, не смотря на многолетнюю практику на западе, остается очень молодой в Украине. Причин тому несколько:
В первом случае человек имеет достаточно неплохое понимание ИТ процессов, но серьезные пробелы в аудиторской методологии.
Во втором случае, это, как правило, специалист уровня ассистента аудитора ИТ из консалтинговой компании. Т.е. "руки" - человек, который имеет практический опыт выполнения аудита руками. Но "голова" - старший аудитор, либо менеджер, который строил программы аудита и проверял существенность и корректность выводов, в комплект не входит. И мы снова упираемся в пробелы в аудиторской методологии.
В обоих случаях, новоиспеченные ИТ аудиторы начинают выполнять проверки, определяя по собственному разумению, что должно проверяться, в каком объеме и что по выявленному можно порекомендовать. Реакция на отчеты со стороны заинтересованных сторон достаточно однообразная - ярость и обвинения в некомпетентности со стороны ИТ и ИБ и недоуменное пожимание плечами со стороны бизнес-руководства. Ниже приведены типичные "болезни" начинающих ИТ аудиторов с указанием симптомов и курсом лечения.
От забора до обеда
Первая распространенная болезнь начинающих ИТ аудиторов - отсутствие понимания что именно проверять и в каком объеме. Но аудитор преисполнен энтузиазма: "я сейчас вас всех научу, как должно работать ИТ". Берется Cobit и начинается тотальная проверка всех 34 процессов. Через какое-то время приходит понимание, что до конца Cobit еще очень долго, времени потрачено уйма, а до основных процессов ИТ руки еще и не добрались.
Лечение. Лечить данную проблему нужно оценкой рисков. Принцип Паретто действует и в ИТ - 20% недостатков создает 80% проблем. Вот на них и нужно сосредоточится. Ну и не мешало бы почитать что-то по определению объема проверки для аудита ИТ :).
Например, если мы решили делать аудит по Cobit, то IT Assurance Guide: Using Cobit к прочтению крайне желателен. Он не только раскроет подходы по планированию, но и выступит хорошим справочником что в каком процессе смотреть.
Если мы делаем аудит впервые и не знаем куда лучшебить посмотреть в ИТ, можно немого почитать перед сном ИТ макулатуры документацию:
Еще одна распространенная болезнь ИТ аудитов - аудит ИТ как таковой, в отрыве от бизнеса. И рекомендации соответствующие - улучшить ИТ. А для чего - не понятно.
Лечение. Для начала неплохо понять какие процессы существуют в компании и их критичность для бизнеса. После выявления критичных процессов определяем какие информационные системы поддерживают эти процессы и выясняем насколько процессы от этих системы зависят. Определение данных связок поможет не только определить наиболее интересные для аудита места, но и внятно строить объяснения для менеджмента (мы ведь для них пишем?), как конкретный недостаток негативно влияет на работу процесса в целом, где компания теряет деньги.
Если же так сложилось, что мы работаем в компании в которой слово IT Governance не является ругательством с высоким уровнем зрелости процессов ИТ (такие тоже есть), то за подспорье можно взять то же Cobit, который подскажет как увязаны бизнес-цели компании с ИТ-целями, ИТ-цели с ИТ-процессами, а ИТ процессы с критериями информации, регуляторными требованиями и т.д.
Как в лучших домах Лондона и Парижа
Из предыдущих двух пунктов может сложиться обманчивое впечатление, что Cobit - это волшебная палочка, которой можно махать во все стороны и каждый раз будет происходить чудо. На самом деле это не так. Еще одной болезнью начинающих ИТ аудиторов является восприятие стандартов серии "лучших мировых практик" как догмы. Соответственно, любое несоответствие таким стандартам вызывает праведный гнев аудиторов и рекомендации "срочно привести в соответствие с лучшим мировым стандартом имярек". При этом единственной необходимостью внедрения является несоответствие.
Лечение. Прежде, чем что-то порекомендовать по соответствию, необходимо для себя ответить на вопрос "что это даст компании, кроме соответствия". Даже если цель - полное соответствие стандарту (например, ISO 27001), то цель не в соответствии, а в убеждении соответствия некой аудитории для, например, повышения доверия и улучшения продаж. Соответственно, истинная цель будет звучать так: "минимально полное соответствие, необходимое для получения сертификата". А это - совсем другой объем, чем полное соответствие , разумеется, совсем другой объем затрат.
Если священный трепет перед "лучшими практиками" мешает сосредоточится на целях компании, необходимо проведение ряда аутотренингов перед сном, с приведением себе следующих аргументов:
Итак, аудит проведен, вопрос "кто виноват?" раскрыт. Остается "что делать?". Открываем аудиторские рекомендации и видим "улучшить", "усилить", "углубить", "уширить". Все рекомендации сводятся к фразе: "сделайте так, что бы все было хорошо". Совет, безусловно, ценный, но малополезный. От аудиторов ожидается не только выявление недостатков, но и конкретных и полезных рекомендаций.
Лечение. На этот раз волшебный Cobit не поможет. Т.е. он, конечно, подскажет направление, но как реализовать рекомендацию в отдельно взятой компании там, скорее всего, не написано. Тут нужен опыт, который нельзя пропить. Не напрасно ISACA не дает всем сдавшим экзамен сертификат CISA - нужно еще подтвердить наличие практического опыта. А что делать, когда его нет, а рекомендации нужны? Можно пойди к аудируемой стороне (они ведь еще разговаривают с вами после проверки?) и попробовать помозговать вместе. Если риск выявлен адекватно, руководитель ИТ будет сам заинтересован его устранить с наименьшими затратами.
КЦ очень дорогой, родной
Кстати о затратах. Рекомендации могут быть сколь угодно полезными, но если их реализация будет стоить компании больше, чем потенциальный урон от недостатка, то пользы не будет.
Лечение. Выход из ситуации простой и сложный одновременно. Совет "считайте сколько будет стоить внедрение" дать легко. А вот посчитать... Во первых, нужно посчитать потенциальный ущерб (это в любом случае полезно для аргументации менеджменту). И тут начинаются проблемы. Ущерб может быть в ИТ, а может быть в процессах, которые ИТ поддерживает. Затраты прямые и не прямые. Считать ли недополученную прибыль? За какой период? Делать дисконтирование? По какой ставке? Вопросов масса. Во-вторых, нужно посчитать стоимость внедрения. Нужно ли говорить, что это не на много проще? Но, в конечном итоге, это то, что ожидается от полноценного ИТ аудитора. И выход один - постоянно изучать бизнес-процессы и повышать финансовую грамотность.
Рубль штучка, а три рубля - кучка
И последняя на сегодня, болезнь начинающих аудиторов, причина которой также лежит в низкой финансовой грамотности - это материальность выявленных недостатков. Если вы не индийский программист или журналист и вам не платят за количество написанных знаков, лучше воздержаться от описания недостатков, ущерб от которых невелик. Это раздражает руководство, которое мыслит достаточно большими суммами и очень ценит свое время, которое тоже стоит очень дорого.
Лечение. Неплохо бы почитать про аудиторскую материальность. Определить шкалу для измерения недостатков (например, традиционные высокий, средний, низкий выразить в денежном диапазоне) и согласовать с руководством. Ну и не писать про копеечные недостатки. Единственным исключением может быть ситуация, когда много мелких недостатков имеют одну причину и большой кумулятивный эффект. Как говорил товарищ Раскольников: "Одна старушка - 20 копеек, а пять - уже рубль".
часть 2 ->
Сразу оговорюсь, что речь пойдет о внутренних ИТ аудиторах. Внешние ИТ-аудиторы - это совсем другая история.
Пролог
Профессия ИТ-аудитора, не смотря на многолетнюю практику на западе, остается очень молодой в Украине. Причин тому несколько:
- "Зрелость" менеджмента отечественных компаний. Зачастую, руководители компаний воспринимают ИТ как вещь в себе и не видят прямой зависимости бизнеса от ИТ. С другой стороны, он считают, что руководитель ИТ - это человек, который в ответе за все. И если что-то не работает в ИТ - нужно просто поменять руководителя ИТ на адекватного.
- Отсутствие понимания сути и пользы ИТ аудита у руководителей функции внутреннего аудита и, как следствие,
страхнежелание развивать сомнительное направление, за деятельность которого необходимо нести ответственность.
- В компанию пришел западный капитал и акционеры требуют наличия такой функции
- Появились законодательные требования (ситуация с украинскими банками и стандартом СОУ Н НБУ)
- Поменялось руководство компании на то, которое понимает необходимость аудита ИТ или текущее "дозрело". Или, как альтернатива, "дозрел" руководитель функции внутреннего аудита (например, получил CIA) и убедил руководство. Случай крайне редкий, но в природе встречаемый.
В первом случае человек имеет достаточно неплохое понимание ИТ процессов, но серьезные пробелы в аудиторской методологии.
Во втором случае, это, как правило, специалист уровня ассистента аудитора ИТ из консалтинговой компании. Т.е. "руки" - человек, который имеет практический опыт выполнения аудита руками. Но "голова" - старший аудитор, либо менеджер, который строил программы аудита и проверял существенность и корректность выводов, в комплект не входит. И мы снова упираемся в пробелы в аудиторской методологии.
В обоих случаях, новоиспеченные ИТ аудиторы начинают выполнять проверки, определяя по собственному разумению, что должно проверяться, в каком объеме и что по выявленному можно порекомендовать. Реакция на отчеты со стороны заинтересованных сторон достаточно однообразная - ярость и обвинения в некомпетентности со стороны ИТ и ИБ и недоуменное пожимание плечами со стороны бизнес-руководства. Ниже приведены типичные "болезни" начинающих ИТ аудиторов с указанием симптомов и курсом лечения.
От забора до обеда
Первая распространенная болезнь начинающих ИТ аудиторов - отсутствие понимания что именно проверять и в каком объеме. Но аудитор преисполнен энтузиазма: "я сейчас вас всех научу, как должно работать ИТ". Берется Cobit и начинается тотальная проверка всех 34 процессов. Через какое-то время приходит понимание, что до конца Cobit еще очень долго, времени потрачено уйма, а до основных процессов ИТ руки еще и не добрались.
Лечение. Лечить данную проблему нужно оценкой рисков. Принцип Паретто действует и в ИТ - 20% недостатков создает 80% проблем. Вот на них и нужно сосредоточится. Ну и не мешало бы почитать что-то по определению объема проверки для аудита ИТ :).
Например, если мы решили делать аудит по Cobit, то IT Assurance Guide: Using Cobit к прочтению крайне желателен. Он не только раскроет подходы по планированию, но и выступит хорошим справочником что в каком процессе смотреть.
Если мы делаем аудит впервые и не знаем куда лучше
- Стратегия ИТ - Вау! Она есть? Смотрим на сколько она соответствует стратегии компании, как измеряется достижение целей и т.д. Если ее нет - не нужно расстраиваться. Ваша компания всего-навсего попадает в те 70% компаний, у которых нет ИТ стратегии.
- Отчеты процессов управления инцидентами и управления проблемами. Если просмотр вторых не представляется возможным по причине отсутствия таковых - можно попробовать проанализировать тренды по инцидентам самостоятельно. Главное не забывать, для чего нам это нужно и вовремя остановиться.
- План IT проектов - для определения ключевых проектов и связанных рисков
- Бюджеты ИТ и анализ план/ факт - определение самых прожорливых статей
- Результаты оценки ИТ-рисков - ситуация такая же, как с ИТ- стратегией: есть - хорошо, нет - нет. Если есть смотрим адекватность и выявляем наиболее рисковые зоны.
- Результаты внешних ИТ-аудитов. Опять же, если такие были. Если были аудиты финансовой отчетности, тоже можно посмотреть - там вопросы ИТ встречаются хотя цели другие.
Еще одна распространенная болезнь ИТ аудитов - аудит ИТ как таковой, в отрыве от бизнеса. И рекомендации соответствующие - улучшить ИТ. А для чего - не понятно.
Лечение. Для начала неплохо понять какие процессы существуют в компании и их критичность для бизнеса. После выявления критичных процессов определяем какие информационные системы поддерживают эти процессы и выясняем насколько процессы от этих системы зависят. Определение данных связок поможет не только определить наиболее интересные для аудита места, но и внятно строить объяснения для менеджмента (мы ведь для них пишем?), как конкретный недостаток негативно влияет на работу процесса в целом, где компания теряет деньги.
Если же так сложилось, что мы работаем в компании
Как в лучших домах Лондона и Парижа
Из предыдущих двух пунктов может сложиться обманчивое впечатление, что Cobit - это волшебная палочка, которой можно махать во все стороны и каждый раз будет происходить чудо. На самом деле это не так. Еще одной болезнью начинающих ИТ аудиторов является восприятие стандартов серии "лучших мировых практик" как догмы. Соответственно, любое несоответствие таким стандартам вызывает праведный гнев аудиторов и рекомендации "срочно привести в соответствие с лучшим мировым стандартом имярек". При этом единственной необходимостью внедрения является несоответствие.
Лечение. Прежде, чем что-то порекомендовать по соответствию, необходимо для себя ответить на вопрос "что это даст компании, кроме соответствия". Даже если цель - полное соответствие стандарту (например, ISO 27001), то цель не в соответствии, а в убеждении соответствия некой аудитории для, например, повышения доверия и улучшения продаж. Соответственно, истинная цель будет звучать так: "минимально полное соответствие, необходимое для получения сертификата". А это - совсем другой объем, чем полное соответствие , разумеется, совсем другой объем затрат.
Если священный трепет перед "лучшими практиками" мешает сосредоточится на целях компании, необходимо проведение ряда аутотренингов перед сном, с приведением себе следующих аргументов:
- Лучшие практики - есть "средняя температура по больнице". Они, как правило, не учитываю специфику страны, размера компании, ментальности отрасли и т.д. и т.п. Что русскому хорошо, то немцу - смерть.
- Лучшие практики - это справочник, из которого выбирают то, что необходимо, а не читают от корки до корки. Это, кстати, обычно пишут во вступлениях к стандарту (кто их читает?).
- Лучшее - враг хорошего (финальный аргумент).
Итак, аудит проведен, вопрос "кто виноват?" раскрыт. Остается "что делать?". Открываем аудиторские рекомендации и видим "улучшить", "усилить", "углубить", "уширить". Все рекомендации сводятся к фразе: "сделайте так, что бы все было хорошо". Совет, безусловно, ценный, но малополезный. От аудиторов ожидается не только выявление недостатков, но и конкретных и полезных рекомендаций.
Лечение. На этот раз волшебный Cobit не поможет. Т.е. он, конечно, подскажет направление, но как реализовать рекомендацию в отдельно взятой компании там, скорее всего, не написано. Тут нужен опыт
КЦ очень дорогой, родной
Кстати о затратах. Рекомендации могут быть сколь угодно полезными, но если их реализация будет стоить компании больше, чем потенциальный урон от недостатка, то пользы не будет.
Лечение. Выход из ситуации простой и сложный одновременно. Совет "считайте сколько будет стоить внедрение" дать легко. А вот посчитать... Во первых, нужно посчитать потенциальный ущерб (это в любом случае полезно для аргументации менеджменту). И тут начинаются проблемы. Ущерб может быть в ИТ, а может быть в процессах, которые ИТ поддерживает. Затраты прямые и не прямые. Считать ли недополученную прибыль? За какой период? Делать дисконтирование? По какой ставке? Вопросов масса. Во-вторых, нужно посчитать стоимость внедрения. Нужно ли говорить, что это не на много проще? Но, в конечном итоге, это то, что ожидается от полноценного ИТ аудитора. И выход один - постоянно изучать бизнес-процессы и повышать финансовую грамотность.
Рубль штучка, а три рубля - кучка
И последняя на сегодня, болезнь начинающих аудиторов, причина которой также лежит в низкой финансовой грамотности - это материальность выявленных недостатков. Если вы не индийский программист или журналист и вам не платят за количество написанных знаков, лучше воздержаться от описания недостатков, ущерб от которых невелик. Это раздражает руководство, которое мыслит достаточно большими суммами и очень ценит свое время, которое тоже стоит очень дорого.
Лечение. Неплохо бы почитать про аудиторскую материальность. Определить шкалу для измерения недостатков (например, традиционные высокий, средний, низкий выразить в денежном диапазоне) и согласовать с руководством. Ну и не писать про копеечные недостатки. Единственным исключением может быть ситуация, когда много мелких недостатков имеют одну причину и большой кумулятивный эффект. Как говорил товарищ Раскольников: "Одна старушка - 20 копеек, а пять - уже рубль".
часть 2 ->
Комментариев нет:
Отправить комментарий