Если подрядчик обрабатывает персональные данные исключительно в интересах оператора, отношения нужно оформить как поручение обработки по части 3 статьи 6 152-ФЗ. Для этого не обязательно заключать отдельный DPA: необходимые условия можно включить в основной договор, дополнительное соглашение или приложение.
Отдельный DPA удобнее, когда обработка сложная, масштабная или регулярно меняется. Но если подрядчик начинает сам определять цели использования полученных данных, проблема уже не решается новым приложением к договору. В такой ситуации нужно пересматривать роли сторон и всю договорную модель.
На практике слабое место часто обнаруживается не потому, что договора с подрядчиком нет вообще. Договор есть, но из него невозможно понять, какие именно ПДн получает контрагент, зачем они ему нужны, какие операции он вправе совершать, кого может привлекать и что должно произойти с данными после завершения услуги.
Переподписывать все договоры с нуля при этом требуется не всегда. Главное сначала определить фактическую модель обработки, а уже затем выбирать между разделом в основном договоре, допсоглашением и отдельным DPA.
Поручение возникает, когда третье лицо работает с ПДн в интересах оператора и не определяет самостоятельную цель такой обработки.
Для квалификации отношений принципиальны две характеристики.
Во-первых, обработчик юридически самостоятелен по отношению к оператору. Поэтому сотрудники самого оператора и его обособленные подразделения в эту модель не входят.
Во-вторых, подрядчик действует в интересах оператора. Он помогает реализовать уже определенную компанией цель, а не решает самостоятельно, зачем использовать полученные персональные данные.
Такая модель может возникать при аутсорсинговой бухгалтерии, кадровом обслуживании, технической поддержке, администрировании информационных систем, использовании облачных сервисов, работе контакт-центров, хранении документов и архивов или организации командировок.
При этом название стороны в договоре ничего не решает само по себе.
Если подрядчик формально назван «обработчиком», но фактически самостоятельно определяет цели использования ПДн, одна эта формулировка не превращает его в лицо, действующее по поручению оператора.
Перед подготовкой DPA стоит проверить три вещи.
Кто определяет цель обработки? Если ее определяет заказчик, это аргумент в пользу модели поручения.
Может ли подрядчик использовать полученные ПДн для собственных целей? Если да, отношения уже нельзя автоматически описывать как обычную обработку по поручению.
Какие операции контрагент совершает с данными и зачем? Они должны быть связаны с услугой и указаниями оператора.
Если после этих вопросов роль сторон остается неясной, сначала нужно определить фактическую договорную модель, а уже затем выбирать документ.
Б-152 может сверить роли подрядчиков, фактическую обработку и действующие договоры и показать, где поручение отсутствует, оформлено неполно или не соответствует реальным отношениям сторон.
Нет. 152-ФЗ устанавливает требования к содержанию поручения, но не требует, чтобы оно обязательно существовало в виде самостоятельного документа с названием Data Processing Agreement.
Условия можно разместить в основном договоре, дополнительном соглашении, отдельном DPA или приложении к договору.
Такую же позицию Роскомнадзор озвучивал на Дне открытых дверей 14 августа 2026 года: законодательство не требует отделять поручение от основного договора.
Поэтому практический вопрос звучит не «обязателен ли DPA?», а иначе: какая конструкция позволит точно описать реальную обработку и закрепить все необходимые условия?
Основного договора может быть достаточно, если обработка ПДн является понятной частью услуги и все условия поручения можно зафиксировать без чрезмерного усложнения документа.
Из договора должно однозначно следовать, что подрядчик действует в интересах оператора и следует его документированным указаниям, самостоятельно не определяет цели обработки, а сама работа с данными непосредственно связана с предметом услуги.
Там же должны быть определимы состав данных, цели, разрешенные операции, требования к конфиденциальности и безопасности, порядок работы с субподрядчиками и инцидентами, а также завершение обработки и уничтожение ПДн.
Такая конструкция может использоваться, например, в договоре на бухгалтерское обслуживание, техническую поддержку, администрирование системы или хранение документов.
Преимущество простое: компании не приходится создавать еще один документ только ради наличия DPA.
Но эта модель работает только тогда, когда основной договор действительно позволяет полноценно описать обработку.
Допсоглашение удобно, если основной договор уже действует и сама модель отношений не изменилась, но privacy-условия отсутствуют или перестали соответствовать реальной работе.
Это может произойти, если старый договор вообще не содержит поручения, положения о ПДн не закрывают требования части 3 статьи 6 152-ФЗ, подрядчик впервые получает доступ к данным или меняются состав ПДн, объем доступа и разрешенные операции.
Так же можно действовать, когда к существующей услуге добавляется новый процесс обработки или договорные положения нужно привести в соответствие с изменившимися требованиями.
Преимущество допсоглашения в том, что оно корректирует существующий договорный контур, а не создает параллельный.
Граница проходит там, где меняются не отдельные параметры, а сама роль сторон.
Например, подрядчик начинает использовать полученные данные для собственной цели. Или появляется новая цепочка участников, которая не укладывается в прежнюю модель обработки.
В такой ситуации попытка добавить еще несколько пунктов о персональных данных способна только скрыть проблему.
Сначала нужно заново квалифицировать отношения сторон, после этого определять договорную конструкцию.
DPA становится практичнее, если работа с персональными данными представляет собой значимую самостоятельную часть отношений.
Например, подрядчик постоянно работает с существенным объемом информации, а параметры обработки приходится регулярно менять. В таком случае отдельный документ позволяет обновлять privacy-условия, не затрагивая коммерческую часть основного договора.
То же справедливо, когда сам договор относительно короткий, а описание обработки требует подробно закрепить цели, категории данных, операции, требования безопасности, работу с субподрядчиками, порядок реагирования на инциденты, контроль исполнения и прекращение обработки.
Отдельный DPA может быть удобен и для рамочных договоров, когда конкретные услуги определяются заявками, спецификациями или техническими заданиями. Тогда единые правила обработки действуют для всех связанных документов.
Еще один сценарий — большое количество подрядчиков. Типовое приложение или DPA помогает компании унифицировать требования и не искать разные privacy-условия в десятках договоров.
В исходном материале также отмечена позиция Роскомнадзора, согласно которой поручение может существовать и при отсутствии других гражданско-правовых отношений, если соблюдены требования части 3 статьи 6 152-ФЗ.
Если заключается новый договор, а обработка проста и непосредственно связана с услугой, условия поручения обычно можно включить в сам договор.
Если договор уже действует, но необходимых условий в нем нет либо требуется уточнить данные, операции или объем доступа без изменения самой модели отношений, удобнее допсоглашение.
Если обработка сложная, масштабная, долгосрочная или регулярно меняется, отдельный DPA зачастую делает договорную конструкцию понятнее.
Для рамочного договора можно использовать DPA или отдельное приложение.
Но если подрядчик начал самостоятельно использовать данные или в цепочке появились новые участники с собственной ролью, сначала требуется анализ отношений. Выбор формы документа в такой ситуации вторичен.
Фразы «подрядчик соблюдает законодательство РФ о персональных данных» недостаточно.
Поручение должно устанавливать конкретные границы обработки.
Из документа должно быть понятно, какие именно персональные данные подрядчик получает, какие операции вправе с ними выполнять и для какой цели действует.
Также закрепляются требования к конфиденциальности и безопасности, применимые требования статьи 18.1, статьи 19 и части 5 статьи 18 152-ФЗ, обязанность предоставлять оператору документы и сведения о выполнении требований и обязанность уведомлять его об инцидентах.
Но для реально работающего договора законодательного минимума часто недостаточно.
Если обработчик привлекает других лиц, оператору нужно понимать, допускается ли это и как будет устроена дальнейшая цепочка.
В зависимости от модели можно установить предварительное согласование новых участников или обязанность уведомлять об их привлечении, определить доступный им объем данных и распространить на дальнейшую обработку необходимые требования основного поручения.
Универсального механизма здесь нет. Его нужно выбирать исходя из фактической схемы отношений.
Особенно внимательно этот вопрос стоит проверять у SaaS-платформ, облачных сервисов и технических подрядчиков с собственной цепочкой поставщиков.
Чем длиннее такая цепочка, тем сложнее оператору понимать, где находятся данные и кто фактически получает к ним доступ.
Формулировка «подрядчик уведомляет оператора об инцидентах» сама по себе не создает рабочий процесс.
Сторонам нужно понимать, кто именно сообщает об инциденте, через какой канал идет коммуникация и какие сведения должен получить оператор.
Конкретные сроки и содержание процедуры должны соответствовать применимым требованиям и реальной модели реагирования.
То же относится к контролю исполнения поручения.
Если оператор вправе получать подтверждающие документы и сведения, договор должен позволять использовать это право практически: должно быть понятно, что можно запросить, кто обязан предоставить информацию и как происходит взаимодействие.
Юридическое окончание отношений не означает, что данные автоматически исчезли из систем и доступов подрядчика.
Поэтому порядок возврата, прекращения обработки и уничтожения ПДн стоит определять заранее.
Это особенно заметно в облачных сервисах и сложной инфраструктуре, где данные могут находиться одновременно в нескольких средах или у привлеченных подрядчиков.
Специалисты Б-152 помогут проверить или подготовить договорные условия по персональным данным: роли сторон, состав данных, допустимые операции, субподрядчиков, взаимодействие при инцидентах и порядок завершения обработки.
Если подрядчиков много, последовательное чтение всех договоров редко является самым эффективным подходом.
Логичнее сначала определить приоритет.
В исходном материале предлагается трехуровневая внутренняя модель оценки. Это не установленная законом классификация, а способ распределить ресурсы компании.
В первую очередь стоит проверять контрагентов с большим объемом ПДн, массовой обработкой, постоянным или широким доступом к информационным системам, собственной цепочкой подрядчиков, трансграничной передачей, специальными категориями или биометрическими данными и широким набором операций.
Средний приоритет можно отдать подрядчикам с ограниченным объемом данных и доступом, работающим с отдельной группой субъектов или в рамках конкретной услуги без сложной цепочки субподрядчиков.
Для отношений с минимальным объемом ПДн и кратковременным доступом достаточно начать с базовой проверки обязательных условий и соответствия договора реальному процессу.
Категория при этом не присваивается навсегда.
Если меняется услуга, объем данных, инфраструктура, доступы или состав участников, оценку подрядчика нужно пересматривать.
При десятках подрядчиков становится сложно поддерживать в актуальном состоянии сведения о том, кто получает ПДн, для какой цели, через какие системы и на основании какого документа.
Privacy Box помогает систематизировать реестры обработки, передачи, информационные системы и ответственных, чтобы не собирать эту картину заново из отдельных договоров и таблиц.
Перед подписанием или ревизией договора удобно проверить:
Если на несколько вопросов невозможно однозначно ответить по тексту договора и фактической схеме, договорный контур стоит пересмотреть.
Чтобы определить роль подрядчика и корректно сформулировать поручение, нужны сведения о фактической обработке.
Владелец услуги или бизнес-процесса должен объяснить, какие данные получает контрагент, откуда они поступают, к каким системам он имеет доступ, какие операции выполняет, привлекает ли другие компании и меняется ли схема обработки в течение срока договора.
Только после этого юридические положения можно сопоставлять с реальной моделью.
Без такой проверки даже подробный DPA рискует описывать не тот процесс, который существует в действительности.
Эта проверка относится прежде всего к заключению или пересмотру договора.
Дальше начинается контроль исполнения.
После подписания нужно отслеживать актуальность цепочки подрядчиков, изменения доступов, подтверждающие документы, инциденты и другие обстоятельства фактической обработки.
Если модель часто меняется, контроль подрядчиков и актуальности требований по 152-ФЗ превращается из разовой юридической проверки в постоянный процесс.
Поручение обработки возникает не из названия документа, а из фактической модели отношений сторон.
Отдельный DPA по 152-ФЗ сам по себе не обязателен. Простую обработку можно описать в основном договоре, действующий договор дополнить соглашением, а сложный или регулярно меняющийся privacy-контур вынести в самостоятельный DPA.
Если же меняется роль подрядчика или он начинает использовать ПДн для своих целей, недостаточно дописать несколько условий. Нужно пересмотреть саму договорную модель.
При большом количестве контрагентов разумнее начинать не с перепроверки всех документов подряд, а с тех поставщиков, которые получают наиболее широкий доступ, работают с большими объемами данных или создают сложную цепочку дальнейшей обработки.
Б-152 поможет разобрать роли подрядчиков, действующие договоры и фактическую обработку и определить, где достаточно допсоглашения, где удобнее отдельный DPA, а где требуется пересобрать модель отношений.
Проверить договоры с подрядчиками
Нет. 152-ФЗ устанавливает требования к содержанию поручения, но не требует отдельного документа именно с названием DPA. Условия можно включить в основной договор, приложение или дополнительное соглашение.
Да, если сама модель отношений не меняется. Допсоглашением можно добавить отсутствующие условия, уточнить данные, операции или доступы. Если подрядчик начинает самостоятельно использовать ПДн или существенно меняется цепочка обработки, сначала нужно пересмотреть роли сторон.
Ключевой критерий — работа в интересах оператора. Обработчик реализует определенную оператором цель и не устанавливает самостоятельную цель использования данных.
Нужно определить перечень ПДн, действия с ними, цель обработки, требования к конфиденциальности и безопасности, применимые требования 152-ФЗ, порядок предоставления подтверждающей информации и взаимодействие при инцидентах.
Если обработчик привлекает других лиц, порядок такого привлечения важно учитывать в договорной конструкции. Конкретный механизм зависит от фактических отношений и цепочки обработки.
Не обязательно читать сто договоров подряд. Начните с нескольких контрагентов, у которых наиболее широкий доступ к системам и данным, есть субподрядчики, трансграничная передача или обработка чувствительных категорий ПДн. После этой ревизии будет понятнее, какой подход масштабировать на остальные отношения.