ПДн в облаке (SaaS/IaaS): как оценить риски и оформить отношения с провайдером

Полное руководство для компаний, которые хранят персональные данные не у себя, а в чужой инфраструктуре

Почему облако стало полем битвы за персональные данные

Облако давно перестало быть привилегией стартапов. CRM в SaaS, корпоративная почта на IaaS-хостинге, 1С в аренду, HR-система у внешнего провайдера — всё это реальность сотен тысяч российских компаний. По оценкам iKS-Consulting, объём российского рынка облачных сервисов в 2024 году достиг 322,3 млрд рублей, показав рост на 32,8%, а к 2030 году рынок прогнозируется на уровне 1,2 трлн рублей [1]. Доля SaaS в структуре рынка уже превышает 60% — выше среднемирового показателя [8].

Параллельно закручивается регуляторная гайка. В 2024 году Роскомнадзор зафиксировал 135 утечек персональных данных, в результате которых в открытый доступ попало более 710 млн записей о россиянах [9]. ЭАЦ ГК InfoWatch насчитал 592 инцидента за тот же год — рост числа компрометаций ПДн на 4% при одновременном росте объёма утечек более чем на 30% [10]. Реакция государства последовала незамедлительно: поправки к ФЗ-152, новые составы административных правонарушений, оборотные штрафы и уголовная ответственность.

Статья адресована широкому кругу специалистов: руководителям ИТ и ИБ, юристам, DPO, а также всем, кто принимает решение о выборе облачного провайдера или уже работает с облачными сервисами и не уверен, соответствует ли эта работа закону в редакции 2025 года.

1. Правовой фундамент: что изменилось в ФЗ-152 и зачем это важно для облака

1.1. Локализация: от нормы к запрету

Требование локализовать базы данных с ПДн граждан РФ на территории России существует с 2015 года (ст. 18 ФЗ-152). Однако до 2025 года формулировка оставляла пространство для интерпретаций. Федеральный закон от 28.02.2025 №23-ФЗ внёс уточнения, вступившие в силу с 1 июля 2025 года: теперь императивно закреплено, что первичная обработка ПДн граждан РФ, включая сбор, запись, систематизацию и хранение, должна происходить только на серверах, физически расположенных в России [3].

Ключевое слово здесь — «первичный сбор». Разъяснения Роскомнадзора от 24.03.2025 №08-134789 и Минцифры от 12.05.2025 №П25-44929 уточнили: требование касается именно процесса сбора, а не последующей обработки. Это означает, что иностранные облачные сервисы не запрещены как таковые — запрещено использовать их для первоначальной записи данных россиян [11].

На практике это влечёт конкретные последствия для облачных решений. Форма обратной связи на сайте, подключённая к иностранной CRM, — нарушение. Файл передачи данных из российской базы в зарубежный аналитический SaaS (при надлежащем согласии и уведомлении) — допустимо. Google Analytics с прямой отправкой данных на серверы США в момент заполнения формы — нарушение [12].

1.2. Штрафная реальность 2025 года

Федеральный закон №420-ФЗ от 30.11.2024, вступивший в силу 30 мая 2025 года, кардинально изменил ценовой сигнал для нарушителей [4]. Ключевые параметры новой ответственности:

1. За неуведомление о начале обработки ПДн — от 100 до 300 тыс. рублей для юридических лиц.
2. За неуведомление об утечке — от 1 до 3 млн рублей.
3. За нарушение требования о локализации — от 1 до 6 млн рублей за первое нарушение и от 6 до 18 млн рублей за повторное [12].
4. За повторную утечку ПДн — оборотный штраф от 1 до 3% годовой выручки компании, но не менее 20 млн рублей и не более 500 млн рублей [4].

Уголовная ответственность введена статьёй 272.1 УК РФ (ФЗ №421-ФЗ, вступил в силу 11 декабря 2024 года) — за незаконные действия с ПДн, с отягчающими обстоятельствами для биометрических данных [13].

1.3. Кто несёт ответственность в облачной схеме

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

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

1.4. Согласие на обработку с 1 сентября 2025 года

