Договор с облачным провайдером: 7 условий

С 30.05.2025 ст. 13.11 КоАП действует в редакции ФЗ-420: 18 частей, оборотный штраф при повторной утечке до 500 млн ₽. Для технического директора SaaS или инфраструктурной команды это означает, что договор с облачным провайдером перестал быть формальностью. Ниже — семь условий, которые должны быть в документе, чтобы оператор мог доказать выполнение требований ст. 6, ст. 19 ФЗ-152 и Приказа ФСТЭК №21 от 18.02.2013.

Почему поручение обработки ПДн — не просто строчка в договоре?

Статья 6 ч. 3 ФЗ-152 разрешает оператору передавать обработку персональных данных третьей стороне только при наличии письменного договора или акта. Провайдер в таком договоре принимает обязанность соблюдать принципы и правила обработки, установленные ФЗ-152. Без этого условия юридически обработка ПДн в облаке происходит без правового основания — нарушение ч. 1 ст. 13.11 КоАП.

Важен и принцип субподряда: если облачный провайдер привлекает для хранения данных субподрядчика (например, CDN или резервный ЦОД), оператор отвечает за действия этого субподрядчика перед субъектами ПДн. Судебная практика ВС РФ подтверждает: оператор несёт ответственность за утечку через подрядчика в полном объёме. Это нужно прямо отразить в договоре — через запрет субпоручения без согласия оператора или обязательное согласование субподрядчиков.

На практике CTO встречает три типичные ситуации: (1) договор с облаком есть, но в нём нет раздела о ПДн; (2) раздел есть, но не перечислены категории ПДн и цели обработки; (3) договор подписан, однако провайдер размещает данные в дата-центре за рубежом без уведомления РКН по ст. 12 ФЗ-152. Все три сценария создают нарушение.

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

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

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

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

Что должно быть в договоре о локализации, KII и трансграничной передаче?

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

Если провайдер является субъектом критической информационной инфраструктуры (КИИ) по 187-ФЗ или ваш SaaS обрабатывает данные в системе, отнесённой к КИИ, — в договоре нужны отдельные условия о соответствии требованиям безопасности КИИ: реагирование на компьютерные инциденты, взаимодействие с ГосСОПКА, ограничение на использование иностранных технических средств при определённых категориях значимости.

Для мультиарендной SaaS (multi-tenant) принципиальный вопрос — сегрегация данных арендаторов. Договор должен описывать механизм изоляции данных клиентов, порядок удаления данных при расторжении и гарантии, что данные одного клиента недоступны другому. Роль оператора в мультиарендной SaaS двоякая: SaaS-компания — оператор для своих клиентов; каждый клиент — самостоятельный оператор для своих пользователей. Это разграничение нужно отразить в договоре явно.

Обезличивание данных для ML и логирование: как прописать в договоре?

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

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

Для ML-пайплайнов практически важно включить в договор: (1) обязанность провайдера не использовать данные клиента для обучения общих моделей без явного согласия; (2) порядок уведомления об изменениях в архитектуре, влияющих на изоляцию данных; (3) запрет на передачу обезличенных данных в ЕНИП НСУД без согласования с оператором (применимо при наличии требований ФЗ-233).

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

Кейс 1. IT-компания (Сибирский ФО, лето 2025) использовала европейского облачного провайдера для хранения аналитических данных SaaS-платформы. В договоре отсутствовал раздел о поручении обработки ПДн и не был указан адрес ЦОД. Внеплановая проверка РКН выявила нарушение ч. 5 ст. 18 ФЗ-152 (локализация) и отсутствие надлежащего договора по ст. 6 ч. 3. Технический директор был привлечён к административной ответственности как должностное лицо; юридическое лицо получило предписание устранить нарушения в течение 30 дней. После привлечения юристов и перезаключения договора с российским провайдером дело закончилось предупреждением по ст. 4.1.1 КоАП — компания являлась микропредприятием и нарушение было первичным.

