API и webhooks с персональными данными: как законно оформлять передачи между сайтом, CRM, оплатой, доставкой и сервис-деском

Правовой минимум, технические стандарты и практические чек-листы для бизнеса в условиях 152-ФЗ 2025–2026

Почему это важно прямо сейчас

Современный интернет-магазин или сервисная компания редко работает в одиночку. За каждым кликом «оформить заказ» разворачивается тихий марафон: данные клиента уходят в CRM, оттуда — в платёжный шлюз, затем — в логистического провайдера, а после — в систему поддержки. Весь этот конвейер работает через API и webhooks.

При этом большинство компаний не отдают себе отчёта в том, что каждая такая передача персональных данных — это юридически значимое действие, требующее документального оформления. Масштаб проблемы впечатляет: по данным InfoWatch, в 2024 году в России было зарегистрировано 592 случая утечки ПДн, а общий объём скомпрометированных записей вырос на 30% по сравнению с 2023 годом [56]. Лидер по числу инцидентов — именно торговля, которая активнее всего использует интеграции через API.

Одновременно с этим законодательство резко ужесточилось: с 30 мая 2025 года действуют новые штрафы, с 1 сентября 2025 года введены обновлённые требования к форме согласий, с 1 июля 2025 года полностью запрещено хранение ПДн российских граждан за рубежом [8]. Цена ошибки выросла с нескольких десятков тысяч рублей до десятков миллионов.

Эта статья — практический гид для разработчиков, технических директоров, compliance-офицеров и руководителей бизнеса, которые хотят понять: как устроены API-интеграции с ПДн, что говорит о них российский закон, как защитить данные технически и какие документы нужны, чтобы пройти проверку Роскомнадзора.

Часть 1. Что происходит с данными при каждой интеграции

1.1. Анатомия типичного потока ПДн

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

1. Сайт → CRM (передача через API при создании сделки/лида).
2. CRM → платёжная система (запрос на выставление счёта или обработку транзакции).
3. Платёжная система → CRM (webhook с уведомлением об успешной оплате).
4. CRM → служба доставки (API-запрос на создание заказа с адресом получателя).
5. Служба доставки → сайт/CRM (webhook со статусом доставки).
6. Сайт/CRM → сервис-деск (передача данных при создании обращения клиента).

В каждой из этих точек происходит «передача персональных данных» по смыслу 152-ФЗ [15]. И в каждой точке нужно знать ответ на вопрос: на каком правовом основании это происходит и правильно ли оформлены отношения с получателем данных?

1.2. Ключевое различие: поручение обработки vs передача ПДн

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

Поручение обработки (ч. 3 ст. 6 152-ФЗ) — это аутсорсинг технической функции. Оператор (ваша компания) поручает другому лицу (например, облачной CRM или сервису рассылок) выполнять определённые операции с ПДн в рамках ваших целей. При этом:

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

Передача ПДн третьему лицу — это когда получатель сам становится самостоятельным оператором и обрабатывает данные по своим целям. Например: вы передаёте данные клиента в страховую компанию для оформления ДМС. В этом случае:

• каждая сторона несёт ответственность самостоятельно [17];
• каждая сторона обязана получать своё согласие субъекта на обработку;
• с 1 сентября 2025 года — согласие на передачу конкретному получателю оформляется отдельным документом с указанием имени получателя и целей [16].

Применительно к типичным интеграциям:

• CRM как SaaS-сервис, куда «складируются» клиентские данные = скорее всего, поручение обработки.
• Платёжная система (если она сама определяет порядок хранения и обработки данных плательщика) = самостоятельный оператор, отдельное согласие [3].
• Служба доставки (получает адрес и ФИО для исполнения конкретного договора) = может быть как поручением, так и передачей в рамках исполнения договора.
• Сервис-деск: получает данные клиента для обработки его обращений = нужно смотреть, кто определяет цели обработки.

Часть 2. Правовые основания: что нужно оформить

2.1. Законные основания для передачи ПДн через API

Согласно ст. 6 152-ФЗ, обработка (включая передачу) персональных данных допустима при наличии хотя бы одного из оснований [15]. В контексте API-интеграций применяются следующие:

1. Согласие субъекта персональных данных. Самый очевидный, но теперь — самый требовательный вариант. С 1 сентября 2025 года согласие должно быть оформлено строго отдельным документом, а не включено в оферту или пользовательское соглашение [12]. Согласие должно содержать: ФИО и адрес лица, осуществляющего обработку по поручению; перечень действий с ПДн; срок действия и способ отзыва [18].
2. Исполнение договора. Если передача ПДн в платёжную систему, службу доставки или колл-центр необходима непосредственно для исполнения договора, заключённого с субъектом ПДн, — это самостоятельное правовое основание. Важно: цели передачи должны соответствовать заявленным при сборе данных [3].
3. Требования законодательства. Например, обязательная передача данных в ФНС через онлайн-кассу по 54-ФЗ.
4. Законные интересы оператора. Этот базис применяется ограниченно и требует доказательства того, что интересы оператора не противоречат правам субъекта.

