Нужно ли удалять ПДн из резервных копий по запросу субъекта?

Правовая коллизия, которая ставит в тупик большинство операторов

Где живут «умершие» данные?

Субъект персональных данных направил оператору требование об уничтожении своих данных. Оператор провёл работу: удалил записи из CRM, почты, файлового сервера. Получил обращение ещё раз — и снова всё почистил. Но что происходит с ежедневными, еженедельными, ежемесячными резервными копиями, которые тихо лежат на лентах и в облаке?

Именно здесь возникает правовая коллизия, о которой большинство операторов предпочитают не думать. Ответ на вопрос «нужно ли удалять ПДн из бэкапов» неочевиден, технически сложен и юридически рискован — в любую сторону.

Разберём всё по порядку.

Что говорит закон

Определение уничтожения по 152-ФЗ

Статья 3 Федерального закона от 27.07.2006 № 152-ФЗ «О персональных данных» определяет уничтожение персональных данных как действия, в результате которых становится невозможным восстановить содержание персональных данных в информационной системе и (или) уничтожаются материальные носители персональных данных [1].

Ключевая фраза — «невозможность восстановить». Если резервная копия существует и содержит ПДн субъекта, условие не выполнено: данные технически восстановимы.

Основания для уничтожения

Статья 21 152-ФЗ устанавливает несколько оснований, при которых оператор обязан уничтожить персональные данные [2]:

1. Выявлена неправомерная обработка — срок 3 рабочих дня для прекращения обработки, 10 рабочих дней — для уничтожения.
2. Субъект отозвал согласие на обработку — срок 30 дней.
3. Достигнуты цели обработки — срок 30 дней.
4. Субъект направил требование о прекращении обработки — срок 10 рабочих дней.

Закон прямо не оговаривает, что речь идёт только об «основных» хранилищах. Напротив, Роскомнадзор в своих разъяснениях подтвердил позицию: уволенный сотрудник вправе потребовать прекратить обработку своих ПДн — и в этом случае работодатель обязан их уничтожить, даже если они хранятся на отдельном носителе в виде резервной копии базы данных [3].

Механизм «отсрочки» при технической невозможности

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

• заблокировать эти данные (или обеспечить их блокирование);
• уничтожить их в срок не более шести месяцев (если иной срок не установлен федеральными законами) [2].

Таким образом, законодатель признаёт, что немедленное уничтожение данных из всех мест хранения может быть технически невозможным — и предоставляет «отсрочку» при условии блокировки.

Практики и юристы в области ПДн называют этот сценарий «механизмом блокировки-с-отложенным-уничтожением» и рассматривают именно его как применимый для резервных копий [4].

Что считается «невозможностью» уничтожения?

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

Технические ограничения бэкапов

Специалисты по ИТ-инфраструктуре давно признают проблему: «удалять ПДн из резервных копий технически невозможно» — в случае если используется традиционная архитектура полных или инкрементных бэкапов, где данные физически перемешаны [5].

Действительно, если резервная копия представляет собой монолитный снимок базы данных за конкретный момент времени, избирательное удаление записей без нарушения целостности архива невозможно. Восстановить такой бэкап без «лишних» данных не получится.

Ряд современных систем резервного копирования позволяет гранулярное удаление — но это скорее исключение для высококлассных enterprise-решений, а не массовая практика.

Что не является «невозможностью»

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

Кроме того, комментаторы отмечают, что «закон не предусматривает частичного уничтожения персональных данных оператором либо возможности их уничтожения в зависимости от вида носителя» [6]. Иными словами, оператор не может законно заявить: «В основной системе удалили, а в бэкапе — нет, потому что там сложно».

Алгоритм действий оператора при запросе субъекта

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

