Удаление аккаунта SaaS: что с ПДн

Когда пользователь удаляет аккаунт, он ожидает, что его данные исчезнут. ФЗ-152 обязывает оператора именно к этому: уничтожить или обезличить ПДн, если отпало основание обработки. Для SaaS-продуктов это создаёт технический и правовой вызов: данные рассредоточены по основной БД, резервным копиям, очередям событий, аналитическим хранилищам и ML-пайплайнам. В 2025 году РКН начал рассматривать «аккаунт удалён» и «ПДн уничтожены» как разные события. Разрыв между ними — основание для протокола.

Что требует ФЗ-152 при уходе субъекта из SaaS?

Статья 21 ФЗ-152 устанавливает: при достижении целей обработки или при утрате необходимости в ней оператор обязан прекратить обработку и уничтожить ПДн в срок не более 30 дней, если иное не предусмотрено договором или законом. Удаление аккаунта означает, что субъект отзывает согласие или расторгает договор — оба события прекращают основание обработки по ст. 6 ФЗ-152.

Статья 9 ФЗ-152 в редакции с 01.09.2025 (ФЗ-156) требует, чтобы отзыв согласия был простым и доступным. Если пользователь нажал «Удалить аккаунт», суды и РКН трактуют это как отзыв согласия. Срок на фактическое уничтожение — 30 дней с момента отзыва, если нет законного основания хранить данные дольше.

Исключения существуют: ФЗ-402 (бухгалтерский учёт) требует хранить первичные документы 5 лет; НК РФ — данные по транзакциям до 4 лет. Если SaaS обрабатывает платёжные данные, часть ПДн сохраняется на основании налогового законодательства. Но это исключение, а не правило. Остальные данные — профиль, поведенческие события, загруженные файлы — уничтожаются в 30-дневный срок.

Где в SaaS-архитектуре «живут» ПДн после удаления аккаунта?

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

Резервные копии. Большинство SaaS-платформ хранят бэкапы 7–90 дней. ПДн удалённого пользователя остаются в каждом снапшоте. ФЗ-152 не освобождает от обязанности уничтожения данных в резервных копиях — это позиция РКН, подтверждённая в методических рекомендациях. Технически это означает либо восстановление бэкапа с последующей зачисткой, либо шифрование с уничтожением ключа (crypto-shredding).

Аналитические хранилища и data warehouse. Если в DWH или озеро данных отправляются события с user_id, которые можно сопоставить с конкретным лицом, — это ПДн. Уничтожение в основной БД без зачистки аналитики не соответствует ст. 21 ФЗ-152.

ML-пайплайны и обученные модели. Данные, вошедшие в обучающую выборку, технически «растворены» в весах модели. Приказ РКН об обезличивании (действует с 01.09.2025) устанавливает 5 методов обезличивания; данные, прошедшие обезличивание по этим методам до включения в ML, могут не требовать последующего уничтожения. Если обезличивания не было — возникает вопрос о правомерности использования ПДн в ML-задачах.

Очереди событий и логи. Kafka-топики, S3-логи, Elasticsearch-индексы с email, IP, user_id — всё это ПДн, если позволяет идентифицировать субъекта. Логирование как ПДн — отдельный риск: регуляторы в ЕС и РФ последовательно признают IP-адреса персональными данными.

Данные у субарендаторов и подрядчиков. SaaS-мультиарендность означает, что один арендатор (корпоративный клиент) может хранить ПДн своих пользователей через вашу платформу. Здесь возникает цепочка: субъект — ваш клиент-оператор — вы как обработчик. По ст. 6 ч. 3 ФЗ-152 оператор отвечает за действия обработчика. Если клиент-оператор попросил удалить данные, а ваш сервис этого не сделал — ответственность несёт оператор, но и обработчик получает требования по договору поручения.

Какой уровень защищённости (УЗ) применим к SaaS с пользовательскими ПДн?

Постановление Правительства №1119 устанавливает 4 уровня защищённости ИСПДн. Выбор уровня зависит от трёх переменных: категория ПДн, тип угроз и число субъектов.

