Webhook'и и передача ПДн партнёрам

Webhook — стандартный инструмент интеграции: событие произошло, данные ушли на endpoint партнёра. CTO видит это как HTTP-запрос. Роскомнадзор видит иначе: передача персональных данных третьему лицу без оформленного правового основания. С 30.05.2025 ст. 13.11 КоАП переписана — штрафы за нарушения при передаче ПДн выросли кратно. Эта статья разбирает, какие webhook-сценарии создают правовые риски, что требует ФЗ-152 от оператора при передаче данных партнёрам, и как привести архитектуру интеграций в соответствие.

Почему webhook считается передачей ПДн — и что из этого следует?

Ст. 3 ФЗ-152 определяет передачу ПДн как один из видов обработки. Любое действие с данными, при котором они становятся доступны третьему лицу, — это передача. Webhook доставляет payload на endpoint получателя: если payload содержит имя, email, телефон, идентификатор пользователя или любое сочетание атрибутов, позволяющих идентифицировать физическое лицо, — это передача ПДн по смыслу ФЗ-152.

Исключений для технических протоколов закон не предусматривает. Не имеет значения, что получатель — ваш маркетинговый партнёр, аналитическая платформа, платёжный агрегатор или служба доставки. С точки зрения ст. 6 ФЗ-152 передача данных третьему лицу требует одного из двух: либо согласия субъекта с указанием конкретного получателя, либо оформленного договора поручения обработки ПДн по п. 3 ст. 6.

На практике это означает: каждый URL endpoint, на который уходят данные пользователей, должен быть соотнесён с документом — поручением обработки ПДн или явным согласием субъекта. Если такого документа нет, а данные уходят — нарушение ст. 6 ФЗ-152 уже состоялось. По ч. 1 ст. 13.11 КоАП (обработка ПДн в случаях, не предусмотренных законом) это 150 000–300 000 ₽ за юридическое лицо; при повторности — 300 000–500 000 ₽ по ч. 1.1.

Отдельный вопрос — трансграничная передача. Если endpoint получателя находится за пределами России, применяется ст. 12 ФЗ-152: до начала передачи данных в страну без адекватной защиты оператор обязан уведомить РКН. Большинство зарубежных webhook-получателей (Stripe, HubSpot, Segment, Mixpanel, Braze) расположены в юрисдикциях, которые требуют отдельного уведомления. Неуведомление — штраф по ч. 10 ст. 13.11 КоАП: 100 000–300 000 ₽.

Что должен содержать договор поручения обработки ПДн с webhook-получателем?

П. 3 ст. 6 ФЗ-152 устанавливает минимальные требования к договору поручения. Их несоблюдение означает, что договор не имеет юридической силы как правовое основание передачи — и передача по-прежнему считается незаконной.

Обязательные элементы договора поручения обработки ПДн:

• Перечень персональных данных, передаваемых на обработку (конкретные поля, не «любые ПДн пользователей»).
• Исчерпывающий список действий, которые получатель вправе совершать с данными (например: «хранение, систематизация, извлечение для формирования отчётов»).
• Цели обработки — должны совпадать с целями, указанными в политике оператора и согласии субъекта.
• Обязанность обеспечить конфиденциальность ПДн.
• Обязанность применять меры защиты по ст. 19 ФЗ-152 и, при необходимости, соответствовать требованиям ПП РФ №1119 и Приказа ФСТЭК №21.
• Обязанность уведомить оператора об инциденте не позднее чем за время, позволяющее оператору соблюсти 24-часовой срок по ч. 3.1 ст. 21 ФЗ-152.
• Запрет на передачу данных субподрядчикам без письменного согласия оператора.

Критичный момент для webhook-архитектуры: если получатель — иностранная компания, в договоре должно быть указано, что данные обрабатываются только на серверах, расположенных в России или в стране с адекватной защитой по перечню РКН. Это прямо вытекает из ч. 5 ст. 18 ФЗ-152 о локализации: запись, систематизация, накопление, хранение ПДн граждан РФ допустимы только в базах, находящихся в России.