Поправки к ст. 9 ФЗ-152 требуют оформлять согласие на обработку персональных данных как самостоятельный документ, не объединённый с другими [14]. Встроенный абзац в пользовательском соглашении или pre-checked чекбокс при регистрации больше не годятся. Штраф за нарушение — от 300 до 700 тыс. рублей для организаций.

Это напрямую затрагивает SaaS-операторов и интеграции: если ваш сервис передаёт ПДн в облачную CRM или аналитическую систему, согласие пользователя на такую передачу теперь должно быть явным и отдельным документом.

2. Облачные модели и ПДн: что именно вы передаёте и куда

2.1. IaaS, PaaS, SaaS: разная степень контроля

Облако — не монолит. В зависимости от модели потребления компания имеет разный уровень контроля над данными и разную глубину разделения ответственности с провайдером.

В модели IaaS (инфраструктура как услуга) компания арендует вычислительные мощности и сама управляет операционной системой, базами данных, приложениями и данными. Провайдер отвечает за физическую безопасность, доступность, виртуализацию. Риски ПДн здесь во многом определяются настройками самой компании.

В модели PaaS (платформа как услуга) провайдер управляет ОС и middleware, компания — приложениями и данными. Зона совместной ответственности шире.

В модели SaaS (программное обеспечение как услуга) компания управляет практически только данными, которые вводит в систему. Вся инфраструктура, приложение, среда выполнения — у провайдера. Это наиболее сложная модель с точки зрения контроля над ПДн, поскольку компания почти не имеет возможности проверить, где именно хранятся данные, как они обрабатываются и защищаются на уровне архитектуры.

2.2. Скрытые каналы передачи ПДн

Очевидные источники риска — это формы сбора данных, CRM, базы клиентов. Но практика показывает, что более опасны скрытые каналы: виджеты обратной связи с иностранным бэкендом, чат-боты на платформах Intercom, Drift и аналогичных, системы аналитики вроде Google Analytics с прямой передачей данных, инструменты A/B-тестирования, отправляющие пользовательские атрибуты за рубеж, корпоративная почта на зарубежном Exchange Online, инструменты HR-аналитики и бухгалтерии в облаке [12].

В 2025 году Роскомнадзор запустил автоматическую проверку сайтов на базе ИИ именно для выявления таких скрытых каналов передачи данных [15].

3. Оценка рисков: как определить уровень защищённости вашей ИСПДн

3.1. ПП РФ №1119 и Приказ ФСТЭК №21: два обязательных документа

Прежде чем передавать ПДн провайдеру, оператор обязан определить уровень защищённости своей информационной системы персональных данных (ИСПДн). Это требование Постановления Правительства РФ от 01.11.2012 №1119 [7].

Существуют четыре уровня защищённости — от УЗ-4 (наименее строгий) до УЗ-1 (самый требовательный). Уровень определяется на основании трёх параметров:

1. Категория обрабатываемых ПДн (специальные, биометрические, общедоступные, иные).
2. Объём обрабатываемых ПДн (количество субъектов, их принадлежность — сотрудники или третьи лица).
3. Тип актуальных угроз безопасности (три типа угроз по ПП №1119).

Три типа угроз по классификации ФСТЭК:

1. Угрозы первого типа — связаны с недокументированными возможностями в системном программном обеспечении.
2. Угрозы второго типа — связаны с недокументированными возможностями в прикладном программном обеспечении.
3. Угрозы третьего типа — не связаны с недокументированными возможностями в ПО [16].

На практике большинство коммерческих операторов принимают актуальными угрозы третьего типа — это наименее ограничительный вариант, позволяющий разместить ИСПДн в стандартном облаке без требований к аттестации.

Приказ ФСТЭК №21 от 18.02.2013 (с поправками 2020 года) устанавливает конкретный состав организационных и технических мер для каждого уровня защищённости [17]. Меры охватывают 16 направлений: от идентификации и аутентификации до защиты среды виртуализации и управления конфигурацией. Для облачных ИСПДн особую роль играет группа мер «Защита среды виртуализации» (ЗСВ).

3.2. Модель угроз: обязательный шаг перед выбором провайдера