Категории ПДн в типичном SaaS: общие ПДн (имя, email, телефон, IP) — базовый случай; специальные (состояние здоровья, политические взгляды) и биометрические — если SaaS собирает фото, голос, биометрию для верификации. Специальные и биометрические категории автоматически повышают минимальный УЗ.

Число субъектов: порог 100 000 по ПП РФ №1119 разделяет УЗ-3 и УЗ-2 для систем с общими ПДн. SaaS с аудиторией выше 100 000 пользователей при угрозах 2-го типа попадает в УЗ-2, что требует использования сертифицированных ФСТЭК средств защиты.

Тип угроз определяется наличием недекларированных возможностей в системном ПО (тип 1), прикладном ПО (тип 2) или их отсутствием (тип 3). Большинство коммерческих SaaS-платформ работают с угрозами типа 3, что снижает требования.

Приказ ФСТЭК №21 содержит 109 мер в 15 группах: идентификация и аутентификация (ИАФ), управление доступом (УПД), защита носителей (ЗНИ), регистрация событий (РСБ), антивирусная защита (АВЗ), обнаружение вторжений (СОВ) и другие. Для УЗ-3 базовый набор включает около 60 мер; для УЗ-2 — расширенный с обязательной сертификацией СЗИ.

Облако в РФ — необходимое, но не достаточное условие. Провайдер облачной инфраструктуры (IaaS) не является оператором ПДн пользователей SaaS — им остаётся SaaS-компания. Договор с облачным провайдером должен содержать поручение обработки по ст. 6 ч. 3 ФЗ-152 с обязательными условиями: цели, перечень действий, обязательства по конфиденциальности и уничтожению.

Как документировать уничтожение ПДн в SaaS: что требует РКН

Статья 21 ФЗ-152 требует не только уничтожить ПДн, но и зафиксировать факт уничтожения. Отсутствие документации — самостоятельное нарушение, которое при проверке РКН трактуется как неисполнение обязанности.

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

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

Типовые сценарии: как CTO сталкивается с проблемой уничтожения ПДн

Сценарий 1. Субъект направил требование об уничтожении, аккаунт удалён, но данные остались в бэкапах.

Ситуация: пользователь удалил аккаунт через интерфейс, получил подтверждение по email. Через два месяца обратился в РКН с жалобой — проверил утечку и нашёл свои данные в базе, предположительно восстановленной из бэкапа конкурентов. РКН инициировал внеплановую проверку. При проверке выяснилось, что процедура уничтожения охватывала только основную БД; 14 резервных снапшотов за последние 90 дней содержали полные профили пользователей.

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

Вероятный исход: протокол по ч. 5 ст. 13.11 КоАП (невыполнение требования субъекта об уничтожении) — штраф 50–90 тыс. ₽; отдельно — протокол по ч. 1 ст. 13.11 за обработку без надлежащего основания — 150–300 тыс. ₽; предписание об устранении в 60 дней.

Стратегия: разработать технический регламент уничтожения с охватом всех хранилищ; внедрить crypto-shredding для бэкапов; заключить договор поручения обработки с облачным провайдером; ввести автоматический трекинг 30-дневного дедлайна.

Сценарий 2. ML-модель обучена на ПДн пользователей, один из которых требует уничтожения данных.

Ситуация: SaaS-платформа для HR-автоматизации (Уральский ФО, середина 2025) использовала профили пользователей для обучения модели ранжирования резюме. Соискатель, данные которого вошли в обучающую выборку, после удаления аккаунта направил требование о полном уничтожении всех его ПДн. CTO не мог подтвердить, входили ли данные субъекта в выборку, и не мог технически «извлечь» их из модели.

Доказательства: согласие на обработку ПДн не предусматривало цели использования в ML; отдельного согласия на использование в ML по ст. 9 ФЗ-152 не запрашивалось; обезличивания данных до включения в выборку не проводилось.

