Удаление логов по требованию субъекта

Требования субъекта об удалении персональных данных приходят всё чаще: пользователи знают о праве на уничтожение, а жалобы в Роскомнадзор стали стандартным инструментом давления. Для IT-команды SaaS-сервиса или корпоративной платформы это означает конкретную задачу: найти все хранилища, где есть ПДн субъекта, включая лог-файлы, удалить данные или обезличить их, задокументировать факт и ответить субъекту в срок. Ниже — как разобраться с правовой природой логов, выстроить процесс и избежать штрафа.

Являются ли логи персональными данными по ФЗ-152?

Вопрос не риторический: от ответа зависит, обязан ли оператор удалять конкретную запись по требованию субъекта. Ст. 3 ФЗ-152 определяет персональные данные как любую информацию, относящуюся к прямо или косвенно определённому физическому лицу. IP-адрес в сочетании с датой и временем действия позволяет идентифицировать пользователя через провайдера — это ПДн. Session ID, связанный с учётной записью, — ПДн. Запись вида «user_id=1234 endpoint=/api/payment 2025-11-03T14:22:01» — ПДн.

Напротив, агрегированная метрика без привязки к конкретному лицу («500 запросов к /api/search за час») — не ПДн, поскольку субъект неидентифицируем. Граница проходит по признаку идентифицируемости: если запись сама по себе или в сочетании с другими данными, доступными оператору, указывает на конкретного человека — это ПДн. Роскомнадзор неоднократно подтверждал эту позицию в методических разъяснениях: логи действий авторизованных пользователей относятся к персональным данным.

Практическое следствие: оператор обязан учитывать лог-файлы в реестре систем обработки ПДн, включать их в политику конфиденциальности, распространять на них требования ПП РФ №1119 об уровнях защищённости и отвечать на требования субъектов об удалении.

Что говорит закон о праве субъекта на уничтожение ПДн?

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

Срок ответа субъекту — 10 рабочих дней с даты обращения, с возможностью продления ещё на 5 рабочих дней при уведомлении субъекта (ст. 20 ФЗ-152). Срок уничтожения по ст. 21 — не более 7 рабочих дней с момента выявления оснований. Если оператор отказывает, он обязан письменно мотивировать отказ.

Ключевое противоречие для IT: лог-файл может содержать одновременно ПДн запрашивающего субъекта и технически необходимую информацию для расследования инцидентов, исполнения требований КИИ по 187-ФЗ или сохранения доказательной базы. В этом случае оператор вправе отказать в удалении, сославшись на законное основание обработки — например, исполнение требований нормативных актов (ст. 6 п. 2 ФЗ-152). Но отказ должен быть обоснован документально, а не объявлен устно.

Как работает удаление логов с учётом УЗ-1..4 и требований ФСТЭК?

Информационная система, обрабатывающая ПДн, получает уровень защищённости (УЗ) по ПП РФ №1119. От него зависит набор мер, включая требования к логированию и удалению данных. УЗ-4 — минимальный уровень для общих ПДн при небольшом числе субъектов и угрозах 3-го типа; УЗ-1 — максимальный, для спецкатегорий или биометрии при актуальных угрозах 1-го типа.

Приказ ФСТЭК №21 от 18.02.2013 содержит группу мер РСБ (регистрация событий безопасности) и ОДТ (обеспечение доступности). Конкретно: меры РСБ.1–РСБ.8 обязывают оператора вести журналы событий, защищать их целостность и обеспечивать хранение. С одной стороны, это создаёт обязанность вести логи. С другой — мера РСБ.8 предусматривает уничтожение защищаемой информации по истечении сроков хранения. Эти два требования не противоречат друг другу: оператор ведёт логи столько, сколько нужно для безопасности и исполнения нормативных требований, а по истечении срока или при наступлении законного основания — уничтожает.

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

Обезличивание логов как альтернатива удалению: что допустимо для ML?