На практике большинство webhook-интеграций с зарубежными платформами нарушают требование локализации: данные уходят на endpoint, который хранит их в облаке AWS us-east-1 или GCP europe-west. Если такое хранение происходит — это нарушение ч. 8 ст. 13.11 КоАП: штраф 1 000 000–6 000 000 ₽ для юридического лица.

Как webhook-архитектура влияет на уровень защищённости ИСПДн?

ПП РФ №1119 устанавливает четыре уровня защищённости (УЗ-1, УЗ-2, УЗ-3, УЗ-4) в зависимости от категории данных, числа субъектов и типа угроз. Webhook сам по себе не меняет категорию ИСПДн, но влияет на контур защиты: каждый endpoint-получатель расширяет периметр обработки.

Если система обрабатывает специальные категории ПДн (медицинские, биометрические, данные о судимости по ст. 10–11 ФЗ-152) и передаёт их через webhook — это не снижает требуемый уровень защищённости. Получатель по договору поручения обязан соответствовать тому же УЗ, что и оператор. На практике это означает: прежде чем подключить webhook к партнёрской CRM, нужно убедиться, что партнёр аттестован по нужному уровню или применяет меры из Приказа ФСТЭК №21, соответствующие УЗ оператора.

Для SaaS с мультиарендностью (multi-tenant) вопрос усложняется: данные разных клиентов-операторов обрабатываются в общей инфраструктуре. Роль SaaS-провайдера — обработчик по поручению каждого из клиентов. При этом webhook-интеграции, настроенные одним клиентом, не должны получать доступ к данным другого. Логическое разграничение на уровне tenant_id — обязательное, но не достаточное условие: ПП РФ №1119 требует технических мер, а не только программной логики.

Обезличивание для ML: снимает ли оно требования ФЗ-152 при передаче через webhook?

Обезличивание — способ снизить правовые риски при передаче данных для ML-обучения и аналитики. Ст. 13.1 ФЗ-152 (введена ФЗ-233 от 08.08.2024) регулирует обезличенные ПДн отдельно. Приказ РКН определяет пять методов: введение идентификаторов, изменение состава и семантики, декомпозиция, перемешивание, обобщение и агрегация.

Ключевой правовой момент: если данные обезличены надлежащим образом — то есть идентификация субъекта по ним невозможна даже при наличии дополнительной информации у получателя, — они перестают быть ПДн по ст. 3 ФЗ-152. Передача обезличенных данных через webhook не требует правового основания по ст. 6 ФЗ-152 и не подпадает под требование локализации по ч. 5 ст. 18.

Проблема в том, что на практике «обезличивание» часто сводится к удалению имени и email при сохранении user_id, device_id или комбинации атрибутов (геолокация + тип устройства + временная метка), по которым субъект однозначно идентифицируется. Это не обезличивание — это псевдонимизация, которая не снимает требований ФЗ-152. РКН при проверке будет оценивать, можно ли по переданным данным восстановить личность субъекта с учётом данных, которые уже есть у получателя.

Для webhook-передач в ML-пайплайны рекомендуемый подход: применять метод обобщения/агрегации на уровне pipeline перед отправкой payload, логировать применённые методы обезличивания (это подтверждает соответствие Приказу РКН о методах обезличивания при проверке) и документально фиксировать, что обезличенные данные не позволяют идентифицировать субъекта.

Три сценария передачи ПДн через webhook: риски и стратегия

Сценарий 1. Webhook в CRM-систему партнёра по продажам (российская юрисдикция). Оператор передаёт через webhook контакты лидов (имя, телефон, email) в CRM аутсорс-колл-центра. Правовое основание — поручение обработки. Договор поручения не оформлен, передача идёт на основании общего договора оказания услуг. Ситуация: у РКН нет оснований считать колл-центр обработчиком по ст. 6 — он получает данные без установленных законом гарантий. Вероятный исход: при проверке или жалобе субъекта — протокол по ч. 1 ст. 13.11 КоАП (150 000–300 000 ₽). Стратегия: заключить отдельный договор поручения обработки ПДн с перечнем обязательных условий; обновить согласие субъектов с указанием колл-центра как получателя данных.

