doc/IT/reliability_risk/risk/850P/ai_proc_850.md

Process

1 Вопрос

Составь иерархию из 20 процессов банка под названием «Операционная надежность банка» в соответствии с 850-П от 13.01.2025 Об обязательных для кредитных организаций, иностранных банков, осуществляющих деятельность на территории Российской Федерации через свои филиалы, требованиях к операционной надежности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг".
«Операционная надежность банка» - это под процесс «Управление операционным риском» (в соответствии с 716-П), сам процесс «Управление операционным риском» рассматривать не нужно, т.е. нужно только элементы 850-П.

К сожалению, в доступных источниках не удалось найти полный список из 20 процессов, относящихся к операционной надёжности банка в соответствии с Положением Банка России №850-П. Однако на основе анализа документа и сопутствующих материалов можно выделить ключевые направления и элементы, которые могут быть структурированы в иерархию.

Основные элементы операционной надёжности по 850-П

1. Технологические процессы
   Перечень процессов, указанных в Приложении 1 к Положению, включает, например:

   • Привлечение денежных средств физических и юридических лиц во вклады.
   • Размещение привлечённых средств.
   • Осуществление переводов денежных средств.
   • Открытие и ведение банковских счетов.
   • Выполнение операций на финансовых рынках.
   • Кассовые операции.
   • Работа онлайн-сервисов дистанционного обслуживания.
   • Размещение и обновление биометрических данных в единой биометрической системе.
   • Идентификация и аутентификация с использованием биометрии. 115

2. Критичная архитектура
   Включает:

   • Технологические процессы и их участки.
   • Подразделения и работников, ответственных за процессы.
   • Объекты информационной инфраструктуры (автоматизированные системы, ПО, средства вычислительной техники, телекоммуникационное оборудование).
   • Технологические участки, предусмотренные Положением №851-П.
   • Взаимосвязи с другими организациями и поставщиками услуг в сфере ИТ.
   • Каналы передачи защищаемой информации. 122

3. Управление изменениями
   Планирование и внедрение изменений в критичной архитектуре для обеспечения непрерывности услуг. 7

4. Управление конфигурациями
   Контроль настраиваемых параметров объектов информационной инфраструктуры. 9

5. Управление уязвимостями и обновлениями
   Своевременное устранение уязвимостей и установка исправлений. 9

6. Выявление и регистрация инцидентов
   Фиксация случаев простоя или деградации технологических процессов, превышающих допустимые значения. 67

7. Реагирование на инциденты
   Меры по устранению нарушений в работе критичной архитектуры. 7

8. Восстановление после инцидентов
   Восстановление функционирования технологических процессов и объектов информационной инфраструктуры. 7

9. Анализ причин и последствий инцидентов
   Исследование факторов, приведших к нарушениям, и их влияния на деятельность банка. 7

10. Взаимодействие между подразделениями и с Банком России
    Координация действий при реагировании на инциденты и восстановлении процессов. 7

11. Тестирование операционной надёжности
    Проведение сценарного анализа и качественной оценки уровня операционного риска. 6

12. Защита от внутренних нарушителей
    Меры против несанкционированного доступа со стороны сотрудников или поставщиков услуг. 2

13. Обеспечение осведомлённости об угрозах
    Информирование сотрудников о актуальных информационных угрозах. 2

14. Сигнальные и контрольные значения деградации
    Установление пороговых значений допустимой доли деградации технологических процессов. 6

15. План обеспечения непрерывности бизнеса
    Разработка и тестирование плана восстановления после прерывания деятельности. 8

16. Учёт и контроль поставщиков услуг
    Ведение реестра поставщиков услуг в сфере ИТ, участвующих в технологических процессах. 12

17. Управление взаимосвязями и зависимостями
    Контроль взаимодействий с другими кредитными организациями, некредитными финансовыми организациями и поставщиками услуг. 12

18. Обеспечение безопасности значимых объектов КИИ
    Выполнение требований к защите объектов, признанных значимыми в соответствии с Федеральным законом №187-ФЗ. 9

19. Регистрация инцидентов в базе данных операционных рисков
    Фиксация событий, повлёкших за собой потери, в соответствии с Положением №716-П. 6

20. Информирование Банка России
    Предоставление сведений о выявленных случаях простоя и мероприятиях по реагированию для филиалов иностранных банков. 6

Примечания

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

2 Сгруппируй по группам

1. Подготовительные мероприятия, например, "становление пороговых значений допустимой доли деградации технологических процессов."
2. Тестирование
3. Обработка события Операционной надежности, например, получение из базы данных операционных рисков идентифицированного события Операционной надежности. А также отправка в Банка России сообщения в такой - то форме (укажи формат и регламент).
4. Пост-анализ события Операционной надежности
5. Разработка и тестирование плана восстановления после прерывания деятельности (если это действительно входит в 850-П)

На основе Положения Банка России №850-П можно выделить следующие группы процессов, связанных с операционной надёжностью:

1. Подготовительные мероприятия