2.2. Договор поручения обработки: что должен содержать

Согласно ч. 3 ст. 6 152-ФЗ, в договоре поручения обязательно должны быть указаны [21]:

1. Перечень персональных данных, которые передаются обработчику.
2. Перечень действий (операций) с ПДн, которые обработчик вправе совершать.
3. Цели обработки.
4. Обязанность соблюдать конфиденциальность.
5. Требования к защите ПДн (согласно ст. 19 152-ФЗ).
6. Обязанность предоставлять документы по запросу оператора.
7. Запрет на передачу ПДн третьим лицам без согласования с оператором.

На практике договор поручения заключается с каждым SaaS-сервисом, который получает доступ к ПДн ваших клиентов или сотрудников: облачной CRM, сервисом email-рассылок, платформой сервис-деска и т.д. [38]. Многие российские вендоры уже включают соответствующие положения в свои стандартные договоры — но это нужно проверять, а не принимать на веру.

2.3. Согласие с указанием получателей: новые требования 2025

Одно из ключевых изменений 2025 года — требование получать отдельное согласие на передачу персональных данных каждому конкретному третьему лицу с явным указанием получателя и целей передачи [16].

На практике это означает следующее:

1. Политика конфиденциальности на сайте должна содержать актуальный список всех третьих сторон, которым передаются данные: CRM-система, платёжный шлюз, служба доставки, сервис-деск, сервис рассылок и т.д. [3].
2. Форма согласия должна ссылаться на этот список или прямо его перечислять.
3. Если вы добавляете новую интеграцию (новый API-коннектор), — старое согласие пользователя уже не покрывает новую передачу. Нужно либо обновить согласие, либо обосновать её иным правовым основанием.
4. Привычная практика «вшивания» согласия в оферту больше не работает [12].

2.4. Локализация данных: ограничения для зарубежных сервисов

С 1 июля 2025 года вступила в силу обновлённая ч. 5 ст. 18 152-ФЗ: запись, систематизация, накопление, хранение, уточнение и извлечение ПДн граждан РФ с использованием баз данных, находящихся за пределами России, полностью запрещены [8].

Что это означает для API-интеграций:

1. Использование зарубежных облачных CRM (Salesforce, HubSpot, Pipedrive) для хранения данных российских клиентов — теоретически нарушение, если данные первично попадают и хранятся на серверах за рубежом.
2. Если зарубежный сервис нужен — необходимо обеспечить, чтобы первичная запись и хранение происходили на российских серверах, а уже потом данные передавались за рубеж при наличии правомерных оснований для трансграничной передачи [5].
3. Передача данных в иностранные системы через API возможна только как вторичная операция: сначала запись в российскую БД, затем — синхронизация с зарубежным сервисом.

Часть 3. Техническая безопасность API и webhooks с ПДн

3.1. Почему webhooks — зона повышенного риска

В отличие от классического API-запроса, который инициирует клиент, webhook — это «обратный вызов»: внешний сервис сам отправляет данные на ваш endpoint. Ключевые риски:

• Ваш endpoint публично доступен в интернете, и любой может отправить на него запрос [27].
• Невозможно заранее знать, является ли входящий запрос легитимным, без специальных мер аутентификации.
• Payload webhook часто содержит ПДн: данные о заказе, информацию о плательщике, статус доставки с адресом клиента.
• Атака replay: злоумышленник перехватывает легитимный, зашифрованный запрос и отправляет его повторно в нужный момент [27].

3.2. HTTPS/TLS: обязательный минимум

Требование использовать HTTPS применяется как к исходящим API-запросам, так и к входящим webhook-эндпоинтам [22]. Согласно российскому законодательству, отсутствие HTTPS при работе с ПДн является основанием для штрафа по ст. 13.11 КоАП РФ [3].

Практические требования:

1. Только HTTPS, никакого HTTP для любых запросов, содержащих ПДн.
2. Действующий сертификат от признанного удостоверяющего центра (не самоподписанный).
3. Используйте только современные версии TLS (1.2 и выше), отключите устаревшие версии и уязвимые шифры.
4. Принимайте webhook-запросы только по HTTPS — большинство провайдеров (например, Twilio) отказываются соединяться с endpoint'ами без валидного сертификата [28].

