Разработчик подключил API стороннего сервиса, убедился, что запросы работают, и запустил интеграцию в продакшен. Через несколько недель корпоративный клиент интересуется, какие компании получают его данные и на каком основании. Выясняется, что API передает больше информации, чем требуется для работы функции, а условия обработки с поставщиком никто не проверял.
С подобной ситуацией может столкнуться практически любой SaaS-бизнес. Интеграции позволяют быстро расширять функциональность продукта, но одновременно создают дополнительные каналы передачи пользовательской информации. Аудит GDPR помогает обнаружить такие риски до того, как они станут предметом претензий клиентов или проверки регулятора.
Какие требования GDPR распространяются на API
Сам по себе API не является отдельным объектом регулирования GDPR. Значение имеет то, какие персональныеданные через него передаются, кто их получает и для каких целей использует.
Статья 5 GDPR закрепляет принципы законности и правомерности обработки, минимизации данных и ограничения целей. Статья 25 предусматривает защиту данных на этапе проектирования продукта, а статья 32 ‒ меры безопасности с учетом рисков.
В руководстве по безопасности персональных данных CNIL за 2024 год API посвящен отдельный раздел. Французский регулятор рекомендует ограничивать передаваемые сведения, разграничивать доступ, вести журналы запросов и защищать API-ключи.
Поэтому при комплаенс-проверке API-интеграции важно изучить условия договора с поставщиком и настройки передачи данных.
Чек-лист GDPR-аудита API-интеграции
1. Определите, какие данные уходят через API
Для начала изучите, какие данные передаются в запросах и ответах. Допустим, сервису доставки для отслеживания посылки достаточно номера отправления, но интеграция дополнительно передаёт email, телефон и внутренний идентификатор клиента.
Проверьте, какие поля действительно нужны алгоритму внешнего сервиса, и исключите лишние сведения из запросов. Это помогает соблюдать принцип минимизации данных по статье 5 GDPR.
2. Установите роль поставщика API
Один поставщик может обрабатывать данные исключительно по инструкциям SaaS-компании, другой ‒ самостоятельно определять цели их использования.
От этого зависит распределение юридических обязанностей. Если поставщик выступает обработчиком, статья 28 GDPR требует договорного оформления отношений, обычно через Data Processing Agreement (DPA).
В договоре должны быть определены предмет и цели обработки, категории данных, меры защиты, порядок привлечения субподрядчиков и действия после прекращения сотрудничества.
3. Проверьте, кто получает доступ к данным
API-провайдер может привлекать облачные платформы, хостинг и других исполнителей.
Причем речь идет не только о непосредственном поставщике API. В Opinion 22/2024 Европейский совет по защите данных (EDPB) разъяснил, что контролер должен располагать актуальной информацией обо всех обработчиках и субобработчиках в цепочке.
Запросите у поставщика перечень таких компаний и проверьте условия их привлечения. При этом глубина оценки предоставляемых гарантий зависит от рисков конкретной обработки.
4. Проверьте международную передачу данных
Если информация через API поступает получателю за пределами Европейской экономической зоны, необходимо оценить применимость главы V GDPR.
В зависимости от обстоятельств могут использоваться решение об адекватности защиты, стандартные договорные положения (SCC) или другой предусмотренный регламентом механизм.
При использовании SCC также может потребоваться оценка законодательства страны получателя и дополнительных мер защиты. Одного указания региона хранения данных в настройках API недостаточно, поскольку оно не всегда позволяет установить, откуда фактически осуществляется доступ к информации.
5. Оцените безопасность API-ключей и запросов
Утечка API-ключа может нарушить конфиденциальность пользовательских данных. Поэтому проверка безопасности должна включать:
- ограничение прав доступа каждого ключа;
- безопасное хранение секретов и возможность их отзыва;
- журналирование запросов без избыточной записи персональных данных;
- отключение устаревших версий API;
- порядок обнаружения подозрительной активности.
Подобные меры предусмотрены рекомендациями CNIL, однако их конкретный набор зависит от характера интеграции и уровня риска.
6. Проверьте удаление данных после отключения API
Удаление интеграции из продукта еще не означает, что поставщик удалил ранее полученную информацию.
Если он действует как обработчик, статья 28(3)(g) GDPR предусматривает возврат или удаление персональных данных после завершения услуг по выбору контроллера, за исключением случаев, когда дальнейшее хранение требуется законом.
Проверьте договорные сроки удаления, порядок обращения с резервными копиями и возможность получить подтверждение выполнения этих обязательств.
Что делать после GDPR-аудита
Результаты аудита стоит зафиксировать в реестре API-интеграций: назначение сервиса, категории данных, роль поставщика, правовое основание обработки, наличие DPA и риски.
По итогам проверки лишние данные исключают из запросов, недостающие договоры оформляют до продолжения обработки, а поставщиков без достаточных гарантий защиты ограничивают в доступе или заменяют.
Для SaaS-бизнеса аудит помогает проверить соответствие настроек API требованиям регламента. Такой GDPR анализ особенно полезен при подключении новых сервисов, смене поставщиков или расширении функциональности продукта (подробнее: https://stalirov.lawyer/services/gdpr-compliance).
Заключение
API-интеграции можно подключить за несколько дней, но юридические риски нередко проявляются спустя месяцы. Поэтому ещё до релиза стоит проверить, какие данные получает поставщик, на каких условиях их обрабатывает и какие меры защиты предусмотрены. Если интеграция уже работает, аудит GDPR поможет выявить нарушения и устранить их до возникновения претензий.