• Установление пороговых значений допустимой доли деградации технологических процессов. Кредитные организации обязаны определить сигнальные и контрольные значения допустимой доли деградации технологических процессов, рассчитываемой как отношение количества операций, проведённых (или не проведённых) в период инцидента к плановому количеству операций в нормальном режиме. 17
• Идентификация критичной архитектуры. Включает технологические процессы, подразделения и работников, ответственных за них, а также объекты информационной инфраструктуры (автоматизированные системы, ПО, средства вычислительной техники и т. д.). 2
• Разработка процедур управления изменениями. Планирование и внедрение изменений в критичной архитектуре для обеспечения непрерывности услуг. 3
• Управление конфигурациями и уязвимостями. Контроль настраиваемых параметров объектов информационной инфраструктуры и своевременное устранение уязвимостей. 39

2. Тестирование

• Сценарный анализ и качественная оценка уровня операционного риска. Кредитные организации должны проводить сценарный анализ в составе качественной оценки уровня операционного риска, учитывая возможные информационные угрозы и сбои объектов информационной инфраструктуры. 6
• Тестирование готовности к противостоянию информационным угрозам. Филиалы иностранных банков определяют периодичность и программу тестирования готовности противостоять реализации информационных угроз в отношении критичной архитектуры. 6
• Тестирование плана восстановления после прерывания деятельности. План должен включать условия активации, действия после инцидента, процедуры восстановления и тестирования, а также обучение работников. 11

3. Обработка события операционной надёжности

• Выявление и регистрация инцидентов. Кредитные организации обязаны регистрировать инциденты операционной надёжности, приведшие к прямым или непрямым потерям, в базе событий согласно Положению №716-П. 23
• Реагирование на инциденты. Меры по устранению нарушений в работе критичной архитектуры, включая взаимодействие между подразделениями и с Банком России. 23
• Информирование Банка России. Филиалы иностранных банков должны информировать Банк России о случаях простоя технологических процессов, превышающих пороговое время, а также о принятых мерах и планируемых мероприятиях по раскрытию информации (пресс-релизы, пресс-конференции). 3

Формат информирования: сведения представляются через техническую инфраструктуру (автоматизированную систему) Банка России или резервный способ взаимодействия, информация о котором размещена на официальном сайте Банка России. 3

4. Пост-анализ события операционной надёжности

• Анализ причин и последствий инцидентов. Исследование факторов, приведших к нарушению операционной надёжности, и оценка последствий. 3
• Корректировка мер обеспечения операционной надёжности. На основе анализа вносятся изменения в процессы и процедуры для предотвращения повторения инцидентов. 1

5. Разработка и тестирование плана восстановления после прерывания деятельности

• Разработка плана обеспечения непрерывности бизнеса и его восстановления. План должен содержать инструкции, порядок действий работников, процедуры восстановления, обучения и повышения осведомлённости. 11
• Тестирование плана. Периодическое тестирование плана с учётом модели угроз и результатов оценки рисков. При необходимости проводится корректировка плана на основе результатов тестирования. 11

Примечание: Положение №850-П акцентирует внимание на непрерывности оказания банковских услуг и требует от кредитных организаций и филиалов иностранных банков комплексного подхода к обеспечению операционной надёжности, включая превентивные меры, мониторинг, реагирование на инциденты и пост-анализ. 610

Для более детального понимания требований рекомендуется обратиться к полному тексту Положения Банка России №850-П и сопутствующим документам, таким как ГОСТ Р 57580.3 и 57580.4, а также к Положению №716-П.

Источники:

• 850-П klerk ; sudact.ru

• https://www.dialognauka.ru/upload/iblock/672/k85dcy0jxxm3hzlx7i3nwploa7d2xvzu/Zasetskaya_K_2025_05_20-METROPOL_GOST-57580.4_2022.pdf

• https://service.securitm.ru/docs/polozhenie-banka-rossii-850-p

• https://rtmtech.ru/articles/polozhenie-850-p-trebovaniya-zb/

3 ТАБ GRC

• https://infostart.ru/soft1c/tab-grc-uchet-riskovyh-sobytiy/

• https://rutube.ru/video/6bdeb1095b02ebf031ac56884126931c

• Созвездие GRC 2024

4 Cобытия операционного риска и инцидент операционной надёжности - укажи все сходства и различия

События операционного риска и инциденты операционной надёжности — это связанные, но разные понятия в банковской сфере. Они регулируются различными нормативными актами и имеют чёткие различия в контексте их определения, последствий и требований к управлению.

Сходства

1. Связь с рисками и нарушениями: оба понятия связаны с нарушениями в работе банковских процессов и систем, которые могут привести к негативным последствиям для кредитной организации и её клиентов.
2. Регистрация и учёт: и события операционного риска, и инциденты операционной надёжности должны фиксироваться в базе данных кредитной организации. Для инцидентов операционной надёжности предусмотрены дополнительные требования к регистрации, включая данные о превышении целевых показателей и мерах реагирования. 8
3. Влияние на банковские услуги: оба явления могут приводить к прерыванию или ненадлежащему оказанию банковских услуг, что негативно сказывается на клиентах и репутации банка.
4. Требования к управлению: оба требуют от кредитных организаций разработки процедур выявления, классификации, реагирования и минимизации последствий. Это включает анализ причин, принятие мер и восстановление нормальной работы. 78