Взаимный TLS (mTLS) — дополнительный уровень защиты для высокочувствительных интеграций: он требует, чтобы обе стороны (отправитель и получатель) предъявляли TLS-сертификат при соединении. Это исключает возможность отправки данных на поддельный endpoint [23].

3.3. HMAC-подписи: как убедиться в подлинности запроса

HMAC (Hash-based Message Authentication Code) — стандарт подписи webhook-запросов. Принцип работы [23]:

1. Обе стороны (провайдер сервиса и ваш сервис) заранее договариваются о секретном ключе.
2. При отправке запроса провайдер вычисляет HMAC-подпись payload'а с использованием секретного ключа (чаще всего SHA-256) и помещает её в заголовок запроса (например, X-Signature).
3. Ваш сервис при получении самостоятельно вычисляет HMAC от полученного payload'а и сравнивает с подписью из заголовка.
4. Если подписи совпадают — запрос подлинный и не был изменён в пути.

Требования к безопасному хранению ключей [25]:

1. Никогда не хранить секретные ключи в исходном коде или конфигурационных файлах в репозитории.
2. Использовать системы управления секретами: HashiCorp Vault, AWS KMS, Yandex Lockbox или аналоги.
3. Ротировать ключи регулярно (минимум раз в квартал) и немедленно при подозрении на компрометацию.
4. При смене ключа поддерживать оба ключа (старый и новый) активными в течение переходного периода.

3.4. Защита от replay-атак: метки времени и idempotency

Даже правильно подписанный webhook можно перехватить и отправить повторно в нужный момент. Защита — метки времени [24]:

1. Провайдер включает Unix-timestamp в тело запроса или заголовок.
2. Ваш сервис при получении проверяет: не превышает ли разница между текущим временем и временем запроса допустимый порог (обычно 5–10 минут).
3. Запросы с истекшим timestamp'ом отклоняются.

Дополнительно используется idempotency-ключ: уникальный идентификатор каждого события, который позволяет обнаружить и проигнорировать дублирующийся запрос.

3.5. Принцип минимизации данных в API-запросах

Согласно принципу минимизации ПДн (ст. 5 152-ФЗ), через API нужно передавать только те данные, которые действительно необходимы для конкретной операции [42]:

1. Платёжная система для проведения транзакции не нуждается в полном адресе доставки и истории покупок.
2. Сервис рассылки для отправки письма не нуждается в номере паспорта или дате рождения.
3. Службе доставки не нужна история всех заказов клиента — только данные конкретной отправки.
4. Сервис-деску для обработки заявки нужны контактные данные и описание проблемы, но не платёжные реквизиты.

Практическое правило: перед каждой интеграцией составьте явный список полей, которые реально нужны получателю, и настройте API так, чтобы передавались только они. Это называется privacy-by-design в архитектуре API [43].

3.6. Логирование: что можно, а что нельзя писать в логи

Логи API-запросов — обязательный инструмент для отладки и аудита безопасности. Но они же являются источником утечек ПДн. Правила [22]:

1. Запрещено логировать ПДн в открытом виде: ФИО, телефоны, email, адреса, реквизиты карт.
2. Допускается логировать хэши или маскированные версии идентификаторов (например, первые 4 символа email).
3. В логах фиксируются: timestamp, метод HTTP, URL (без параметров с ПДн), HTTP-статус, IP источника, идентификатор запроса.
4. Для целей аудита безопасности можно фиксировать хэш SHA-256 от тела запроса — это позволяет отследить целостность данных без их раскрытия [24].
5. Логи, содержащие любые персональные данные, являются информационными системами ПДн и требуют соответствующей защиты.

Часть 4. Специфика конкретных интеграций

4.1. Сайт → CRM

CRM — как правило, первый и главный получатель ПДн. С точки зрения 152-ФЗ отношения с CRM-провайдером — это поручение обработки [38].

Что нужно сделать:

1. Заключить договор поручения обработки ПДн с вендором CRM или убедиться, что соответствующие положения включены в лицензионное соглашение.
2. Убедиться, что сервер CRM находится в России, если используете российские персональные данные (с 1 июля 2025 года) [5].
3. Настроить передачу через HTTPS-API с аутентификацией (OAuth 2.0, Bearer-token или JWT).
4. Передавать только необходимые поля: не стоит отправлять в CRM всё подряд из формы заявки.
5. В политике конфиденциальности сайта указать CRM-систему как получателя данных.

