Резервное копирование персональных данных: что требует 152-ФЗ и почему бэкап сам становится утечкой

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

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

Обязывает ли 152-ФЗ делать резервные копии?

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

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

Приказ ФСТЭК №21 раскрывает состав мер по группам, включая обеспечение доступности персональных данных. Конкретный набор оператор выбирает сам, отталкиваясь от уровня защищённости по постановлению Правительства №1119 и от актуальных угроз — подробнее в статье «Приказ ФСТЭК №21: что касается владельца сайта».

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

Почему резервная копия чаще утекает, чем рабочая база?

Рабочая база защищена: пароль, ограничение доступа по сети, журнал обращений, отдельный пользователь для приложения. Копия почти всегда живёт вне этого периметра.

Типичные места, где бэкап становится публичным:

1. Архив в корне сайта. backup.zip, dump.sql, site_old.tar.gz, оставленные после переезда или обновления. Скачиваются по прямой ссылке без всякого взлома.
2. Копия в облачном диске сотрудника, расшаренная «по ссылке» подрядчику пять лет назад.
3. Тестовая среда из боевого дампа. Полная копия базы с настоящими клиентами, доступная без пароля, потому что «это же тест».
4. Копия у бывшего подрядчика. Агентство, которое делало сайт, хранит дамп у себя — и продолжает хранить после окончания договора.
5. Почтовая рассылка выгрузок. Ежемесячный отчёт с полной таблицей заказов, уходящий на личные почтовые ящики.
6. Панель хостинга с бэкапами и слабым паролем — доступ к панели означает доступ ко всем копиям сразу.

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

Где хранить копии и чего не делать?

Тестовая среда — отдельный случай. Правильный путь — не копия боевой базы, а обезличенный набор: требования и методы обезличивания установлены приказом Роскомнадзора №140, а различие между обезличиванием и псевдонимизацией разобрано в статье «Обезличивание, анонимизация, псевдонимизация».

Что делать с резервными копиями, когда данные нужно уничтожить?

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

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

Отсюда рабочая схема для резервных копий:

1. Удалить данные из рабочей системы в течение тридцати дней.
2. Зафиксировать, в каких копиях данные остаются, и заблокировать их — то есть исключить любое использование, а не просто «не трогать».
3. Обеспечить уничтожение при плановой ротации копий, уложившись в шесть месяцев.
4. Оформить подтверждение уничтожения.

Подтверждение — не свободная форма. Приказ Роскомнадзора №179 от 28.10.2022 требует акт об уничтожении персональных данных, а при обработке с использованием средств автоматизации — акт и выгрузку из журнала регистрации событий в информационной системе. Выгрузка содержит сведения о субъекте, чьи данные уничтожены, перечень категорий уничтоженных данных и наименование информационной системы. Сроки и основания удаления по запросу человека разобраны в статье «Право на удаление персональных данных».

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

Кто отвечает, если копию потерял подрядчик?

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

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

Что из этого следует для договора:

• Поручение оформлено договором и называет перечень персональных данных, перечень действий с ними, цели обработки, обязанность соблюдать конфиденциальность и требования к защите по статье 19 152-ФЗ. Само поручение обработки подрядчику допускается с согласия субъекта, если иное не предусмотрено федеральным законом, — это стоит предусмотреть в тексте согласия, которое человек подписывает на сайте.
• Указан срок, в который подрядчик сообщает вам об инциденте. Обязанность уведомить Роскомнадзор об утечке — на операторе, и срок жёсткий: 24 часа с момента выявления инцидента (подробнее — в статье «Как обнаружить утечку персональных данных»). Если подрядчик узнает об утечке через неделю, ваши 24 часа это не продлит.
• Прописано удаление копий после окончания работ и способ подтверждения, что они удалены.
• Зафиксировано, где физически хранятся копии — иначе вы не сможете ответить ни на вопрос о локализации, ни на вопрос о трансграничной передаче.

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

Можно ли хранить резервную копию за границей?

Здесь смешивают два разных требования, и от этого получаются противоположные советы.

