Комплаенс в финтехе: мой опыт работы с нормативкой
Когда я начал работать руководителем комплаенса информационной безопасности в финтехе, первым делом мне нужно было разобраться: какие именно требования к нам применимы? Оказалось, что нормативки не так уж и мало, и каждая требует своего подхода.
В этой статье я расскажу о том, с какими регуляторными требованиями мне пришлось работать, как я их осваивал и что из этого вышло. Это не официальное руководство, а личный опыт — возможно, он поможет тем, кто только начинает свой путь в комплаенсе.
С чего всё началось
Когда я пришёл в компанию, там уже была некоторая база по информационной безопасности. Но она была фрагментарной — то там закрыли какое-то требование, то здесь что-то внедрили. Системного подхода не было.
Первое, что я сделал — составил список всех требований, которые к нам применимы. И тут началось самое интересное.
Нормативка Банка России: с чего начинать
Банк России для финансовых организаций — это главный регулятор. И требования у него серьёзные. Когда я начал изучать нормативную базу, я понял, что просто так от этих требований не отвертеться.
Положение Банка России № 683-П
Это одно из ключевых положений, которое устанавливает требования к защите информации при банковской деятельности. Основная цель — предотвратить несанкционированные переводы денежных средств. Звучит страшно? На самом деле, если разобраться, всё логично.
Положение требует:
- Организацию системы защиты информации
- Контроль доступа к банковским системам
- Мониторинг и реагирование на инциденты
- Регулярные проверки и аудиты
Когда я впервые читал это положение, меня удивило, насколько детально там прописаны требования. Кажется, что это избыточно, но на практике каждая мера находит своё применение.
Положение Банка России № 787-П
Этот документ регламентирует требования к защите информации в платежной системе Банка России. Если ваша компания работает с платежами — этот документ обязателен к изучению.
Основной фокус здесь — на защите платежных данных и обеспечении непрерывности платежных процессов. Мне пришлось потратить не одну неделю, чтобы разобраться во всех тонкостях.
Положение Банка России № 821-П
Ещё одно важное положение, которое определяет порядок обеспечения защиты информации при переводах денежных средств. Здесь детально прописано, как должна быть организована защита на каждом этапе обработки платежей.
Когда я внедрял требования этого положения, мне пришлось плотно работать с разработчиками. Потому что многие требования нужно было закладывать на уровне архитектуры системы.
СТО БР БФБО-1.8-2024
Относительно новый стандарт, который устанавливает требования к безопасности финансовых сервисов при дистанционной идентификации и аутентификации. Это актуально для всех, кто работает с онлайн-банкингом и дистанционным обслуживанием.
Здесь особый упор на безопасность процедур идентификации клиентов. И это не просто формальность — реально нужно защищать от мошенничества.
СТО БР ИББС
Стандарт Банка России по информационной безопасности банковских систем. Это комплексный документ, который охватывает:
- Управление рисками ИБ
- Защиту информации на всех уровнях
- Инцидент-менеджмент
- Безопасность разработки
Когда я начал работать с этим стандартом, я понял, что это не просто набор требований, а целая система. Нужно выстраивать процессы управления рисками, нужно настраивать мониторинг, нужно обучать людей.
ГОСТ Р 57580.1-2017: базовый состав мер защиты
ГОСТ Р 57580.1-2017 «Безопасность финансовых (банковских) операций. Защита информации финансовых организаций» — это документ, с которым мне пришлось работать плотно. Он определяет базовый состав организационных и технических мер.
Что внутри стандарта
Стандарт структурирован логично. Начинается с области применения и терминов — казалось бы, скучно, но без понимания терминов дальше двигаться невозможно. Потом идут общие положения, которые задают направление.
Уровни защиты информации
Один из ключевых разделов — это уровни защиты информации. Стандарт определяет несколько уровней, и для каждого уровня прописаны свои требования. Мне нужно было определить, какой уровень защиты применим к нашей компании.
Это не всегда очевидно. Нужно анализировать объём обрабатываемых данных, критичность систем, риски. Я потратил немало времени на этот анализ, но без него дальше двигаться нельзя.
Требования к системе защиты информации
Здесь прописаны требования к организационным и техническим мерам защиты. Это не просто список — это система взаимосвязанных требований.
Организационные меры включают:
- Назначение ответственных лиц
- Разработку политик и процедур
- Обучение персонала
- Контроль и мониторинг
Технические меры — это:
- Средства защиты информации
- Системы контроля доступа
- Средства мониторинга
- Резервное копирование
Когда я начал внедрять эти требования, я понял, что они должны работать вместе. Нельзя сделать только технические меры и забыть про организационные, и наоборот.
Требования к выбору мер защиты
Важный раздел, который определяет, как выбирать конкретные меры защиты. Не всё нужно внедрять сразу — нужно оценить риски и выбрать меры адекватно рискам.
Мне этот подход понравился. Он позволяет не делать избыточные вложения, но при этом обеспечить необходимый уровень защиты.
Требования к полноте реализации
Этот раздел устанавливает требования к тому, чтобы меры были реализованы полностью, а не частично. С формальной точки зрения можно создать политику, но если она не работает — это не защита.
Я видел компании, где были все документы, но на практике ничего не работало. Это плохая практика. Лучше сделать меньше, но качественно.
Защита на этапах жизненного цикла
Очень важный раздел для тех, кто разрабатывает свои системы. Стандарт требует обеспечивать защиту информации на всех этапах: от проектирования до вывода из эксплуатации.
Для меня это означало тесную работу с командами разработки. Нужно было внедрять практики безопасной разработки, проводить анализ безопасности кода, тестировать защиту на всех этапах.
Это оказалось одним из самых сложных направлений. Разработчики привыкли делать функциональность, а здесь нужно ещё и думать о безопасности. Но постепенно это стало частью культуры разработки.
PCI DSS: когда работаешь с картами
Если ваша компания обрабатывает платежные карты, без PCI DSS не обойтись. Это международный стандарт, но требования его обязательны к выполнению.
Я работал с PCI DSS, и могу сказать: требования там жёсткие, но логичные. Основные направления:
- Защита периметра — файрволы, сегментация сетей
- Защита данных — шифрование данных карт, ограничение хранения
- Управление доступом — строгий контроль, кто и к чему имеет доступ
- Мониторинг — отслеживание всех действий с данными карт
- Тестирование — регулярные проверки уязвимостей
- Политики — документирование всех процессов
Самый сложный момент — это ограничение хранения данных карт. По стандарту, нельзя хранить полные номера карт, CVV-коды и другие чувствительные данные дольше, чем необходимо. Пришлось переделывать часть системы, чтобы соответствовать этим требованиям.
Но когда всё внедрено и работает — становится спокойнее. Понимаешь, что данные защищены, что есть мониторинг, что система устойчива к атакам.
152-ФЗ: про персональные данные
Федеральный закон № 152-ФЗ «О персональных данных» — это то, с чем работают все, кто обрабатывает персональные данные. В финтехе это особенно актуально, потому что мы работаем с финансовыми данными клиентов.
Основные требования:
- Получение согласия на обработку
- Обеспечение безопасности
- Уведомление регулятора
- Права субъектов персональных данных
Это базовые требования, но их нужно выполнять качественно. Особенно важно обеспечить безопасность обработки — не просто формально, а реально защитить данные.
Как я строил систему комплаенса
Когда я разобрался с требованиями, началась практическая работа. Я не пытался закрыть всё сразу — это нереально. Вместо этого я составил план.
Первый этап: аудит и оценка
Начал с того, что провёл аудит текущего состояния. Что уже есть? Что работает? Что только на бумаге? Это заняло около месяца, но без этого дальше двигаться было нельзя.
Оказалось, что часть требований уже выполнена, но не системно. Какие-то меры были внедрены для одного требования, но не использовались для другого. Нужно было унифицировать подход.
Второй этап: приоритизация
Потом определил приоритеты. Критичные требования — те, которые могут привести к остановке деятельности или серьёзным штрафам. Их — в первую очередь.
Высокоприоритетные — влияют на репутацию и доверие клиентов. Средние и низкие — по остаточному принципу, но не забывать про них.
Третий этап: внедрение
И начал внедрять. Не всё сразу, а постепенно. Сначала — базовые меры, которые закрывают несколько требований сразу. Потом — более специфичные.
Важно было не делать «для галочки». Каждая мера должна реально работать. Если политика написана, но никто её не выполняет — это не защита, а иллюзия.
Четвёртый этап: обучение и культура
Одно из самых важных направлений — это обучение сотрудников. Можно построить самую совершенную систему, но если люди не понимают, зачем это нужно — система не будет работать.
Я проводил обучение для разных групп: для разработчиков, для операторов, для менеджмента. Для каждой группы — свой подход, свои примеры, свои акценты.
Что получилось в итоге
Через полгода работы у нас была система комплаенса, которая реально работала. Не идеальная, но рабочая. Все критичные требования были закрыты, процессы были настроены, люди понимали, что и зачем они делают.
Важно было то, что система не была формальной. Каждый документ, каждая процедура, каждая мера защиты — всё это имело практическое применение. И это стало заметно — количество инцидентов снизилось, проверки проходили успешно.
Уроки, которые я извлёк
Работая с нормативкой, я понял несколько важных вещей:
Не бойтесь нормативки. Требования кажутся сложными, но если разобраться — они логичны. Каждое требование решает конкретную задачу.
Системный подход важен. Нельзя закрывать требования по отдельности — нужно строить систему. Одна мера может закрывать несколько требований.
Практика важнее теории. Можно написать кучу документов, но если они не работают на практике — это бесполезно. Лучше сделать меньше, но качественно.
Коммуникация критична. Нужно объяснять людям, зачем нужны те или иные требования. Когда люди понимают цель — они лучше выполняют требования.
Комплаенс — это процесс. Не разовое мероприятие, а непрерывная работа. Нужно постоянно мониторить, улучшать, адаптироваться к изменениям.
Что дальше
Нормативка постоянно обновляется. Появляются новые требования, меняются старые. Нужно следить за изменениями и адаптировать систему.
Я продолжаю работать в этом направлении. Каждый день — новые вызовы, новые задачи. Но теперь я понимаю, как с ними работать, как строить систему, которая реально защищает.
Если вы только начинаете работать с комплаенсом в финтехе — не паникуйте. Начните с изучения требований, проведите аудит, определите приоритеты. И двигайтесь постепенно, шаг за шагом. Результат обязательно будет.
Вопросы? Пишите в комментариях или свяжитесь со мной через Telegram или Email.
Следующая статья будет посвящена практическим кейсам внедрения стандартов ИБ. Следите за обновлениями!