Сценарий 2. Webhook в зарубежную маркетинговую платформу (Braze, Klaviyo, HubSpot). Данные пользователей (email, имя, история действий) уходят на endpoint платформы, серверы которой в EU/US. Нарушены два требования: ч. 5 ст. 18 (локализация — данные хранятся за рубежом) и ст. 12 (трансграничная передача без уведомления РКН). Вероятный исход: ч. 8 ст. 13.11 — 1–6 млн ₽ за нарушение локализации; ч. 10 — 100 000–300 000 ₽ за неуведомление о трансграничной передаче. Стратегия: проверить, есть ли у платформы дата-центры в России или возможность обработки данных граждан РФ на российских серверах; если нет — перейти на российского аналога или передавать только обезличенные агрегированные данные.

Сценарий 3. Утечка ПДн через скомпрометированный webhook-endpoint. Партнёр (получатель webhook) был атакован; данные пользователей оператора оказались в открытом доступе. С точки зрения ФЗ-152 ответственен оператор: он поручил обработку, но не проверил, соответствует ли партнёр требованиям УЗ и Приказа ФСТЭК №21. Принцип, подтверждённый практикой ВС РФ: оператор отвечает за утечку через подрядчика. Вероятный исход: ч. 12–14 ст. 13.11 в зависимости от числа субъектов — от 3 до 15 млн ₽; при повторности — оборотный штраф по ч. 15 (1–3% выручки, не менее 20 млн ₽). Уведомление РКН об инциденте — в течение 24 часов по ч. 3.1 ст. 21 ФЗ-152; если срок пропущен — дополнительно ч. 11 ст. 13.11 (1–3 млн ₽). Стратегия: включить в договор поручения обязанность партнёра уведомить оператора об инциденте немедленно; регулярно проверять соответствие партнёра требованиям защиты ПДн.

Как применяется ст. 272.1 УК РФ к webhook-инцидентам?

Ст. 272.1 УК РФ введена ФЗ-421 от 30.11.2024, действует с 11.12.2024. Состав: незаконное использование, передача, сбор или хранение компьютерной информации, содержащей ПДн. Максимальная санкция по ч. 5 — лишение свободы до 10 лет при наступлении тяжких последствий.

Применительно к webhook-архитектуре риск уголовной ответственности возникает в двух ситуациях. Первая: разработчик или DevOps-инженер намеренно настраивает webhook на endpoint, не предусмотренный договором, — фактически передаёт данные третьему лицу без санкции оператора. Это незаконная передача компьютерной информации с ПДн. Вторая: CTO или технический руководитель осознанно сохраняет webhook-интеграцию с партнёром после прекращения договора поручения — незаконное хранение и передача.

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

Как применяется это на практике

Кейс 1. IT-компания (Центральный ФО, весна 2026) предоставляла SaaS-платформу для ритейла. В архитектуре были настроены webhook'и на три партнёрские CRM: две российские и одна — европейская. Договоры поручения обработки ПДн с российскими партнёрами содержали неполный перечень действий, уведомление о трансграничной передаче для европейской платформы не подавалось. При плановой проверке РКН выявил оба нарушения. По ч. 1 ст. 13.11 (неправомерная обработка) и ч. 10 (неуведомление о трансграничной передаче) назначены штрафы в сотни тысяч рублей. Компания заблаговременно не проводила аудит интеграций — устранение потребовало трёх месяцев и полной переработки договорной базы с партнёрами.

Кейс 2. Медтех-стартап (Северо-Западный ФО, осень 2025) передавал медицинские данные пациентов через webhook в аналитическую ML-платформу для построения предиктивных моделей. Данные передавались с user_id и диагнозами — псевдонимизация, а не обезличивание. После публичной утечки у платформы-получателя РКН возбудил дело по ч. 12 ст. 13.11 (утечка специальных категорий ПДн более 1 000 субъектов). Оператор не смог доказать, что применял надлежащие методы обезличивания, предусмотренные Приказом РКН. Штраф составил несколько миллионов рублей. CTO компании проходит проверку по ст. 272.1 УК РФ как лицо, принявшее техническое решение о формате передачи данных.

Услуги DATUM по теме

• Аудит соответствия 152-ФЗ — проверка всех точек передачи ПДн, реестр получателей, договоры поручения
• DPIA (оценка воздействия) — оценка рисков при передаче данных через webhook в ML-платформы
• Комплект ОРД под ключ — договоры поручения, регламент передачи ПДн, уведомления РКН о трансграничной передаче

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

