DPA соглашение об обработке персональных данных

DPA — Data Processing Agreement, соглашение об обработке персональных данных — давно стало стандартной частью контрактного периметра при передаче персональных данных от одного лица к другому. В российском праве оно строится не на Article 28 GDPR, а на конструкции части 3 статьи 6 Федерального закона «О персональных данных» — поручения оператора лицу, осуществляющему обработку. Несмотря на функциональное сходство с европейским DPA, российская модель имеет жёсткие императивные требования: локализацию первичной обработки данных граждан России на территории Российской Федерации, специальные меры защиты, прямой запрет на самостоятельное определение целей обработки лицом-обработчиком. Цена ошибок выросла кратно: статья 13.11 КоАП РФ в редакции, действующей с 2025 года, предусматривает оборотные штрафы за повторные инциденты, а Роскомнадзор последовательно проверяет договорные основания обработки.

Эта статья — практическое руководство по DPA в российской юрисдикции. Мы разберём правовую квалификацию поручения, обязательные условия документа, разграничение ответственности оператора и обработчика, особенности привлечения субобработчиков, требования к мерам защиты, регламент уведомления об инцидентах, типовые ошибки и судебную практику. В завершающем блоке FAQ собраны вопросы, которые чаще всего задают клиенты при структурировании передачи данных в облако, SaaS-сервисы, в маркетинговые агентства и аналитические платформы.

Правовая природа DPA: поручение оператора по 152-ФЗ

Российский законодатель не использует термин DPA, но описывает соответствующую конструкцию в части 3 статьи 6 Федерального закона от 27.07.2006 № 152-ФЗ. Оператор вправе поручить обработку персональных данных другому лицу с согласия субъекта персональных данных, если иное не предусмотрено федеральным законом, на основании заключаемого с этим лицом договора. Таким договором — а в широком смысле и любым иным письменным соглашением — оформляется поручение, которое в обороте принято называть DPA.

Закон формулирует минимальный обязательный набор условий: договор должен определять перечень действий с персональными данными, цели обработки, обязанность лица, осуществляющего обработку (обработчика), соблюдать конфиденциальность и обеспечивать безопасность персональных данных при их обработке, требования к защите обрабатываемых персональных данных в соответствии со статьёй 19 152-ФЗ. Это — императивный каркас. Всё остальное — сроки обработки, обязанности по уведомлению об инцидентах, ответственность, аудит, субобработчики, локализация — выстраивается над этим каркасом и не должно ему противоречить.

С точки зрения гражданского права DPA — это, как правило, не самостоятельный возмездный договор, а специальное условие или приложение к основному договору (договор оказания услуг, договор хранения, лицензионный договор на SaaS). Иногда DPA оформляется как самостоятельный документ — например, при отношениях группы компаний или при многосторонней схеме обработки. Российская доктрина допускает и то, и другое: ст. 6 152-ФЗ не предписывает форму поручения, а статья 421 Гражданского кодекса РФ гарантирует Сторонам свободу договора.

Главное отличие от GDPR: российский закон жёстко закрепляет ответственность оператора перед субъектом персональных данных. Даже при передаче обработки обработчику оператор остаётся первичным лицом, отвечающим перед субъектом и перед Уполномоченным органом — Роскомнадзором. Обработчик отвечает только перед оператором. Это означает, что DPA должен быть составлен с акцентом на регрессное требование оператора к обработчику: любой административный штраф, любая выплаченная субъекту компенсация должны быть переложимы на обработчика, если инцидент возник по его вине.

Разграничение ролей: оператор, обработчик, субобработчик

Корректное юридическое разграничение ролей — ключевой шаг в работе над DPA. Оператор — лицо, которое определяет цели обработки персональных данных. Обработчик действует исключительно по поручению оператора и в пределах целей, которые оператор перед ним поставил. Если лицо, формально называющее себя обработчиком, фактически само определяет, какие данные собирать и для чего, оно автоматически приобретает статус оператора со всеми сопутствующими обязанностями — в том числе по уведомлению Роскомнадзора, ведению политики обработки, обеспечению уровня защищённости.

На практике встречаются три типичные схемы. Первая — простая двусторонняя: оператор поручает обработку облачному провайдеру или SaaS-сервису. Вторая — каскадная: основной обработчик привлекает субобработчика (например, оператор центра обработки данных, размещающий инфраструктуру). Третья — совместная обработка, когда два лица одновременно определяют цели и средства обработки. Российский закон совместную обработку прямо не регулирует, что создаёт практический риск: оба лица будут признаны самостоятельными операторами и каждый — независимо отвечать перед субъектом. Для каскадной схемы часть 3 статьи 6 152-ФЗ предполагает, что условия передачи данных субобработчику должны соответствовать условиям, согласованным с оператором; иначе говоря, требования DPA автоматически пробрасываются вниз по цепочке.