Если удаление записи невозможно из-за технических зависимостей (лог используется для дообучения ML-модели, аудита безопасности или расследования инцидентов), оператор может предложить обезличивание как альтернативу. Ст. 21 ФЗ-152 допускает обезличивание вместо уничтожения, если основание обработки устранено, но данные нужны для иных целей без привязки к субъекту.

С 01.09.2025 действует Приказ РКН, устанавливающий 5 методов обезличивания: введение идентификаторов, изменение состава и семантики, декомпозиция, перемешивание, обобщение и агрегация. Для логов чаще всего применяются два метода: введение идентификатора (замена user_id на псевдоним без обратной таблицы соответствия) и обобщение (замена точного IP на маску /24 или страну). Результат должен исключать возможность идентификации субъекта без дополнительных данных, недоступных оператору.

Важное ограничение: обезличивание для ML должно быть воспроизводимым и верифицируемым. Если оператор заявляет, что данные обезличены, но модель способна восстановить оригинальный атрибут через инверсию признаков — это не обезличивание, а псевдонимизация, которая по-прежнему является обработкой ПДн. Для обучающих датасетов рекомендуется применять дифференциальную приватность или k-анонимность, совместимые с методами РКН.

Типовые сценарии: как CISO сталкивается с требованием удаления логов

Три ситуации, характерные для IT-инфраструктуры среднего и крупного бизнеса.

Сценарий 1. Пользователь требует удалить все данные после закрытия аккаунта. Ситуация: субъект закрыл учётную запись и потребовал уничтожения всех ПДн, включая логи действий. CISO обнаруживает, что access-логи хранятся в SIEM на 12 месяцев по требованиям ИБ-политики, а часть попала в архивные резервные копии S3. Доказательства: реестр систем не содержит упоминания SIEM как места хранения ПДн; договора поручения с облачным провайдером нет. Вероятный исход: при проверке РКН — штраф по ч. 1 ст. 13.11 КоАП (150 000–300 000 ₽) за обработку без законного основания после закрытия аккаунта плюс ч. 5 за неисполнение требования субъекта. Стратегия: внести SIEM и резервные копии в реестр систем, определить срок хранения логов, обоснованный требованиями ИБ, и описать его в политике. По истечении срока или при требовании субъекта — процедура удаления из всех систем, включая резервные копии.

Сценарий 2. SaaS-провайдер получает требование напрямую от субъекта, минуя клиента-оператора. Ситуация: пользователь корпоративного SaaS обращается к провайдеру, а не к своему работодателю. CISO провайдера не знает, как реагировать — оператором является клиент-юрлицо. Доказательства: в пользовательском соглашении SaaS не указано, кто является оператором для конечных пользователей; поручение обработки есть, но не описывает процедуру работы с запросами субъектов. Вероятный исход: провайдер может быть привлечён как обработчик по ст. 6 ФЗ-152, если суд установит, что он самостоятельно определял цели. Стратегия: в договоре поручения чётко разграничить роли, описать процедуру переадресации запросов субъектов клиенту-оператору в течение 3 рабочих дней, установить техническую возможность изолированного удаления данных конкретного субъекта по инструкции оператора.

Сценарий 3. Объект КИИ: требование удалить логи, которые нельзя трогать по 187-ФЗ. Ситуация: промышленная компания — субъект КИИ хранит логи SCADA-систем, содержащие идентификаторы операторов-физлиц. Субъект требует удаления. CISO знает, что по требованиям ГосСОПКА логи должны храниться не менее 3 лет. Вероятный исход при отказе без мотивировки: штраф по ч. 5 ст. 13.11. При правильно оформленном отказе — спор отсутствует. Стратегия: отказ субъекту должен быть письменным, с указанием конкретной нормы — обязательство сохранять информацию о событиях ИБ по требованиям 187-ФЗ и приказов ФСТЭК/ФСБ по КИИ. Применить обезличивание для атрибутов, не относящихся к событиям безопасности (например, удалить ФИО, сохранив идентификатор сессии).