Российские CRM (Битрикс24, amoCRM, RetailCRM) хранят данные на российских серверах и, как правило, готовы подписать договор поручения. У зарубежных решений ситуация сложнее — с 1 июля 2025 года их использование в качестве основного хранилища ПДн граждан РФ фактически невозможно без буферного российского сервера [71].

4.2. Сайт/CRM → платёжная система

Платёжная система — наиболее регулируемый участник цепочки. К ней применяются помимо 152-ФЗ также требования PCI DSS (стандарт безопасности данных платёжных карт) и нормы Банка России.

Ключевые особенности:

1. Платёжная система является самостоятельным оператором ПДн в части платёжных данных; вы не «поручаете» ей обработку — вы передаёте данные [3].
2. В согласии пользователя должна быть прямо упомянута платёжная система как получатель данных.
3. Для снижения рисков рекомендуется использовать токенизацию: вы не передаёте реальные данные карты через свой сервер, а перенаправляете пользователя на защищённую форму провайдера или получаете токен, заменяющий реквизиты карты.
4. Webhook от платёжной системы о статусе оплаты должен обрабатываться с проверкой HMAC-подписи или аналогичного механизма [26].
5. Никогда не логировать данные карты, CVV, номера счетов — даже в зашифрованном виде.

4.3. CRM/сайт → служба доставки

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

Практические требования:

1. В договоре с логистическим провайдером должен быть раздел о конфиденциальности и обработке ПДн согласно 152-ФЗ.
2. Если логистический провайдер использует данные получателей для своих рассылок или аналитики — нужно либо запретить это в договоре, либо получить согласие клиента.
3. Webhook о статусе доставки (трек-номер, статус посылки) может содержать ПДн — проверяйте подлинность запроса через подпись.
4. Настройте срок хранения данных о заказах в соответствии с заявленными целями: данные для доставки не нужно хранить вечно.

4.4. Сайт/CRM → сервис-деск

Система обработки обращений (Help Desk / Service Desk) получает, как правило, контактные данные клиента, описание проблемы, историю покупок для контекста. Это — поручение обработки данных в пользу оператора.

Особенности:

1. В тикете сервис-деска не должны находиться платёжные данные, реквизиты карт или чувствительные персональные данные — это прямое нарушение принципа минимизации.
2. Если агент поддержки работает в отдельной системе (не в CRM), интеграция между ними должна быть задокументирована как отдельный канал передачи ПДн.
3. Многие сервис-деск платформы (Jira Service Management, Freshdesk и их российские аналоги) хранят данные на зарубежных серверах — проверьте соответствие требованию о локализации [66].
4. API-ключи сервис-деска должны иметь минимально необходимые права: агент поддержки не должен получать доступ к платёжным реквизитам клиента через API.

Часть 5. Практический чек-лист: что проверить прямо сейчас

5.1. Юридический чек-лист

1. Составлен актуальный реестр всех API-интеграций с указанием: какие ПДн передаются, кому, на каком правовом основании.
2. С каждым получателем ПДн (CRM, платёжная система, доставка, сервис-деск, сервис рассылок) заключён договор поручения обработки или зафиксированы иные правовые основания.
3. Согласие пользователя оформлено отдельным документом (с 1 сентября 2025 года) [12].
4. В согласии или политике конфиденциальности перечислены все третьи лица, которым передаются данные [10].
5. При добавлении новой интеграции — обновляется политика и при необходимости запрашивается новое согласие.
6. Компания зарегистрирована в реестре операторов ПДн Роскомнадзора (обязательно с 30 мая 2025 года для всех) [4].
7. Первичные базы данных с ПДн граждан РФ размещены на российских серверах [8].
8. При трансграничной передаче данных соблюдены требования 152-ФЗ: есть разрешение РКН или иное основание.

5.2. Технический чек-лист

1. Все API-интеграции работают исключительно через HTTPS с действующим сертификатом.
2. Используется TLS версии 1.2 или выше; устаревшие версии отключены.
3. Для аутентификации API используются Bearer-токены, OAuth 2.0 или JWT — не Basic Auth.
4. Каждому внешнему сервису выдан отдельный API-ключ с минимально необходимыми правами.
5. Для входящих webhooks реализована проверка HMAC-подписи или аналогичного механизма.
6. Для webhooks реализована защита от replay-атак (проверка timestamp в пределах ±5 минут).
7. API-ключи и секреты хранятся в защищённых хранилищах (не в коде и не в репозитории).
8. API-ключи ротируются минимум ежеквартально.
9. В логах API отсутствуют ПДн в открытом виде.
10. Реализована rate-limiting (ограничение числа запросов) на webhook-эндпоинтах.
11. Перечень полей ПДн, передаваемых каждому сервису, сведён к минимуму.
12. Настроен аудит-лог событий изменения ПДн через API (кто, что, когда изменил).