Вероятный исход: штраф по ч. 2 ст. 13.11 (обработка без надлежащего согласия) — 300–700 тыс. ₽; предписание об уничтожении модели или её переобучении на обезличенных данных.

Стратегия: с момента старта ML-проектов обезличивать ПДн перед включением в обучающие выборки по методам Приказа РКН об обезличивании; разграничивать цели обработки и запрашивать отдельное согласие на использование в ML там, где обезличивание невозможно.

Сценарий 3. Корпоративный клиент (арендатор) требует уничтожить данные своих пользователей после расторжения договора.

Ситуация: крупный корпоративный клиент расторг договор с SaaS-платформой для управления задачами (Центральный ФО, осень 2025). В договоре был прописан 90-дневный период хранения данных для возможности миграции. Клиент потребовал немедленного уничтожения, ссылаясь на ст. 21 ФЗ-152. SaaS-компания настаивала на 90-дневном сроке по договору.

Доказательства: договорное условие о 90-дневном хранении противоречит требованию субъекта об уничтожении при отсутствии законного основания; в договоре поручения обработки (если он был заключён корректно) должны быть предусмотрены условия уничтожения по требованию оператора-клиента.

Вероятный исход: спор решается в плоскости гражданского права; однако если корпоративный клиент-оператор подаст жалобу в РКН — возможен протокол по ч. 1 ст. 13.11 за обработку без оснований после истечения цели.

Стратегия: формулировать договорные условия с учётом ФЗ-152; 90-дневный период хранения допустим только при наличии законного основания; после истечения — уничтожение обязательно с подтверждением актом.

Как это применяется на практике

Кейс 1. IT-компания из Приволжского ФО, конец 2025 года. Разрабатывала B2B SaaS для управления персоналом; аудитория — около 80 000 пользователей. При внеплановой проверке РКН обнаружено: аккаунты удалялись программно, но данные сохранялись в аналитическом хранилище (ClickHouse) и в системе логирования (Elasticsearch) без ограничения срока. CTO представил доказательства того, что в аналитических данных использовались только агрегированные метрики — без прямой идентификации субъектов. РКН принял доводы частично: логи с email и user_id признаны ПДн, аналитика — нет. Назначен штраф по ч. 5 ст. 13.11 в диапазоне десятков тысяч рублей; выдано предписание об ограничении срока хранения логов до 90 дней с последующим обезличиванием. Компания внедрила автоматическое TTL на уровне Elasticsearch и переработала схему логирования с заменой email на псевдонимизированный идентификатор.

Кейс 2. SaaS-платформа для телемедицины (Северо-Западный ФО, начало 2026). Обрабатывала специальные категории ПДн — данные о состоянии здоровья пациентов. При расторжении договора с одной из клиник клиника потребовала уничтожить ПДн своих пациентов. Платформа провела уничтожение в основной БД, но резервные копии за 6 месяцев остались нетронутыми. В суде компания представила договор поручения обработки, в котором был прописан crypto-shredding как метод уничтожения данных в бэкапах. Суд установил, что crypto-shredding к моменту проверки не был реализован — ключи шифрования продолжали существовать. Штраф по ч. 5 ст. 13.11 в сотни тысяч рублей. После этого CTO внедрил автоматическое уничтожение ключей шифрования при получении запроса на удаление, что фактически делало данные в бэкапах невосстановимыми.

Услуги DATUM по теме

• Аудит соответствия 152-ФЗ — проверка всех хранилищ и процедур уничтожения ПДн
• DPIA (оценка воздействия) — оценка рисков SaaS-архитектуры с учётом ПП РФ №1119 и Приказа ФСТЭК №21
• Комплект ОРД под ключ — регламент уничтожения, договоры поручения обработки, акты уничтожения

Частые вопросы

1. Какой УЗ выбрать для SaaS?

