SaaS и персональные данные: кто в команде отвечает за роль оператора, серверы и трекеры
В SaaS-компаниях вопрос о персональных данных обычно всплывает в двух ситуациях: крупный клиент присылает анкету безопасности перед подписанием договора, или юрист замечает, что политику на сайте никто не обновлял с момента запуска. В обоих случаях выясняется, что за данные отвечают сразу все и одновременно никто. Маркетинг ставит счётчики, продукт отвечает за регистрацию, инфраструктура выбирает облако, продажи подписывают договоры. Каждое из этих решений по отдельности выглядит мелким, а все вместе они формируют правовой профиль сервиса.
Сложность в том, что облачный продукт работает с двумя потоками данных. Первый поток — собственные пользователи: регистрация, биллинг, техподдержка, аналитика. Второй — базы, которые загружают клиенты. Обязанности по закону для этих потоков разные, и путать их опасно в обе стороны.
Две роли сервиса и почему их стоит развести на бумаге
Если сервис сам решает, зачем и как собирать сведения о людях, он выступает оператором. Так обстоит дело с аккаунтами, платёжными данными и обращениями в поддержку. Когда же клиент сам определяет, что загружать в систему и как этим пользоваться, а сервис лишь даёт инфраструктуру, у SaaS появляется роль обработчика по поручению. Для этой роли нужен договор, где описаны обязанности сторон и меры защиты.
Типичная ошибка в том, что команда выбирает одну роль и считает вопрос закрытым. Продажи говорят клиенту: «Мы только обработчик, данные ваши», при этом продукт собирает по тем же пользователям поведенческую аналитику для собственных целей. Здесь сервис фактически действует как оператор, и к нему возникнут вопросы, на какое основание опирается такая обработка. Если цели расходятся с теми, ради которых данные собирались, это создаёт риск по ч. 1 ст. 13.11 КоАП: для юрлиц от 150 до 300 тыс. ₽.
Руководителю проще всего объяснить это таблицей из двух колонок: какие данные сервис собирает для себя и какие хранит по поручению клиентов. У каждой строки должен быть ответственный. Похожая логика нужна при работе с подрядчиками, и мы уже разбирали, как оценивать аутсорсера с этой точки зрения.
Инфраструктура: локация серверов как решение, а не настройка по умолчанию
Закон требует, чтобы запись, накопление, хранение и извлечение данных российских граждан шли через базы на территории России. Облачные платформы использовать можно, но регион дата-центра нужно выбрать осознанно и зафиксировать. Частая история: сервис запускали на крупном зарубежном облаке, оставили европейский или американский регион по умолчанию, а потом об этом забыли.
Хранение за рубежом означает трансграничную передачу. До её начала нужно уведомить Роскомнадзор и проверить, подходит ли страна назначения по критериям защиты. С поправками, внесёнными 265-ФЗ в июле 2026 года, критерии стран уточнены, но обязанность уведомлять заранее сохранилась. Для инфраструктурной команды это значит, что любая миграция или новый регион должны проходить через согласование с теми, кто отвечает за данные.
Регион облака выбирает инженер за пару минут, а отвечать за этот выбор потом приходится всей компании.
Сайт и интеграции: зона маркетинга
Публичный сайт SaaS обычно перегружен внешними скриптами: аналитика, чат поддержки, вход через иностранные сервисы, платёжные виджеты, зарубежные рекламные пиксели. Каждый из них может передавать данные посетителя, и если сервис иностранный, снова встаёт вопрос трансграничной передачи. Отдельная проблема — трекеры, которые запускаются раньше, чем человек ответил на cookie-баннер. Такая обработка не имеет законного основания, будь то Google Analytics, Hotjar или Яндекс.Метрика.
Маркетологу удобно проверять сайт глазами нового посетителя. Перед каждым релизом команде стоит пройти короткий порядок действий:
- Открыть сайт в окне инкогнито, не трогая баннер
- Посмотреть во вкладке Network, какие запросы ушли к внешним доменам
- Сверить список с теми сервисами, что описаны в политике
- Нажать отказ и убедиться, что трекеры не стартуют
- Проверить, что политика опубликована и называет конкретные данные, сроки и место хранения
Последний пункт часто недооценивают. Шаблонная фраза «данные используются для улучшения сервиса» не описывает реальную обработку. Хорошая политика конкретна: какие поля собираются при регистрации, в какой стране хранятся, когда удаляются после закрытия аккаунта. Подробнее о подходе к облачным продуктам — в материале Dobrolex о проверке SaaS-сервиса, а для отраслей с чувствительными данными пригодится разбор сайтов медицинских организаций.
Внешний технический осмотр показывает только видимое снаружи: публичные страницы без входа в аккаунт и без отправки форм. Серверную часть, закрытые разделы и договоры с клиентами так не проверить. Сетевые запросы браузера — технический сигнал для команды, а не готовое доказательство, и консультацию юриста они не заменяют.
В SaaS соответствие закону о данных складывается не из одного документа, а из множества мелких решений разных отделов. Если роли, регион серверов и набор скриптов закреплены за конкретными людьми и пересматриваются при каждом изменении продукта, анкеты клиентов и вопросы регулятора перестают заставать команду врасплох.