Принцип ответственности обработчика за привлечённых им лиц закреплён общегражданской нормой статьи 403 ГК РФ: должник отвечает за действия третьих лиц, на которых было возложено исполнение, если законом не установлено, что ответственность несёт это третье лицо. Применительно к 152-ФЗ это означает, что обработчик отвечает перед оператором за действия каждого субобработчика как за свои собственные. Этот тезис следует прямо включить в DPA — он повышает дисциплину при выборе субподрядчиков.

Обязательные условия DPA: что должно быть в документе

Первое обязательное условие — перечень действий по обработке. Перечень формулируется по терминологии статьи 3 152-ФЗ: сбор, запись, систематизация, накопление, хранение, уточнение, извлечение, использование, передача, обезличивание, блокирование, удаление, уничтожение. Указание «все действия по статье 3 152-ФЗ» допустимо, но рискованно: при проверке Роскомнадзор предпочитает видеть точный закрытый список, отражающий реальные операции обработчика.

Второе — цели обработки. Цели должны совпадать с целями обработки у самого оператора и быть сформулированы конкретно (например, «оказание Оператору облачных услуг — хранение и предоставление доступа к информационным системам Оператора»). Размытые цели типа «улучшение качества услуг» в DPA не работают: Роскомнадзор устойчиво квалифицирует их как нарушение принципа конкретности (часть 2 статьи 5 152-ФЗ).

Третье — обязанность обработчика соблюдать конфиденциальность и обеспечивать безопасность персональных данных. Здесь общая формулировка недостаточна. Хорошее DPA содержит ссылку на конкретный уровень защищённости по постановлению Правительства РФ № 1119, перечень технических и организационных мер по приказу ФСТЭК России № 21, требования к шифрованию (AES-256 или ГОСТ Р 34.12-2015), ведение журналов доступа, реагирование на инциденты.

Четвёртое — категории обрабатываемых персональных данных и категории субъектов. Это требование прямо вытекает из принципа адекватности (часть 5 статьи 5 152-ФЗ): обрабатываются только те данные, которые необходимы для достижения целей. Обработка специальных категорий (расовая принадлежность, политические взгляды, здоровье, интимная жизнь) или биометрических данных требует отдельных оснований и должна быть отражена в DPA с особой тщательностью.

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

Шестое — порядок взаимодействия при запросах субъектов и Роскомнадзора. Обработчик не должен самостоятельно отвечать субъекту персональных данных; запрос подлежит немедленной передаче оператору. Аналогично — при запросе Роскомнадзора в адрес обработчика последний обязан незамедлительно уведомить оператора и согласовать совместный ответ.

Локализация и трансграничная передача

Российский режим персональных данных уникален требованием локализации первичной обработки. Часть 5 статьи 18 152-ФЗ обязывает оператора при сборе персональных данных, в том числе через сеть «Интернет», обеспечить запись, систематизацию, накопление, хранение, уточнение и извлечение персональных данных граждан Российской Федерации с использованием баз данных, находящихся на территории Российской Федерации. Это правило действует и применительно к обработчику: если оператор поручает обработку, обработчик должен использовать ту же инфраструктуру в РФ.

Трансграничная передача регулируется статьёй 12 152-ФЗ. С 2023 года передача в иностранные государства возможна только после уведомления Роскомнадзора в специальной форме, а в случаях передачи в государства, не обеспечивающие адекватной защиты, — только после получения соответствующего решения Уполномоченного органа. На практике это означает, что DPA, заключённое с обработчиком, использующим зарубежные дата-центры (например, в США или в странах ЕС, не признанных адекватными для российских целей), требует отдельной структуризации с учётом запретов и уведомительных процедур.

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

Уведомление об инцидентах: режим 24 часов

С 1 сентября 2022 года в статью 21 152-ФЗ внесены поправки, существенно ужесточившие режим уведомления об инцидентах. Оператор обязан в течение 24 часов с момента выявления инцидента, повлёкшего неправомерную или случайную передачу персональных данных, уведомить Роскомнадзор о произошедшем инциденте, его предполагаемых причинах, лице, уполномоченном на взаимодействие, и принятых мерах. В течение 72 часов с момента выявления оператор предоставляет результаты внутреннего расследования и идентифицирует лиц, чьи действия привели к инциденту.

Применительно к DPA это правило транслируется в обязанность обработчика уведомить оператора об инциденте раньше, чем оператор должен уведомить Роскомнадзор. На практике — в течение нескольких часов. Грамотный DPA устанавливает срок не более 6 часов с момента выявления, обязывает обработчика предоставить максимально полный объём сведений (затронутые субъекты, объём данных, причины, принятые меры) и оказывать содействие оператору в дальнейшем взаимодействии с Уполномоченным органом. Любая задержка по вине обработчика, повлёкшая нарушение оператором 24-часового срока, должна влечь штраф, эквивалентный размеру административного штрафа, наложенного на оператора по статье 13.11 КоАП РФ.

