Поручение обработки облачному провайдеру

С 01.07.2025 требования локализации персональных данных ужесточены: первичная запись, систематизация, накопление и хранение ПДн граждан России должны вестись исключительно на серверах в РФ (ч. 5 ст. 18 ФЗ-152, ФЗ-233). Для CTO это означает пересмотр инфраструктуры: Salesforce, AWS, Google Cloud, HubSpot — всё под вопросом, если данные россиян попадают на зарубежные серверы до их первичной записи в российскую базу. Параллельно с 30.05.2025 введены оборотные штрафы за утечки. Ниже — анализ правовой конструкции поручения, требований к облаку по уровням защищённости и практические сценарии для IT-команды.

Что такое поручение обработки по 152-ФЗ и чем оно отличается от передачи данных?

Поручение обработки персональных данных регулируется п. 3 ст. 6 ФЗ-152. Оператор вправе поручить обработку ПДн другому лицу — в том числе облачному провайдеру — на основании договора. Существенные условия такого договора: перечень разрешённых действий с ПДн, цели обработки, запрет на передачу данных третьим лицам без согласия оператора, обязанность обеспечивать конфиденциальность и безопасность по ст. 19 ФЗ-152.

Ключевое различие между поручением и передачей данных: при поручении провайдер действует строго в рамках инструкций оператора и не определяет цели обработки. Если провайдер самостоятельно определяет цели — он становится оператором со всеми вытекающими обязанностями. Это важно при использовании SaaS-платформ: когда вендор аналитики, CRM или ML-платформы обрабатывает данные для своих целей (улучшение модели, обучение алгоритмов на ваших данных), он действует как самостоятельный оператор, а не обработчик по поручению.

Договор с облачным провайдером должен содержать: перечень операций с ПДн, категории обрабатываемых данных, требования к защите в соответствии с установленным УЗ, обязанность уведомить оператора об инциденте в срок, позволяющий направить уведомление в РКН за 24 часа (ч. 3.1 ст. 21 ФЗ-152), и порядок уничтожения данных по завершении поручения.

Какой уровень защищённости (УЗ) нужен для облака и что требует Приказ ФСТЭК №21?

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

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

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

Обратите внимание на логирование как отдельную проблему. Журналы событий безопасности (группа РСБ, Приказ ФСТЭК №21) содержат IP-адреса, идентификаторы пользователей, метаданные действий — это персональные данные. Хранение логов в облаке без надлежащего договора-поручения означает, что провайдер обрабатывает ПДн без правового основания. Срок хранения логов — от 3 лет по требованиям ФСТЭК.

Как выстроить поручение обработки для мультиарендной SaaS-платформы?

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

Для SaaS-вендора, разрабатывающего продукт с мультиарендностью, правовая архитектура выглядит следующим образом. Клиент SaaS-платформы — оператор ПДн своих пользователей или сотрудников. SaaS-вендор — обработчик по поручению. Если SaaS-вендор использует субподрядчиков (суб-процессоры) — например, облачную инфраструктуру AWS или Yandex Cloud — он обязан либо включить их в договор-поручение с клиентом, либо получить отдельное согласие клиента на привлечение субпроцессора. Принцип ответственности оператора за действия подрядчика подтверждён судебной практикой.

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

Можно ли использовать иностранные облака после ужесточения локализации?

С 01.07.2025 (ФЗ-233) ужесточены требования ч. 5 ст. 18 ФЗ-152: первичная запись, систематизация, накопление, хранение, уточнение и извлечение ПДн граждан РФ должны осуществляться исключительно в базах данных на территории России. Это означает: если ваш облачный провайдер — AWS (регион eu-west), Google Cloud (регион europe-west), Microsoft Azure (регион northeurope) — и данные россиян попадают туда первично, это нарушение.

Практические варианты для CTO при работе с иностранными облаками. Первый — гибридная схема: первичная запись и хранение в российском облаке (Yandex Cloud, VK Cloud, SberCloud, отечественные ЦОД), репликация обезличенных или агрегированных данных — в иностранное. Второй — перевод инфраструктуры на российских провайдеров. Третий — использование иностранного вендора, имеющего точку присутствия в РФ и обрабатывающего данные россиян в российском регионе (если таковой имеется и подтверждён DPA). Что недопустимо: использовать иностранное облако как основное хранилище ПДн граждан РФ без российского «зеркала» — это прямое нарушение ч. 5 ст. 18.

Типовые сценарии и правовые риски

