ФЗ-152 для SaaS-продуктов в 2026: что реально требует архитектура (а не только бумажки)

Что нужно знать до начала

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

Эта статья — про другое. Про то, как 152-ФЗ выглядит со стороны архитектуры, кода и эксплуатации, и какие решения нужно принимать на уровне сервиса, а не приказа.

01 · Что такое ФЗ-152 на самом деле — для инженеров

Для инженера требования удобно разложить на несколько практических вопросов:

• На каком основании и для какой цели обрабатываются персональные данные (ПДн).
• Где выполняются операции, на которые распространяется требование локализации.
• Как к ним получают доступ — внутри компании и со стороны подрядчиков.
• Что происходит, если эти данные утекли, изменились или были обработаны не по назначению.

Конкретный набор мер зависит от целей обработки, категорий данных, актуальных угроз, типа информационной системы и роли компании. Поэтому фраза «мы соответствуем 152-ФЗ» без модели данных и правовых оснований мало что сообщает.

Когда команда говорит «мы под 152-ФЗ», на практике это означает, что архитектура должна:

• знать правовое основание каждой цели обработки;
• разделять ПДн и остальные данные продукта там, где это оправдано моделью угроз;
• хранить ПДн физлиц-резидентов РФ на территории РФ при первичной обработке;
• применять меры защиты, выбранные по результатам определения угроз и уровня защищённости;
• уметь находить, исправлять, блокировать или уничтожать данные в предусмотренных законом случаях;
• выдерживать инцидент так, чтобы 24 часа на уведомление РКН были реалистичным сроком.

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

02 · Локализация: почему «ПДн физлиц в РФ» — это не только про регион сервера

Самое частое упрощение: «арендовали VPS в России — значит, мы локализованы».

На практике локализация — это про первичную обработку. По закону запись, систематизация, накопление, хранение, уточнение и извлечение ПДн физлиц-резидентов РФ должны происходить с использованием баз данных, расположенных на территории РФ.

Что это значит технически:

• Основная (master) база с ПДн — в РФ.
• Очередь сообщений, в которой PII лежит даже временно — в РФ.
• Поисковый индекс с ФИО, email, телефоном — в РФ.
• Файловое хранилище со сканами паспортов, договорами, селфи для KYC — в РФ.
• Бэкапы этих систем — в РФ.

Зарубежные сервисы могут использоваться только после отдельной проверки сценария трансграничной передачи. До начала такой передачи оператор направляет отдельное уведомление в Роскомнадзор и выполняет требования статьи 12; одного пункта в согласии или договора с подрядчиком недостаточно.

В реальности это значит, что в SaaS-продукте на 2026 год обычно нет одной «европейской» инфраструктуры и одной «российской». Есть разделение на контуры:

• основной контур — РФ, master-данные;
• контур синхронизации — РФ, ETL, очереди;
• контур аналитики — может быть зарубежным, но получает обезличенные или агрегированные данные;
• контур маркетинга — отдельный, с отдельной моделью согласий.

Самая частая ошибка стартапов — отправлять весь поток событий через зарубежный аналитический сервис, включая email и user_id, который однозначно сопоставим с PII. С точки зрения 152-ФЗ это уже трансграничная передача персональных данных, а не «аналитика».

03 · Категории операторов и почему стартап может попасть в «значимые»

Внутри 152-ФЗ операторы делятся по объёму и характеру обрабатываемых данных. Для стартапа это редко обсуждается на старте, но именно классификация определяет, сколько у вас будет компонентов compliance.

Ключевые категории, к которым стоит относиться внимательно:

• обработка специальных категорий ПДн (здоровье, политические взгляды, биометрия) — резко повышает требования к защите;
• обработка биометрических ПДн, используемых для установления личности, регулируется отдельно; при этом само наличие фотографии ещё не всегда означает обработку биометрии — важны цель и способ использования;
• большой объём субъектов и идентификаторов влияет на уровень защищённости в сочетании с типом угроз и категорией данных, но сам по себе не образует отдельную «категорию оператора»;
• обработка ПДн в рамках государственных или муниципальных систем — отдельный режим.

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

• KYC с фотографией документа;
• селфи-биометрия для входа;
• медицинские данные пациентов или сотрудников;
• интеграция с государственными системами (Госуслуги, ЕСИА, ЕБС).

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