Методика ФСТЭК 2021 года требует разработки модели угроз для каждой ИСПДн [18]. Это не формальный документ, а аналитический инструмент. Модель угроз должна отвечать на вопросы: кто потенциальный нарушитель, какие уязвимости существуют, какие угрозы актуальны для данной конфигурации системы.

Для облачных систем в модель угроз необходимо включать:

1. Угрозы, специфичные для мультиарендной среды (утечка данных между клиентами одного провайдера).
2. Угрозы со стороны персонала провайдера.
3. Угрозы, связанные с доступностью облачной инфраструктуры.
4. Угрозы, связанные с субподрядчиками провайдера (субпроцессорами).
5. Угрозы трансграничной передачи данных при использовании зарубежных CDN или резервных площадок.

Результат разработки модели угроз напрямую влияет на требования к контракту с провайдером и на технические меры, которые необходимо реализовать.

3.3. Чек-лист: оценка рисков ПДн перед подключением облачного сервиса

Перед тем как передать ПДн любому провайдеру или SaaS-системе, необходимо пройти следующие шаги:

1. Идентифицировать категорию ПДн, которая будет передаваться (обычные, специальные, биометрические).
2. Оценить объём субъектов ПДн, данные которых попадут к провайдеру.
3. Определить, является ли провайдер российским юридическим лицом с инфраструктурой в РФ.
4. Проверить наличие у провайдера аттестата соответствия ФСТЭК (для систем с УЗ-1, УЗ-2, а также для государственных информационных систем).
5. Запросить у провайдера документальное подтверждение физического расположения дата-центров в РФ.
6. Выяснить, использует ли провайдер субподрядчиков (субпроцессоров) и где они расположены.
7. Убедиться, что провайдер готов подписать договор-поручение на обработку ПДн в соответствии с требованиями ст. 6 ФЗ-152.
8. Проверить наличие у провайдера процедур реагирования на инциденты и уведомления оператора в течение 24 часов (ст. 21 ФЗ-152).
9. Оценить риски vendor lock-in: возможно ли извлечь ПДн из системы провайдера при расторжении договора, и в какие сроки провайдер обязуется уничтожить данные.
10. Убедиться, что договор предусматривает право на проверку (аудит) провайдера оператором или уполномоченным третьим лицом.

4. Договор с провайдером: что обязательно должно быть в тексте

4.1. Поручение на обработку ПДн: правовая природа и форма

Статья 6, ч. 3 ФЗ-152 устанавливает: оператор вправе поручить обработку ПДн другому лицу на основании договора. Такой договор в деловом обороте называется «договор-поручение на обработку персональных данных», хотя по природе это может быть как отдельный договор, так и приложение к основному договору на оказание услуг [19]. Закон не требует выделять поручение в самостоятельный документ, однако на практике отдельное приложение удобнее для аудита и проверок.

Без письменного договора-поручения передача ПДн провайдеру является нарушением закона [19]. Это относится ко всем облачным сервисам, которым передаются персональные данные: IaaS-провайдеру, SaaS-CRM, облачной бухгалтерии, HR-системе, системе рассылок.

4.2. Обязательное содержание договора-поручения

Согласно обновлённым требованиям ст. 6 ФЗ-152 (в редакции с учётом последних поправок), в поручении оператора должны быть определены [6]:

1. Перечень персональных данных, передаваемых провайдеру.
2. Перечень конкретных действий (операций) с ПДн, которые провайдер вправе совершать (хранение, систематизация, извлечение — но не продажа, не раскрытие третьим лицам без ведома оператора).
3. Цели обработки.
4. Обязанность провайдера соблюдать конфиденциальность ПДн.
5. Требование обеспечивать безопасность ПДн в соответствии со ст. 19 ФЗ-152.
6. Обязанность провайдера по запросу оператора предоставлять документы, подтверждающие соблюдение требований (в том числе до начала обработки).
7. Требование о локализации — обработка ПДн исключительно на серверах в РФ (ч. 5 ст. 18 ФЗ-152).
8. Обязанность уведомлять оператора об инцидентах в установленные сроки.