1. Проверить наличие оснований для сохранения данных. Существуют законные основания, при которых оператор вправе отказать в уничтожении даже по запросу субъекта: исполнение договора, исполнение требований законодательства (например, ФЗ-115 о противодействии отмыванию доходов обязывает банки хранить данные не менее 5 лет [7]), защита жизненно важных интересов, иные основания из ч. 2 ст. 6 и ч. 2 ст. 11 152-ФЗ.
2. Уничтожить данные из доступных систем в установленные сроки. Основные хранилища, СУБД, почта, файловые серверы, CRM — всё, откуда технически возможно гранулярное удаление, должно быть зачищено немедленно.
3. Заблокировать ПДн в резервных копиях. Если немедленное уничтожение из бэкапов невозможно, данные блокируются — то есть ограничивается любой доступ к ним и их обработка.
4. Документально зафиксировать блокировку. Факт блокировки и причины невозможности немедленного уничтожения фиксируются в акте. Это важно: при проверке Роскомнадзора именно документация будет свидетельствовать о добросовестности оператора.
5. Уничтожить данные из резервных копий в течение 6 месяцев. Это может означать: удаление соответствующих бэкапов целиком, ожидание естественной ротации резервных копий с запретом их восстановления, или гранулярное удаление при следующем цикле обслуживания систем хранения.
6. Уведомить субъекта и (при необходимости) РКН. По завершении уничтожения оператор обязан уведомить субъекта. Если дело касается неправомерной обработки, уведомляется и Роскомнадзор [2].
7. Оформить акт уничтожения. С 1 марта 2023 года оператор обязан подтверждать факт уничтожения актом (для автоматизированной обработки — дополнительно выгрузкой из журнала событий ИСПДн), согласно Приказу Роскомнадзора от 28.10.2022 № 179 [8].

Обезличивание как альтернатива уничтожению

С 1 сентября 2025 года в 152-ФЗ появилась норма, устанавливающая обезличивание как допустимую альтернативу уничтожению при достижении целей обработки — при условии, что данные не нужно уничтожать по иным основаниям [9].

Методы обезличивания закреплены в Приказе Роскомнадзора от 19.06.2025 № 140 [10]:

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

Применительно к резервным копиям обезличивание — теоретически более реализуемая процедура, чем гранулярное удаление. Однако требования строги: результат обезличивания должен исключать идентификацию субъекта без использования дополнительной информации. Кроме того, с 1 сентября 2025 года введено требование раздельного хранения: обезличенные данные нельзя хранить в одном месте с исходными [11].

Важно: обезличивание запрещено для специальных категорий ПДн (расовая принадлежность, здоровье, интимная жизнь и др.) вне специальных случаев [10].

Международный контекст: как решают аналогичную проблему по GDPR

Европейская практика в этом вопросе несколько мягче, но суть та же.

Статья 17 GDPR закрепляет право на удаление («право быть забытым»), которое распространяется на все копии данных, включая резервные [12]. Однако регуляторы — в частности, Информационный комиссар Великобритании (ICO) — признают, что немедленное удаление из резервных систем может быть технически нереализуемым [13].

Допустимый подход по GDPR: данные в бэкапе исключаются из любого будущего восстановления и уничтожаются в естественном цикле ротации. Этот подход должен быть задокументирован и доведён до сведения субъекта [14].

По данным отчёта Европейского совета по защите данных (EDPB) за 2026 год, проверка 764 операторов в 32 странах ЕС выявила: у многих организаций нет специфических процедур уничтожения данных из резервных систем, а некоторые вовсе не удаляют данные из бэкапов [14]. Это говорит о системности проблемы — она не специфична для России.

Типичные ошибки операторов

Следующие подходы несут очевидные правовые риски и не рекомендуются:

1. Полное игнорирование резервных копий при уничтожении. «Мы удалили из основных систем — этого достаточно» — такая позиция не соответствует букве закона и может быть оспорена Роскомнадзором или в суде.
2. Ссылка на техническую невозможность без блокировки и документирования. Сама по себе ссылка на сложность технической реализации не освобождает от обязанности. Необходимо заблокировать данные и зафиксировать причины в документах.
3. Восстановление данных из бэкапа после заявленного уничтожения. Если оператор сообщил субъекту об уничтожении, а затем в рамках аварийного восстановления поднял старый бэкап и восстановил данные — это нарушение. Данные субъекта при восстановлении не должны «воскресать».
4. Неведение реестра резервных копий. Без понимания, где и какие бэкапы существуют, организовать их управляемое уничтожение невозможно. Это фундаментальная проблема инвентаризации.
5. Ожидание, что проблема решится сама. Роскомнадзор последовательно ужесточает контроль, а штрафы с 30 мая 2025 года многократно выросли.

Практические рекомендации: чек-лист для оператора

Чтобы система работы с запросами на уничтожение ПДн охватывала резервные копии, рекомендуется:

