Определяем границы ответственности ИБ-службы в процессе управления операционными рисками

В 2020 году Банк России утвердил требования к системе управления операционным риском в Положении №716-П. В соответствии с этими требованиями кредитные организации должны оценивать свои операционные риски и ущерб в случае их реализации. Речь идет о потерях от самых разных событий, в том числе и инцидентов информационной безопасности. Пожалуй, в каждой финансовой организации возникли те или иные вопросы, как выполнять эти требования.

Определяем границы ответственности ИБ-службы в процессе управления операционными рисками

Определяем границы ответственности ИБ-службы в процессе управления операционными рисками

В первую очередь, большинство компаний столкнулись с трудностями определения зон ответственности в управлении операционными рисками в целом и отдельными видами рисков. Нормативная база Банка России определяет только требования к системе, но не дает четкого определения, как выстроить соответствующие процессы и как распределить ответственность по управлению операционным риском и обеспечению операционной надежности в организациях. Было бы логично, если подразделения, ответственные за управления рисками внедряли систему управления операционными рисками (СУОР) и становились бы ее владельцами. Но на практике рисковикам не хватает собственных компетенций для управления ИТ и ИБ-рисками, а профильные подразделения не стремятся брать на себя дополнительную ответственность. Это становится основной причиной «пробуксовки» внедрения требований.

Сегодня со стороны регулятора на вопросы управления рисками информационной безопасности финансовым организациям отвечает Департамент информационной безопасности. Также известно о намерениях Банка России повысить вовлеченность высшего менеджмента финансовых организаций в процессы управления операционными рисками.

В своей практике AKTIV.CONSULTING часто сталкивается с вопросами определения границ ответственности службы ИБ в процессе управления операционными рисками, поэтому мы решили разобраться в этой теме.

Требования Банка России направлены на достижение одной из основных целей — обеспечение стабильности финансового рынка Российской Федерации. Для этого нужно, чтобы каждая финансовая организация могла обеспечить непрерывность бизнеса и эффективно распределять ресурсы, что, в свою очередь, отвечает интересам как высшего менеджмента, так и операционных подразделений.

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

Организационная структура и основные процессы УОР

Кто управляет рисками?

На практике мы столкнулись с разными кейсами. Первая ситуация — СУОР (систему управления операционными рисками) внедрена, или планируется в службе управления рисками. ИБ-служба формирует свою часть процессов и интегрирует их в СУОР. Такой вариант соответствует требованиям нормативным документам. В данном случае рисковики запускают проект внедрения и являются владельцами процесса. Департаменты ИТ и ИБ становятся центрами профильных компетенций в СУОР.

Второй сценарий ― служба рисков не запускает СУОР вовсе или не включает в СУОР ИБ-риски. Нередко это случается из-за отсутствия компетенций или нехватки специалистов. В данном случае подразделения ИБ могут лишь частично адаптировать свои процессы. Но всё это не в полной мере соответствует требованиям Банка России.

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

Какие промежуточные выводы можно сделать:

  • Даже если СУОР в организации нет, функцию по управлению операционными рисками требуется выполнять.
  • Для ИБ-службы есть три сценария реализации требований регулятора, как минимум. Роли, участие и ответственность будут отличаться в зависимости от варианта сценария.
  • ИБ-служба не может взять на себя полностью управление оперриском. Даже если СУОР будет выстраиваться внутри ДИБа, менеджмент будет выполнять функции согласования и контроля.

Процесс управления операционными рисками

Давайте рассмотрим, что из себя должен представлять процесс управления операционными рисками. Требования Положения №716-П подталкивают на организацию классического цикла Деминга — PDCA (Plan-Do-Check-Act). Итак, по порядку.

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

При соотнесении возможных потерь с историческими данными определить для каждой компании приемлемый уровень операционного риска в денежном выражении, то есть рассчитать контрольные показатели уровня операционного риска (КПУР). Эти показатели подлежат утверждению высшим менеджментом на плановый (годовой) период. Результатом этого этапа должен стать реестр рисков, перечень мер снижения влияния, порядок реагирования и установленные КПУР.

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

Далее реализуется контроль базы событий, то есть производится мониторинг ключевых индикаторов риска, в том числе на предмет превышения уровня операционных рисков (КПУР). В результате формируется регулярная отчетность, и в случаях превышения показателей запускаются процессы реагирования. Реагирование обычно связано с привлечением дополнительных незапланированных ресурсов и изменениями в бизнес-процессах, поэтому указания на реагирование производится на уровне высшего менеджмента.

По итогам каждого планового периода происходит совершенствование всей системы: проводится аудит, который можно сделать как внутренними силами, так и обратиться к внешним подрядчикам. Аудит направлен на повышение качества СУОР. На основе его результатов вырабатывают мероприятия на год вперед, которые могут повлиять на вероятность событий риска и снижение потерь от рисков. Топ-менеджмент утверждает планы соответствующих мероприятий.

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

Конечно, чтобы соответствовать требования Банка России, можно управлять операционными рисками и формально. С другой стороны, если найти силы и методически подойти к расчету операционных рисков, можно получить больше ценной информации для принятия управленческих решений на всех уровнях — от менеджмента до обеспечивающих подразделений.