Кроме того, оператор обязан вести реестр инцидентов и хранить его не менее одного года. DPA должен зеркалить эту обязанность для обработчика: вести собственный реестр инцидентов, предоставлять его оператору по запросу и хранить не менее срока, установленного нормативными актами Роскомнадзора (приказ Роскомнадзора № 274 от 14.11.2022 утверждает форму уведомления).

Меры защиты: ФСТЭК и постановление № 1119

Технические и организационные меры защиты — предмет наибольшего количества разногласий между сторонами DPA. Базовая привязка: статья 19 152-ФЗ обязывает оператора принимать меры, необходимые и достаточные для обеспечения выполнения обязанностей, предусмотренных законом. Конкретный состав мер раскрыт в двух подзаконных актах: постановлении Правительства РФ от 01.11.2012 № 1119 (требования к защите персональных данных при их обработке в информационных системах) и в приказе ФСТЭК России от 18.02.2013 № 21 (состав и содержание организационных и технических мер).

Постановление № 1119 устанавливает четыре уровня защищённости (УЗ-1 — самый высокий, УЗ-4 — самый низкий). Уровень определяется типом обрабатываемых данных (общедоступные, иные категории, биометрические, специальные), количеством субъектов и категорией актуальных угроз. DPA должен фиксировать установленный уровень защищённости и обязывать обработчика поддерживать его не ниже согласованного — в противном случае оператор не сможет доказать выполнение собственных обязательств по 152-ФЗ.

Приказ ФСТЭК № 21 детализирует конкретные меры: идентификация и аутентификация (ИАФ), управление доступом (УПД), ограничение программной среды (ОПС), защита машинных носителей (ЗНИ), регистрация событий безопасности (РСБ), антивирусная защита (АВЗ), обнаружение вторжений (СОВ), контроль и анализ защищённости (АНЗ), обеспечение целостности (ОЦЛ), обеспечение доступности (ОДТ), защита среды виртуализации (ЗСВ), защита технических средств (ЗТС), защита системы и её компонентов (ЗИС), управление конфигурацией (УКФ). Не обязательно дословно перечислять все группы в DPA — но обязательно сослаться на приказ № 21 и обязать обработчика выполнять меры, соответствующие установленному уровню защищённости.

Шифрование — отдельный вопрос. Прямого требования об использовании криптографических средств защиты информации (СКЗИ) ФСБ в DPA нет: оно возникает только в случаях, прямо предусмотренных законом (например, при обработке в государственных информационных системах). В коммерческом обороте допускается использование любых надёжных алгоритмов — AES-256, ГОСТ Р 34.12-2015 (Магма/Кузнечик). Однако при обработке специальных категорий персональных данных или при УЗ-1/УЗ-2 целесообразно прямо договариваться об использовании сертифицированных ФСТЭК средств защиты и сертифицированных ФСБ криптосредств — это минимизирует риски при проверке.

Аудит обработчика: право или иллюзия

Право оператора на аудит обработчика — стандартное условие, унаследованное из практики GDPR. В российской правовой среде это условие применяется реже, чем должно: операторы редко настаивают на реальной проверке, а обработчики — крупные облачные провайдеры — часто отказывают, ссылаясь на коммерческую тайну и угрозы безопасности других клиентов. Тем не менее, в крупных проектах и при работе с критическими данными аудит — единственный способ убедиться, что обработчик действительно поддерживает обещанный уровень защищённости.

Грамотное условие об аудите содержит несколько элементов: периодичность (как правило, не чаще одного раза в 12 месяцев); состав документов, которые обработчик обязан предоставить (политики, перечень мер, сертификаты, отчёты по итогам внутренних аудитов); право оператора привлекать независимую аудиторскую организацию; обязанность обработчика обеспечить разумный доступ к инфраструктуре с учётом требований безопасности; распределение расходов на аудит; конфиденциальность результатов аудита. Хорошей практикой является разделение «лёгкого» аудита (запрос документов и анкета) и «тяжёлого» (физическая проверка) с разными режимами доступа.

Альтернатива самостоятельному аудиту — принятие обработчиком обязательства предоставлять оператору актуальные сертификаты ISO/IEC 27001, ISO/IEC 27017 (security for cloud services), ISO/IEC 27018 (PII in public clouds), отчёты SOC 2 Type II, а также подтверждение соответствия требованиям ФСТЭК России. Это снижает административную нагрузку и при этом даёт оператору достаточный комфорт.

Ответственность сторон и штрафы

