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

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

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

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

Первое, что стоит понять: закон не выделяет облачного провайдера в отдельную категорию с особым статусом. Есть оператор персональных данных - компания, которая решает, зачем и как обрабатываются данные клиентов или сотрудников, и есть лица, которых оператор привлекает для обработки по поручению. Облачный сервис, где физически лежит база сайта, CRM или 1С, - именно такое привлеченное лицо, а не самостоятельный оператор, даже если в его рекламе написано обратное.

Часть 3 статьи 6 152-ФЗ разрешает оператору поручить обработку персональных данных другому лицу, но только на основании договора, включая договор с компанией, оказывающей услуги облачного хранения. Из этого следует главное: ответственность перед клиентом или сотрудником, чьи данные обрабатываются, по-прежнему несет оператор - та компания, которая эти данные собрала. Если облачный провайдер допустит утечку из-за собственной уязвимости, разбираться с проверкой Роскомнадзора и объясняться перед клиентами придется владельцу сайта или магазина, а не дата-центру, даже если виноват фактически именно он. С 2025 года такая утечка может обернуться оборотным штрафом - процентом от годовой выручки компании, а не фиксированной суммой, и это уже совсем другой уровень риска, чем штраф в несколько десятков тысяч рублей.

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

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

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

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

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

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

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

На практике многие облачные сервисы - готовые SaaS-CRM, конструкторы сайтов с облачной базой, платформы для рассылок - предлагают типовой договор оферты, где раздел про персональные данные умещается в два-три предложения. Прежде чем подписывать, стоит запросить отдельное приложение про обработку персональных данных: если провайдер регулярно работает с бизнес-клиентами, у него такой документ обычно уже есть, просто его не публикуют на главной странице сайта.

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

Хранение персональных данных в облаке: требование к локализации в России

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

Смысл требования не в том, что все копии данных обязаны лежать в России, а в том, что первичная база - место, где данные фиксируются и обновляются, - должна находиться на серверах внутри страны. Для выбора облака это означает: нужно уточнить, где физически расположены дата-центры провайдера, а не только по какому юридическому адресу зарегистрирована компания. Иностранный сервис с русским интерфейсом, рублевой оплатой и офисом продаж в Москве может при этом хранить данные на серверах в другой стране - юрисдикция договора и физическая локация сервера не одно и то же.

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

Уровни защищенности по ПП-1119 и приказ ФСТЭК 21: при чем тут облако

Когда компания сама администрирует сервер, она сама выбирает средства защиты под нужный уровень. В облаке часть этой работы берет на себя провайдер, но только часть, и только если правильно выбран тариф и провайдер вообще умеет работать с персональными данными, а не просто дает виртуальную машину в аренду.

ПП-1119 делит системы персональных данных на четыре уровня защищенности в зависимости от типа данных, категории субъектов и модели угроз. Приказ ФСТЭК 21 расписывает конкретные организационные и технические меры для каждого уровня. Определить свой уровень нужно до выбора провайдера, а не после: чек-лист по ПП-1119 разобран в статье уровни защищенности персональных данных, и от результата зависит, какой тариф облака вообще подходит.

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

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

Иностранные облака: когда хранение становится трансграничной передачей

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

Популярные зарубежные сервисы - облачные CRM, конструкторы сайтов, платформы рассылок, корпоративные мессенджеры - стали для многих компаний привычным инструментом, но с точки зрения закона это чаще всего именно трансграничная передача, а не просто использование удобного сервиса. Актуальный список стран и порядок уведомления Роскомнадзора при такой передаче разобран в статье трансграничная передача ПДн в 2026.

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

Чек-лист выбора облачного провайдера для персональных данных

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

Что смотреть в договоре с российским провайдером

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

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

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

Последний пункт легко пропустить, но именно он часто скрыт не в договоре с корпоративным клиентом, а в пользовательском соглашении сервиса. Некоторые облачные CRM и аналитические платформы в стандартной оферте оставляют себе право обрабатывать обезличенные данные пользователей для улучшения сервиса. Формально это не нарушение, если данные действительно обезличены, но формулировку стоит проверить, а не полагаться на добросовестность разработчика.

Резервные копии в облаке: отдельный источник риска

Резервная копия базы данных - тоже персональные данные, и на нее распространяются те же требования, что на рабочую базу: локализация, уровень защиты, срок хранения. Частая ошибка - настроить бэкап в другое, более дешевое облако, не проверив, где оно физически хранит данные, потому что кажется, будто это техническая деталь, а не вопрос закона.

Стоит проверять не только, что бэкап делается, но и что из него реально можно восстановить данные: резервная копия, которая физически существует, но ни разу не тестировалась на восстановление, с точки зрения закона ничем не лучше ее отсутствия - если из-за сбоя данные пропадут безвозвратно, ссылка на регулярное копирование не спасет от вопросов проверяющего.

Отдельная сложность - срок хранения самих резервных копий. Если оператор обязан удалить данные клиента по его запросу или по истечении срока хранения, а в старых бэкапах эти данные остаются годами, требование об удалении формально не выполнено. Как согласовать политику резервного копирования с обязанностью удалять данные по запросу, разобрано в статье хранение резервных копий персональных данных.

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

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

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

SLA про скорость работы сервиса и документ про меры защиты персональных данных - разные бумаги, и наличие одной не говорит о наличии другой. Провайдер может гарантировать 99,9 процента доступности и при этом не иметь внятного ответа на вопрос, что произойдет с базой клиентов при взломе одного из его серверов - эти два вопроса стоит задавать отдельно, а не считать, что высокий SLA автоматически означает защиту данных.

Для малого и среднего бизнеса полноценный технический аудит облака обычно недоступен - нет ни ресурсов, ни экспертизы для этого. Но минимальный набор действий выполним почти всегда: запросить у провайдера актуальную редакцию его политики обработки персональных данных, уточнить, назначен ли у него собственный ответственный за организацию обработки персональных данных, и раз в год перечитывать раздел договора про безопасность - за это время состав услуг у провайдера мог измениться, а договор с оператором остался прежним.

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

Что сделать, если персональные данные уже в облаке

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

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

Разобраться, какие из этих пунктов уже закрыты у конкретной компании, а какие требуют нового документа или переговоров с провайдером, проще при взгляде со стороны - на договор, на форму сбора данных на сайте и на фактическую схему хранения. На сайте 152fzpro.ru можно уточнить, какие документы и доработки сайта нужны именно для вашей схемы работы с облаком, без универсальных шаблонов на все случаи сразу.