1. Провести инвентаризацию всех мест хранения ПДн, включая бэкапы, архивы, тестовые среды, облачные копии и DR-сайты.
2. Описать политику резервного копирования в части ПДн: какие данные попадают в бэкапы, как долго хранятся, как организован доступ.
3. Разработать регламент ответа на запросы субъектов, в котором отдельно прописаны шаги для резервных копий: блокирование, сроки уничтожения, документирование.
4. Оценить техническую возможность гранулярного удаления из бэкапов. Если текущие системы этого не позволяют, рассмотреть архитектурные изменения или переход к решениям с поддержкой такой функциональности.
5. Внедрить «метки для уничтожения»: при поступлении запроса субъекта фиксировать его в реестре, а затем при каждой ротации бэкапов автоматически или вручную убеждаться, что данные субъекта не попали в новый цикл.
6. Разграничить бэкапы по срокам хранения: оперативные (7–30 дней), долгосрочные (год и более). Для долгосрочных архивов предусмотреть регламент проверки на предмет наличия ПДн с истёкшим сроком обработки.
7. Обучить ИТ-персонал: системные администраторы должны понимать, что восстановление данных из бэкапа, включающего «уничтоженные» ПДн, — это нарушение, а не рутинная операция.
8. Регулярно проводить тестирование процедуры: имитировать запрос субъекта и проверять, насколько полно и быстро отрабатывает алгоритм.

Ответственность за нарушения: штрафной пейзаж 2025–2026

С 30 мая 2025 года КоАП РФ приобрёл принципиально иное измерение для операторов ПДн (Федеральный закон от 30.11.2024 № 420-ФЗ) [15].

За невыполнение в срок требования субъекта об уничтожении ПДн (ч. 5 ст. 13.11 КоАП) штраф для юридических лиц составляет от 50 000 до 90 000 рублей, при повторном нарушении — вдвое больше [16].

За общее несоответствие требованиям обработки ПДн (ч. 1 ст. 13.11) штраф для организаций вырос до 150 000–300 000 рублей [15]. За повторное нарушение — от 300 000 до 500 000 рублей.

Особая строка — утечки, которые могут произойти в том числе из резервных копий. Здесь введены оборотные штрафы, зависящие от масштаба инцидента: при утечке данных 10 000–100 000 человек — от 5 до 10 млн рублей для организаций; при массовой утечке — до 500 млн рублей [17].

Дополнительно с декабря 2024 года введена уголовная ответственность за незаконные использование, передачу и хранение ПДн (ст. 272.1 УК РФ, ФЗ № 421-ФЗ от 30.11.2024) — наказание от штрафа до 10 лет лишения свободы в зависимости от последствий [18].

Тренды и будущее регулирования

Вектор движения очевиден: регуляторная нагрузка нарастает, а технические требования становятся всё конкретнее.

Введение с 1 сентября 2025 года требования о раздельном хранении обезличенных данных и исходных массивов, включая резервные копии и DR-сайты [11], фактически означает: архитектура хранения данных должна «знать» о статусе каждого набора ПДн.

Требование о локализации (ч. 5 ст. 18 152-ФЗ, вступила в силу с 1 июля 2025 года) — все бэкапы с ПДн граждан РФ должны храниться на серверах в России, а использование иностранных облаков для резервного копирования — нарушение [19].

EDPB в своём отчёте 2026 года зафиксировал, что многие операторы используют обезличивание как замену удалению, но качество такого обезличивания часто не соответствует стандартам — данные остаются фактически псевдонимизированными, а не анонимными [14]. Ожидается, что и Роскомнадзор будет аналогично ужесточать контроль в этом направлении.

В горизонте 2026–2027 годов стоит ожидать появления методических рекомендаций регулятора, прямо затрагивающих работу с резервными копиями — по аналогии с тем, как Приказ № 140 детализировал требования к обезличиванию.

Заключение: что делать прямо сейчас

Удалять ли ПДн из резервных копий по запросу субъекта? Ответ закона — да, но с учётом технических ограничений, которые позволяют использовать механизм блокировки и отсрочки до 6 месяцев.

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

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

Как «Пятый фактор» помогает решить задачу

Корень проблемы с бэкапами — в отсутствии актуальной карты данных. Оператор нередко не знает, в каких именно бэкапах и хранилищах находятся ПДн конкретного субъекта, какой давности эти копии и где их искать.

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