Регрессное требование оператора к обработчику — центральная конструкция ответственности в DPA. Базовое правило статьи 24 152-ФЗ: лица, виновные в нарушении требований закона, несут административную, гражданскую и иную ответственность в соответствии с законодательством Российской Федерации. Это означает, что любой штраф, наложенный на оператора по статье 13.11 КоАП РФ и связанный с виновными действиями обработчика, должен быть переложим на обработчика в полном объёме. DPA должно содержать прямое условие об этом — без него регресс возможен только в общем порядке возмещения убытков, который потребует доказывания вины обработчика, причинно-следственной связи и размера ущерба.

С 2025 года статья 13.11 КоАП РФ ужесточена: введены оборотные штрафы за повторные утечки в размере от 1 до 3 процентов годовой выручки, увеличены штрафы за умышленные нарушения, появилась специальная ответственность за неуведомление об инциденте в 24-часовой срок. Это резко повышает значимость регрессного условия в DPA: операторы должны переносить экономический риск на лицо, фактически контролирующее инфраструктуру.

Ограничение ответственности в DPA должно быть структурировано с осторожностью. Стандартное ограничение «не более стоимости услуг за 12 месяцев» в части обязательств по защите персональных данных, как правило, не применяется к умышленным нарушениям и грубой неосторожности — это вытекает из императивных норм ГК РФ. Хорошая практика — прямо исключить из ограничений обязательства по защите персональных данных, регрессные требования по штрафам Роскомнадзора и обязательства по возмещению вреда субъектам.

Судебная практика: ключевые ориентиры

Судебная практика по DPA-спорам в чистом виде в России пока невелика — большинство дел концентрируется на ответственности оператора перед субъектом или перед Роскомнадзором, не затрагивая регрессную цепочку. Однако несколько ориентиров уже сформировано. Обзор судебной практики Верховного Суда Российской Федерации № 4 (2017) подтвердил, что оператор не освобождается от ответственности перед субъектом фактом передачи обработки третьему лицу — этот тезис стал основанием для устойчивого подхода нижестоящих судов.

Постановления Пленума Верховного Суда Российской Федерации по вопросам обработки персональных данных в чистом виде не существует, но релевантные позиции содержит постановление Пленума ВС РФ от 23.06.2015 № 25 о применении общих положений Гражданского кодекса. Применительно к DPA важен пункт о добросовестности участников гражданского оборота: обработчик не вправе ссылаться на буквальные пробелы DPA, если из его поведения было видно намерение получить экономическую выгоду от использования данных за пределами поручения оператора.

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

Типичные ошибки при составлении DPA

Первая ошибка — использование шаблона европейского DPA без адаптации к 152-ФЗ. Терминология GDPR (controller, processor, sub-processor, joint controller, data subject rights) частично пересекается с российской, но имеет иной правовой режим. Прямой перевод приводит к появлению в документе условий, не имеющих юридической силы в России (например, ссылки на стандартные договорные условия Еврокомиссии — Standard Contractual Clauses), и одновременно — к пропуску ключевых российских требований (локализация, уведомление в 24 часа, регистрация в реестре операторов).

Вторая ошибка — отсутствие конкретного перечня обрабатываемых данных и категорий субъектов. Формулировка «персональные данные, передаваемые Оператором» без перечисления категорий не позволяет проверить соблюдение принципа адекватности и провоцирует Роскомнадзор на квалификацию как избыточной обработки.

Третья ошибка — недостаточный режим уведомления об инцидентах. Срок «незамедлительно» без указания конкретной длительности и без обязанности раскрывать минимально необходимый объём сведений делает условие неэффективным. С учётом 24-часового режима в статье 21 152-ФЗ корректный срок уведомления оператора обработчиком — 6–12 часов с момента выявления инцидента.

Четвёртая ошибка — попытка ограничить ответственность обработчика суммой, несоразмерной возможному ущербу. Штрафы Роскомнадзора по статье 13.11 КоАП РФ исчисляются десятками миллионов рублей, а с 2025 года — процентами от выручки оператора. Ограничение ответственности обработчика стоимостью услуг за 3 месяца в этих условиях не защищает оператора от риска.

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

Заключение

DPA в российской юрисдикции — это не формальный документ, который можно скопировать у иностранного партнёра и перевести на русский. Это рабочий инструмент управления рисками в передаче персональных данных, опирающийся на императивные требования 152-ФЗ, постановления Правительства РФ № 1119, приказа ФСТЭК № 21, статьи 13.11 КоАП РФ в действующей редакции. Грамотный DPA содержит конкретный перечень действий и категорий данных, фиксирует уровень защищённости и меры защиты, выстраивает регрессную цепочку ответственности, устанавливает быстрый режим уведомления об инцидентах, регулирует субобработчиков и судьбу данных при прекращении отношений. Цена ошибки — административные штрафы оператора, гражданские иски субъектов, репутационный ущерб; цена грамотного DPA — несколько часов работы юриста и значительное снижение операционных рисков.