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

Частая ошибка — свести контроль подрядчика к подписанию договора поручения на обработку персональных данных. Документ есть, галочка в чек-листе стоит, но фактический контроль не появляется.

До подписания документов нужно ответить на более важный вопрос: является ли контрагент обработчиком персональных данных вообще.

На практике компании часто автоматически направляют контрагентам соглашения о поручении, не анализируя фактическую роль такого лица в процессе обработки данных. Между тем в российской модели есть две базовые роли: оператор и лицо, осуществляющее обработку персональных данных по поручению оператора.

Обработчик действует в интересах оператора. Он не определяет цели обработки самостоятельно, а помогает оператору достичь уже определенной цели. Обычно это:

• аутсорсинговая бухгалтерия;
• провайдер технической поддержки;
• облачный сервис;
• контакт-центр;
• подрядчик по организации командировок;
• сервис рассылок;
• поставщик ИТ-системы, если получает доступ к ПДн для обслуживания.

Если контрагент самостоятельно определяет цели обработки, использует данные в собственных интересах или продолжает обработку после прекращения отношений с заказчиком, он уже не может рассматриваться как обработчик. В такой ситуации отношения строятся по модели «оператор — оператор», а каждая сторона самостоятельно несет обязанности и риски по законодательству о персональных данных.

После определения статуса подрядчика многие компании ограничиваются подписанием соглашения о поручении и считают задачу выполненной. Но на практике именно после подписания договора начинается основная работа по контролю обработчика.

Чаще всего подрядчик выпадает из поля зрения компании:

• не запрашиваются подтверждения мер защиты;
• не проверяются субподрядчики;
• не проводится переоценка рисков;
• отсутствует порядок реагирования на инциденты;
• не собираются доказательства выполнения договорных обязательств.

В результате при утечке или жалобе субъекта компания не может доказать, что действительно контролировала обработчика и предпринимала разумные меры по управлению рисками.

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

Минимальный набор условий в договоре с обработчиком лучше разделить на несколько блоков. Чем конкретнее они описаны, тем проще компании доказать, что подрядчик не просто получил доступ к данным, а работает в понятных правовых и технических границах.

В поручении нужно определить:

• цели обработки;
• категории субъектов;
• перечень персональных данных;
• действия с персональными данными;
• срок обработки.

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

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

Подрядчик должен принять меры, предусмотренные законодательством о персональных данных, в частности ст. 18.1 Федерального закона № 152-ФЗ «О персональных данных».

В договоре стоит закрепить, что подрядчик обязан:

• назначить ответственного за организацию обработки персональных данных;
• утвердить политику обработки персональных данных;
• проводить внутренний контроль и аудит;
• обучать работников, допущенных к обработке данных;
• оценивать риски и возможный вред субъектам персональных данных.

Недостаточно просто написать, что подрядчик обязуется соблюдать законодательство. Такая фраза редко помогает оператору оценить фактический уровень зрелости процессов подрядчика.

Лучше закреплять конкретные организационные мероприятия, которые должны быть реализованы. Тогда оператор сможет запрашивать подтверждающие документы и оценивать исполнение требований в ходе регулярных проверок.

В договоре желательно закрепить обязанность подрядчика:

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

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

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

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

Если подрядчик передает данные третьим лицам, оператор должен знать:

• кто является субподрядчиком;
• где осуществляется обработка;
• какие данные передаются;
• какие меры безопасности внедрены;
• кто отвечает за инциденты в цепочке субподрядчиков.

На практике операторы нередко узнают о субподрядчиках уже после инцидента. Особенно часто это происходит при использовании облачных сервисов, когда подрядчик привлекает дополнительных поставщиков инфраструктуры.

Хорошая практика — заранее согласовать перечень субподрядчиков и закрепить обязанность подрядчика проверять их до начала обработки персональных данных. Также стоит включить условие об уведомлении оператора при появлении новых субпроцессоров и существенных изменениях в инфраструктуре.

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

В качественном соглашении можно установить обязанность подрядчика сообщать об инциденте в течение 12 часов после выявления и предоставлять первичную информацию:

