Уведомление от облачного провайдера, CRM-интегратора или агентства по обработке лидов редко означает, что риск остается на стороне поставщика. Для регулятора, клиентов и инвесторов первым адресатом вопросов обычно становится компания, которая определила цели работы с персональными данными и получила их от пользователей. Именно поэтому вопрос, кто отвечает за утечку подрядчика, нельзя оставлять на уровне формулировки «виноват сервис».
Правильный ответ зависит от роли сторон, применимого права, текста договора и фактической архитектуры доступа. Если подрядчик получил выгрузку клиентской базы, ключи к API или административный доступ к SaaS-системе, его ошибка может стать инцидентом заказчика с обязанностью уведомлять надзорный орган, пользователей и контрагентов.
Кто отвечает за утечку подрядчика по GDPR
В логике GDPR компания-заказчик чаще всего выступает контролером, то есть определяет, зачем и как обрабатываются персональные данные. Подрядчик, действующий исключительно по ее поручению, является обработчиком. Например, e-commerce агрегатор передает адреса покупателей сервису рассылок, а провайдер использует их только для отправки транзакционных сообщений.
При такой модели обработчик обязан соблюдать требования статьи 28 GDPR, обеспечивать меры безопасности по статье 32 и уведомлять контролера о нарушении без неоправданной задержки. Однако обязанность сообщить о нарушении надзорному органу в срок до 72 часов по статье 33 GDPR обычно лежит на контролере. Если инцидент создает высокий риск для прав и свобод людей, контролер также организует уведомление затронутых лиц по статье 34.
Это не означает, что поставщик автоматически освобожден от ответственности. Статья 82 GDPR допускает взыскание ущерба с обработчика, когда он нарушил обязанности, прямо адресованные обработчикам, либо действовал вне законных инструкций контролера. Между компаниями убытки, расходы на расследование и регуляторные претензии могут распределяться по договору. Но договорная оговорка не отменяет полномочия надзорного органа и не лишает субъекта данных права предъявить требование.
Когда подрядчик перестает быть только исполнителем
Риски существенно меняются, если поставщик сам решает, какие данные собирать, как долго хранить их или кому передавать. В таком случае он может быть признан самостоятельным контролером либо совместным контролером. Название договора здесь вторично: регулятор оценивает реальные процессы, доступы, инструкции и экономическую роль сторон.
Типичный пример — агентство веб-скрапинга получает от заказчика задачу собрать цены конкурентов, но по собственной инициативе сохраняет аккаунты пользователей, контактные данные и технические идентификаторы для повторного использования в других проектах. По этой части оно уже не действует в рамках поручения. Аналогичный риск возникает у дата-брокера, который приобретает базу «для верификации» и затем обогащает ее для собственных коммерческих целей.
Российское право и ответственность оператора
По ФЗ-152 оператором считается лицо, которое организует и или осуществляет обработку персональных данных, а также определяет ее цели и состав. Оператор вправе поручить обработку другому лицу при соблюдении условий закона. При этом поручение должно устанавливать перечень операций, цели, обязанность сохранять конфиденциальность и обеспечивать безопасность данных.
Перед субъектами персональных данных и Роскомнадзором ключевая ответственность остается у оператора. Исполнитель отвечает перед оператором в рамках договора и может нести самостоятельные последствия за собственные нарушения, но передача базы подрядчику не позволяет заказчику снять с себя обязанность контролировать ее защиту.
При инциденте российскому оператору необходимо оценить обязанность уведомить Роскомнадзор. Закон предусматривает направление первичной информации об инциденте в течение 24 часов, а результатов внутреннего расследования — в течение 72 часов. Для международной группы компаний это означает необходимость сверить российский режим с требованиями GDPR, законами отдельных штатов США и условиями контрактов с корпоративными клиентами. Один инцидент может запускать несколько параллельных сроков.
Почему формального DPA недостаточно
Подписанный DPA полезен только тогда, когда его положения совпадают с реальной технической схемой. Если договор запрещает выгрузку данных за пределы ЕЭЗ, а инженер подрядчика ежедневно копирует файлы в неутвержденное хранилище, бумажный запрет не станет защитой. Контролеру придется объяснять, почему он не выявил нарушение раньше.
Рабочий договор обработки данных должен фиксировать не только статус сторон, но и практические границы доступа. Для поставщиков, работающих с клиентскими базами, журналами событий, данными заказов или корпоративными учетными записями, особенно важны следующие условия:
- конкретные категории данных, цели и допустимые операции;
- запрет использовать сведения для собственных целей, включая повторную продажу, обогащение или создание независимой базы;
- согласование субподрядчиков и порядок контроля их юрисдикций;
- минимальные технические меры: разграничение прав, многофакторная аутентификация, шифрование, журналирование, удаление копий;
- срок, формат и содержание уведомления об инциденте, включая круглосуточный контакт;
- обязанность содействовать расследованию, уведомлениям и ответам на запросы регуляторов;
- правила возврата или безопасного удаления данных после завершения услуги.
Для CCPA и CPRA договор должен также ограничивать использование, продажу и передачу персональной информации поставщиком. Американская квалификация service provider или contractor не возникает только из-за заголовка соглашения: ограничения должны быть отражены в обязательствах и соблюдаться на практике.
Лимит ответственности не всегда спасает заказчика
В договорах подрядчики часто ограничивают ответственность стоимостью услуг за один или несколько месяцев. Для обычной технической ошибки это может быть коммерчески объяснимо. Но при утечке такая сумма иногда несоразмерна затратам заказчика на форензику, внешних юристов, уведомления, поддержку клиентов, восстановление доступа и защиту в споре.
Условие о лимите следует согласовывать отдельно для нарушений конфиденциальности, требований о защите данных, умышленных действий и несанкционированного использования базы. Практический компромисс возможен: общий лимит для стандартных нарушений и повышенный лимит либо отдельное возмещение для критичных инцидентов. Также стоит проверить, располагает ли поставщик реальными ресурсами для исполнения обязательства, а не только красивой формулировкой в договоре.
Что делать в первые часы после обнаружения
Главная ошибка — спорить о виновнике до локализации события. Сначала необходимо остановить несанкционированный доступ: отозвать токены, заблокировать скомпрометированные учетные записи, ограничить интеграцию, изолировать резервные копии. Удалять логи или перезапускать системы без фиксации доказательств нельзя: это усложнит расследование и проверку регулятора.
Далее заказчик и поставщик должны создать единый контур управления инцидентом. В него обычно входят владелец данных, ИБ-команда, технический представитель подрядчика, юрист по privacy и ответственный за коммуникации. Задача первых часов — установить, какие системы затронуты, какие категории данных раскрыты, сколько лиц потенциально затронуто, продолжается ли доступ и в каких странах находятся пользователи.
Не следует принимать на веру лаконичное сообщение подрядчика «критических данных не обнаружено». Заказчику нужны подтверждающие материалы: журналы доступа, временная шкала, сведения о выгрузках, перечень учетных записей, результаты анализа резервных копий и меры, принятые для устранения причины. Если поставщик не способен предоставить эти данные быстро, это самостоятельный признак слабого контроля.
После первичной локализации проводится юридическая квалификация. Для GDPR оцениваются риск для прав и свобод субъектов, применимые сроки и необходимость уведомления. Для ФЗ-152 определяется объем сообщения Роскомнадзору и содержание внутреннего расследования. Для договоров с корпоративными клиентами проверяются отдельные сроки оповещения: они нередко короче законодательных.
Как снизить риск до передачи базы поставщику
Проверка подрядчика должна начинаться до подписания договора и выдачи доступа. Для SaaS-провайдера, скрапинг-агентства или оператора контакт-центра недостаточно получить сертификат или заполненный опросник. Нужно сопоставить заявленные меры с фактической моделью работы: где размещаются данные, кто имеет привилегированный доступ, как подключаются субподрядчики, можно ли выгружать файлы локально, как удаляются резервные копии.
Особое внимание требуется, когда поставщик получает доступ к закрытому API, личному кабинету маркетплейса или экспортам CRM. Выдавайте минимально необходимые права, используйте отдельные сервисные аккаунты и ограниченные по сроку токены. Передавать полную клиентскую базу «на всякий случай» — плохая практика и с точки зрения privacy-комплаенса, и с позиции коммерческой тайны.
Полезно заранее провести tabletop-упражнение: смоделировать утечку у подрядчика и проверить, кто принимает решение об отключении интеграции, кто получает уведомление ночью, где лежит актуальный реестр обработчиков и кто готовит сообщение регулятору. Такой тест быстро показывает, что регламент без владельцев задач и технических контактов не работает.
Дата-юристы Data Lawyer Agency помогают выстроить эту систему до инцидента и защитить позицию компании после него: провести аудит цепочки обработчиков, подготовить DPA и договорные механизмы возмещения, проверить трансграничные передачи и собрать регламент реагирования для GDPR, ФЗ-152 и CCPA. Чем раньше доступы, договоры и сроки уведомления приведены в порядок, тем больше у бизнеса контроля в тот момент, когда подрядчик сообщает о проблеме.