Data Processing Agreement (DPA) для SaaS

С 30.05.2025 редакция ст. 13.11 КоАП действует в полном объёме: 18 частей, оборотный штраф, отдельная ответственность за утечку биометрии. Для SaaS-архитектур это означает, что каждый клиент платформы — потенциальный субъект проверки, а каждый облачный сервис без DPA — основание для протокола. Ниже разбор того, что должен содержать корректный DPA для SaaS в рамках 152-ФЗ, как выбрать уровень защищённости и что делать с обезличиванием данных для ML.

Что обязательно включить в DPA по российскому праву?

Поручение обработки персональных данных регулируется п. 3 ст. 6 ФЗ-152. Оператор вправе поручить обработку третьему лицу — обработчику — только при соблюдении ряда условий: наличие договора или государственного (муниципального) задания, фиксированный перечень действий, цели обработки, обязанности по конфиденциальности и обеспечению безопасности. Если хотя бы одно из условий отсутствует — обработка обработчиком считается неправомерной со всеми последствиями по ч. 1 ст. 13.11 КоАП.

На практике DPA для SaaS должен содержать следующие обязательные разделы:

• Предмет и стороны. Явное указание: кто оператор, кто обработчик, какой продукт является ИСПДн. При мультиарендной архитектуре (multi-tenant) — отдельный раздел о разграничении данных разных операторов.
• Перечень ПДн и действий. Конкретные категории данных (общие, специальные, биометрические) и исчерпывающий перечень операций: сбор, хранение, передача, извлечение, уничтожение. Размытые формулировки «иные действия» — основание для претензий РКН.
• Цели обработки. Должны совпадать с целями, указанными оператором при уведомлении РКН по ст. 22 ФЗ-152. Расширение целей обработчиком — нарушение ст. 5 ФЗ-152 (принцип целевого ограничения).
• Меры безопасности. Ссылка на уровень защищённости по ПП РФ №1119 и обязанность обработчика выполнять меры Приказа ФСТЭК №21. В облачном SaaS — обязанность держать данные в дата-центрах на территории РФ (ч. 5 ст. 18 ФЗ-152).
• Субподряд и субобработчики. Условие об обязательном согласовании оператором любой передачи данных субобработчику. По позиции судов, оператор несёт полную ответственность за утечку через подрядчика — независимо от наличия регрессного иска.
• Уничтожение по истечении целей. Срок и способ уничтожения (или обезличивания) после завершения договора — ст. 21 ФЗ-152.

Как выбрать уровень защищённости (УЗ) для SaaS-платформы?

Уровень защищённости информационной системы персональных данных (ИСПДн) определяется по ПП РФ №1119 от 01.11.2012. Матрица: категория ПДн × тип угроз × число субъектов. Для SaaS существенны три параметра.

Категории данных. Общие ПДн (имя, email, телефон) — ниже по шкале. Специальные (здоровье, судимость, политические взгляды по ст. 10 ФЗ-152) и биометрические (по ст. 11) — требуют УЗ-3 или выше даже при небольшом числе субъектов. Если SaaS обрабатывает данные пациентов, финансовые профили с биометрической аутентификацией — это УЗ-2 или УЗ-1.

Тип угроз. Угрозы 1-го типа (актуальны НДВ в системном ПО) — крайне редко применимы к коммерческому SaaS. Угрозы 2-го типа (НДВ в прикладном ПО) — чаще всего актуальны для платформ с открытым API и сторонними плагинами. Угрозы 3-го типа — базовый сценарий для большинства SaaS.

Число субъектов. Порог 100 000 — ключевой по ПП РФ №1119. SaaS с аудиторией выше порога и общими ПДн при угрозах 3-го типа — УЗ-3. Ниже порога — УЗ-4. Специальные ПДн — минимум УЗ-3 вне зависимости от числа субъектов.

Практически важно: оператор обязан зафиксировать УЗ в модели угроз и техническом паспорте ИСПДн. При проверке РКН инспектор запрашивает этот документ первым. Отсутствие модели угроз — типовое нарушение по ч. 1 ст. 13.11 в части несоблюдения требований к мерам безопасности. Для SaaS-обработчика обязанность составить модель угроз должна быть прямо закреплена в DPA.

Меры защиты по каждому УЗ определяются Приказом ФСТЭК №21 от 18.02.2013. Базовый набор включает 15 групп мер (идентификация и аутентификация — ИАФ, управление доступом — УПД, регистрация событий — РСБ, антивирусная защита — АВЗ, обнаружение вторжений — СОВ и др.). Для УЗ-3 обязательно применение сертифицированных СЗИ по классу не ниже КС1 (КИИ — отдельно по 187-ФЗ). Конкретный выбор СЗИ фиксируется в техническом проекте.

Облако в РФ: требования локализации и трансграничной передачи

С 01.09.2015 действует требование локализации: запись, систематизация, накопление, хранение, уточнение и извлечение ПДн граждан РФ должны происходить в базах данных, физически расположенных на территории РФ (ч. 5 ст. 18 ФЗ-152). Для SaaS это означает: если платформа арендует инфраструктуру в зарубежных облаках (AWS eu-west, GCP europe-west, Azure) и первично записывает данные российских пользователей туда — нарушение.