04 · Согласие на обработку — техническая сторона

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

• зафиксировано в момент сбора данных;
• однозначно привязано к конкретному субъекту;
• содержит цели обработки, на которые субъект согласился;
• может быть отозвано — и отзыв технически приведёт к остановке обработки.

С точки зрения сервиса это отдельная сущность — назовём её consent_record — с минимальным набором полей:

• subject_id — привязка к субъекту ПДн.
• purpose — цель обработки (маркетинг, аналитика, передача подрядчику и т.п.).
• granted_at — timestamp согласия.
• revoked_at — timestamp отзыва или null.
• evidence — хеш или снимок текста согласия, IP, user-agent.
• source — где и как было получено (форма, договор, чек-бокс в продукте).

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

В реальном продукте чаще всего работает один из двух паттернов:

• Gateway-проверка: API-шлюз проверяет согласие до того, как запрос дойдёт до бизнес-сервиса.
• Service-side guard: каждый сервис, работающий с ПДн, делает явный вызов consent.check(subject_id, purpose) перед началом обработки.

Service-side guard обычно устойчивее, потому что не зависит от того, как пришёл запрос — через API, очередь или cron. Но это архитектурный паттерн, а не предписанная законом реализация.

05 · Хранение и сегрегация ПДн — архитектурные паттерны

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

• удаление по запросу субъекта;
• ограничение доступа;
• ротацию ключей шифрования;
• ответ на инцидент;
• передачу обезличенных данных в аналитику.

Базовая модель, которая хорошо работает для SaaS:

• Identity store — ПДн (ФИО, email, телефон, документы). Один сервис, одна БД, узкий доступ.
• Application store — рабочие данные продукта (заказы, проекты, сообщения). Хранит только subject_id, без PII.
• Analytics store — события, агрегаты. Получает обезличенные данные.

Это паттерн «PII vault»: персональные данные изолированы, а бизнес-логика работает с непрозрачными идентификаторами. Уничтожение данных при этом всё равно должно учитывать связанные записи, документы, сроки обязательного хранения, резервные копии и подрядчиков — одной записи в Identity store недостаточно.

Преимущество для compliance очевидно. Преимущество для команды — менее очевидное, но важное: при инциденте вы можете чётко сказать, какие именно данные были затронуты, потому что они физически отделены.

06 · Шифрование: что требуется, что — гигиена

152-ФЗ напрямую не предписывает конкретные алгоритмы. Требования к средствам защиты идут через сопутствующие документы: 21-й приказ ФСТЭК, требования ФСБ к СКЗИ, постановления Правительства РФ по уровням защищённости.

Для SaaS на типовых задачах разумная инженерная база выглядит так:

• Шифрование в покое (at-rest) для БД с ПДн — распространённая защитная мера. Disk-level в облаке можно дополнять application-level шифрованием критичных полей.
• Шифрование канала (in-transit) — TLS 1.2+ снаружи и между сервисами.
• Сертифицированные средства защиты применяются там, где это следует из выбранного набора мер и применимых требований ФСТЭК/ФСБ. Проверять это нужно по конкретной информационной системе, а не по признаку «SaaS».
• Управление ключами — отдельный сервис (KMS) с разделением ролей: те, кто пишет код, не должны иметь прямого доступа к ключам шифрования продакшена.

Что часто пропускают:

• Шифрование бэкапов. Бэкапы с открытым PII — самая частая дыра, которую находит аудит.
• Шифрование логов, если в логах есть PII (а часто есть — через ошибочный console.log(user)).
• Ротация ключей. Один ключ, выписанный когда-то и не менявшийся — это формальное соответствие, но не реальная защита.

07 · Логирование и аудит обращений к ПДн

152-ФЗ требует принимать правовые, организационные и технические меры безопасности. Универсальной нормы «логировать каждое чтение» в законе нет. Но аудит действий часто нужен, чтобы расследовать инциденты, контролировать доступ и подтверждать выполнение выбранных мер:

• кто (user_id сотрудника или service account);
• что (какие поля, какого субъекта);
• когда (timestamp);
• откуда (источник, IP);
• зачем (purpose, если применимо).

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