4.3. Дополнительные договорные условия, снижающие риски оператора

Помимо законодательного минимума, опыт практики показывает: следующие условия существенно снижают риски оператора при работе с облаком.

1. Запрет на субобработку без предварительного письменного согласия оператора — это исключает ситуацию, когда ваш провайдер молча передаёт данные субподрядчику.
2. Право оператора на аудит провайдера (самостоятельно или через третью сторону) не реже одного раза в год.
3. Точные сроки уничтожения ПДн при расторжении договора (рекомендуется — не позднее 30 дней) с документальным подтверждением.
4. Обязанность провайдера немедленно уведомить оператора при любом требовании со стороны государственных органов на предоставление ПДн.
5. Порядок обработки запросов субъектов ПДн: провайдер должен содействовать оператору в исполнении прав субъектов (доступ, исправление, удаление).
6. Явный запрет на использование ПДн оператора в собственных целях провайдера (включая улучшение продукта, обучение моделей ИИ, аналитику).
7. Требование к провайдеру применять шифрование данных в состоянии покоя и при передаче.
8. Порядок действий при принудительном изменении провайдером условий договора (sanction risk, геополитические риски).

4.4. Трансграничная передача: отдельный правовой режим

Если провайдер или его субподрядчик находится за пределами России, возникает режим трансграничной передачи персональных данных (ст. 12 ФЗ-152). С марта 2023 года в России действует уведомительный порядок такой передачи, который на практике работает как разрешительный [20].

Оценка допустимости трансграничной передачи зависит от юрисдикции получателя. Страны с «адекватным» уровнем защиты перечислены в реестре Роскомнадзора (pd.rkn.gov.ru): туда входят страны ЕАЭС, ОАЭ, Бахрейн, Саудовская Аравия и ряд других [20]. Для передачи данных в страны вне реестра необходимо либо получить письменное согласие субъекта ПДн, либо доказать наличие иного законного основания.

С декабря 2025 года Государственная дума в первом чтении приняла законопроект, расширяющий полномочия Роскомнадзора по ограничению трансграничной передачи: ведомство сможет блокировать передачу данных в конкретные страны на основании оперативной оценки ситуации [21]. Это создаёт дополнительную неопределённость для компаний, работающих с международными SaaS-провайдерами.

5. Технические меры: что должен обеспечить провайдер, а что — вы

5.1. Разделение ответственности в облаке

В мировой практике используется концепция shared responsibility model (модель разделённой ответственности). Применительно к российским требованиям она выглядит следующим образом.

В зоне ответственности провайдера (IaaS): физическая безопасность ЦОД, безопасность гипервизора, сетевая инфраструктура, защита среды виртуализации.

В зоне ответственности оператора (при IaaS): операционная система, СУБД, приложение, настройка прав доступа, шифрование данных, антивирусная защита, аудит событий, резервное копирование.

В модели SaaS зона ответственности провайдера шире — он управляет всем стеком до уровня приложения. Однако ответственность за данные, корректность согласий, управление доступом пользователей — по-прежнему остаётся за оператором.

5.2. Технические требования по Приказу ФСТЭК №21

Для каждого уровня защищённости Приказ ФСТЭК №21 определяет обязательные технические меры [17]. Для наиболее распространённого УЗ-3 ключевые требования включают:

1. Идентификацию и аутентификацию всех пользователей (ИАФ) — включая многофакторную аутентификацию для привилегированных учётных записей.
2. Управление доступом по принципу минимальных привилегий (УПД).
3. Регистрацию событий безопасности с хранением журналов (РСБ).
4. Антивирусную защиту (АВЗ).
5. Контроль (анализ) защищённости — периодические проверки уязвимостей, не реже одного раза в три года (АНЗ).
6. Защиту среды виртуализации (ЗСВ) — особенно актуально для облачных ИСПДн.
7. Выявление инцидентов и реагирование на них (ИНЦ).
8. Управление конфигурацией (УКФ).

Для УЗ-1 и УЗ-2 к этому добавляются требования к аттестации системы защиты ПДн. Проводить аттестацию имеют право лицензиаты ФСТЭК.