Сценарий 1. SaaS без договора-поручения. Компания использует CRM на облачной платформе (российский провайдер). Данные клиентов — имена, телефоны, адреса — хранятся у провайдера. Договор на услуги подписан, но без раздела о поручении обработки ПДн. При плановой проверке РКН инспектор запрашивает договоры с обработчиками — документ отсутствует. Нарушение квалифицируется по ч. 1 ст. 13.11 (150–300 тыс. ₽). Если одновременно отсутствует политика конфиденциальности — плюс ч. 3 ст. 13.11 (30–60 тыс. ₽). Стратегия: заключить дополнительное соглашение с провайдером, содержащее все обязательные условия п. 3 ст. 6 ФЗ-152, до проверки.

Сценарий 2. Утечка данных через облачного субпроцессора. Компания — оператор ПДн работников (5 000 человек: имена, СНИЛС, паспортные данные). Данные хранятся в российском облаке. Облачный провайдер использует субподрядчика для резервного копирования — без уведомления оператора. Субподрядчик допускает утечку. По судебной практике оператор несёт ответственность за действия обработчика вне зависимости от наличия субподрядного договора у провайдера. Квалификация: ч. 13 ст. 13.11 (5–10 млн ₽, от 10 000 субъектов). Дополнительно — ч. 11 ст. 13.11, если уведомление в РКН направлено позже 24 часов (1–3 млн ₽). Стратегия: включить в договор-поручение запрет на привлечение субпроцессоров без письменного согласия оператора.

Сценарий 3. ML-обучение на ПДн клиентов без обезличивания. EdTech-платформа обучает рекомендательную модель на данных пользователей (поведенческие паттерны + email + возраст). Данные не обезличены, цель обработки в согласии — «предоставление образовательных услуг». Использование данных для обучения ML — новая цель, несовместимая с первоначальной (ст. 5 ФЗ-152). РКН вправе возбудить дело по ч. 1 ст. 13.11. Если данные обезличены по 5 методам Приказа РКН до передачи в ML-пайплайн — обработка выходит из-под режима 152-ФЗ. Стратегия: внедрить обезличивание на входе в ML-пайплайн, зафиксировать методы в технической документации и ОРД.

Как это применяется на практике

Кейс 1. IT-компания (Центральный ФО, осень 2025) мигрировала CRM с иностранного облака на российского провайдера в рамках подготовки к проверке РКН. В ходе аудита выявлено: провайдер привлекал субпроцессора для CDN-кэширования без уведомления компании. Данные касались около 15 000 клиентов (ФИО, email, телефоны). Компания заключила договор-поручение с надлежащими условиями и получила от провайдера подтверждение соответствия УЗ-3. Проверка РКН прошла без предписаний. Документальная база позволила закрыть все вопросы инспектора на месте.

Кейс 2. SaaS-вендор (Северо-Западный ФО, начало 2026) использовал ML-модель, обученную на данных клиентов без обезличивания. После аудита выявлено нарушение ст. 5 ФЗ-152 (несовместимость целей). Компания внедрила обезличивание методом введения псевдонимов (метод 1 по Приказу РКН) и методом агрегации (метод 5) перед передачей данных в обучающий датасет. В ОРД добавлен регламент обезличивания для ML. По итогам повторного аудита нарушений не выявлено.

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

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

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

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

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

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

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

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

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

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

В мультиарендной SaaS оператором является клиент платформы — именно он определяет цели и состав обрабатываемых ПДн. SaaS-вендор — обработчик по поручению по п. 3 ст. 6 ФЗ-152. Если вендор обрабатывает данные клиентов для собственных целей (аналитика, обучение моделей, улучшение продукта) — он становится самостоятельным оператором и обязан получить отдельное согласие субъектов. Это требует пересмотра пользовательского соглашения и политики конфиденциальности.

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

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

Итог

Поручение обработки облачному провайдеру — законная схема, но требующая тщательного юридического оформления. Без надлежащего договора-поручения, классификации ИСПДн и разграничения ответственности по Приказу ФСТЭК №21 оператор несёт полную ответственность за любые нарушения на стороне провайдера. С 30.05.2025 цена ошибки — от 3 до 500 млн ₽ в зависимости от масштаба утечки и повторности.

DATUM сопровождает IT-компании и SaaS-вендоров в выстраивании правовой архитектуры облачной обработки ПДн: от классификации ИСПДн и составления договоров-поручений до DPIA и разработки методики обезличивания для ML-пайплайнов.

3 марта 2029 года