• чтение карточки субъекта в админке;
• экспорт списка субъектов;
• массовая операция над субъектами;
• изменение полей PII;
• удаление субъекта;
• предоставление доступа подрядчику.

Что важно архитектурно:

• аудит-лог пишется в отдельное хранилище, к которому у разработчиков продукта нет write-доступа;
• логи append-only — нельзя ретроактивно «подчистить» историю;
• срок хранения определяется политикой, целями контроля и применимыми требованиями; универсального минимума «три года» для всех аудит-логов 152-ФЗ не устанавливает;
• в аудит-логе не должно быть самих ПДн — только идентификаторы. Иначе аудит становится вторым местом хранения PII и расширяет поверхность атаки.

В реальной эксплуатации аудит-лог помогает восстановить картину инцидента и подтвердить работу контроля. Его состав и детализацию нужно связать с моделью угроз, ролями доступа и процедурами реагирования.

08 · Удаление, экспорт, отзыв согласия

В предусмотренных законом случаях субъект может:

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

В архитектуре это превращается в три отдельные функции — назовём их по аналогии с GDPR-практикой DSR:

• data_export(subject_id) — собрать все ПДн субъекта из всех сервисов в один файл.
• data_erasure(subject_id) — удалить или анонимизировать данные субъекта.
• consent_revoke(subject_id, purpose) — пометить согласие как отозванное, остановить связанные процессы.

Главная сложность не в том, чтобы написать эти функции. Сложность в том, что данные одного субъекта лежат в десятках мест:

• основная БД;
• кэши;
• поисковый индекс;
• очереди;
• бэкапы;
• логи приложения;
• аналитический контур;
• сторонние сервисы (рассылки, поддержка, CRM);
• email-копии в Inbox менеджеров.

«Удалить пользователя» в коде — это DELETE FROM users WHERE id = ?. Исполнить требование субъекта сложнее: сначала нужно установить правовое основание и обязательные сроки хранения, затем охватить нужные компоненты и подрядчиков. Отзыв согласия не всегда означает немедленное уничтожение всех данных, если сохраняется другое законное основание.

Для сложной распределённой системы полезен erasure-orchestrator — компонент, который знает места хранения, рассылает команды и фиксирует результат. В небольшом продукте ту же функцию может выполнять управляемая процедура: закон задаёт результат, но не требует отдельного сервиса с таким названием.

09 · Уведомление об утечке в РКН — 24/72 часа

При инциденте, повлекшем нарушение прав субъектов, закон устанавливает короткие сроки:

• 24 часа с момента обнаружения инцидента — на первичное уведомление РКН;
• 72 часа — на отчёт с указанием установленных причин и принятых мер.

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

• какие данные были затронуты (категории, объём);
• сколько субъектов задето;
• через какой компонент произошла утечка;
• какие меры приняты для локализации.

Если ответы на эти вопросы требуют недельного расследования с привлечением подрядчика DevOps и реверс-инжиниринга логов — 24 часа вы не уложите.

Что должно быть готово заранее:

• Карта данных (data map): где какие категории ПДн лежат, в каких сервисах, в каких регионах.
• Runbook на инцидент: кто принимает решение об уведомлении, кто пишет уведомление, кто его подаёт.
• Контактные данные назначенного ответственного за организацию обработки ПДн — должны быть актуальны.
• Логирование такого уровня детализации, которое позволяет за часы оценить scope утечки.

В практике зрелых продуктов отдельно держат incident-таблицу: список потенциальных сценариев утечки (компрометация сервиса X, утечка через подрядчика Y, инсайдер), и для каждого сценария — заранее подготовленный шаблон уведомления и список действий. В момент инцидента команда не пишет уведомление с нуля, а уточняет шаблон.

10 · Подрядчики, sub-processors, трансграничная передача

В типичном SaaS-продукте 2026 года ПДн почти всегда уходят за пределы вашей основной системы. Самые частые потребители:

• провайдер инфраструктуры (российский cloud или собственное железо);
• email-рассылки;
• SMS-рассылки;
• сервис поддержки клиентов;
• CRM;
• аналитика;
• инструменты разработки и тестирования (логирование, мониторинг, error-tracking).