5.3. Сертификация и аттестация: когда это нужно

Для государственных информационных систем (ГИС) аттестация по Приказу ФСТЭК №17 является обязательной [16]. Для коммерческих ИСПДн с УЗ-3 и УЗ-4 аттестация не обязательна — достаточно самостоятельной оценки эффективности мер защиты. Ряд российских провайдеров (Selectel, Cloud.ru, Yandex Cloud) предоставляют аттестованные сегменты ЦОД для размещения систем с высокими требованиями к защите.

При выборе провайдера обратите внимание на наличие следующих документов и сертификатов:

1. Аттестат соответствия ФСТЭК (для ГИС и ИСПДн УЗ-1, УЗ-2).
2. Лицензии ФСТЭК на деятельность по технической защите конфиденциальной информации.
3. Лицензии ФСБ на деятельность с шифровальными средствами (при использовании СКЗИ).
4. Сертификаты на средства защиты информации, применяемые в инфраструктуре.
5. SOC 2 Type II или ISO/IEC 27001 (как дополнительный ориентир для международных провайдеров).

6. Типичные ошибки и как их избежать

Анализ практики показывает несколько устойчивых паттернов нарушений при работе с ПДн в облаке.

Ошибка первая: работа без договора-поручения. Компания подключает SaaS-CRM, её сотрудники вводят туда данные клиентов — и никакого договора-поручения нет. Провайдер при этом может находиться в другой юрисдикции. Решение: составить реестр всех систем, получающих ПДн, и по каждой либо подписать договор-поручение, либо принять решение об отказе от системы.

Ошибка вторая: неактуальный реестр операторов в Роскомнадзоре. Компания добавила новую систему обработки ПДн (например, новый HR-сервис), но не обновила уведомление в Роскомнадзоре. Штраф — от 100 до 300 тыс. рублей [4]. Решение: при любых изменениях в составе систем обработки ПДн актуализировать уведомление.

Ошибка третья: неправильно определённый уровень защищённости. Компания занижает класс ИСПДн, чтобы уйти от более строгих требований. При проверке это устанавливается достаточно быстро. Решение: проводить оценку уровня защищённости с участием квалифицированного специалиста по ИБ.

Ошибка четвёртая: иллюзия ответственности провайдера. Распространённое заблуждение: «мы всё передали в облако, теперь это их проблема». Нет. Ответственность перед Роскомнадзором и субъектами ПДн всегда остаётся у оператора [5]. Решение: включить контроль соблюдения провайдером условий договора-поручения в регулярные процессы ИБ-команды.

Ошибка пятая: неучтённые субпроцессоры. Провайдер, которому вы доверяете, сам использует субподрядчиков — CDN-провайдера, облако для резервных копий, сервис мониторинга. Если эти субподрядчики получают ПДн, возникает неконтролируемая цепочка обработки. Решение: требовать от провайдера полного перечня субпроцессоров и права вето на их изменение.

Ошибка шестая: отсутствие плана на случай ухода провайдера. Практика 2022–2023 годов, когда ряд зарубежных облачных провайдеров прекратил работу в России, показала: компании, не имевшие плана миграции и прав на экспорт данных, оказались в крайне уязвимом положении. Суды при этом фиксировали случаи одностороннего изменения условий договора [22]. Решение: прописывать в договоре конкретные сроки и форматы экспорта данных при расторжении.

7. Кейсы и практика

7.1. Иностранное облако: как это выглядит после 1 июля 2025 года

Рассмотрим типичный сценарий: компания использует Salesforce (иностранная CRM) для хранения данных клиентов. До 1 июля 2025 года это было технически возможно при наличии договора-поручения и согласия субъектов. После 1 июля 2025 года — первичный сбор данных через формы, интегрированные напрямую с Salesforce, является нарушением ч. 5 ст. 18 ФЗ-152.

Правомерный вариант: данные с формы сначала попадают в российскую базу (API-эндпоинт на российском сервере), затем синхронизируются с Salesforce. При этом должны быть соблюдены требования к трансграничной передаче: уведомление Роскомнадзора и/или получение явного согласия субъекта [11, 12].