Кейс 2. Финтех-стартап (Центральный ФО, конец 2025) обрабатывал скоринговые данные клиентов в облачной инфраструктуре без явного указания УЗ в договоре с провайдером. При утечке через уязвимость в API скоринговой модели затронуто около 8 000 субъектов. Оператор уведомил РКН в течение 20 часов — срок 24 ч соблюдён. Однако в 72-часовом отчёте не удалось подтвердить реализацию мер по Приказу ФСТЭК №21, поскольку договор с провайдером не содержал конкретного перечня применённых мер защиты. Штраф составил несколько миллионов рублей по ч. 12 ст. 13.11 КоАП (утечка 1 000–10 000 субъектов). Арбитражный суд региона снизил штраф до минимума диапазона с учётом оперативного уведомления и последующего устранения нарушений.

Семь условий: чек-лист для договора с облачным провайдером

Седьмое условие — право аудита: оператор вправе проверить соответствие провайдера требованиям договора не реже одного раза в год, в том числе с привлечением независимого аудитора. Без этого пункта оператор лишён инструмента контроля, а провайдер — стимула поддерживать заявленный УЗ.

Типовые сценарии: когда отсутствие условий приводит к нарушению

Сценарий 1. Мигрируете в облако без DPIA. Ситуация: SaaS-компания переводит 500 000 профилей пользователей в нового облачного провайдера. Договор подписан, но без указания УЗ и мер защиты. Доказательства: нет документа об установлении уровня защищённости, нет перечня применённых мер по Приказу ФСТЭК №21. Вероятный исход при проверке: нарушение ч. 1 ст. 13.11 (обработка без надлежащих условий) + предписание. Стратегия: до миграции — DPIA, установление УЗ-3 или УЗ-2 (более 100 000 субъектов, иные ПДн, угрозы второго типа), внесение соответствующего раздела в договор.

Сценарий 2. Провайдер делает бэкап в зарубежный ЦОД. Ситуация: в договоре указано «хранение в РФ», но типовой SLA провайдера предусматривает резервное копирование в европейский регион без отдельного уведомления клиента. Доказательства: технический регламент провайдера, в котором упоминается EU-регион. Вероятный исход: нарушение ч. 5 ст. 18 ФЗ-152 (локализация), ч. 8 ст. 13.11 КоАП — от 1 до 6 млн ₽. Стратегия: добавить в договор явный запрет на размещение ПДн граждан РФ за пределами РФ, включая резервные копии; ежеквартальное подтверждение соответствия.

Сценарий 3. Утечка через субподрядчика провайдера. Ситуация: провайдер использует сторонний сервис мониторинга, у которого произошла утечка. В договоре с провайдером нет условия об ответственности за субподрядчиков. Доказательства: принцип ВС РФ — оператор отвечает за действия всей цепочки обработчиков. Вероятный исход: ч. 12–14 ст. 13.11 (в зависимости от числа затронутых субъектов), от 3 до 15 млн ₽. Стратегия: включить в договор запрет на субпоручение без письменного согласия оператора и право на расторжение при несанкционированном субподряде.

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

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

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

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

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

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

Иностранные облака можно использовать для операций, не входящих в перечень ч. 5 ст. 18 ФЗ-152: запись, систематизация, накопление, хранение, уточнение, извлечение ПДн граждан РФ должны происходить в РФ. Зарубежная передача (трансграничная) для иных целей допустима при уведомлении РКН по ст. 12 ФЗ-152 и соблюдении условий. Практически: первичная база данных — в российском ЦОД, зарубежный регион — только для данных, не включающих ПДн граждан РФ, или после надлежащего уведомления. С 01.07.2025 требования к локализации ужесточены ФЗ-233.

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

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

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

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

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

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

Итог

Договор с облачным провайдером — юридически значимый документ, а не технический SLA. Семь обязательных условий (поручение по ст. 6 ч. 3 ФЗ-152, УЗ и меры по ПП РФ №1119 и Приказу ФСТЭК №21, локализация по ч. 5 ст. 18 ФЗ-152, уведомление об инциденте за 12 часов, обезличивание для ML, порядок логирования, право аудита) — минимальный набор, без которого оператор остаётся незащищённым при любой проверке РКН или инциденте через облачную инфраструктуру.

Команда DATUM сопровождает IT-компании и SaaS-провайдеров в части соответствия 152-ФЗ: от установления УЗ и составления договоров-поручений до DPIA и подготовки к проверкам РКН. Специализация — техническая сторона 152-ФЗ: Приказ ФСТЭК №21, обезличивание для ML, мультиарендные архитектуры.