Как страховой компании определить периметр, защищаемую информацию и уровень защиты по 757-П

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

Материал подготовлен с учётом нормативных актов, опубликованных по состоянию на 9 октября 2026 года, включая изменения, вступающие в силу с 1 января 2027 года.

Какой уровень защиты по 757-П нужен страховой компании

757-П предусматривает минимальный, стандартный и усиленный уровни защиты информации. Требуемый уровень определяется по нормативным критериям для соответствующего вида НФО, а не по бюджету службы ИБ или количеству установленных средств защиты.

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

Как оформить определение уровня

Рекомендуем зафиксировать в документе правовой статус организации, применимую редакцию 757-П, дату, нормативное основание и требуемый уровень. Отдельно важно обозначить переход со старых требований на новые. Для компании, ранее реализовавшей минимальный уровень, подготовка к 2027 году включает анализ дополнительных мер и процедур оценки, а не только изменение формулировки в политике ИБ.

Об изменениях требований и общем плане подготовки читайте в статье «757-П для страховых компаний: что должен сделать ответственный за ИБ в 2026–2027 годах».

Что считается защищаемой информацией по 757-П в страховой компании

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

Чтобы определить защищаемую информацию для НФО по 757-П, эти категории необходимо сопоставить с реальными процессами. Для страховщиков важно проверить прежде всего:

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

Это примеры для классификации, а не отдельный нормативный перечень всех данных страховщика. По каждой категории следует документировать связь с пунктом 1.1 и конкретной операцией.

Какие данные страховой защищаются по 757-П, а какие – по другим требованиям

Персональные данные и защищаемая информация по 757-П – пересекающиеся, но не тождественные категории. Реквизиты получателя выплаты могут одновременно относиться к обоим режимам. Кадровая информация не становится объектом 757-П только потому, что принадлежит страховщику, но сохраняет требования к защите персональных данных.

Как определить периметр выполнения 757-П для страховой компании

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

Для каждого процесса ответьте на четыре вопроса:

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

Какие автоматизированные системы страховой попадают под 757-П

Следующая таблица служит практическим ориентиром для обследования. Решение принимается по фактическим функциям системы и архитектуре.

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

Нужно ли включать личный кабинет клиента в периметр 757-П

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

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

Нужно ли включать мобильное приложение страховой в 757-П

Критерий тот же – функциональная связь с операциями и защищаемыми данными. Рассматриваются приложение, серверная часть, интерфейсы обмена, механизм подтверждения действий и хранение информации на устройстве.

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

Технологические участки финансовой операции: пример для страховой

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

Рассмотрим условный пример подачи заявления на выплату:

Основная задача здесь – описать реальный процесс и связать каждый применимый участок с данными и компонентами.

Как провести инвентаризацию систем для 757-П

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

Рекомендуем последовательность:

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

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

Что делать с облаками и подрядчиками

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

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

Как связаны 757-П и ГОСТ Р 57580 для страховой компании

757-П устанавливает обязательные требования и основания выбора уровня. ГОСТ Р 57580.1-2017 описывает состав защиты, а ГОСТ Р 57580.2-2018 – методику оценки соответствия в предусмотренных Положением случаях.

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

Нужна ли модель угроз по 757-П для страховой компании

Работу с угрозами следует выстраивать на основе требований применимых мер ГОСТ и параллельных режимов защиты. Нельзя без уточнений обещать, что любой один документ под названием «модель угроз по 757-П» закроет все обязанности страховщика.

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

Если система обрабатывает персональные данные, отдельно проверяются требования к определению актуальных угроз для этой обработки. Результаты анализа должны соответствовать реальной архитектуре и помогать выбирать защиту.

Что делать, если страховая не понимает свой уровень защиты по 757-П

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

Частые вопросы

Можно ли оставить минимальный уровень при активах менее 20 млрд рублей?

С 1 января 2027 года для страховой организации прежний порог не является основанием оставаться на минимальном уровне. Необходимо учитывать изменения № 7219-У.

Нужно ли включать всю CRM?

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

Достаточно ли перечня серверов?

Нет. Нужны связи между финансовыми процессами, защищаемой информацией, приложениями, инфраструктурой и внешними сервисами.

Можно ли использовать документы по персональным данным?

Можно использовать результаты обследования, схемы и действующие меры, но их нужно сопоставить с требованиями 757-П. Документы по персональным данным не заменяют такое сопоставление.

С чего начать подготовку?

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

Как RTM Group может помочь

Нормативные источники

• Положение Банка России от 20.04.2021 № 757-П
• Указание Банка России от 28.10.2025 № 7219-У (опубликовано 17.02.2026)
• Методические рекомендации Банка России по описанию наименований объектов информационной инфраструктуры