5.3. Организационный чек-лист

1. Назначен ответственный за безопасность персональных данных [64].
2. Разработана процедура уведомления Роскомнадзора об утечке ПДн в течение 24 часов.
3. Проводится регулярный аудит всех активных API-интеграций (не реже раза в квартал).
4. При смене подрядчика (нового интегратора, нового вендора) — автоматически запускается проверка соответствия требованиям 152-ФЗ.
5. Сотрудники, работающие с API-интеграциями, прошли инструктаж по обработке ПДн.

Часть 6. Типичные ошибки и как их избежать

6.1. «Нам не нужен договор — они надёжные ребята»

Самая распространённая ошибка: компания давно работает с поставщиком и не считает нужным формализовать отношения по ПДн. По 152-ФЗ добросовестность контрагента не является правовым основанием для передачи данных. При проверке Роскомнадзора отсутствие договора поручения с каждым обработчиком ПДн является нарушением независимо от репутации получателя [38].

6.2. Один API-ключ на все сервисы

Использование единого API-ключа для всех интеграций — грубое нарушение принципа минимальных привилегий. Если один из сервисов будет скомпрометирован, злоумышленник получит доступ ко всей системе. Каждому внешнему сервису — отдельный ключ с ограниченными правами [32].

6.3. Webhook без проверки подписи

Многие разработчики принимают webhook-запросы без проверки подлинности, рассчитывая на «security through obscurity» (скрытость URL). Это не защита: URL endpoint'а может быть обнаружен, и злоумышленник может отправить поддельный запрос, инициировав ложные действия в системе (например, изменение статуса заказа) [26].

6.4. ПДн в URL-параметрах

Передача ПДн в URL — email, имя, телефон, ID пользователя — критическая ошибка. URL фиксируется в: server-логах, браузерной истории, Referer-заголовках запросов к сторонним ресурсам, CDN и proxy-серверах. Данные нужно передавать в теле запроса (POST-body) или заголовках, но не в URL [42].

6.5. Не обновляется политика конфиденциальности при добавлении интеграций

Разработчики добавляют новый сервис (например, подключают новую службу доставки), данные начинают туда уходить, а политика конфиденциальности об этом не знает. Это нарушение принципа прозрачности 152-ФЗ и прямое основание для санкций Роскомнадзора [10].

6.6. Хранение секретных ключей в репозитории

Встречается регулярно: разработчик коммитит .env-файл с API-ключами или хардкодит токены прямо в исходном коде. Компрометация репозитория = компрометация всех интеграций. Решение: использовать .gitignore, менеджеры секретов и автоматические проверки на предмет случайного попадания ключей в репозиторий [25].

6.7. Избыточные данные в запросах

Разработчики нередко передают через API «всё поле целиком», не задумываясь о минимизации. CRM при создании сделки отправляет в платёжную систему полный профиль клиента вместо минимально необходимых данных. Это нарушает принцип минимизации ПДн и создаёт лишние точки риска [43].

Часть 7. Кейсы и типичные сценарии

Кейс 1: Интернет-магазин с автоматическим конвейером заказа

Описанная выше схема «сайт → CRM → платёжная система → доставка → сервис-деск» является стандартной и реализуется через webhook-события [32]. При правильной настройке:

• Платёжная система отправляет webhook об успешной оплате → CRM меняет статус сделки → CRM создаёт заявку в службе доставки.
• Служба доставки отправляет webhook с трек-номером → CRM обновляет статус → клиент получает уведомление.

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

Кейс 2: Компания использует зарубежную CRM

С 1 июля 2025 года первичное хранение ПДн граждан РФ в зарубежных базах запрещено [8]. Выход для компаний, не готовых к полной миграции:

1. Настроить «буферную» российскую базу данных (on-premise или российское облако).
2. Данные из формы сайта первично попадают в российскую БД.
3. Из российской БД через API синхронизируются с зарубежной CRM — только для оперативной работы менеджеров.
4. Трансграничная передача при этом оформляется по правилам ст. 12 152-ФЗ.

Кейс 3: Подрядчик или интегратор, работающий с вашими ПДн

Если вы привлекаете внешнего разработчика для настройки API-интеграций, а он в процессе работы получает доступ к реальным ПДн клиентов — это тоже передача ПДн обработчику. Нужен договор поручения [20]. Распространённая ошибка: разработчику дают доступ к production-базе с реальными данными «на время настройки» без какого-либо юридического оформления.

Часть 8. Будущее: тренды в регулировании и технологиях

8.1. Тренд на автоматизацию контроля

