ОГЛАВЛЕНИЕ
Введение
Компания может обеспечить высокий уровень защиты данных, однако часть процессов часто передаётся подрядчикам. Если утечка происходит у такого подрядчика, возникает вопрос: кто несёт ответственность – заказчик или исполнитель?
Если утечка произошла у подрядчика, компания-заказчик не освобождается от ответственности автоматически. Как оператор персональных данных (ПДн) она отвечает перед субъектами за действия обработчика. Контрагент отвечает перед оператором и может самостоятельно нести ответственность за собственные нарушения. Последствия могут быть административными, гражданско-правовыми, договорными, репутационными.
Если утечка произошла у подрядчика, компания-заказчик не освобождается от ответственности автоматически. Как оператор персональных данных (ПДн) она отвечает перед субъектами за действия обработчика. Контрагент отвечает перед оператором и может самостоятельно нести ответственность за собственные нарушения. Последствия могут быть административными, гражданско-правовыми, договорными, репутационными.
Почему проблема утечек через цепочку поставок стала массовой
Современные компании активно используют подрядчиков, облачные сервисы, внешних поставщиков услуг. Это расширяет периметр безопасности за пределы собственной инфраструктуры. Поэтому контрагенты становятся частью цепочки поставок, а их недостаточный уровень защиты может привести к компрометации данных заказчика.
Кто отвечает за утечку данных
Договор с подрядчиком регулирует отношения между сторонами, но не отменяет обязательств компании перед регулятором и перед собственными клиентами. Это два разных уровня ответственности, и их легко перепутать.
Даже если утечка произошла у контрагента, оператор не освобождается от ответственности перед субъектами ПДн.
- Первый уровень – перед субъектами ПДн и государством отвечает оператор.
- Второй уровень – между оператором и подрядчиком ответственность распределяется условиями договора.
Даже если утечка произошла у контрагента, оператор не освобождается от ответственности перед субъектами ПДн.
При этом результат разбирательства зависит не только от места утечки. Будет оцениваться, кто определял цели обработки данных и какие обязанности были закреплены за подрядчиком. Отдельно учитывается, были ли приняты необходимые меры защиты, насколько быстро стороны обнаружили инцидент и выполнили ли обязанность по уведомлению Роскомнадзора. Поэтому повторяющиеся утечки может повлечь претензии как к заказчику, так и к исполнителю, в зависимости от нарушений каждой стороны.
Что говорят законодательство и стандарты
В российском законодательстве передача обработки ПДн подрядчику не означает передачи ему всей ответственности. Федеральный закон № 152-ФЗ позволяет оператору поручить обработку другому лицу, но требует закрепить цели обработки, перечень данных, меры безопасности, порядок уведомления об инцидентах.
Оператор отвечает перед субъектами ПДн, а контрагент – перед оператором. При этом каждая сторона самостоятельно несёт ответственность за допущенные ею нарушения.
Похожий подход используется в международных стандартах:
При этом сертификат ISO/IEC 27001 сам по себе не гарантирует безопасность конкретной услуги и отсутствие инцидентов. Он может быть одним из критериев оценки поставщика, но не заменяет проверку его доступов, процессов, фактически применяемых мер защиты.
Оператор отвечает перед субъектами ПДн, а контрагент – перед оператором. При этом каждая сторона самостоятельно несёт ответственность за допущенные ею нарушения.
Похожий подход используется в международных стандартах:
- ISO/IEC 27001 и ISO/IEC 27002 – устанавливают требования к управлению рисками поставщиков, закреплению требований ИБ в договорах и контролю оказываемых услуг;
- ISO/IEC 27036 – рассматривает защиту данных на всём протяжении работы с подрядчиком,
- NIST Cybersecurity Framework – также относит управление рисками цепочки поставок к основным задачам кибербезопасности.
При этом сертификат ISO/IEC 27001 сам по себе не гарантирует безопасность конкретной услуги и отсутствие инцидентов. Он может быть одним из критериев оценки поставщика, но не заменяет проверку его доступов, процессов, фактически применяемых мер защиты.
Основные риски работы через подрядчиков
На практике большинство проблем повторяется от компании к компании. Вот основные из них.
- Отсутствие оценки поставщика. Уровень защиты становится известен только после инцидента.
- Отсутствие требований безопасности в договоре. Не определены меры защиты информации, порядок уведомления об инцидентах и распределение ответственности.
- Избыточный доступ. Контрагент получает больше полномочий, чем требуется для выполнения своих задач.
- Отсутствие права на аудит. Заказчик не может проверить соблюдение подрядчиком требований ИБ.
- Бесконтрольные субподрядчики. Контрагент может привлекать третьих лиц без ведома заказчика, увеличивая риски компрометации данных.
- Несвоевременное уведомление об инцидентах. Задержка в информировании сокращает время на реагирование и устранение последствий.
- Отсутствие контроля за жизненным циклом данных. Данные могут храниться дольше необходимого или не удаляться после завершения работ.
Меры защиты при работе с подрядчиками
1. Предварительная оценка поставщика. До заключения договора необходимо оценить зрелость ИБ, историю инцидентов и применяемые меры защиты.
2. Требования безопасности в договоре. Следует закрепить требования к защите информации, сроки уведомления об инцидентах и право заказчика на аудит.
3. Минимальные привилегии и контроль. Подрядчик должен получать только необходимые доступы, а его действия должны журналироваться и регулярно проверяться.
4. Распределение поставщиков по уровню риска. Глубина проверки и мониторинга контрагента должна зависеть от объёма его доступа к ПДн и критическим системам.
2. Требования безопасности в договоре. Следует закрепить требования к защите информации, сроки уведомления об инцидентах и право заказчика на аудит.
3. Минимальные привилегии и контроль. Подрядчик должен получать только необходимые доступы, а его действия должны журналироваться и регулярно проверяться.
4. Распределение поставщиков по уровню риска. Глубина проверки и мониторинга контрагента должна зависеть от объёма его доступа к ПДн и критическим системам.
Типичные ситуации из практики
▶ Небольшой интернет-магазин подключает стороннюю службу доставки, чтобы автоматически передавать заказы курьерам. Служба получает доступ к именам, адресам, телефонам покупателей через общий API. Через полгода у службы доставки происходит взлом: базу с адресами, контактами выкладывают в открытый доступ. Формально магазин ни при чём и его собственные системы не тронуты. Но письма от разгневанных покупателей и запрос от регулятора приходят именно магазину, потому что для клиента заказ был оформлен именно у него.
▶ Компания заказывает разработку мобильного приложения у внешней студии. На время работ студии открывают доступ к боевой базе данных пользователей, чтобы тестировать функции на реальных данных. Проект завершается, приложение сдано, но доступ у студии не отзывают: он просто остаётся активным, потому что никто не занимается его закрытием. Через год один из бывших разработчиков студии использует эту забытую учётную запись, чтобы скачать базу и продать её. Расследование быстро выходит на источник, но отвечать перед клиентами всё равно приходится заказчику приложения.
▶ Медицинский центр переводит хранение записей пациентов в облачный сервис, чтобы сэкономить на собственных серверах. Договор с провайдером составлен по типовому шаблону. В нём есть пункт о конфиденциальности, но не определены требования к шифрованию и порядок доступа к данным. У провайдера случается сбой конфигурации, из-за которого часть архивов оказывается доступна по прямой ссылке без пароля. Медицинский центр узнаёт об этом последним из жалобы одного из пациентов, который случайно нашёл в сети собственную медицинскую карту.
▶ Компания заказывает разработку мобильного приложения у внешней студии. На время работ студии открывают доступ к боевой базе данных пользователей, чтобы тестировать функции на реальных данных. Проект завершается, приложение сдано, но доступ у студии не отзывают: он просто остаётся активным, потому что никто не занимается его закрытием. Через год один из бывших разработчиков студии использует эту забытую учётную запись, чтобы скачать базу и продать её. Расследование быстро выходит на источник, но отвечать перед клиентами всё равно приходится заказчику приложения.
▶ Медицинский центр переводит хранение записей пациентов в облачный сервис, чтобы сэкономить на собственных серверах. Договор с провайдером составлен по типовому шаблону. В нём есть пункт о конфиденциальности, но не определены требования к шифрованию и порядок доступа к данным. У провайдера случается сбой конфигурации, из-за которого часть архивов оказывается доступна по прямой ссылке без пароля. Медицинский центр узнаёт об этом последним из жалобы одного из пациентов, который случайно нашёл в сети собственную медицинскую карту.
Заключение
Утечка на стороне контрагента не освобождает компанию-заказчика от ответственности. Если она остаётся оператором ПДн, то отвечает перед субъектами за действия обработчика, а подрядчик – перед оператором и за собственные нарушения.
Поэтому ответственность нужно не пытаться полностью передать договором, а управлять связанными с контрагентом рисками. Для этого поставщика проверяют до начала работ, закрепляют требования безопасности, ограничивают доступы, контролируют их на протяжении всего сотрудничества.
Современная защита данных заканчивается не на границе инфраструктуры компании, а там, где прекращается доступ последнего подрядчика.
Поэтому ответственность нужно не пытаться полностью передать договором, а управлять связанными с контрагентом рисками. Для этого поставщика проверяют до начала работ, закрепляют требования безопасности, ограничивают доступы, контролируют их на протяжении всего сотрудничества.
Современная защита данных заканчивается не на границе инфраструктуры компании, а там, где прекращается доступ последнего подрядчика.
FAQ
1. Достаточно ли подписать с подрядчиком NDA, чтобы защитить компанию?
Нет. NDA помогает сохранить конфиденциальность информации, но сам по себе не снижает риск утечки. Для работы с подрядчиком также необходимы требования по ИБ в договоре, разграничение доступов, право на аудит и порядок уведомления об инцидентах.
2. Нужно ли проверять каждого подрядчика на соответствие требованиям ИБ?
Да, но глубина проверки должна зависеть от уровня риска. Чем больше данных или критичных систем доступно подрядчику, тем тщательнее должна быть его оценка и последующий контроль.
3. Можно ли полностью переложить ответственность за утечку данных на подрядчика?
Нет. Передача обработки данных не освобождает компанию от ответственности как оператора ПДн. Договор может определить обязанности сторон и порядок возмещения убытков, но не заменяет контроль подрядчика и выполнение требований законодательства.
Нет. NDA помогает сохранить конфиденциальность информации, но сам по себе не снижает риск утечки. Для работы с подрядчиком также необходимы требования по ИБ в договоре, разграничение доступов, право на аудит и порядок уведомления об инцидентах.
2. Нужно ли проверять каждого подрядчика на соответствие требованиям ИБ?
Да, но глубина проверки должна зависеть от уровня риска. Чем больше данных или критичных систем доступно подрядчику, тем тщательнее должна быть его оценка и последующий контроль.
3. Можно ли полностью переложить ответственность за утечку данных на подрядчика?
Нет. Передача обработки данных не освобождает компанию от ответственности как оператора ПДн. Договор может определить обязанности сторон и порядок возмещения убытков, но не заменяет контроль подрядчика и выполнение требований законодательства.
Нужна консультация эксперта? Оставьте заявку >>>