Практика: как выглядят реальные последствия

Кейс 1. IT-компания (Северо-Западный ФО, лето 2025) получила требование от бывшего сотрудника об удалении всех ПДн, включая системные логи. CISO подтвердил удаление из основной базы, однако логи аутентификации оставались в резервных копиях ещё 6 месяцев. Субъект повторно обратился в РКН. По результатам внеплановой проверки оператору назначен штраф по ч. 5 ст. 13.11 КоАП. Ошибка — отсутствие процедуры удаления из резервных копий в регламенте обработки ПДн.

Кейс 2. Облачная платформа (Центральный ФО, осень 2025) с мультиарендной архитектурой не имела договора поручения обработки с клиентами-операторами. При требовании субъекта к одному из клиентов технически удалить данные оказалось невозможным без затрагивания данных других арендаторов. Арбитражный суд региона установил, что платформа фактически являлась соопера
тором и не выполнила требование ст. 21 ФЗ-152. Итог — штраф в диапазоне ч. 1 ст. 13.11 КоАП и предписание разработать технические меры изоляции данных по арендаторам. Оба кейса: менеджер уточняет реквизиты при публикации.

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

• Аудит соответствия 152-ФЗ — проверка всех систем хранения ПДн, включая логи и резервные копии
• DPIA (оценка воздействия) — оценка рисков при обработке логов для ML и аналитики
• Комплект ОРД под ключ — регламент удаления ПДн, политика хранения логов, договор поручения

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

1. Какой УЗ выбрать для SaaS, который обрабатывает логи пользователей?

Уровень защищённости определяется по ПП РФ №1119 исходя из трёх параметров: категория ПДн (общие, специальные, биометрические), тип актуальных угроз (1–3) и число субъектов. Для SaaS с общими ПДн, угрозами 3-го типа и числом субъектов до 100 000 — УЗ-4. При числе субъектов свыше 100 000 — УЗ-3. Если SaaS обрабатывает данные сотрудников клиентов в корпоративной HR-функции — возможно повышение до УЗ-3 из-за категории данных. Точный УЗ определяется в ходе DPIA с моделью угроз.

2. Можно ли использовать иностранные облака для хранения логов, содержащих ПДн граждан РФ?

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

3. Что такое обезличивание для ML и как оно соотносится с требованием субъекта об удалении?

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

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

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

5. Какие технические меры по Приказу ФСТЭК №21 обязательны для системы логирования?

Приказ ФСТЭК №21 от 18.02.2013 для систем логирования требует реализации мер группы РСБ (регистрация событий): определения состава регистрируемых событий, защиты журналов от изменения и несанкционированного доступа, обеспечения хранения в течение установленного срока (РСБ.1–РСБ.8). Минимальный набор для УЗ-4 — РСБ.1 (определение событий), РСБ.2 (запись) и РСБ.3 (защита записей). Для УЗ-3 добавляются РСБ.4 (мониторинг) и РСБ.7 (защита от переполнения). Точный перечень мер определяется в модели угроз.

Итог

Лог-файлы с идентификаторами пользователей — это персональные данные, и требования ФЗ-152 к ним применяются в полном объёме: учёт в реестре систем, уровень защищённости по ПП РФ №1119, технические меры по Приказу ФСТЭК №21 и обязанность исполнить требование субъекта об уничтожении в 7 рабочих дней. Отказ возможен только при наличии документально подтверждённого законного основания — например, требований КИИ по 187-ФЗ или судебного предписания.

DATUM сопровождает IT-компании и SaaS-провайдеров в выстраивании процессов обработки и удаления ПДн: от аудита систем хранения логов до разработки регламентов и договоров поручения, соответствующих требованиям ФЗ-152 и ФСТЭК.

13 января 2029 года