7.2. Российский провайдер: на что смотреть при выборе

На рынке работают несколько крупных российских облачных провайдеров: Cloud.ru, РТК-ЦОД, Yandex Cloud, Selectel, MWS — совместно они занимают около 70% рынка IaaS+PaaS [1]. Выбирая российского провайдера, необходимо проверить:

1. Расположение ЦОД — все дата-центры должны находиться на территории РФ (документарное подтверждение).
2. Наличие лицензий ФСТЭК и ФСБ.
3. Готовность подписать договор-поручение с необходимыми условиями.
4. Наличие сертифицированных средств защиты информации в составе предлагаемой инфраструктуры.
5. Наличие аттестованного сегмента (для систем с повышенными требованиями).
6. Прозрачность в части субпроцессоров и резервных площадок.

7.3. Sanction risk: геополитическое измерение

Судебная практика 2025 года зафиксировала дела, связанные с односторонним расторжением договоров облачных услуг иностранными провайдерами под предлогом санкционных ограничений. Суды квалифицировали такое поведение как незаконное одностороннее изменение существенных условий договора [22]. Для компаний, которые ещё работают с иностранными облачными сервисами, это создаёт риск не только регуляторный, но и операционный: в один день они могут оказаться без доступа к своим данным.

8. Ошибки в договорах: что юристы часто пропускают

Помимо технических нарушений, при работе с ПДн в облаке встречаются юридические пробелы в договорах, которые дорого обходятся при инцидентах.

1. Отсутствие чёткого перечня ПДн — поручение оформлено «на все персональные данные», без конкретного перечня. Это не соответствует требованию определённости из ст. 6 ФЗ-152 и затрудняет доказательство ограниченности доступа провайдера.
2. Размытые сроки уведомления об инцидентах — провайдер обязан уведомить оператора, но в договоре срок не указан. Оператор при этом должен уведомить Роскомнадзор в течение 24 часов [15]. Без чёткого дедлайна со стороны провайдера выполнить это нереально.
3. Отсутствие механизма проверки субпроцессоров — договор разрешает субобработку «в соответствии с применимым законодательством» без идентификации конкретных субпроцессоров.
4. Нет права аудита — типичная позиция провайдеров в стандартных договорах. Без права аудита оператор лишён возможности верифицировать соблюдение требований защиты.
5. Нет положения об уничтожении ПДн — при расторжении договора данные остаются у провайдера на неопределённый срок, что создаёт риски.

9. Будущее и тренды

Несколько векторов, которые будут определять ландшафт ПДн в облаке в ближайшие 1–3 года.

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

Второй вектор — автоматизация надзора. Роскомнадзор уже запустил ИИ-систему автоматической проверки сайтов [15]. Вероятно расширение автоматических инструментов проверки на корпоративный сектор.

Третий вектор — рост рынка частных облаков. Компании, работающие со специальными категориями ПДн или в регулируемых отраслях, всё чаще выбирают private cloud или on-premise, избегая рисков публичной инфраструктуры [8].

Четвёртый вектор — развитие требований к обезличиванию. С 1 сентября 2025 года действует Приказ Роскомнадзора №140 с требованиями к методам обезличивания ПДн [15]. Обезличивание становится одним из ключевых инструментов снижения регуляторных рисков при аналитике данных.

Пятый вектор — уголовная ответственность как реальность. Статья 272.1 УК РФ уже действует. По мере роста правоприменительной практики уголовные дела в сфере ПДн перестанут быть экзотикой.

10. Практический чек-лист: минимум для соответствия требованиям

Ниже — минимально необходимый набор действий для компании, обрабатывающей ПДн в облаке.

Организационные меры:

1. Подать или актуализировать уведомление об обработке ПДн в Роскомнадзоре.
2. Составить реестр всех систем, получающих ПДн (включая SaaS, интеграции, API).
3. Разработать и утвердить политику обработки персональных данных.
4. Определить уровни защищённости для всех ИСПДн (по ПП РФ №1119).
5. Разработать модель угроз безопасности ПДн.
6. Назначить ответственного за организацию обработки ПДн.
7. Оформить согласия на обработку ПДн как отдельные документы (с 1 сентября 2025 года).