Роскомнадзор уже использует автоматизированные системы мониторинга: в 2025 году около 84% выявленных нарушений были обнаружены в ходе автоматического мониторинга [7]. Это означает, что рассчитывать на «не заметят» больше не приходится. Нарушения в политиках конфиденциальности, неправильные формы согласия, отсутствие уведомлений — всё это выявляется роботизированно, 24/7.

8.2. Оборотные штрафы: новая логика ответственности

Введение оборотных штрафов (до 3% от годовой выручки, минимум 25 млн рублей) кардинально меняет логику принятия решений в сфере ПДн [53]. Если раньше штраф в 50–100 тысяч рублей можно было «заложить в бизнес-план», то теперь для крупного ритейлера или сервисной компании одна утечка данных может обойтись в сотни миллионов рублей.

8.3. Privacy-by-design как стандарт разработки

Концепция «privacy by design» — включение требований конфиденциальности на этапе проектирования системы, а не как дополнение — постепенно становится индустриальным стандартом. Это касается и API-архитектуры: какие поля передавать, нужна ли токенизация, как настроить доступ [43].

8.4. Open API и регулируемый обмен данными

В России активно развивается концепция Open Banking (открытые API для банков) под надзором Банка России. Разрабатываемая Платформа коммерческих согласий (ПКС) на базе Госуслуг призвана стать централизованным инструментом управления разрешениями на передачу данных [33]. В будущем это может изменить механику работы consent-flow в любых API-интеграциях.

8.5. Уголовная ответственность за нарушения

Принятый в конце 2024 года Федеральный закон №421-ФЗ, вступивший в силу 11 декабря 2024 года, вводит уголовную ответственность за незаконный оборот ПДн [8]. Это качественное изменение ландшафта: теперь речь идёт не только о корпоративных штрафах, но и о личной ответственности должностных лиц.

Заключение: что делать прямо сейчас

Интеграция через API и webhooks — это не только технический вопрос. В 2025–2026 годах в России это одновременно юридический, организационный и процессный вопрос.

Минимальный план действий для любой компании, работающей с API-интеграциями:

1. Составьте карту потоков ПДн: какие данные, куда и через какие каналы уходят прямо сейчас. Без этого невозможно понять масштаб задачи.
2. Аудит договоров: есть ли договор поручения с каждым сервисом, получающим ПДн?
3. Обновите согласия и политику конфиденциальности в соответствии с требованиями 2025 года: отдельный документ, список получателей.
4. Технический аудит: HTTPS везде, HMAC для webhooks, секреты в хранилищах, минимизация передаваемых полей.
5. Проверьте локализацию: все первичные базы данных с ПДн граждан РФ находятся на российских серверах?
6. Зарегистрируйтесь в реестре операторов ПДн Роскомнадзора, если ещё не сделали этого.
7. Настройте процедуру уведомления об утечках в 24-часовой срок.

Платформа «Пятый фактор»: непрерывный контроль ПДн в корпоративной инфраструктуре

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

Именно эту проблему решает Пятый фактор — on-premise платформа для автоматического обнаружения, инвентаризации и контроля персональных данных в корпоративных системах. Она работает с метаданными, структурой данных и агрегатами — без передачи и хранения «сырых» ПДн, что само по себе исключает создание нового источника риска.

Ключевые возможности применительно к теме API-интеграций:

• Автоматическое обнаружение новых полей с ПДн в БД, CRM, хранилищах и API — вы видите изменения сразу, не дожидаясь утечки.
• Живая «карта ПДн»: где какие данные есть, кто их владелец, какие изменения произошли.
• Сокращение времени аудита с недель до часов — за счёт непрерывной автоматической инвентаризации.
• Готовность к проверкам Роскомнадзора: актуальная картина вместо разрозненных ручных описей.

Когда у вас появляется новая API-интеграция — новый поставщик, новая CRM, новый логистический сервис — «Пятый фактор» поможет сразу увидеть, какие ПДн начали туда поступать, и не упустить момент для юридического оформления.

Источники

[1] Федеральный закон от 27.07.2006 N 152-ФЗ «О персональных данных» — https://base.garant.ru/12148567/

[2] Изменения в 152-ФЗ 2025 года — Альфа-Курс — https://kurs.alfabank.ru/articles/personalnye-dannye-izmeneniya/

[3] Гайд по 152-ФЗ с изменениями 2025 года — 1ps.ru — https://1ps.ru/blog/dirs/2025/kak-ne-popast-na-millionyi-razbiraem-novyie-trebovaniya-po-obrabotke-personalnyix-dannyix/