Различия

Критерий	Событие операционного риска	Инцидент операционной надёжности
Определение	Реализация операционного риска, которая может включать ошибки персонала, сбои систем, внешние события и другие факторы, приводящие к прямым или косвенным потерям.	Событие операционного риска или серия связанных событий, вызванных информационными угрозами или сбоями объектов информационной инфраструктуры, которые привели к неоказанию или ненадлежащему оказанию банковских услуг. 2468
Связь с ИТ	Может быть связано с ИТ, но не ограничивается ими. Включает широкий спектр факторов: от ошибок сотрудников до юридических рисков.	Обязательно связан с информационными угрозами или сбоями объектов информационной инфраструктуры (автоматизированных систем, ПО, оборудования). 2468
Последствия для клиентов	Не всегда непосредственно влияет на клиентов. Например, ошибка в внутренних процессах может не быть заметна клиентам.	Прямое влияние на клиентов: приводит к прерыванию или ненадлежащему оказанию услуг, что заметно для клиентов (например, невозможность подать распоряжение, задержка в выполнении операций). 1112
Критерии классификации	Классифицируется по источникам риска, типам событий, направлениям деятельности и видам потерь.	Классифицируется как инцидент, если событие операционного риска привело к превышению допустимой доли деградации технологического процесса или допустимого времени простоя. 378
Нормативная база	Регулируется Положением Банка России №716-П «О требованиях к системе управления операционным риском в кредитной организации и банковской группе».	Регулируется Положением Банка России №787-П «Об обязательных для кредитных организаций требованиях к операционной надёжности при осуществлении банковской деятельности». 3489
Информирование Банка России	Не всегда требует информирования Банка России, если не приводит к серьёзным последствиям.	Обязательно требует информирования Банка России, если превышены допустимые показатели деградации или простоя. 78

Дополнительные пояснения

• Допустимая доля деградации технологического процесса — это заранее установленный кредитной организацией порог, превышение которого квалифицирует событие как инцидент операционной надёжности. Рассчитывается на основе статистических данных за 12 месяцев. 78
• Время простоя — период с момента нарушения технологического процесса до его восстановления. Учитывается только в случае превышения допустимой доли деградации. 78
• Взаимодействие с Банком России: при инциденте операционной надёжности кредитная организация обязана информировать Банк России о принятых мерах и планируемых мероприятиях по раскрытию информации (например, пресс-релизах). 7

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

5 Приведи пример, когда событие операционного риска (СОР) не является инцидентом операционной надёжности (ИОН). Также укажи особые (дополнительные) свойства (параметры), которые есть у ИОН, но нет у СОР.

Пример события операционного риска (СОР), которое не является инцидентом операционной надёжности (ИОН):

Представьте ситуацию, когда в банке произошла ошибка в расчётах при оформлении кредитного договора из-за невнимательности сотрудника. Это событие относится к операционному риску, так как связано с человеческим фактором и может привести к финансовым потерям для банка или клиента. Однако если ошибка была обнаружена до того, как клиент получил кредит, и не повлияла на оказание банковских услуг (например, клиент не подал заявку или не получил средства), то это событие не квалифицируется как инцидент операционной надёжности. Для ИОН необходимо, чтобы событие привело к прерыванию или ненадлежащему оказанию услуг клиентам. 1

Особые свойства (параметры) ИОН, которых нет у СОР:

1. Превышение допустимой доли деградации технологического процесса. ИОН фиксируется, если доля невыполненных операций во время инцидента превышает заранее установленные кредитной организацией пороги. Для СОР такого критерия нет — он может возникнуть и без нарушения целевых показателей. 19

2. Превышение допустимого времени простоя. ИОН регистрируется, если время простоя технологического процесса превысило установленные лимиты. СОР может произойти без остановки процессов, например, из-за ошибки в документации. 19

3. Прямое влияние на клиентов. ИОН всегда приводит к прерыванию или ненадлежащему оказанию банковских услуг, что заметно для клиентов (например, невозможность подать распоряжение, задержка в выполнении операций). СОР может быть внутренним событием, не затрагивающим клиентов напрямую. 12

4. Обязательность информирования Банка России. При ИОН кредитная организация обязана уведомить Банк России, если превышены допустимые показатели деградации или простоя. Для СОР такое требование возникает только в определённых случаях, например, при значительных потерях или нарушениях, требующих регуляторного контроля. 75

5. Связь с информационными угрозами или сбоями объектов информационной инфраструктуры. ИОН обязательно вызван сбоями систем, ПО, оборудования или информационными угрозами. СОР может быть связан с другими факторами: ошибками персонала, юридическими рисками, внешними событиями (например, стихийными бедствиями). 67

6. Регистрация в специальной базе данных операционной надёжности. ИОН фиксируется в отдельной системе учёта, где отслеживаются показатели деградации, время простоя и меры реагирования. СОР регистрируется в базе событий операционного риска, которая может включать более широкий спектр событий. 69

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