• характер нарушения;
• категории затронутых данных;
• предполагаемый вред субъектам;
• затронутые системы;
• принятые первичные меры;
• контактное лицо со стороны подрядчика.

Результаты внутреннего расследования можно предусмотреть отдельным этапом, например с ограничением срока предоставления до 48 часов. Это договорная модель, которая помогает оператору не ждать, пока подрядчик завершит все внутренние процедуры, и сразу начать собственную оценку риска.

Чем быстрее оператор получает информацию об инциденте, тем больше у него возможностей провести расследование, сохранить доказательства, ограничить ущерб и своевременно взаимодействовать с Роскомнадзором.

Такую таблицу удобно использовать как внутренний минимум для владельца процесса, но и иных подразделений, участвующих в процессе Она не заменяет полноценный договор, но помогает быстро увидеть, где поручение обработки остается декларативным.

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

Минимальное досье подрядчика должно содержать:

• политику обработки персональных данных;
• политику информационной безопасности;
• сведения о размещении инфраструктуры;
• информацию о локализации баз данных;
• сведения о субподрядчиках;
• сертификаты и результаты аудитов, если они есть;
• историю инцидентов и корректирующих мероприятий;
• подтверждение обучения работников, допущенных к обработке данных;
• ответы на анкеты по ПДн и информационной безопасности;
• подтверждение уничтожения или возврата данных после завершения договора.

Особое внимание стоит уделить документам, подтверждающим выполнение требований по запросу заказчика. Именно такие подтверждения обычно запрашиваются в ходе клиентских аудитов.

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

Поэтому оператору лучше формировать единое досье подрядчика. Оно позволит быстро подтвердить выполнение требований перед клиентом, регулятором или внутренним комитетом по рискам.

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

Даже без отдельного DPO компания может внедрить простую риск-ориентированную модель. Но важно не пытаться одинаково глубоко проверять всех подрядчиков.

Подрядчик, который получает один рабочий email для сервисного уведомления, и подрядчик, который администрирует CRM с клиентской базой, создают разный уровень риска. Значит, и глубина проверки должна быть разной.

На этапе выбора подрядчика нужно оценить:

• какие данные будут передаваться;
• какие категории субъектов затронуты;
• где данные будут храниться;
• будет ли доступ к ИСПДн;
• будут ли использоваться субподрядчики;
• есть ли риск нарушения локализации баз данных;
• какие меры защиты уже внедрены;
• были ли у подрядчика инциденты.

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

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

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

• актуален ли перечень обрабатываемых данных;
• не изменились ли цели обработки;
• не появились ли новые субподрядчики;
• не изменилась инфраструктура;
• не переносились ли базы данных;
• не было ли инцидентов;
• выполняется ли порядок уничтожения или возврата данных.

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

Внеплановая проверка нужна при:

• утечке персональных данных;
• смене облачного провайдера;
• переносе баз данных;
• появлении новых субобработчиков;
• расширении перечня данных;
• изменении цели обработки;
• подключении подрядчика к новой системе.

Для подрядчиков, имеющих доступ к значительным объемам персональных данных или критически важным бизнес-процессам, целесообразно проводить периодическую переоценку рисков даже при отсутствии инцидентов.

Даже если в компании нет DPO, у процесса должен быть владелец. Иначе контроль подрядчиков быстро превращается в набор разрозненных действий: юрист подписал договор, ИТ выдал доступ, бизнес запустил сервис, но никто не видит всю цепочку обработки.

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

Показательным является дело Министерства труда и социальной защиты РФ. Персональные данные сотрудников и членов их семей оказались в открытом доступе в интернете. Министерство ссылалось на то, что инцидент произошел через инфраструктуру подрядчика и был вызван действиями третьих лиц. Однако Верховный Суд Р Ф указал, что сам по себе факт использования подрядчика не освобождает оператора от ответственности.

Ключевым вопросом является наличие доказательств того, что оператор принял необходимые правовые, организационные и технические меры по защите персональных данных. Поскольку такие доказательства представлены не были, Министерство было привлечено к административной ответственности.