Договорные меры:

1. Заключить договор-поручение на обработку ПДн с каждым провайдером, получающим ПДн.
2. Включить в договор конкретный перечень ПДн, действий, целей и сроков.
3. Включить условия о субпроцессорах, праве аудита, уничтожении данных.
4. Проверить соответствие провайдера требованиям локализации.
5. Оформить процедуру трансграничной передачи при её наличии.

Технические меры:

1. Реализовать меры защиты в соответствии с Приказом ФСТЭК №21 для определённого уровня защищённости.
2. Настроить ведение журналов событий безопасности.
3. Внедрить многофакторную аутентификацию для доступа к облачным системам.
4. Настроить шифрование данных в состоянии покоя и при передаче.
5. Разработать план реагирования на инциденты с учётом 24-часового срока уведомления Роскомнадзора.

Процессные меры:

1. Проводить периодические проверки соблюдения требований защиты (не реже одного раза в три года).
2. При подключении каждого нового SaaS или интеграции проходить оценку рисков ПДн.
3. Мониторить изменения в законодательстве и обновлять документацию.

11. «Пятый фактор»: непрерывный контроль ПДн-ландшафта

Все описанные выше меры объединяет одна общая проблема: ИТ-ландшафт компании постоянно меняется. Появляются новые поля в базах данных, новые SaaS-интеграции, новые подрядчики. Ручные аудиты не успевают за этими изменениями — в среднем аудит занимает недели, а новый контур риска может появиться в течение одного рабочего дня после изменения бизнес-процесса.

Именно эту проблему решает платформа «Пятый фактор» — on-premise система для автоматического обнаружения, инвентаризации и контроля персональных данных в корпоративных системах: базах данных, файловых хранилищах, почте, AD/LDAP, CRM, 1С, API.

Принципиальная особенность платформы — privacy-by-design архитектура: она работает с метаданными, структурой и агрегатами, не передавая и не сохраняя «сырые» значения ПДн. Это означает, что сама платформа не становится дополнительным источником риска.

В контексте описанных в статье задач «Пятый фактор» решает сразу несколько критических проблем:

1. Непрерывная «живая карта» ПДн: где и какие данные есть, кто владелец, что изменилось. Это именно то, что необходимо для актуального уведомления в Роскомнадзоре и для договоров-поручений — вы всегда знаете, что именно передаёте провайдеру.
2. Раннее обнаружение новых рисков: платформа видит новые поля в БД, новые интеграции и источники ПДн, пока они не превратились в инцидент. Это критично в условиях, когда каждое новое SaaS-подключение потенциально создаёт нарушение требований локализации.
3. Сокращение времени аудита: вместо ручных недельных проверок — актуальный реестр с нарушениями, владельцами и статусами. Готовность к проверке Роскомнадзора или внутреннему ИБ-аудиту становится постоянным состоянием, а не результатом аврального режима.
4. Контроль соблюдения договоров-поручений: если провайдер по договору должен получать только определённые категории данных, платформа позволяет отслеживать, не расширился ли реальный объём передачи.

При постоянно ужесточающемся регулировании и росте числа утечек непрерывный автоматизированный контроль ПДн-ландшафта перестаёт быть дополнительным инструментом и становится необходимым условием реальной безопасности и соответствия требованиям.

Заключение

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

Регуляторный ландшафт 2025 года сделал цену бездействия реальной и значимой. Штрафы, оборотные санкции, уголовная ответственность — не абстракция, а работающие инструменты. Вместе с тем требования закона вполне выполнимы при системном подходе: инвентаризация ПДн-потоков, грамотные договоры, правильно настроенная система защиты и постоянный мониторинг.

Что делать дальше: начать с инвентаризации — составить полный реестр систем, получающих ПДн, включая все SaaS-подключения. Затем проверить договорную базу. Затем провести оценку уровней защищённости и убедиться, что технические меры соответствуют Приказу ФСТЭК №21. Это не одноразовый проект, а непрерывный процесс — и именно так к нему и нужно относиться.