[4] Как работать с персональными данными в 2025 — AltCraft — https://altcraft.com/ru/blog/shtraf-za-narushenie-zakona-o-personalnyh-dannyh

[5] Закон о персональных данных: что изменилось в 2025 году — b-152.ru — https://b-152.ru/zakon-o-personalnyh-dannyh-2025

[6] 152-ФЗ, последняя редакция — ГАРАНТ — https://base.garant.ru/12148567/

[7] 152-ФЗ для бизнеса в 2026 году — Клерк — https://www.klerk.ru/blogs/roskom24/674017/

[8] 152-ФЗ в 2025–2026 годах — Business.ru — https://www.business.ru/article/5705-152-fz-o-personalnyh-dannyh-gg

[9] Изменения закона о ПДн в 2025 году — Qugo — https://qugo.ru/blog/izmeneniya-zakona-o-personalnyh-dannyh-v-2025-godu

[10] Изменения 152-ФЗ с 1 сентября 2025: чек-лист — Robokassa — https://robokassa.com/blog/articles/izmeneniya-v-152-fz-s-1-sentyabrya/

[11] 152-ФЗ, редакция от 24.06.2025 — Контур.Норматив — https://normativ.kontur.ru/document?moduleId=1&documentId=501173

[12] Особенности договора поручения и передачи ПДн — Астрал — https://astral.ru/aj/elem/osobennosti-dogovora-porucheniya-i-dogovora-peredachi-dannykh-tretim-litsam/

[13] Сравнение соглашений о поручении и передаче ПДн — RPPA — https://rppa.pro/analitika/sravnenie_poruchenija_i_peredachi_pdn

[14] Персональные данные в 2025 году — Nubes — https://nubes.ru/blog/articles/personal-data-2025

[15] Ст. 6 152-ФЗ — КонсультантПлюс — https://www.consultant.ru/document/cons_doc_LAW_61801/315f051396c88f1e4f827ba3f2ae313d999a1873/

[16] Новые правила обработки ПДн 2025 — EmpDocs — https://empldocs.ru/novye-pravila-obrabotki-pdn-2025

[17] Отличие соглашения о поручении от передачи ПДн — Cortel — https://blog.cortel.cloud/2023/08/03/otlichie-soglasheniya-o-poruchenii-na-obrabotku-personalnyh-dannyh-ot-peredachi-pdn/

[18] Ст. 9 152-ФЗ (согласие субъекта) — КонсультантПлюс — https://www.consultant.ru/document/cons_doc_LAW_61801/6c94959bc017ac80140621762d2ac59f6006b08c/

[19] Примерная форма договора поручения (октябрь 2025) — ГАРАНТ — https://base.garant.ru/1970611/

[20] Документы по ПДн в 2026 году — Legal-box — https://legal-box.ru/152fz-docs

[21] Согласие на передачу ПДн третьей стороне — КонсультантПлюс — https://www.consultant.ru/law/podborki/soglasie_na_peredachu_personalnyh_dannyh_tretej_storone/

[22] Webhook Security Best Practices — Invicti — https://www.invicti.com/blog/web-security/webhook-security-best-practices

[23] Webhooks security best practices — Stytch — https://stytch.com/blog/webhooks-security-best-practices/

[24] Adaptive Webhook Security Best Practices — PentestTesting — https://www.pentesttesting.com/adaptive-webhook-security-best-practices/

[25] Webhook Security — Kusari — https://www.kusari.dev/learning-center/webhook-security

[26] Webhook Security — WebhookRelay — https://webhookrelay.com/blog/webhook-security/

[27] Webhook Security Best Practices — Snyk — https://snyk.io/blog/creating-secure-webhooks/

[28] Webhooks Security — Twilio — https://www.twilio.com/docs/usage/webhooks/webhooks-security

[29] How to Secure Webhooks — Hookdeck — https://hookdeck.com/webhooks/guides/webhooks-security-checklist

[30] Webhook Security Fundamentals — Hooklistener — https://www.hooklistener.com/learn/webhook-security-fundamentals

[31] Securing Webhooks — Zoho Zeptomail — https://www.zoho.com/zeptomail/articles/securing-webhooks.html

[32] Интеграция CRM через API — KT-Team — https://www.kt-team.ru/blog/api-integration-crm-automation

[33] Open API 2026: возможности интеграции — Локо-Банк — https://www.lockobank.ru/articles/RKO/api-banking-2026-sravnenie-vozmozhnostej-integratsii-v-krupnejshih-bankah/

[34] Российские CRM-системы 2025 — InFullBroker — https://www.infullbroker.ru/articles/rossiyskiye-crm-sistemy/