Этот кейс имеет принципиальное значение для практики контроля обработчиков. Наличие соглашения о поручении само по себе не доказывает надлежащий контроль подрядчика.

Оператор должен иметь возможность показать, что он:

• проверял подрядчика до начала сотрудничества;
• оценивал уровень защищенности его процессов;
• предъявлял требования к безопасности;
• контролировал исполнение договорных обязательств;
• запрашивал подтверждающие документы;
• реагировал на возникающие риски.

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

Минимальная самопроверка контроля подрядчиков может выглядеть так:

1. Составьте перечень подрядчиков, которые получают доступ к персональным данным.
2. Определите роль каждого: обработчик по поручению или самостоятельный оператор.
3. Проверьте, есть ли с обработчиками поручение обработки.
4. Сверьте поручения с фактической передачей данных.
5. Запросите у подрядчиков подтверждения организационных и технических мер.
6. Проверьте, есть ли у подрядчиков субподрядчики.
7. Уточните, где хранятся данные и соблюдается ли локализация.
8. Проверьте порядок уведомления об инцидентах.
9. Соберите досье подрядчика.
10. Назначьте периодичность повторной проверки.

Эту проверку лучше проводить не только силами юриста. Юрист видит договор, но не всегда видит фактический доступ. ИТ видит системы, но не всегда знает правовую модель. Владелец процесса знает, зачем нужен подрядчик, но может не понимать требований 152-ФЗ. Поэтому контроль подрядчиков должен быть совместной задачей.

После изменений законодательства и появления крупных штрафов главным риском для оператора становится не отсутствие отдельного документа, а отсутствие доказательств контроля.

Сегодня недостаточно просто заключить соглашение о поручении и получить от подрядчика заверение о соблюдении закона. Оператор должен понимать:

• кому передаются данные;
• для какой цели;
• в каком объеме;
• где они хранятся;
• какие субподрядчики участвуют;
• какие меры защиты применяются;
• как подрядчик сообщает об инцидентах;
• как данные уничтожаются или возвращаются после завершения договора.

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

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

1) Нужно ли компании назначать DPO, чтобы контролировать подрядчиков?

Да, необходимо в соответствии с п. 1 ч. 1 ст. 18.1 152-ФЗ, однако многие компании не имеют такого специалиста. Чаще руководители распределяют контроль подрядчиков между юристом, ИТ/ИБ, владельцем процесса и руководителем.

2) Чем обработчик отличается от самостоятельного оператора?

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

3) Достаточно ли подписать договор поручения?

Нет. Договор поручения — только первый уровень контроля. Оператору нужно собирать доказательства исполнения: документы по ИБ, сведения о локализации, список субподрядчиков, подтверждение обучения, результаты аудитов и информацию об инцидентах.

4) Какие условия должны быть в поручении обработки?

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

5) Почему оператор отвечает за нарушения подрядчика?

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

6) Что хранить в досье подрядчика?

Минимально: договор поручения, анкету подрядчика, политику ПДн, документы по ИБ, сведения об инфраструктуре и локализации, список субподрядчиков, историю инцидентов, результаты аудитов и подтверждение уничтожения или возврата данных.

7) Когда нужно проводить внеплановую проверку подрядчика?

При утечке, смене облачного провайдера, переносе баз данных, появлении новых субпроцессоров, расширении перечня данных, изменении цели обработки или подключении подрядчика к новой системе.

Несмотря на законодательную обязанность, контроль подрядчиков без DPO возможен, если компания не подменяет его формальным подписанием договора. Устойчивую позицию дают три элемента: правильная квалификация роли подрядчика, конкретное поручение обработки и регулярное досье доказательств.

Если подрядчик получает доступ к персональным данным, оператор должен понимать, что именно передается, зачем, где хранится, кто еще участвует в обработке и как подтверждается защита данных. Без этих ответов риск остается у компании, даже если нарушение фактически произошло на стороне контрагента.

Следующий практический шаг — составить реестр подрядчиков с доступом к ПДн и проверить по каждому: роль, договор, меры защиты, субподрядчики, локализация, инциденты и порядок прекращения обработки.