Аудит требований Банка России: как выбрать проверку и подготовить доказательства

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

Материал отражает положение, проверенное на 9 октября 2026 года, и относится к организациям российского финансового сектора. Это не универсальный международный банковский стандарт и не полный каталог российских регуляторных обязанностей. До закупки ответственный за комплаенс или юридическая служба должны подтвердить статус организации, действующую редакцию актов, переходные положения и индивидуальные предписания.

Главный принцип закупки: начинать с регулируемой деятельности и требуемого вывода, а затем строить технический периметр. Стартовый список «все внешние IP-адреса» или «одно мобильное приложение» может привести к качественному техническому тесту, который не отвечает на вопрос аудита.

Составьте матрицу применимости до запроса предложений

Три положения Банка России показывают, почему единого чек-листа нет.

Положение 851-П от 30 января 2025 года регулирует защиту информации кредитными организациями и филиалами иностранных банков при банковской деятельности, связанной с переводами денежных средств. Оно заменило 683-П. Документ разделяет регулярные технические проверки и формальную оценку: один пентест сам по себе не создаёт заключение о соответствии.

Положение 821-П охватывает определённых субъектов и операторов национальной платёжной системы, включая операторов по переводу денежных средств и операторов услуг платёжной инфраструктуры. Оно заменило 719-П, поэтому 719-П нельзя брать как действующую основу. Указание 7220-У изменило 821-П с 1 октября 2026 года. Объём, утверждённый до этой даты, требует проверки версии, особенно если затронуты биометрические переводы или единый контур защиты нескольких видов деятельности.

Положение 757-П образует отдельную ветку для некредитных финансовых организаций, работающих на финансовом рынке. Применимость и требуемый уровень защиты зависят от вида организации, деятельности и критериев самого положения. Поэтому периодичность и метод нельзя переносить из программы кредитной организации или оператора платёжной системы. Указание 7219-У содержит более поздние изменения, основные положения которых вступают в силу 1 января 2027 года; на дату статьи их нельзя выдавать за действующие требования.

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

У одной организации может быть несколько строк. Некредитная финансовая организация способна одновременно выполнять отдельную роль в платёжном процессе. Общая система идентификации, API-шлюз или процессинговая платформа могут обслуживать виды деятельности с разными требованиями. Матрица должна сохранить различия между ними и показать общие технические зависимости.

Как выбрать нужный вид проверки

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

ГОСТ Р 57580.1 описывает базовый состав организационных и технических мер защиты информации. ГОСТ Р 57580.2 задаёт методику оценки соответствия и оформления результата. Это разные роли. Пентест может дать доказательства фактического технического поведения, но после сдачи его нельзя переименовать в оценку соответствия по ГОСТ Р 57580.2.

Квалификацию исполнителя нужно привязывать к конкретному результату. Если 851-П, 821-П или 757-П требует для формальной оценки внешнюю проверяющую организацию с указанными лицензиями или независимостью, закупка должна проверить эти условия именно для такой оценки. Для внешнего пентеста 2-МР рекомендует проверять лицензию на техническую защиту конфиденциальной информации и независимость. Рекомендательный статус 2-МР не отменяет других обязательных требований. Заказчик проверяет квалификацию и для регулируемой оценки, и для планируемой технической услуги.

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

Переведите каждый регулируемый процесс в технический периметр

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

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

Для периметра также нужны среды, адреса, версии, учётные записи, роли, доверительные связи, классы данных и владельцы. Все исключения называются явно и сопровождаются причиной. Если тестирование рабочей среды ограничено, укажите замещающую среду и доказательства, а также утверждения, которые останутся непроверенными. Согласованное исключение — решение о риске; молчаливый пропуск — разрыв прослеживаемости.

1. Деятельность и рольОпределить финансовую деятельность, юридическую роль, уровень защиты, применимый акт, редакцию и дату действия
2. Защищаемый процессПроследить операцию, данные, решения об авторизации, привилегированные действия и пути отказа
3. Технический периметрСвязать приложения, API, инфраструктуру, учётные записи, поставщиков, среды, исключения и владельцев
4. Метод и исполнительНазначить оценку соответствия, пентест, анализ уязвимостей или внутреннюю проверку с нужной квалификацией
5. Приёмка и повторная проверкаСвязать обязанность с доказательством, находкой, владельцем исправления, критерием приёмки и статусом ретеста

Эта цепочка предотвращает две типичные ошибки. Первая — проверить всё доступное извне, но пропустить внутренний сервис, который меняет статус операции. Вторая — тщательно проверить один регулируемый продукт, оставив за границей общую систему идентификации, администрирование или путь поставки изменений.

Пересматривайте объём работ при изменении требований

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

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

Закрепите такой порядок пересмотра в договоре. Назначенный заказчиком владелец решает, требует ли изменение нового объёма, цены, графика или критерия приёмки. Подрядчик не должен молча принимать новую юридическую трактовку, а заказчик не должен при сдаче обнаруживать устаревшую редакцию. Решение о том, что изменение не влияет на проект, тоже записывается с обоснованием.

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

Как включить подрядчиков и облачные сервисы в проверку

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

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

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

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

Спроектируйте матрицу доказательств до теста

Отчёт помогает аудиту требований Банка России, только если проверяющий прослеживает путь от обязанности до доказательства. До полевых работ создайте матрицу как минимум со следующими полями:

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

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

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

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

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

Включите приёмку и ретест в предмет закупки

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

Для исправлений нужны столь же точные статусы. «Исправлено» — утверждение команды. «Повторно проверено на сборке X в среде Y; исходный путь не воспроизводится с согласованной ролью» — доказательство. Если изменение закрыло прежний путь, но создало другую уязвимость, это отражается в результате. Если объект удалён или риск принят, укажите решение и согласующего, не называя это техническим исправлением.

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

Проверка перед приёмкой состоит из четырёх вопросов:

• Может ли комплаенс назвать применимую обязанность и действующую редакцию?
• Может ли инженер назвать объект, версию, роль и наблюдаемое поведение?
• Может ли владелец риска назвать ответственного и решение по каждому пробелу?
• Может ли независимый проверяющий пройти от требования через доказательство к исправлению и ретесту?

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

Как это работает на примере финансовой организации

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

Сначала матрица фиксирует деятельность НФО и определяет релевантную классификацию по 757-П. В отдельной строке записывается фактическая роль в платёжной системе и проверяется применимость 821-П. Поскольку общие сервисы поддерживают обе строки, техническая карта показывает, где требования сходятся на идентификации, администрировании, журналировании и восстановлении. Указание 7220-У входит в проверку версии 821-П, так как уже действует; будущие изменения 757-П записываются как плановая задача для работ после 1 января 2027 года.

Далее результаты разделяются. Квалифицированная проверяющая организация выполняет формальную оценку, если она требуется для подтверждённой строки. Услуга тестирования на проникновение проверяет разрешённые пути атаки и защищаемые процессы. Анализ уязвимостей охватывает утверждённый инвентарь, по возможности с аутентифицированным доступом. Внутренний комплаенс ведёт матрицу доказательств и принимает решения о применимости и риске.

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

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

Что согласовать до начала аудита

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

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

Если подтверждённые объём и требования к квалификации совпадают с возможностями исполнителя, роль Pentest.red в этой схеме конкретна: помочь определить разрешённый технический периметр, выполнить согласованные проверки, описать наблюдаемые пути атаки и уязвимости и передать доказательства для аудиторского досье заказчика. Решение о юридической применимости и формальный вывод о соответствии остаются у лиц и организаций, имеющих полномочия и квалификацию для таких решений.