Если подрядчик обрабатывает ПДн по поручению оператора, отношения нужно формализовать. В поручении определяют данные, операции, цели, требования конфиденциальности и безопасности; одного общего NDA недостаточно.

• правовое основание и совместимость с заявленной целью;
• поручение на обработку ПДн с обязательными условиями;
• возможность запросить подтверждение принятых мер и получить уведомление об инциденте.

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

Особое внимание — трансграничной передаче. До её начала оператор отдельно уведомляет Роскомнадзор, собирает сведения о получателе и оценивает условия передачи по статье 12. Наличие согласия не отменяет эту процедуру, а Роскомнадзор может ограничить или запретить передачу.

Что часто упускают на старте:

• Error-tracking (Sentry-подобные сервисы) — стек-трейсы могут содержать PII. Для зарубежного сервиса это потенциальная трансграничная передача, которую нужно либо исключить технически, либо оформить по применимым требованиям.
• Логирование в облако — то же самое.
• AI-сервисы, которым отправляются данные субъекта для обработки — отдельная и быстро меняющаяся история.

Простое правило для проектирования: считать, что любой логгер и любой third-party API — это потенциальный канал утечки ПДн, и проектировать клиенты к ним так, чтобы PII в них не попадало по умолчанию.

11 · Что важно проверить в продакшен SaaS 2026

Если вы запускаете или развиваете SaaS-продукт под российскую аудиторию в 2026 году, минимальный технический чек, который имеет смысл прогнать раз в квартал:

• Master-БД с ПДн физлиц-резидентов РФ находится в РФ.
• Бэкапы этой БД находятся в РФ и зашифрованы.
• Аналитический контур получает обезличенные или агрегированные данные.
• В error-tracking и логах не уходят ФИО, email, телефон, документы.
• Для каждой цели определено правовое основание; согласия фиксируются там, где они являются таким основанием.
• Логируются значимые действия в соответствии с моделью угроз и политикой контроля.
• Есть рабочая процедура поиска, уточнения, блокирования и уничтожения данных в предусмотренных законом случаях.
• Есть актуальная карта данных (data map) и список подрядчиков с PII-доступом.
• Есть runbook на инцидент с уведомлением РКН в 24 часа.
• Есть назначенный ответственный за обработку ПДн с актуальными контактами.

Это не «полный compliance». Это минимум, без которого compliance в принципе не воспроизводим.

12 · Чек-лист на 2026: от MVP до зрелого продукта

Удобный способ мыслить про 152-ФЗ — не «всё сразу» и не «ничего», а через стадии зрелости продукта.

MVP / ранняя стадия

• Master-БД в РФ.
• Карта целей и правовых оснований; фиксация версии и факта согласия там, где обработка основана на нём.
• Отдельный сервис identity (даже если он внутри монолита — как отдельный модуль).
• Никаких PII в зарубежных error-tracking и аналитике.
• Один документ — политика обработки ПДн — на сайте и в продукте.

Рост / первые тысячи пользователей

• Управляемый реестр согласий и других оснований обработки.
• Аудит значимых действий, достаточный для расследования и контроля.
• Реализованные процедуры ответа на обращения субъекта и уничтожения данных, когда это требуется.
• Реестр подрядчиков с PII-доступом и договоры поручения с ними.
• Шифрование бэкапов и ротация ключей.

Масштаб / сотни тысяч пользователей и enterprise-клиенты

• Оркестрация уточнения, блокирования и уничтожения данных во всех системах.
• Карта данных как живой документ, обновляемая при изменениях архитектуры.
• Runbook на инцидент с тренингом команды.
• Назначенный ответственный за организацию обработки ПДн с реальными полномочиями.
• Отдельный pipeline для биометрии и специальных категорий ПДн.

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

Источники и что почитать дальше

• 152-ФЗ, статья 6 — условия и правовые основания обработки.
• 152-ФЗ, статья 11 — биометрические персональные данные.
• 152-ФЗ, статья 12 — порядок трансграничной передачи.
• 152-ФЗ, статья 18 — обязанности оператора и локализация.
• 152-ФЗ, статья 19 — меры безопасности.
• 152-ФЗ, статья 21 — обращения субъектов и уведомление об инцидентах.
• Постановление Правительства РФ № 1119 — уровни защищённости ПДн в информационных системах.

---

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