Штраф за нарушение локализации по ч. 8 ст. 13.11 КоАП — 1–6 млн ₽. При повторном нарушении (ч. 9) — 6–18 млн ₽. В 2025 году РКН усилил контроль: по данным регулятора, число проверок по локализации выросло по сравнению с 2023 годом.

Трансграничная передача — отдельный вопрос. Передача данных за рубеж после первичной записи в РФ допустима, если страна назначения включена в перечень адекватной защиты по приказу РКН или оформлено уведомление о трансграничной передаче по ст. 12 ФЗ-152. Большинство популярных SaaS-инструментов (аналитика, CRM, поддержка) передают данные в ЕС или США — страны с адекватной защитой ЕС признаются таковыми по актуальному перечню, США — нет. Это означает: для Salesforce, HubSpot, Zendesk, размещённых без российского региона, требуется либо переход на российский экземпляр, либо уведомление РКН о трансграничной передаче с оценкой рисков.

В DPA для SaaS-обработчика необходимо прямо указать: физическое расположение дата-центров, условия хранения бэкапов, запрет на репликацию в юрисдикции без согласования с оператором.

Как применяются сценарии обработки в мультиарендной SaaS?

Мультиарендная архитектура (multi-tenant) порождает нетривиальный вопрос: кто является оператором — платформа или каждый клиент-арендатор? Ответ зависит от цели и контроля над данными.

Сценарий 1 — SaaS как обработчик. Клиент (компания-арендатор) собирает ПДн своих пользователей, определяет цели и средства обработки. SaaS-платформа только хранит и обрабатывает данные по инструкции клиента. В этой модели клиент — оператор, платформа — обработчик. DPA обязателен. Платформа не вправе использовать данные для собственных целей (в том числе обучения ML-моделей) без отдельного согласия субъекта или оператора-клиента.

Сценарий 2 — SaaS как самостоятельный оператор. Платформа собирает ПДн пользователей в собственных целях (аналитика, улучшение продукта, монетизация). Платформа сама уведомляет РКН по ст. 22 ФЗ-152, публикует политику обработки ПДн по ст. 18.1, обеспечивает соблюдение прав субъектов по ст. 20. Клиент-арендатор здесь — лишь пользователь продукта, не соопределяющий цели.

Сценарий 3 — совместные операторы. Платформа и клиент совместно определяют цели: например, CRM-система, где и вендор, и клиент получают агрегированную аналитику по одной базе. В этом случае оба должны быть включены в уведомление РКН, DPA дополняется соглашением о распределении обязанностей — кто отвечает на запросы субъектов, кто несёт ответственность за безопасность, как разграничены права уничтожения. Отсутствие такого распределения при проверке — основание для протокола сразу к обоим.

Обезличивание ПДн для ML: что требует российское право?

Обучение ML-моделей на персональных данных без обезличивания — обработка ПДн, требующая правового основания по ст. 6 ФЗ-152. Если согласие субъекта не предполагает использование его данных для обучения моделей — это нарушение принципа целевого ограничения по ст. 5 ФЗ-152.

С 2025 года регулирование обезличенных ПДн введено ст. 13.1 ФЗ-152 (ФЗ-233 от 08.08.2024). Методы обезличивания установлены отдельным приказом РКН: введение идентификаторов, изменение состава и семантики, декомпозиция, перемешивание, обобщение и агрегация. Для обучения ML на данных клиентов SaaS-платформы корректный путь — применение одного или нескольких методов до передачи данных в тренировочный пайплайн.

В DPA для ML-сценариев необходимо прямо указать: разрешается ли обработчику использовать данные для обучения моделей, какой метод обезличивания применяется, на каком этапе пайплайна данные считаются обезличенными, кто верифицирует необратимость обезличивания. Практика: лог-файлы с идентификаторами пользователей до обезличивания — это ПДн, и они требуют защиты по выбранному УЗ. Логирование как источник ПДн — отдельный риск для SaaS: если в логах есть IP-адреса, cookie-идентификаторы или user-agent в связке с аутентифицированной сессией, РКН квалифицирует это как обработку ПДн без надлежащего правового основания.

Как применяется DPA в реальной практике

Кейс 1. IT-компания (Центральный ФО, начало 2026 года) предоставляла B2B SaaS для HR-автоматизации. Клиенты — около 40 корпоративных заказчиков, в совокупности более 120 000 субъектов ПДн работников. При внеплановой проверке РКН выяснилось: договоры с клиентами не содержали условий поручения обработки по п. 3 ст. 6 ФЗ-152, модель угроз отсутствовала, УЗ не определён. Компании предъявлены протоколы по ч. 1 и ч. 8 ст. 13.11 КоАП. Штрафы в совокупности составили сотни тысяч рублей; дополнительно выдано предписание об устранении нарушений в 30 дней. Исход: компания в ускоренном режиме формировала ОРД и переконфигурировала инфраструктуру под локализацию. Судебная процедура обжалования результата не принесла — нарушения были очевидны из документов.