Когда поступает запрос субъекта, у оператора есть живая «карта ПДн»: в каких системах присутствуют данные этого человека, включая резервные копии, тестовые среды и сторонние хранилища. Это позволяет:

• точно идентифицировать все точки хранения и не пропустить ни одну;
• документировать, какие данные были заблокированы или уничтожены;
• контролировать соблюдение сроков (30 дней, 6 месяцев);
• быть готовыми к проверке Роскомнадзора с актуальной, а не устаревшей документацией.

Без такой «карты» уничтожение ПДн по запросу субъекта остаётся ручным, неполным и юридически уязвимым процессом.

Источники

[1] consultant.ru — Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных», ст. 3 — https://www.consultant.ru/document/cons_doc_LAW_61801/

[2] consultant.ru — Статья 21 152-ФЗ: обязанности оператора по уничтожению ПДн — https://www.consultant.ru/document/cons_doc_LAW_61801/d3fe43a7c415353b17faab255bc0de92bea127da/

[3] glavbukh.ru — Роскомнадзор подтвердил, что уволенный сотрудник вправе потребовать уничтожения ПДн из резервных копий — https://www.glavbukh.ru/art/390998-personalnye-dannye-chto-eto-chto-k-nim-otnosyat-kak-ispolzuyutsya

[4] comply.ru — Рекомендации по процедуре уничтожения персональных данных — https://comply.ru/tpost/5xcrm0ro31-rekomendatsii-po-protsedure-unichtozheni

[5] lib.itsec.ru — Закон «О персональных данных»: старые песни о главном — https://lib.itsec.ru/articles2/pravo/zakon-o-personaljnyh-dannyh-starye-pesni-o-glavnom

[6] rulaws.ru — Комментарий к ст. 21 152-ФЗ: об отсутствии частичного уничтожения — https://rulaws.ru/laws/Federalnyy-zakon-ot-27.07.2006-N-152-FZ/Statya-21/

[7] data-sec.ru — Сроки уничтожения персональных данных по 152-ФЗ (в т.ч. коллизия с ФЗ-115) — https://data-sec.ru/personal-data/destruction-deadline/

[8] consultant.ru — Приказ Роскомнадзора от 28.10.2022 № 179 «Требования к подтверждению уничтожения ПДн» — https://www.consultant.ru/law/hotdocs/78098.html

[9] kontur.ru — Добровольное обезличивание персональных данных с 1 сентября 2025 года — https://kontur.ru/articles/979

[10] spectrumdata.ru — Методы обезличивания по Приказу РКН № 140 от 19.06.2025 — https://spectrumdata.ru/blog/proverka-soiskatelya/obrabotka-personalnykh-dannykh-poshagovaya-instruktsiya-dlya-hr/

[11] companies.rbc.ru — Как работать с ПДн в 2025 году: изменения с 1 сентября — https://companies.rbc.ru/news/BSZ231iAod/kak-rabotat-s-personalnyimi-dannyimi-v-2025-godu-izmeneniya-s-1-sentyabrya/

[12] gdpr-info.eu — Art. 17 GDPR: Right to erasure («right to be forgotten») — https://gdpr-info.eu/art-17-gdpr/

[13] ico.org.uk — Right to erasure — https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/individual-rights/right-to-erasure/

[14] legiscope.com — Right to Erasure Under GDPR: что говорит отчёт EDPB 2026 года о бэкапах — https://www.legiscope.com/blog/right-to-erasure-gdpr.html

[15] consultant.ru — Новые штрафы за нарушения в области ПДн с 30 мая 2025 года — https://www.consultant.ru/legalnews/28492/

[16] kodap.ru — Ст. 13.11 КоАП РФ: нарушение законодательства о персональных данных — https://www.kodap.ru/razdel-2/glava-13/st-13-11-koap-rf

[17] data-sec.ru — Штрафы за персональные данные в 2026 году — https://data-sec.ru/personal-data/fines/

[18] pravovest-audit.ru — Обработка персональных данных: изменения с 30.05.2025 (ст. 272.1 УК РФ) — https://pravovest-audit.ru/nashi-statii-nalogi-i-buhuchet/izmeneniya-v-obrabotke-personalnykh-dannykh-s-30-maya-2025-goda/

[19] intecweb.ru — Запрет хранения ПДн на иностранных серверах — https://intecweb.ru/company/news/zapret_khraneniya_pdn_na_inostrannykh_serverakh/