В законодательном пространстве РФ за последний десяток лет появились принципиально новые категории и связанные с ними требования/ограничения.

• Понятие критической информационной инфраструктуры вводит Федеральный закон от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации» в редакции Федерального закона от 07.04.2025 № 58-ФЗ «О внесении изменений в Федеральный закон “О безопасности критической информационной инфраструктуры Российской Федерации”». 
• Перечень типовых объектов критической информационной инфраструктуры по отраслям определят проект Постановления Правительства РФ «Об утверждении перечней типовых отраслевых объектов критической информационной инфраструктуры».
• Постановление Правительства России № 1912 предполагает запрет на использование зарубежных программно-аппаратных комплексов (ПАК) на объектах критической информационной инфраструктуры (КИИ) с оговоркой, что иностранные технологии могут быть использованы только в двух случаях: если комплексы были приобретены до 1 сентября 2024 года и если на рынке отсутствуют отечественные аналоги необходимого решения, что подтверждается заключением Минпромторга. При этом полный переход на отечественные ПАКи должен состояться до 1 января 2030 года.
• Правила разработки и анализа уязвимостей ПО регламентирует ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования», а также ГОСТы и проекты ГОСТов по статистическому, динамическому и композиционному анализу.
• Приказ ФСТЭК России от 1 декабря 2023 года, а также многочисленные методические рекомендации определяют порядок проведения сертификации процессов безопасной разработки программного обеспечения средств защиты информации.

В общем случае к субъектам критической информационной инфраструктуры относятся государственные органы и российские юридические лица, владеющие информационными системами в сфере здравоохранения, науки, транспорта, связи, энергетики, финансового сектора, оборонной и химической промышленности. Суть законодательных инициатив сводится во введении обязательных требований по переходу на отечественное программное обеспечение и программно-аппаратные комплексы — вплоть до целевого заключения форвардных контрактов на разработку необходимых решений, для которых «в моменте» нет российских аналогов.

При этом совершенствуются не только «матчасть» информационных технологий, но и методики оценки влияния этих технологий на ведение бизнеса, методики оценки рисков.

Применительно к банковской отрасли вопросы классификации и оценки операционных рисков, а также управления ими регулирует Положение Банка России от 8 апреля 2020 года № 716-П «О требованиях к системе управления операционным риском в кредитной организации и банковской группе». При этом определение операционного риска и основные процедуры по управлению им раскрыты в гл. 4 Приложения 1 к Указанию Банка России от 15 апреля 2015 года № 3624-У «О требованиях к системе управления рисками и капиталом кредитной организации и банковской группы».

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

Для каждого из выявленных рисков определяется уровень существенности по четырехуровневой шкале: «очень высокий», «высокий», «средний», «низкий», а также проводятся качественная оценка вероятности реализации конкретного вида операционного риска в условиях текущих процессов и оценка количественных потерь (часто выражаемая в процентах от конкретных объемных показателей или в универсальном рублевом эквиваленте).

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

В числе мероприятий, направленных на ограничение размера потерь от реализации событий операционного риска, кредитная организация разрабатывает планы по обеспечению непрерывности и (или) восстановления критически важных процессов и функционирования информационных систем, включая объекты информационной инфраструктуры, с учетом внешних факторов, влияющих на критически важный процесс и (или) информационную систему.

ЦБ РФ рекомендует придерживаться следующей структуры при описании типовых процессов (в целях оценки операционного риска):

• направление деятельности (в соответствии с п. 3.9 Положения № 716-П),

  • процесс первого уровня,

  • процесс второго уровня,

  • процесс третьего уровня.

Например:

• розничное банковское обслуживание,

  • кредитование физических лиц,

    • потребительское кредитование,

      • с применением инструментов ДБО.

      • Без применения инструментов ДБО

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

С точки зрения современных подходов к платформенной архитектуре при разработке информационных систем выделяют некие универсальные блоки, которые не зависят от предметной области и работают на основе промышленных спецификаций (например, BPMN 2.0), забирая на себя техническую сложность, связанную с управлением жизненным циклом бизнес-сущностей и пакетов пользовательских данных. Именно такой подход демонстрирует применение BPM-движков, которые выступают в качестве бизнес-оркестраторов или workflow-менеджеров при автоматизации сложных отраслевых процессов, особенно в банковской отрасли. 

За последние пять-десять лет в РФ и в мире очень много проектов автоматизации для кредитных организаций было реализовано на иностранном open-source BPM-движке Camunda 7 от компании Camunda Services GmbH. Однако в октябре 2025 года компания Camunda прекращает развитие этой open-source-платформы и сосредотачивается на развитии своих коммерческих версий, которые с 2022 года недоступны для приобретения на территории РФ. В результате огромное число проектов оказываются в «подвешенном состоянии» без вендорской поддержки, без обновлений и исправления уязвимостей, без понятного пути развития и миграции на горизонте в два-три года. Таким образом, реализуются операционные риски информационных систем, обусловленные внешними факторами, связанные с вопросами информационной безопасности и вопросами обеспечения непрерывности ведения бизнеса (так как на технологической базе BPM-движков реализованы и ключевые процессы продаж, и многие обслуживающие банковские процессы).

Перечень рисков

Перечислю пути устранения и/или компенсации выявленных операционных рисков.

• Миграция проектов автоматизации с иностранного решения Camunda на российскую платформу OpenBPM соответствует требованиям, установленным к критической информационной инфраструктуре для финансового сектора РФ.
• При этом инженерная команда компании «Хоулмонт» обеспечивает централизованное решение вопросов совместимости с инфраструктурным российским окружением, а также берет на себя устранение ошибок и уязвимостей, выявляемых в коде BPM-движка и его зависимых библиотек. Это в совокупности снижает частоту появления критичных сбоев и инцидентов информационной безопасности на продуктивном контуре заказчика.
• Командам заказчика не нужно будет отвлекать свои ресурсы на поддержку и актуализацию собственных «форков» иностранного решения. При этом можно будет переиспользовать все те компетенции, которые были накоплены в командах разработки за время работы с иностранными решениями, сохранив инвестиции в обучение.
• Использование профессиональных инструментов из состава платформы OpenBPM позволяет до трех раз ускорить отдельные этапы разработки и до четырех раз их удешевить за счет глубокой интеграции компонентов и возможности использования бесплатных версий по сравнению с традиционной разработкой на базе закрытых коробочных BPMS-систем. 
• Возможность использовать при разработке современные версии языков программирования, актуальные сборки JDK, а также свобода в выборе фронтального стека расширяет диапазон вариантов при найме IT-специалистов и в целом усиливает HR-бренд заказчика.

Таким образом, затраты на лицензирование платформы OpenBPM, если говорить о ее коммерческой версии с оперативными обновлениями и поддержкой, составляют 5–10% совокупных потерь, обусловленных реализацией операционных рисков, которые порождены продолжением использования иностранного решения Camunda после его официального EOL (End-of-Life) в октябре 2025 года.

Узнать подробнее про OpenBPM и оставить заявку на технологическое демо для ваших команд вы можете на сайте.