Кейс 2. Платформа машинного обучения (Северо-Западный ФО, осень 2025 года) обучала модели на данных пользователей без обезличивания. По жалобе одного из клиентов-операторов РКН провёл проверку. Обработчик не мог предоставить ни модель угроз, ни технический регламент по методам обезличивания — документов не существовало. Дело передано по ч. 1 ст. 13.11 КоАП; дополнительно рассматривался вопрос квалификации по ст. 272.1 УК РФ (незаконное использование компьютерной информации с ПДн, действует с 11.12.2024). Стратегия защиты строилась на доказательстве отсутствия умысла и оперативном внедрении методов обезличивания — это позволило ограничить ответственность административным составом.

Услуги DATUM по теме

• Аудит соответствия 152-ФЗ — проверка DPA, модели угроз, ОРД и инфраструктуры SaaS по 38 пунктам
• DPIA (оценка воздействия) — обязательна при высокорисковой обработке, ML, биометрии
• Комплект ОРД под ключ — политика, DPA-шаблон, приказы, регламент реагирования на инциденты

Частые вопросы

1. Какой УЗ выбрать для SaaS?

Зависит от трёх параметров по ПП РФ №1119: категория ПДн (общие, специальные, биометрические), актуальный тип угроз (1–3) и число субъектов (порог 100 000). Большинство B2B SaaS с общими ПДн и угрозами 3-го типа попадают в УЗ-3 при аудитории свыше 100 000 субъектов или в УЗ-4 при меньшей аудитории. Если платформа обрабатывает медицинские, биометрические данные или данные о судимостях — минимум УЗ-3 вне зависимости от числа субъектов. УЗ нужно зафиксировать в модели угроз и техническом паспорте ИСПДн.

2. Можно ли использовать иностранные облака?

Первичная запись, систематизация и хранение ПДн граждан РФ должны происходить в базах на территории РФ (ч. 5 ст. 18 ФЗ-152). Использовать иностранное облако для первичного сбора — нарушение, штраф 1–6 млн ₽ по ч. 8 ст. 13.11 КоАП. Репликация после первичной записи в РФ возможна, но при передаче в страны без адекватной защиты требует уведомления РКН по ст. 12 ФЗ-152. США не входят в перечень адекватной защиты — передача данных в AWS us-east или GCP us-central без уведомления РКН незаконна.

3. Что такое обезличивание для ML?

Обезличивание — приведение ПДн к форме, при которой невозможно без дополнительной информации установить принадлежность данных конкретному субъекту (ст. 3 ФЗ-152). Для ML применяются 5 методов по приказу РКН: введение идентификаторов, изменение состава и семантики, декомпозиция, перемешивание, обобщение и агрегация. Только необратимо обезличенные данные выходят из-под требований ФЗ-152. Если модель способна де-анонимизировать субъекта — обезличивание считается ненадлежащим и данные остаются ПДн с полным набором требований по безопасности.

4. Кто оператор в мультиарендной SaaS?

Роль зависит от того, кто определяет цели и средства обработки. Если клиент-арендатор определяет цели — он оператор, платформа — обработчик, DPA обязателен по п. 3 ст. 6 ФЗ-152. Если платформа самостоятельно определяет цели обработки (аналитика, улучшение продукта) — она оператор и обязана уведомить РКН по ст. 22 ФЗ-152 самостоятельно. При совместном определении целей оба субъекта — операторы, что требует соглашения о распределении обязанностей и совместного уведомления РКН.

5. Какие СЗИ обязательны?

Конкретный набор зависит от УЗ и актуальных угроз по модели, разработанной в соответствии с Приказом ФСТЭК №21 от 18.02.2013. Базовый набор для УЗ-3: средства идентификации и аутентификации (МФА), управление доступом (RBAC/ABAC), регистрация событий безопасности (SIEM), антивирусная защита, средства обнаружения вторжений. При угрозах 1–2-го типа — сертифицированные по ФСТЭК СЗИ (класс КС1 и выше). Для объектов КИИ дополнительно применяются требования ФЗ-187 о защите критической информационной инфраструктуры.

Итог

DPA для SaaS — не формальность и не документ «для галочки». Это техническая и правовая основа, без которой SaaS-платформа несёт ответственность за чужие данные без договорной защиты, а оператор-заказчик — за чужую инфраструктуру без контроля. С 30.05.2025 ст. 13.11 КоАП в полной редакции: нарушение локализации — до 6 млн ₽, утечка через подрядчика при повторности — оборотный штраф от 20 млн ₽, незаконное использование данных для ML — потенциально ст. 272.1 УК РФ.

Практика DATUM включает сопровождение SaaS-компаний по всему циклу: от квалификации роли (оператор/обработчик) и разработки DPA до определения УЗ, внедрения мер по Приказу ФСТЭК №21 и сопровождения при проверках РКН. Специализация аналитика по технологиям и ИБ — архитектурные решения, модели угроз, логирование и обезличивание для ML.

28 февраля 2027 года