Источники

[1] iKS-Consulting. Российский рынок облачных инфраструктурных сервисов 2025 — https://www.iksmedia.ru/articles/6071546-Rossijskij-rynok-oblachnyx-uslug.html

[2] КонсультантПлюс. Федеральный закон от 27.07.2006 N 152-ФЗ (ред. от 24.06.2025) — https://www.consultant.ru/document/cons_doc_LAW_61801/

[3] b-152.ru. Хранение персональных данных за границей: что разрешено, что запрещено и как соблюсти локализацию в 2025 году — https://b-152.ru/hranenie-personalnyh-dannyh-za-granicej

[4] vc.ru / Право. Персональные данные 2025: штраф до 15 млн ₽ и запрет зарубежных баз — https://vc.ru/legal/2186769-personalnye-dannye-2025-izmeneniya-i-shtrafy

[5] cloud.ru. 152-ФЗ в облаке: хранение персональных данных в облаке — https://cloud.ru/blog/152-fz-v-oblake

[6] КонсультантПлюс. Статья 6. Условия обработки персональных данных — https://www.consultant.ru/document/cons_doc_LAW_61801/315f051396c88f1e4f827ba3f2ae313d999a1873/

[7] Постановление Правительства РФ от 01.11.2012 №1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»

[8] anti-malware.ru. Российский рынок облаков в 2025: структура, тренды, прогноз — https://www.anti-malware.ru/analytics/Technology_Analysis/Russian-cloud-market-prospects

[9] ТА Tadviser. Утечки данных в России — https://www.tadviser.ru/index.php/Статья:Утечки_данных_в_России

[10] InfoWatch. Количество слитых персональных данных в 2024 году выросло на треть — https://www.infowatch.ru/company/presscenter/news/kolichestvo-slitykh-personalnykh-dannykh-v-dve-tysyachi-dvadtsat-chetvertom-godu-vyroslo-na-tret

[11] comply.ru. Локализация и трансграничная передача персональных данных. Что изменилось с 1 июля 2025 года? — https://comply.ru/tpost/c43ezsout1-lokalizatsiya-i-transgranichnaya-peredac

[12] pr-cy.ru. Персональные данные 2026: локализация, уведомления Роскомнадзора и штрафы за утечки — https://pr-cy.ru/news/p/10608-novye-trebovaniya-personal-dannye

[13] ezybrand.ru. Изменения в 152 ФЗ о персональных данных в 2025 году — https://ezybrand.ru/blog/izmeneniya-v-152-fz-v-2025-godu/

[14] garant.ru. Согласие на обработку персональных данных с 1 сентября 2025 года — https://www.garant.ru/article/1862510/

[15] klerk.ru. Обработка персональных данных: новые требования с 01.07.2025 и 01.09.2025 — https://www.klerk.ru/blogs/fedresurs/658225/

[16] selectel.ru. ИСПДн и уровни защищённости персональных данных — https://selectel.ru/blog/personal-info-is/

[17] ФСТЭК России. Приказ от 18.02.2013 N 21 — https://fstec.ru/dokumenty/vse-dokumenty/prikazy/prikaz-fstek-rossii-ot-18-fevralya-2013-g-n-21

[18] selectel.ru. Модель угроз безопасности персональных данных: как составить по требованиям ФСТЭК — https://selectel.ru/blog/personal-data-security-threat-model/

[19] kdelo.ru. Поручение на обработку персональных данных, образец по 152-ФЗ — https://www.kdelo.ru/art/386991-kak-oformit-poruchenie-na-obrabotku-personalnyh-dannyh-obrazets

[20] business.ru. Трансграничная передача персданных в 2025–2026 годах — https://www.business.ru/article/5351-transgranichnaya-peredacha-personalnyh-dannyh-gg

[21] digital-report.ru. Роскомнадзор получает право блокировать любые зарубежные сервисы — https://digital-report.ru/rkn-transgranichnaya-peredacha-dannyh-zapret/

[22] garant.ru. Постановление Суда по интеллектуальным правам от 15.08.2025 по делу А40-238444/2024 — https://base.garant.ru/12148567/