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

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

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

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

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

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

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

Все остальное — категории операторов, состав согласия, регистрация в Роскомнадзоре, организационно-распорядительные документы — следует из этих трёх вопросов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• обработка специальных категорий ПДн (здоровье, политические взгляды, биометрия) — резко повышает требования к защите;
• обработка биометрии (фото лица как идентификатор, голос как идентификатор) — требует отдельной модели согласий и фиксации в ЕБС или в собственной системе;
• обработка ПДн более 100 000 субъектов — поднимает требования к организационным мерам;
• обработка ПДн в рамках государственных или муниципальных систем — отдельный режим.

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

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

Архитектурно это означает, что блок биометрии и медданных всегда стоит выделять в отдельный сервис со своим хранилищем и своей моделью доступа, даже если бизнесу это кажется избыточным. Иначе compliance-требования по самой строгой категории «зальют» весь продукт.

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

Юристы пишут текст согласия. Архитектура отвечает за то, что согласие:

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

С точки зрения сервиса это отдельная сущность — назовём её 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) перед началом обработки.

Второй подход надёжнее, потому что не зависит от того, как именно пришёл запрос — через API, через очередь, через cron.

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

В нормальной зрелой системе ПДн не лежат в одной таблице с бизнес-данными. И не потому, что «так положено», а потому что это упрощает всё остальное:

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

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

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

Это классический pattern «PII vault»: персональные данные изолированы, бизнес-логика работает с непрозрачными идентификаторами, удаление субъекта = удаление одной записи в Identity store + опционально tombstone-флаг в Application store.

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

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

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

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

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

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

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

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

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

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

Минимальный набор событий, которые точно должны попадать в аудит:

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

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

• аудит-лог пишется в отдельное хранилище, к которому у разработчиков продукта нет write-доступа;
• логи append-only — нельзя ретроактивно «подчистить» историю;
• срок хранения — соразмерен сроку хранения самих ПДн (обычно 3 года минимум для обоснования законности обработки);
• в аудит-логе не должно быть самих ПДн — только идентификаторы. Иначе аудит становится вторым местом хранения 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 = ?. «Удалить субъекта» по 152-ФЗ — это распределённая операция, которая должна охватить все компоненты, включая подрядчиков.

Архитектурно для этого обычно делают erasure-orchestrator — отдельный сервис, который ведёт список всех мест, где могут лежать PII, рассылает команды на удаление и фиксирует результат. Без такого оркестратора удаление субъекта остаётся «удалили из основной таблицы», что для регулятора — не удаление.

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

Это, возможно, самое жёсткое требование 152-ФЗ в текущей редакции:

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

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

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

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

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

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

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

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

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

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

С точки зрения 152-ФЗ каждый из них — третье лицо, которому вы передаёте ПДн, и для каждого нужны три вещи:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 152-ФЗ «О персональных данных» — действующая редакция на 2026 год.
• 21-й приказ ФСТЭК — требования к мерам защиты при обработке ПДн в ИСПДн.
• Постановление Правительства РФ № 1119 — уровни защищённости ПДн.
• Руководящие документы Роскомнадзора — порядок уведомлений об утечках.
• Внутренние документы вашей юридической команды или внешнего юриста, специализирующегося на 152-ФЗ.

---

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