1. Какой УЗ выбрать для SaaS-платформы, передающей данные через webhook?

Уровень защищённости определяется по ПП РФ №1119 в зависимости от категорий ПДн (общие, специальные, биометрические), типа угроз (УЗ-1, УЗ-2, УЗ-3, УЗ-4) и числа субъектов. Для большинства B2C SaaS с общими ПДн и числом субъектов более 100 000 — минимальный требуемый уровень УЗ-3. Если SaaS обрабатывает специальные категории или биометрию — УЗ-2 или УЗ-1. Получатели webhook-данных по договору поручения обязаны соответствовать тому же уровню, что и оператор.

2. Можно ли использовать иностранные облака для хранения ПДн граждан РФ?

По ч. 5 ст. 18 ФЗ-152 запись, систематизация, накопление, хранение, уточнение и извлечение ПДн граждан РФ должны производиться в базах данных, расположенных в России. AWS, GCP и Azure (регионы за пределами РФ) не соответствуют этому требованию. Нарушение квалифицируется по ч. 8 ст. 13.11 КоАП — штраф от 1 до 6 млн ₽. Обход через обезличивание возможен: если данные надлежащим образом обезличены до передачи в зарубежное облако, они перестают быть ПДн по ст. 3 ФЗ-152 и требования локализации не применяются.

3. Что такое обезличивание для ML и чем оно отличается от псевдонимизации?

Обезличивание по ст. 3 ФЗ-152 — это действия, в результате которых становится невозможным без использования дополнительной информации определить принадлежность ПДн конкретному субъекту. Приказ РКН определяет пять методов обезличивания. Псевдонимизация — замена идентификаторов (имя → user_id) — не является обезличиванием: при наличии ключа соответствия или косвенных атрибутов субъект идентифицируется. Для ML-пайплайнов обезличивание означает агрегацию, обобщение или добавление дифференциального шума до передачи через webhook — так, чтобы идентификация была невозможна даже при наличии внешних баз данных у получателя.

4. Кто является оператором ПДн в мультиарендной SaaS?

В мультиарендной SaaS оператором ПДн конечных пользователей является клиент (арендатор), а не SaaS-провайдер. Провайдер действует как обработчик по поручению каждого клиента на основании договора, включающего условия по ст. 6 ФЗ-152. При этом провайдер несёт ответственность за соответствие своей инфраструктуры требованиям, которые установлены договором поручения. Webhook-интеграции, настроенные клиентом, с точки зрения ФЗ-152 — это действия оператора (клиента), а не провайдера; но если провайдер технически обеспечивает передачу и не препятствует незаконной интеграции, он может быть привлечён как соучастник незаконной обработки.

5. Какие СЗИ обязательны для системы с webhook-передачей ПДн?

Конкретный состав средств защиты информации определяется уровнем защищённости по ПП РФ №1119 и базовым набором мер по Приказу ФСТЭК №21. Для УЗ-3 (наиболее распространённый для B2C SaaS) обязательны: идентификация и аутентификация (ИАФ), управление доступом (УПД), защита носителей (ЗНИ), регистрация событий/логирование (РСБ), антивирусная защита (АВЗ), анализ защищённости (АНЗ), обеспечение целостности (ОЦЛ). Применительно к webhook: весь трафик должен передаваться по TLS с взаимной аутентификацией; payload должен содержать HMAC-подпись для верификации источника; логи передачи — сохраняться в системе регистрации событий.

Итог

Webhook — это не просто технический протокол, а правовое событие по ст. 6 ФЗ-152. Каждая интеграция с передачей ПДн требует договора поручения обработки, соответствия получателя требованиям защиты и — при трансграничной передаче — уведомления РКН. Нарушение этих требований после 30.05.2025 обходится компании от 150 000 ₽ до оборотного штрафа в 500 млн ₽, а техническому руководителю — потенциально уголовным делом по ст. 272.1 УК РФ.

Практика DATUM по IT-сектору включает аудит webhook-архитектуры, классификацию интеграций по категориям ПДн, формирование реестра получателей и полный комплект ОРД для передачи данных партнёрам. Задача решается до проверки РКН, а не после протокола.