[35] API-интеграция автоматизирует бизнес — KT-Team — https://www.kt-team.ru/blog/crm-1c-marketplace-api-integration-profit-boost

[36] Интеграции с CRM — Битрикс24 — https://www.bitrix24.ru/journal/integratsii-s-crm-zachem-oni-nuzhny-i-kakie-byvayut/

[37] Интеграция сервисов CRM через API — Альбато — https://albato.ru/apps-crm

[38] Персональные данные и CRM: кто ответит за безопасность — Profit-lab — https://profit-lab.ru/article/personalnye-dannye-i-crm-kto-otvetit-za-bezopasnost/

[39] Персональные данные 2025: новые правила — Passwork — https://passwork.ru/blog/piersonalnyie-dannyie-2025/

[40] CRM рынок России 2025 — KT-Team — https://www.kt-team.ru/blog/crm-market-russia-2025-bitrix24-adoption-trends-digitalization

[41] Персональные данные и CRM в 2025 году — Sigma Messaging — https://sigmasms.ru/blog/personalnye-dannye-i-crm-v-2025-godu-kak-rabotat-po-zakonu-i-bez-syurprizov/

[42] GDPR API Security — ComplyDog — https://complydog.com/blog/gdpr-api-security-data-protection-developers

[43] API Data Protection: Developer's GDPR Guide — ComplyDog — https://complydog.com/blog/api-data-protection-developers-gdpr-implementation-guide

[44] First-Party Data Compliance 2025 — SecurePrivacy — https://secureprivacy.ai/blog/first-party-data-collection-compliance-gdpr-ccpa-2025

[45] GDPR Compliance for API Integration — ApyHub — https://apyhub.com/blog/gdpr-compliance-api-integration

[46] GDPR in 2025: Key Changes — ComplyDog — https://complydog.com/blog/gdpr-in-2025

[47] GDPR Compliance for API Developers — CookieLawInfo — https://www.cookielawinfo.com/gdpr-compliance-api/

[48] API Compliance & Security — Salt Security — https://salt.security/blog/beyond-checkboxes-the-essential-need-for-robust-api-compliance

[49] APIs and data protection — activeMind.legal — https://www.activemind.legal/guides/api-data-protection/

[50] GDPR Compliance Guide 2026 — SecurePrivacy — https://secureprivacy.ai/blog/gdpr-compliance-2026

[51] Роскомнадзор: 24 млн записей утекло с начала 2025 года — IaaSSaaS — https://iaassaaspaas.ru/news/okolo-milliarda-strok-personalnyh-dannykh-uteklo-v-set-za-polgoda-nikakie-shtrafy-ne-pomogayut

[52] Роскомнадзор зафиксировал 103 утечки за январь–май 2025 — DP.ru — https://www.dp.ru/a/2025/10/31/roskomnadzor-zafiksiroval

[53] Утечки данных в России — TAdviser — https://www.tadviser.ru/index.php/%D0%A1%D1%82%D0%B0%D1%82%D1%8C%D1%8F:%D0%A3%D1%82%D0%B5%D1%87%D0%BA%D0%B8_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85_%D0%B2_%D0%A0%D0%BE%D1%81%D1%81%D0%B8%D0%B8

[54] РКН выявил 35 фактов утечек в первом полугодии 2025 — Хабр — https://habr.com/ru/news/924602/

[55] Утечки ПДн в России выросли на 30% в 2024 году — InfoWatch — https://www.infowatch.ru/company/presscenter/news/kolichestvo-slitykh-personalnyh-dannykh-v-dve-tysyachi-dvadtsat-chetvertom-godu-vyroslo-na-tret

[56] Аналитический отчёт ГК InfoWatch за первое полугодие 2024 — InfoWatch — https://www.infowatch.ru/company/presscenter/news/v-rossii-v-pervom-polugodii-uteklo-pochti-odin-milliard-personalnyh-dannykh

[57] Роскомнадзор раскрыл число утечек за 2024 год — CNews — https://gov.cnews.ru/news/top/2025-02-07_roskomnadzor_zafiksiroval

[58] Роскомнадзор сообщил о 30 случаях утечек в 2025 году — Ведомости — https://www.vedomosti.ru/society/news/2025/05/07/1109003-roskomnadzor-utechek-dannih

[59] Утечки ПДн в России: статистика 2024 — CISOCLUB — https://cisoclub.ru/roskomnadzor-soobshhil-o-kolichestve-utechek-dannyh-v-2024-godu/

[60] В 2024 году утекли более 710 млн записей о россиянах — CNews — https://www.cnews.ru/news/top/2025-01-16_v_2024_godu_proizoshlo_135_utechek