IT-аудит помогает выявить, насколько банк приблизился к передовым практикам управления информационными технологиями. Такой анализ целесообразно проводить регулярно, в частности, чтобы не допустить стратегических ошибок в построении IT-инфраструктуры банка и соответствовать нормативным требованиям.
Анализ информационных систем часто проводится не только в рамках обязательных проверок (например, в рамках аудита финансовой отчетности), но и по инициативе самого банка, его высшего руководства, акционеров или руководства отдельных подразделений, например, IT-департамента. Если заказчиками становятся руководители или акционеры банка с целью получения общей картины IT, проверка, как правило, проводится по методологии CobiT, разработанной Международной ассоциацией аудита и контроля информационных систем ISACA. Все управление информационными технологиями в банке при такой методологии анализируется в разрезе 34 процессов. В CobiT учтены аспекты планирования и организации IT в соответствии со стратегией бизнеса, выбора и внедрения IT-решений, результативности и безопасности текущей поддержки IT, а также мониторинга эффективности IT-процессов.
Аудит по методологии CobiT не относится к регуляторным требованиям, но он очень полезен, когда банку нужно оценить, где он находится с точки зрения управления IT по отношению к передовым практикам. По результатам анализа не только представляется отчет, содержащий перечень недостатков и достижений по модели CobiT, но и показывается тот уровень, который банк достиг с точки зрения управления IT, — от 0 до 5 (по возрастанию). Обычно такой анализ проводится при слияниях и поглощениях или выходе на различные международные фондовые площадки. Это наиболее широкомасштабная с точки зрения покрытия работа.
Заказ на технологический аудит обычно исходит от руководства служб информационной безопасности или IT-департамента. Это может быть проверка технической защищенности периметра сети банка или отдельной информационной системы, например, основной банковской системы или платежной системы. Анализ конкретных узких областей может проводиться несколько раз в год по мере необходимости.
Следующий вид аудита наиболее характерен для банков: речь идет о проверке на выполнение требований карточных платежных систем стандарту PCI DSS в соответствии с требованиями Visa и MasterCard. Этот аудит обязателен для банков, которые имеют собственные процессинговые центры.
Среди специализированных аудитов можно отметить анализ системы управления информационной безопасностью в соответствии со стандартом СТО БР ИББС 1.0 Банка России. Он был создан с учетом международных стандартов серии ISO 27ххх, специфичных для банковской системы требований, а также российского законодательства, в частности ФЗ № 152 «О персональных данных». Проверки состояния информационной безопасности нужно проводить регулярно, поскольку обеспечение банковской тайны и защита персональных данных клиентов — законодательные требования.
Типичные недочеты
Разные виды аудита вскрывают конкретные недочеты или несоответствие лучшим практикам на разных уровнях управления и инфраструктуры IT. Так, тест на защищенность периметра сети банка поможет обнаружить уязвимости, например, возможность несанкционированного проникновения в информационные системы, несвоевременность обновления антивирусных программ. Общие проверки, например построенные на основе методологии CobiT, помогут вскрыть принципиальные проблемы, такие как несогласованность действий департамента IT и департамента информационной безопасности, и даже несоответствие развития IT основным положениям бизнес-стратегии кредитной организации. Нередко выявляется неадекватное управление проектами, например, проект по внедрению новой системы не выдерживает графика, не укладывается в ресурсы или содержит риск, что поставленные цели не будут достигнуты.
IT-аудит и стратегия банка
В рамках анализа управленческих аспектов рассматриваются следующие вопросы: насколько служба IT внедряет именно те проекты, которые нужны бизнесу, в какой мере пользователи внутри банка и клиенты удовлетворены IT-системами; находятся ли на современном уровне сервисы, которые предлагает банк, например ДБО или интернет-банк. Такие виды анализа очень часто приводят к обновлению IT-стратегии, которая должна быть тесно увязана с бизнес-стратегией банка. Например, если по бизнес-плану в течение года количество клиентов банка или услуг должно удвоиться, то соответствующие корректировки должны быть предусмотрены и в IT-планах.
Типичные риски
Наиболее актуальные IT-риски связаны с ужесточением требований законодательства к информационной безопасности и защите персональных данных. Система информационной безопасности всегда должна соответствовать регуляторным требованиям и уровню рисков.
Другой пример возрастающих рисков вызван тем, что инфраструктура банков становится все более комплексной и централизованной. Раньше каждый филиал или отделение имел автономный мини-ЦОД, сервер, который мог поддерживать автономную работу отделения. Однако все чаще все информационные системы банка управляются из одного ЦОДа. Централизованные решения сильно повысили эффективность работы банка, дали возможность предоставлять клиентам широкий спектр услуг с максимально удобным и быстрым доступом, но в то же время растет риск, связанный с единой точкой возможного сбоя — ведь если
Теоретически защитить интересы собственников банка в случаях прерывания работы поможет страхование. В случае существенного сбоя в инфраструктуре, страховка позволит обеспечить финансовые ресурсы на обновление оборудования, которое вышло из строя. Правда, в нашей стране эти услуги еще не слишком развиты в силу новизны и в силу того, что не всегда можно обеспечить быструю доставку необходимого оборудования для замены. Еще один риск связан с новыми услугами для клиентов: ДБО, мобильный банк, интернет-банк, а также с давно обсуждаемыми банковскими услугами через интерактивное ТВ. Снижать этот риск надо не только техническими средствами, но и через разъяснительную работу с пользователями банковских услуг.
Один из самых значимых внутренних рисков для банка — затягивание внедрения проектов. Чтобы минимизировать эти риски, желательно использовать проверенные методологии управления проектами. Для каждой крупной информационной системы есть свои методологии внедрения, а у крупнейших системных интеграторов есть соответствующие наработки. Но не менее важна организация процесса внутри банка, построение управленческой команды. В идеале внедрение должен контролировать комитет под руководством члена правления. В этот комитет следует привлекать не только сотрудников IT-службы, но и представителей ключевых бизнес-департаментов. В этом случае будет возможно соблюсти баланс интересов разных служб банка, оптимально использовать все ресурсы и вовлечь конечных пользователей к тестированию нового функционала систем.
Аудиторы помогут повысить доверие к аутсорсингу
Многие российские банки, особенно кредитные организации с иностранным участием, уже начали отдавать IT-сервисы на аутсорсинг. Пока на сторону отдаются рутинные операции, которые содержат меньше риска и требуют много ресурсов. Например, расширяется практика передачи на аутсорсинг поддержки рабочих станций, службы help-desk, а ремонт давно отдали на аутсорсинг (хотя еще лет 10—15 назад банки сами ремонтировали свои компьютеры). Что касается IT-инфраструктуры, банки стали брать в аренду резервные ЦОДы. Собственный резервный ЦОД, особенно для средних и небольших банков, пока остается роскошью.
Однако на нашем рынке еще нет того уровня доверия, чтобы банки легко отдавали на аутсорсинг администрирование и поддержку ключевых приложений. В частности, банки опасаются возможных утечек информации, особенно когда компания — поставщик услуг аутсорсинга одновременно предоставляет услуги и конкурентам.
За рубежом один из инструментов повышения доверия к поставщикам услуг — отчет независимых аудиторов по стандарту SAS 70. В соответствии с этим стандартом независимым аудитором проводится проверка среды контроля поставщика услуг, результаты которой предоставляются клиентам поставщика и их аудиторам.
Важно отметить, что можно отдать на аутсорсинг какую-то часть IT-сервисов, но нельзя передать на сторону общую ответственность банка перед своими клиентами.
Проблема «зоопарка»
Эта тема широко обсуждается банковскими специалистами, и трудно дать однозначный ответ на вопрос, какой вариант лучше — максимальная унификация или сохранение «лоскутной» структуры банковских систем. С одной стороны, интеграция отдельных систем и модулей упрощается, так как разные производители вынуждены делать всевозможные интерфейсы по обмену между собой информационными потоками. С другой стороны, приобретение комплекса решений от одной фирмы обеспечивает максимальную интеграцию и зачастую более выгодно с экономической точки зрения. Здесь есть два важных момента. Во-первых, вряд ли есть поставщики, у которых все их модули — лучшие решения на рынке. Кроме того, есть риск, что «все яйца окажутся в одной корзине», то есть банк попадет в зависимость от одного поставщика. Основная рекомендация такова: нужно стараться иметь общие платформы. Например, если основные системы разработаны на СУБД Oracle, пусть новые системы и модули будут по возможности на той же СУБД. Такая совместимость по основным платформам облегчит интеграцию систем от разных производителей.
Системы собственной разработки тоже имеют свои плюсы и минусы. На Западе в некоторых крупных банках до сих пор работают системы, написанные 20 лет назад. Эти системы более гибкие по сравнению с внешними приобретенными стандартными решениями, и способны обеспечить банк наиболее подходящим решением. Однако только крупные банки с хорошим штатом профессиональных разработчиков могут позволить себе подобные решения.
И здесь, в свою очередь, возникает риск зависимости от этих разработчиков, носителей знаний — они могут попросту сменить место работы, и тогда некому будет поддерживать и развивать систему. Есть еще одна проблема — внутренние разработчики хорошо разбираются в банковских технологиях, но они не всегда своевременно реагируют на изменения в законодательстве. А у крупных поставщиков есть службы, которые отслеживают готовящиеся изменения в нормативных актах, отчетности перед ЦБ, ФНС, органами статистики и т. п. Обязательные изменения вносятся в рамках сервисного контракта.
Чтобы снизить риск зависимости от программистов, нужно документировать собственные разработки на всех уровнях, как на уровне инструкций для конечных пользователей, так и на уровне кодов и алгоритмов. И нужно все время готовить новые кадры. Ключевые разработчики должны своевременно передавать знания специалистам, которые затем смогут обслуживать и совершенствовать эти системы.
Андрей ДРОЗДОВ
Автор — старший менеджер отдела управления рисками и комплаенс КПМГ в России и СНГ.