Локализация. Часть 5 статьи 18 152-ФЗ в редакции Федерального закона от 28.02.2025 №23-ФЗ, действующей с 1 июля 2025 года, прямо не допускает при сборе персональных данных граждан России запись, систематизацию, накопление, хранение, уточнение и извлечение с использованием баз данных, находящихся за пределами территории РФ (исключения — только случаи из пунктов 2, 3, 4, 8 части 1 статьи 6 152-ФЗ). Слово «хранение» в этом перечне есть, а резервная копия — это хранение. Если зарубежная копия остаётся единственным или первичным местом, где данные записываются и обновляются, локализация не выполнена. Если российская база первична и полна, зарубежная копия формально попадает уже в поле статьи 12 152-ФЗ о трансграничной передаче — но это зона риска, а не безопасная схема. Безопасный вариант один: держать копии там же, где первичную базу. Подробнее о требовании — в статье «Хранение персональных данных на серверах в России», о санкциях — в статье «Штрафы за нарушение локализации».

Трансграничная передача. Отправка копии на зарубежный сервер — это ещё и трансграничная передача по статье 12 152-ФЗ, и уведомить о ней Роскомнадзор нужно до начала передачи. Перечень стран, обеспечивающих адекватную защиту, утверждён приказом Роскомнадзора №128 от 05.08.2022; сам критерий формирования перечня в 2026 году уточнён Федеральным законом №265-ФЗ. Порядок — в статье «Трансграничная передача персональных данных».

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

Сколько хранить резервные копии?

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

• Цель обработки. Данные хранятся не дольше, чем этого требует цель; достигнута цель — данные подлежат уничтожению.
• Обязательное хранение документов. Бухгалтерские и договорные документы хранятся по своим правилам, и это законное основание не удалять часть данных вместе с остальными.
• Технический горизонт восстановления. Для сайта обычно достаточно ежедневных копий за последние две недели и ежемесячных — не глубже полугода, чтобы не ломать схему блокирования и уничтожения. Глубокий архив «на десять лет» чаще создаёт риск, чем пользу.

Что именно и как долго хранит интернет-магазин после покупки, разобрано в статьях «Персональные данные покупателей интернет-магазина» и «Возврат товара и хранение данных покупателя».

Чек-лист: резервное копирование без новых рисков

1. Перечень копий: какие есть, где лежат, кто имеет доступ, до какого срока хранятся.
2. Ни одной копии в публичных каталогах сайта — проверено вручную по типовым именам файлов.
3. Архивы с персональными данными зашифрованы, ключ хранится отдельно.
4. Восстановление проверено на практике, дата проверки зафиксирована.
5. Ротация копий короче шести месяцев.
6. Тестовые среды работают на обезличенных данных.
7. Подготовлена форма акта об уничтожении по приказу Роскомнадзора №179.
8. Договор с подрядчиком обязывает удалить копии после окончания работ.
9. Если копия уходит за рубеж — подано уведомление о трансграничной передаче.
10. Внешний контур сайта проверен: политика, формы, согласия, сторонние скрипты.

Последний пункт — единственный, который проверяется без вашего участия и который первым видит автоматизированный мониторинг. Бесплатный скан на rkn-ok.ru покажет внешний контур сайта: политику, формы, согласия и сторонние скрипты — то, что видит любой посетитель и регулятор. Бэкапы в публичных каталогах он не ищет: пункт 2 чек-листа придётся проверить руками.

→ Проверить сайт на нарушения 152-ФЗ (бесплатно, 30 секунд)

Что читать дальше

• Как обнаружить утечку персональных данных — где ещё у сайта открыта дверь
• Право на удаление персональных данных — сроки и основания уничтожения
• Защита от CSRF-атак — ещё одна мера из того же круга: статья 19 152-ФЗ и приказ ФСТЭК №21
• Подзаконные акты к 152-ФЗ — где искать требования целиком
• Обезличивание, анонимизация, псевдонимизация — как делать тестовые среды правильно

Источники: Федеральный закон №152-ФЗ «О персональных данных» — статьи 6, 12, 18, 19, 21; часть 5 статьи 18 приводится в редакции Федерального закона от 28.02.2025 №23-ФЗ, действующей с 01.07.2025; приказ Роскомнадзора №179 от 28.10.2022; приказ ФСТЭК №21 от 18.02.2013; постановление Правительства №1119 от 01.11.2012.