Если спросить любую финтех-команду, какой стандарт безопасности они используют, ответ будет примерно одинаковый: NIST, ISO 27001, CIS Controls — у кого что ближе.

Но есть нюанс.

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

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

Источник: Ассоциация_Финтех_Compliance_Control_Security_resilience_Подходы

Сначала — плохая новость: универсальных стандартов не существует

Главный вывод исследования звучит почти крамольно: международные практики ИБ в финтехе работают… но только после серьёзной адаптации.

Причина довольно очевидная:

  • требования регуляторов,

  • локализация инфраструктуры,

  • ограничения на зарубежные сервисы,

  • интеграция ИБ с финансовыми процессами и AML.

То есть безопасность — это уже не набор best practices, а гибрид из архитектуры и комплаенса.

И именно здесь начинается самое интересное.

NIST CSF как карта местности, а не инструкция

Авторы исследования берут за основу доменную модель NIST CSF 2.0 — но используют её не как стандарт, а как способ структурировать хаос.

Шесть доменов:

  • Governance

  • Identify

  • Protect

  • Detect

  • Respond

  • Recover

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

Если перевести на язык инженеров: NIST здесь — это скорее reference architecture, чем набор контролей.

Где практика расходится с теорией

Теперь к самому интересному — реальным ограничениям, которые исследование разбирает довольно подробно.

Governance: безопасность начинаетcя не с SOC, а с регулятора

В классических моделях Governance — это про стратегию и риск-аппетит.

В российском финтехе — это про:

  • требования регуляторов,

  • выбор отечественного ПО,

  • управление зависимостями от поставщиков.

Фактически стратегия безопасности часто определяется внешними ограничениями раньше, чем внутренними рисками.

И это меняет архитектуру сверху вниз.

Identify: когда Threat Intelligence не приходит извне

Международные модели сильно завязаны на обмен CTI.

Но исследование прямо говорит — в России нет единой широко доступной экосистемы обмена угрозами уровня US-CERT или ENISA.

Что происходит на практике:

  • больше reliance на внутренние источники,

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

  • выше требования к инвентаризации активов.

И да — это увеличивает стоимость зрелости.

Protect: импортозамещение — это не про продукты, а про архитектуру

Многие думают, что импортозамещение — это просто выбор другого вендора.

Но в отчёте хорошо показано, что ограничения на зарубежные облака меняют саму модель безопасности:

  • меньше cloud-native контролей,

  • больше локальной инфраструктуры,

  • сложнее масштабирование.

И это влияет не только на Protect, но и на Detect.

Detect: SOC становится «локальным»

Требования к локальному размещению логов и мониторинга означают, что классическая cloud-SIEM модель просто не работает.

В результате:

  • больше on-prem решений,

  • выше требования к 24/7 мониторингу,

  • жёсткие сроки уведомления о инцидентах.

SOC перестаёт быть просто технической функцией — он становится частью регуляторного процесса.

Respond: инцидент-response как юридическая дисциплина

Одна из самых сильных частей отчёта — описание сроков уведомления (3/24/72 часа).

Это меняет всю философию IR:

  • автоматизация нужна не ради скорости, а ради соблюдения сроков;

  • классификация инцидентов — это уже не только технический вопрос;

  • коммуникации с регуляторами становятся частью runbook.

Recover: устойчивость стоит дорого

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

По оценке исследования — до 20–30% ИТ-бюджета может уходить на обеспечение устойчивости.

И это тот случай, когда resilience — это не красивое слово, а архитектурный компромисс.

Главная идея: гибрид вместо копирования

Авторы приходят к довольно зрелому выводу:

  • ГОСТ — это нормативная база и проверяемость,

  • NIST CSF — архитектура и управление рисками.

Вместе они дают модель, которая реально работает в финтехе.

Это не «локальная версия NIST» и не «ISO с поправками».
Это новая гибридная практика.

AFT Framework: попытка измерить зрелость без самообмана

Вторая часть исследования — собственный фреймворк оценки зрелости.

Что интересно:

  • добавлен отдельный домен Supply Chain — управление зависимостями;

  • зрелость измеряется не только технологиями, но и управлением, обучением, коммуникациями;

  • оценка строится через балльную модель по доменам.

По сути — это попытка сделать maturity model, которая учитывает реальные ограничения рынка.

TL;DR для тех, кто строит безопасность сегодня

Если упростить весь отчёт до нескольких практических выводов:

  • NIST — это уже не стандарт, а язык описания архитектуры.

  • SOC становится юридически значимой функцией.

  • Импортозамещение влияет на процессы сильнее, чем на технологии.

  • Governance — главный драйвер зрелости, а не Detect.

  • Security resilience — это про инфраструктуру и процессы, а не про очередной продукт.

Вместо вывода

Есть ощущение, что финтех-ИБ переживает переходный момент.

Раньше можно было взять западный фреймворк и попытаться внедрить его «как есть». Сейчас приходится пересобирать архитектуру под реальные ограничения — и именно об этом, по сути, всё исследование.

И если раньше зрелость безопасности измеряли количеством контролей, то теперь — способностью системы выживать в условиях ограничений.

Владислав Прокопови�� | CIO.логия