Уровень защищённости определяется по ПП РФ №1119 в зависимости от трёх параметров: категория ПДн, тип актуальных угроз и число субъектов. Для большинства коммерческих SaaS с общими ПДн (email, имя, телефон) и угрозами 3-го типа при числе субъектов до 100 000 применяется УЗ-3. При превышении порога 100 000 субъектов или угрозах 2-го типа — УЗ-2, что требует сертифицированных ФСТЭК средств защиты информации. Специальные или биометрические ПДн автоматически повышают минимальный уровень независимо от числа субъектов. Определение УЗ следует закрепить в модели угроз и нарушителя.

2. Можно ли использовать иностранные облака?

Использование иностранных облаков для хранения ПДн граждан РФ нарушает ч. 5 ст. 18 ФЗ-152 (требование локализации). Запись, систематизация, накопление, хранение, уточнение и извлечение ПДн граждан РФ должны осуществляться в базах данных на территории РФ. С 01.07.2025 (после ФЗ-233) требование ужесточено: первичный сбор и обработка должны происходить в РФ. Иностранный облачный провайдер допустим только как зеркало или CDN без первичного хранения, при условии что основная база и первичная обработка находятся в России. Штраф за нарушение локализации — 1–6 млн ₽ по ч. 8 ст. 13.11 КоАП.

3. Что такое обезличивание для ML?

Обезличивание для ML — это преобразование ПДн таким образом, что определить принадлежность данных конкретному субъекту становится невозможным без дополнительной информации, которой у оператора нет. Приказ РКН об обезличивании (действует с 01.09.2025) устанавливает 5 допустимых методов: введение идентификаторов (псевдонимизация), изменение состава и семантики, декомпозиция, перемешивание и обобщение (агрегация). Если данные, вошедшие в обучающую выборку, прошли надлежащее обезличивание по одному из этих методов до включения в ML-пайплайн, требование об уничтожении к ним не применяется. Это ключевое архитектурное решение для SaaS, использующих ML.

4. Кто является оператором в мультиарендной SaaS?

В мультиарендной SaaS оператором ПДн конечных пользователей является компания-арендатор (корпоративный клиент), которая определяет цели и порядок обработки данных своих сотрудников или клиентов. SaaS-компания в этой модели выступает обработчиком по поручению оператора в соответствии с п. 3 ст. 6 ФЗ-152. Договор поручения обработки между оператором и SaaS-платформой обязателен. При этом SaaS-компания одновременно является оператором собственных данных пользователей своего сервиса (учётные записи, платёжные данные, логи). Отсутствие договора поручения делает SaaS-компанию соопоратором с полной ответственностью по ФЗ-152.

5. Какие средства защиты информации обязательны для SaaS?

Конкретный набор мер определяется Приказом ФСТЭК №21 на основании установленного УЗ. Для УЗ-3 и УЗ-4 допустимо использование несертифицированных средств при наличии обоснования. Для УЗ-1 и УЗ-2 ряд мер требует сертифицированных ФСТЭК СЗИ, в том числе в части межсетевого экранирования (ЗИС), обнаружения вторжений (СОВ) и антивирусной защиты (АВЗ). Для SaaS на базе контейнеров (Kubernetes, Docker) необходимо дополнительно обеспечить защиту среды виртуализации (ЗСВ) и защиту технических средств (ЗТС). Облачный провайдер с аттестатом ФСТЭК снимает часть требований к инфраструктурным мерам, но не к прикладным.

Итог

Удаление аккаунта в SaaS — это юридически значимое событие, которое запускает 30-дневный таймер уничтожения ПДн во всех хранилищах. Технический долг в виде «живых» бэкапов, аналитических хранилищ и ML-выборок с персональными данными — это не только архитектурная проблема, но и основание для штрафов до 500–700 тыс. ₽ при первом нарушении и до 500 млн ₽ при повторной утечке по ч. 15 ст. 13.11 КоАП.

Практика DATUM по технической стороне 152-ФЗ охватывает SaaS-платформы от определения УЗ и разработки модели угроз до регламента уничтожения ПДн и договоров поручения обработки с облачными провайдерами.

18 февраля 2027 года