Страховая платформа без конфликтов требований: ПДн, КИИ и контур ЦБ в одном проекте

Клиент обратился с задачей привести деятельность компании в соответствие со 152‑ФЗ и одновременно привести платформу страхования в соответствие требованиям информационной безопасности в части персональных данных.

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

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

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

Во вводных прямо указано: как страховой брокер клиенту нужно было учитывать требования к КИИ и требования, которые предъявляет ЦБ РФ. На практике это означает, что один и тот же объект (платформа и ее инфраструктура) рассматривается под разными углами:

— как контур обработки персональных данных;
— как потенциальный объект/часть объектов КИИ;
— как ИТ‑контур финансовой организации с ожиданиями регулятора по управлению рисками и контролю.

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

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

В таких проектах модель угроз становится точкой сборки: без нее невозможно обосновать, почему выбранные меры достаточны именно в этом контуре. Тем более, когда требования идут и от ФСТЭК, и от ЦБ РФ.

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

Команда шла по логике полного цикла: интервью → модель угроз → техзадание → проектирование → ЛНА → оценка эффективности. Методики были стандартными — интервью и анкетирование.

При этом параллельно был выполнен privacy‑блок, направленный на снятие правовой неопределенности по ролям в трехсторонних отношениях и на формирование документации по 152‑ФЗ.

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

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

Разработали модель угроз. По итогам моделирования было выявлено около 40 угроз, релевантных в контексте требований ФСТЭК и ЦБ РФ. Такой результат помогает уйти от абстрактной безопасности и перейти к управлению приоритетами.

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

Подготовили внутренние ЛНА по ИБ, а также разработали документы по 152‑ФЗ в части организации обработки ПДн и закрепления ролей/оснований взаимодействия. Для страхового брокера это не бюрократия: ЛНА фиксируют правила доступа и обработки, порядок контроля, ответственности и реакции. Именно они помогают удерживать соответствие при изменениях в платформе.

Провели оценку эффективности, чтобы подтвердить применимость и достаточность спроектированных мер в контуре ПДн.

— Проведены интервью и анкетирование.

— Выполнен privacy‑аудит, в рамках которого разложили цепочку взаимодействия клиента со страховыми компаниями и застрахованными лицами.

— Подготовлен отчет, в котором объяснили роли сторон в модели обработки ПДн.

— Разработаны документы по 152‑ФЗ.

— Разработана модель угроз (выявлено около 40 угроз с учетом требований ФСТЭК и ЦБ РФ).

— Подготовлено техническое задание.

— Выполнено проектирование системы защиты.

— Разработаны ЛНА по информационной безопасности.

— Проведена оценка эффективности системы защиты ПДн.

Ключевой смысл проекта — адаптировать контур защиты персональных данных под дополнительные требования (КИИ и контур ЦБ РФ) и одновременно снять правовую неопределенность по ролям в обработке ПДн, чтобы результат был устойчивым и не требовал «переделок» при внешней проверке.

Проект дал клиенту снижение рисков и более управляемую систему безопасности платформы.

Требования разных контуров были учтены в единой логике проектирования.

Появилась документальная и техническая база, на которую можно опираться при развитии платформы: отчет по ролям и цепочкам взаимодействия, документы по 152‑ФЗ, модель угроз, техзадание, ЛНА и подтвержденная эффективность в части ПДн.

Клиент получил практическое понимание своей роли в трехсторонних отношениях со страховыми компаниями и застрахованными лицами — и за счет этого смог пересмотреть распределение ответственности за обработку и объем необходимой документации.

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

Кейс актуален для страховых брокеров и в целом для финансовых организаций, которые развивают цифровые платформы и сталкиваются с «перекрывающимися» требованиями: 152‑ФЗ, КИИ и контур регулятора финансового рынка.

Типовая ошибка — пытаться отдельно закрыть ПДн, а требования КИИ и ЦБ рассматривать как отдельный проект когда‑нибудь потом. В итоге появляются конфликтующие документы и несогласованные меры.

Отдельный вывод по privacy‑части: важно разбираться в ролях при обработке ПДн. В трехсторонних моделях (брокер — страховая — застрахованные лица) корректное определение роли помогает пересмотреть ситуацию с ответственностью за обработку и объемом требуемых документов.