Задача надежности функционирования внутренних процессов организации является основной для любого руководителя. Действительно ли прямо сейчас организация работает так, как предполагалось? Действительно ли организация может обслуживать клиентов и данные услуги надлежащим образом оказываются? Несмотря на очевидность данных вопросов, не каждый руководитель их связывает с управлением операционными рисками. А именно на эти вопросы и отвечает система управления операционными рисками.
Банк России, регулируя финансовый рынок, в 2021–2022 годах разработал серию нормативных актов, направленных на ускоренную интеграцию процессов управления операционными рисками в финансовых организациях. Для кредитных организаций это Положения 716‑П, 787‑П. Для некредитных – это профильные указания по СУР и Положение 779‑П. Несмотря на достаточно жесткое регулирование финансового рынка, данные стандарты применимы и для нефинансовых организаций, при желании руководства и при наличии явной полезности их применения.
Операционная надежность обеспечивается за счет непрерывности оказания услуг. В случае регулирования Банком России операционная надежность рассматривается как функционирование именно объектов информатизации (оборудование и ПО), но не берутся во внимание другие факторы, такие как ошибка работников организации или форс-мажорные обстоятельства. Затрагивается работоспособность автоматизированных систем, программного обеспечения, средств вычислительной техники, телекоммуникационного оборудования. Регулирование между кредитными и некредитными финансовыми организациями отличается незначительно. У некредитных организаций затрагиваются исключительно сбои, возникшие за счет информационных угроз, у кредитных же добавляются любые сбои оборудования и/или программных продуктов и/или информационных автоматизированных систем.
Автоматизированные системы менее подвержены человеческому фактору, но при этом их функционирование критично зависимо от работоспособности различного оборудования и доступности связи между ним. Перед организацией становятся новые вызовы обеспечения бесперебойности работы оборудования и защиты от информационных угроз.
Рассматривать вопросы обеспечения операционной надежности, согласно требованиям Банка России, необходимо только в виде группы экспертов, каждый из которых специализируется на своих профильных задачах. Эта группа должна включать в себя: эксперта по рискам, эксперта по информационным технологиям и эксперта по информационной безопасности. Такой состав значительно сократит дальнейшие операционные расходы организации за счет отсутствия дублирования части процессов. Например, есть требование РЗИ.1 ГОСТ 57580.1–2017 «Безопасность финансовых (банковских) операций», по данному требованию организация должна вести учет объектов и ресурсов доступа, то же самое требует и Положение 779‑П/787‑П «Операционная надежность», в рамках требований к учету объектов информатизации (критичной архитектуры). Данные требования четко адресованы конкретным экспертам, и их читает только профильный эксперт, рисковик не будет читать требования по информационной безопасности, и наоборот. Таким образом, рисковик не узнает о требованиях ведения соответствующего учета по требованиям безопасности и продублирует процесс учета, то же самое сделает и безопасник. Только координация решений позволит не допустить такого рода ошибок.
Можно представить взаимодействие между нормативным регулированием в виде следующей схемы:
Требования по операционной надежности фактически связывают ранее не связанное регулирование между системой управления операционными рисками и информационной безопасностью. Исключением является только рынок кредитных организаций, где в гл.7 Положения Банка России 716‑П четко выделяется риск информационной безопасности и требования к управлению им.
Мало того, документы по информационной безопасности требуют доработки с учетом новых требований, так как на момент вступления в силу требований по информационной безопасности требований по операционной надежности не существовало.
С точки зрения организации внутренних нормативных актов лучше выдерживать следующую базовую структуру:
Ключевым моментом данной структуры является описание всех организационных мер, предусмотренных в ГОСТ 57580 в виде процедур внутреннего контроля, которые описываются по шаблону:
Это позволяет определить достаточно кратко и системно порядок обеспечения требований самого ГОСТ, в таком виде будет точно понятно: кто, когда, что именно делает, какой должен быть результат. Документ будет содержать порядка 150–200 процедур контроля. При этом они обладают группой качеств:
1. Единообразность исполнения.
2. Отсутствие конфликта интересов.
3. Системность.
4. Соответствие регулируемым и общим принятым правилам обеспечения внутреннего контроля.
В требованиях к операционной надежности можно выделить два основных требования:
1. Порядок идентификации инцидента операционной надежности.
2. Расчет целевых показателей операционной надежности: суммарного времени простоя, времени простоя и доли деградации.
Целевые показатели операционной надежности являются прямым аналогом ключевых индикаторов риска (КИР) и имеют все соответствующие свойства и функции. Важно понимать и не смешивать воедино расчет КИР и процедуру идентификации риска. Уверен, что для многих это кажется очевидным, но при этом это ключевой момент в процессе управления операционным риском.
Пример
Классическая ошибка вышеописанной ситуации, когда организация рассчитывает количество операций, выполненных за прошлый период, за текущий период, и если разница между ними превышает установленную долю деградации, то тогда считает это операционным риском с признаком инцидента операционной надежности. То есть КИР является причиной возникновения риска, что противоречит определению КИР как таковому.
Предполагается следующий порядок проведения процедур операционной надежности:
1. Выявление событий операционного риска.
2. Идентификация и классификация операционного риска. Оценка количественных и качественных потерь.
3. Классификация каждого события операционного риска, является ли он инцидентом операционной надежности.
4. Расчет по каждому инциденту операционной надежности показателей КИР: доля деградации и времени простоя.
5. Расчет за квартал показателя КИР: суммарное время простоя.
Порядок выявления, идентификации и оценки операционных рисков рассматривается в других научных трудах. Хотелось бы более подробно рассмотреть именно порядок классификации инцидента операционной надежности как некоего нового критерия, регулируемого Банком России для целей расчета целевых показателей операционной надежности. Порядок классификации следующий:
1. Это событие операционного риска или с превышением количественных потерь, или с превышением качественных потерь на уровень равный или более чем «средний».
2. Время, в течение которого произошло событие, входит в режим работы технологического процесса.
3. Событие вызвано информационными угрозами и сбоями ПО/оборудования.
4. Событие привело к неоказанию или ненадлежащему оказанию услуг.
Ключевой деталью является ввод некой качественной шкалы, которая подразумевает отсечение части событий, исходя из длительности события в часах. Это позволяет вынести процедуру идентификации коротких событий в процесс управления операционными рисками за рамки регулирования 779‑П/787‑П. В результате не потребуется уведомлять ФинЦерт по некритичным событиям с небольшой длительностью и не потребуется принимать меры по каждому событию, что в целом соответствует общим принципам управления рисками.
Один из активно применяемых принципов идентификации риска, когда организация утверждает, что вне зависимости от произошедшего сбоя все операции будут проведены и выполнены. Тут важно обратить внимание на критерий п. 4 в процедуре классификации инцидента операционной надежности – это ненадлежащее оказание услуг. Пока услуга оказана надлежащим образом, условно у клиента не возникли проблемы, она не является инцидентом операционной надежности. Например, организация принимает распоряжение от клиента о выполнении операции, происходит сбой системы, длящийся 24 часа, при этом клиент ожидает выполнение распоряжения трое суток, он даже не заметит происходящего, значит, это не инцидент операционной надежности. Тут же есть обратная ситуация: клиент не может подать распоряжение уже много часов, при этом уже выстраивается очередь из клиентов, кто‑то уходит, не дождавшись возможности подать распоряжение. То есть, чтобы событие операционного риска стало инцидентом операционной надежности, это должно повлиять напрямую на клиентов и их ожидания.
Расчет целевых показателей операционной надежности осуществляется уже по списку событий, заранее классифицированных как инцидент операционной надежности.
Количественно сообщений о риске будет больше всего, подтвержденных событий операционного риска уже меньше, а из них инцидентов операционной надежности еще меньше, нарушений целевых показателей будут единицы. Можно представить это в виде схемы:
Расчет доли деградации происходит на основании выполненных операций во время инцидента операционной надежности к ожидаемому количеству операций. Расчет фактического времени простоя осуществляется только по тем событиям, по которым нарушена доля деградации. Суть деградации в том, что у нас очень редко бывают сбои, приводящие к полному простою процесса организации. Приведу несколько примеров:
1. Сбой личного кабинета, полностью не работает. При этом можно принести распоряжение в офис или отправить по ЭДО (через электронный документооборот).
2. Одно подразделение не работает, но работают другие подразделения организации и можно получить услугу в них.
3. Не работает мобильное приложение, но можно подать распоряжение через веб-сайт.
Доля деградации определяет, каким объемом бизнеса организация готова пожертвовать, например, одним регионом, в котором представлена, или одним из способов подачи распоряжений на операции.
В связи с разделением процесса на этапы и в связи с обработкой этих этапов различными информационными системами сбои, приводящие к полной остановке процесса, достаточно редки.
Фактическое значение допустимой доли деградации считается по формуле:
(Кво/Коп), где
Кво – количество совершенных операций во время инцидента операционной надежности.
Коп – плановое количество операций, совершенных в течение прошлого периода. Прошлый период для простоты можно определить как прошлый рабочий час или прошлый период прошлой недели.
Несмотря на кажущуюся сложность определения операционных рисков, связанных с операционной надежностью, все вопросы разрешаются при концентрации на ключевом тезисе: действительно ли прямо сейчас мы надлежащим образом оказываем услуги нашим клиентам.
Денис БЕЛЯЕВ, генеральный директор ООО «Технологии и Бизнес»
