- SaaS с клиентами из РФ и ЕС обязан соответствовать обоим законам параллельно
- Главная задача — локализация: первичное хранилище данных россиян в РФ
- Процесс уведомления об утечках выстраивается по строжайшему сроку — 24 часа
- С каждым инфраструктурным подрядчиком нужен DPA, соответствующий обоим режимам
- Первоначальные затраты на приведение в порядок — около 100 000 рублей
Облачные сервисы — это передовая линия столкновения двух регуляторных миров. Когда у SaaS-продукта клиенты и в России, и в Европе, вопрос «какому закону подчиняться» перестаёт быть теоретическим. Разберём на сквозном примере, как привести такой сервис в порядок.
Исходная ситуация
Сервис предоставляет облачное хранилище и совместную работу с документами. Клиенты из России, Евросоюза и США. Инфраструктура развёрнута на зарубежном облаке с дата-центрами в США и Европе. Компания зарегистрирована в России, основатели — россияне.
Проблема, с которой пришла команда: они выросли, появились крупные европейские клиенты, начали спрашивать про GDPR, а юрист напомнил, что и ФЗ-152 никто не отменял. Возникла путаница — что вообще нужно делать.
Анализ: какие законы применяются
Первый шаг — разложить клиентскую базу по юрисдикциям и понять, какой закон к кому применим.
| Клиенты | Применимый закон |
|---|---|
| Граждане РФ | ФЗ-152 |
| Резиденты ЕС | GDPR |
| Граждане РФ, живущие в ЕС | Оба |
| Клиенты из США | Законы штатов + GDPR/ФЗ-152, если затронуты их жители |
Поскольку у сервиса есть и российские, и европейские клиенты, соответствовать нужно обоим законам одновременно. Это не означает двойную работу — грамотная архитектура закрывает оба требования единой системой, где более строгие правила покрывают более мягкие.
Требование 1: локализация
Главная проблема исходной ситуации — данные россиян лежат на зарубежных серверах. Это прямое нарушение ФЗ-152.
Решение строится так: первичное хранилище данных граждан РФ переносится в российское облако, а зарубежная инфраструктура остаётся для европейских клиентов и резервных копий.
На практике команда арендует мощности в российском облаке, настраивает маршрутизацию так, чтобы данные российских пользователей писались сначала в РФ, и шифрует данные с хранением ключей внутри страны.
Без переноса первичного хранилища в Россию никакие другие меры не спасут от штрафа за нарушение локализации — а это до 6 млн рублей за первое нарушение и до 18 млн за повторное. Это первое, что нужно закрыть.
Требование 2: согласие и политика
Сервис обновляет политику конфиденциальности, чтобы она покрывала оба закона. В ней честно описывается, какие данные собираются (email, содержимое документов, IP, данные об устройствах), для чего, где хранятся (первично в РФ, резервно за рубежом) и что происходит при удалении аккаунта.
Согласие при регистрации формулируется так, чтобы удовлетворять требованиям обоих режимов: явное, информированное, отзываемое.
Требование 3: DPA со всеми подрядчиками
SaaS почти никогда не работает в одиночку. Этот сервис использует российское облако, зарубежное облако, платёжный процессор и сервис уведомлений. С каждым нужен договор поручения на обработку.
| Подрядчик | Роль | DPA |
|---|---|---|
| Российское облако | Первичное хранилище | Да |
| Зарубежное облако | Резервная копия | Да + механизм трансграничной передачи |
| Платёжный процессор | Обработка платежей | Да |
| Сервис уведомлений | Отправка писем | Да |
Передача данных в зарубежное облако из ЕС требует законного механизма — стандартных договорных положений. А передача данных россиян за рубеж требует согласия субъекта либо иного основания. Эти два требования нужно закрыть отдельно, они не взаимозаменяемы.
Требование 4: процесс реагирования на утечки
Здесь команда принимает ключевое архитектурное решение: строить процесс под 24 часа (требование ФЗ-152), а не под 72 часа (GDPR). Так один процесс закрывает оба закона.
Регламент описывает, кто обнаруживает инцидент, как фиксируются доказательства, кто принимает решение об уведомлении, как и в какой срок уведомляются РКН, европейский регулятор и сами пользователи.
Требование 5: права субъектов
Сервис реализует в личном кабинете функции, закрывающие права субъектов по обоим законам: просмотр своих данных, экспорт в машиночитаемом формате, удаление аккаунта со всеми данными, управление согласиями.
Затраты и сроки
Команду интересовал прагматичный вопрос — сколько это стоит и сколько займёт. Вот реалистичная оценка.
| Задача | Срок | Затраты |
|---|---|---|
| Регистрация в реестре РКН | 1–2 недели | Бесплатно |
| Политика под оба закона | 2–3 дня | 5 000–10 000 ₽ |
| DPA с подрядчиками | 2–3 дня | 5 000–10 000 ₽ |
| Перенос хранилища в РФ | 1–2 недели | 20 000–50 000 ₽ |
| Логирование и мониторинг | 1 неделя | 30 000–50 000 ₽ |
| Итого первоначально | ~1 месяц | ~100 000 ₽ |
Плюс регулярные расходы на российскую инфраструктуру — порядка 5 000–10 000 рублей в месяц.
Сто тысяч рублей кажутся ощутимой суммой для стартапа. Но это разовая инвестиция против штрафов до 18 млн рублей и потери крупных европейских клиентов, которые не подпишут контракт без подтверждённого соответствия GDPR. Для SaaS соответствие — часто условие сделки, а не просто защита от штрафа.
Результат
После выполнения всех шагов сервис соответствует обоим законам: данные россиян хранятся в РФ, компания в реестре операторов, процесс реагирования рассчитан на 24 часа, с подрядчиками заключены DPA, права субъектов реализованы в продукте. Теперь команда может спокойно подписывать контракты и с российскими, и с европейскими клиентами.
Чек-лист для SaaS с международными клиентами
- Первичное хранилище данных россиян перенесено в РФобязательно
- Компания зарегистрирована в реестре операторов РКНобязательно
- Процесс реагирования на утечки рассчитан на 24 часаобязательно
- Политика покрывает требования GDPR и ФЗ-152обязательно
- С каждым подрядчиком заключён DPAобязательно
- Настроен механизм трансграничной передачи для данных из ЕС
- В продукте реализованы экспорт и удаление данных
- Управление согласиями доступно в личном кабинете
Главный урок этого кейса: соответствие двум законам — это не удвоение работы, а грамотная архитектура. Когда система спроектирована под более строгие требования, мягкие закрываются автоматически. И чем раньше SaaS закладывает это в продукт, тем дешевле обходится — переделывать готовую инфраструктуру всегда дороже, чем спроектировать правильно с самого начала.