Резервные копии и персональные данные: как удалять, ограничивать доступ и доказывать соблюдение сроков хранения

Невидимый риск в каждом бэкапе: почему резервные копии превращаются в юридическую ловушку

Зачем эта тема важна именно сейчас

Представьте типичную ситуацию: клиент прислал требование об удалении своих данных. Разработчики оперативно очистили продуктивную базу, CRM, почту. Через полгода проводится плановое восстановление бэкапа для тестирования — и данные этого клиента «воскресли». Или: регулятор проводит внеплановую проверку и запрашивает подтверждение уничтожения ПДн уволенных сотрудников — а акты об уничтожении не составлялись вовсе.

Эти сценарии становятся всё более реальными по мере того, как ужесточается российское законодательство о персональных данных. Подписанный Президентом в ноябре 2024 года Федеральный закон № 420-ФЗ [1] с 30 мая 2025 года кратно увеличил штрафы за нарушения — до 500 млн рублей для организаций и ввёл уголовную ответственность до 10 лет [2]. На этом фоне вопрос о том, что происходит с персональными данными в резервных копиях, перестал быть теоретическим.

Данная статья предназначена для широкой аудитории: ИТ-директоров и системных администраторов, специалистов по информационной безопасности, юристов и DPO (ответственных за обработку ПДн), а также руководителей, которым необходимо понять реальные операционные риски и технически грамотно выстроить процессы работы с бэкапами в правовом поле 152-ФЗ.

Часть 1. Правовая рамка: что требует российское законодательство

1.1. Принцип хранения «не дольше, чем необходимо»

Основополагающая норма содержится в части 7 статьи 5 Федерального закона № 152-ФЗ «О персональных данных» [3]: хранение персональных данных должно осуществляться в форме, позволяющей определить субъекта, не дольше, чем этого требуют цели обработки. После достижения цели или утраты необходимости в её достижении данные подлежат уничтожению или обезличиванию.

Статья 21 того же закона [4] конкретизирует сроки:

1. 30 дней с даты достижения цели обработки (общий случай).
2. 30 дней с момента отзыва субъектом согласия на обработку.
3. 10 дней при выявлении оператором факта нарушения принципов обработки.
4. 7 дней при поступлении доказательного требования от субъекта ПДн.
5. 10 рабочих дней при обращении субъекта с требованием о прекращении обработки (срок может быть продлён ещё на 5 рабочих дней при мотивированном уведомлении).

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

1.2. Параллельные сроки из других отраслевых законов

152-ФЗ не работает в вакууме. Компании, работающие в регулируемых отраслях, обязаны учитывать конкурирующие требования [5]:

1. ФЗ-115 (противодействие отмыванию доходов): банки, страховщики, посредники обязаны хранить информацию о клиентах не менее 5 лет с момента прекращения отношений.
2. Налоговый кодекс РФ: первичные учётные документы хранятся 5 лет (приказ Росархива от 20.12.2019 № 236) [6].
3. Трудовое законодательство: документы по личному составу, созданные после 2003 года, — 50 лет [7].
4. Кредитные истории: 10 лет в бюро кредитных историй.

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

1.3. Локализация: резервные копии должны быть в России

С 1 июля 2025 года вступила в силу новая редакция части 5 статьи 18 152-ФЗ (ФЗ-23 от 28.02.2025) [8]. Теперь первичный сбор, запись, систематизация и хранение ПДн граждан РФ должны осуществляться в базах данных, физически расположенных на территории России. Это требование распространяется на резервные копии — хранить бэкап персональных данных российских граждан в зарубежном облаке или дата-центре без соблюдения установленного порядка трансграничной передачи недопустимо [9].

1.4. Требования к документированию уничтожения

Приказ Роскомнадзора от 28.10.2022 № 179 [10], действующий с 1 марта 2023 года по 1 марта 2029 года, устанавливает обязательный набор подтверждающих документов:

1. Для неавтоматизированной обработки: акт об уничтожении персональных данных.
2. Для автоматизированной обработки: акт об уничтожении плюс выгрузка из журнала регистрации событий в информационной системе персональных данных (ИСПДн).

Акт должен содержать: наименование оператора и лица-исполнителя, ФИО субъектов (или иные идентифицирующие сведения), категории уничтоженных данных, наименование уничтоженного носителя, дату уничтожения, подписи ответственных лиц [10]. Акты и выгрузки из журналов хранятся минимум 3 года [10].

Часть 2. Техническая проблема: почему «удалить» сложнее, чем кажется

2.1. Анатомия хранения данных в современной организации

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

1. Продуктивные базы данных (СУБД): основной источник.
2. Полные резервные копии баз: создаются раз в неделю или раз в сутки.
3. Инкрементальные и дифференциальные бэкапы: ежедневные «срезы» изменений.
4. Архивные ленты и холодные хранилища: долгосрочное хранение.
5. Тестовые и dev-среды: копии продуктивных данных для разработки.
6. Логи приложений и SIEM-систем: ПДн могут попасть в логи при ошибках.
7. Почтовые архивы: письма с вложениями, содержащими ПДн.
8. Снимки виртуальных машин (VM snapshots): «фотографии» состояния систем.
9. Репликационные копии: синхронизированные дубликаты для отказоустойчивости.
10. Резервные копии в облаке (при гибридной инфраструктуре).

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

2.2. Технические методы удаления ПДн

Практика информационной безопасности и международный опыт [11, 12, 13] выработали несколько подходов, каждый из которых применим в разных сценариях.

Физическое удаление (перезапись) — запись поверх данных случайными или нулевыми битами несколько раз (метод Гутмана, стандарт DoD 5220.22-M). Применимо для отдельных файлов и баз данных с возможностью гранулярного доступа к записям. Минус: ресурсоёмко для больших резервных копий.

Криптографическое стирание (Cryptographic Erasure) — шифрование данных с последующим уничтожением ключа. Суть метода: если данные зашифрованы, а ключ уничтожен, они становятся практически недоступными — как сейф, к которому сожгли все ключи [14]. Метод особенно эффективен для облачных хранилищ и ситуаций, когда физическая перезапись невозможна или нецелесообразна [15]. Для реализации необходимо: шифровать резервные копии при создании (AES-256 или ГОСТ Р 34.12-2015 «Кузнечик» для систем, требующих отечественной криптографии), хранить ключи отдельно от данных (рекомендуется HSM — аппаратный модуль безопасности) [16], иметь реестр, какой ключ соответствует каким данным какого субъекта.

Режим «вне использования» (beyond use) — данные в бэкапе не удаляются немедленно, но блокируются от любого доступа и использования. Применяется как временная мера, когда техническое удаление невозможно в установленные сроки. По истечении срока хранения бэкапа или при восстановлении — данные удаляются из восстановленной копии до возврата в продуктивную среду. Этот подход признаётся рядом европейских регуляторов — в частности, французским CNIL [15] — при условии чёткого документирования.

Физическое уничтожение носителей — дегауссирование (для магнитных лент), шредерование, инсинерация (сжигание). Используется при выводе из эксплуатации физических носителей с резервными данными. Стандарт NIST SP 800-88 регламентирует методы и уровни санации носителей [17].

2.3. Специфика различных типов бэкапов

Разные виды резервных копий требуют разных подходов.

Для логических резервных копий баз данных (SQL dump, pg_dump) возможна гранулярная работа: восстановить копию, удалить нужные записи, создать новую копию. Это трудоёмко, но технически реализуемо.

Для снимков файловых систем (LVM snapshot, ZFS snapshot, VM snapshot) гранулярное удаление крайне затруднено — снимок представляет собой «образ» определённого момента времени. Криптографическое стирание или ожидание ротации становятся предпочтительными стратегиями.

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

2.4. Проблема тестовых сред

Отдельного внимания заслуживает категория тестовых и девелоперских сред. По данным многолетней практики ИБ-аудитов, разработчики нередко работают с «продуктовой копией» базы данных, не подозревая, что там содержатся реальные ПДн. Когда субъект требует удаления своих данных, ИТ-команда чистит продуктивную среду — но о тестовой просто не думает.

В российском правовом контексте использование реальных ПДн в тестовых средах без соответствующего правового основания само по себе является нарушением принципа минимизации данных (статья 5 152-ФЗ). Решение: обязательная анонимизация или обезличивание данных перед передачей в непродуктивные среды.

Часть 3. Разграничение доступа к резервным копиям

3.1. Принцип минимальных привилегий

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

Для резервных копий применимы следующие механизмы:

1. Ролевая модель доступа (RBAC): право на восстановление из бэкапа и право на чтение содержимого бэкапа — разные роли. Инженер, делающий резервирование, не должен иметь возможности просматривать данные внутри бэкапа.
2. Шифрование бэкапов с раздельным хранением ключей: бэкап зашифрован — без ключа прочитать его невозможно. Ключи хранятся в защищённом хранилище (HSM или отдельный Key Management Service) с собственной моделью доступа [16].
3. Immutable backups: бэкапы записываются в режиме «только чтение» (WORM — Write Once, Read Many). Такой подход защищает от злоумышленника, пытающегося удалить резервную копию, и от случайного изменения.
4. Отдельная сеть для резервного копирования: бэкап-инфраструктура изолируется в отдельном сегменте сети, недоступном из корпоративной сети напрямую.
5. Многофакторная аутентификация для администраторов бэкап-систем.
6. Логирование всех операций с бэкапами: кто, когда, что восстанавливал или просматривал.

3.2. Разграничение доступа при восстановлении

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

1. Определить процедуру «replay erasure requests»: перед возвратом восстановленных данных в продуктивную среду система должна повторно применить все запросы на удаление ПДн, которые были обработаны после даты создания бэкапа [13].
2. Вести реестр запросов на удаление с датами: при любом восстановлении этот реестр используется как чеклист для повторной чистки.
3. Ограничить список лиц, имеющих право инициировать восстановление из бэкапа, и требовать мотивированного запроса с согласованием.

3.3. Особенности облачных бэкапов

Для резервных копий в облаке ситуация осложняется тем, что физическую инфраструктуру контролирует провайдер. Ключевые требования при работе с облачными бэкапами в российском правовом поле [8, 9]:

1. Провайдер должен иметь дата-центры на территории России (требование локализации).
2. В договоре с провайдером должны быть прописаны обязанности по защите ПДн (статья 6 152-ФЗ, обработка по поручению).
3. Необходимо убедиться, что политика удаления провайдера соответствует требованиям 152-ФЗ: при удалении данных они не должны оставаться в «мягком удалении» (soft delete) или в бэкапах самого провайдера за пределами согласованного срока.
4. Уточнить политику шифрования: кто управляет ключами — провайдер или клиент? Для соответствия требованиям желательно, чтобы ключами шифрования управлял оператор ПДн (модель BYOK — Bring Your Own Key).

Часть 4. Документирование и доказательство соблюдения сроков

4.1. Что именно нужно доказать

Оператор персональных данных должен быть способен подтвердить проверяющим органам три ключевых факта:

1. Данные конкретного субъекта были уничтожены (или данные определённой категории уничтожены после истечения срока хранения).
2. Уничтожение произошло в установленные законом сроки.
3. Уничтожение охватило все системы, где эти данные хранились, включая резервные копии.

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

4.2. Реестр ПДн и карта данных: фундамент всей системы

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

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

4.3. Автоматизация ведения журналов

Ручное документирование не масштабируется. При сотнях субъектов, требующих удаления данных ежемесячно, или при нескольких десятках информационных систем, ручной учёт становится неуправляемым. Современная практика предполагает:

1. Автоматическое логирование всех операций удаления данных в СУБД с сохранением метаданных (идентификатор субъекта, категория данных, дата операции, исполнитель).
2. Интеграцию системы обработки запросов субъектов (DSR — Data Subject Requests) с системами хранения данных: при поступлении запроса автоматически формируется задача на удаление во всех связанных системах.
3. Автоматическую генерацию актов об уничтожении на основе логов.
4. Систему напоминаний и дедлайн-трекинга по срокам уничтожения.

4.4. Политика хранения резервных копий как инструмент compliance

Хорошо выстроенная политика хранения бэкапов — это одновременно и технический инструмент, и юридическая защита [18]. Основные принципы:

1. Определить сроки хранения для каждого типа бэкапа: ежедневные — 7–30 дней, еженедельные — 30–90 дней, ежемесячные — до 1 года, архивные — в соответствии с требованиями конкретного вида данных.
2. Привязать сроки хранения бэкапов к максимальному сроку хранения ПДн в данной системе: бэкап не может «жить» дольше, чем допустимо хранить данные в системе-источнике.
3. Автоматически удалять устаревшие бэкапы без возможности восстановления.
4. Документировать каждый цикл ротации бэкапов.

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

Часть 5. Практический чек-лист

5.1. Инвентаризация: что у вас есть

1. Составьте полный перечень всех систем, хранящих ПДн: СУБД, почтовые серверы, файловые хранилища, CRM, ERP/1С, AD/LDAP, бэкап-системы, тестовые среды, архивные ленты.
2. Для каждой системы определите: какие категории ПДн хранятся, каков установленный срок хранения, входит ли система в периметр резервного копирования.
3. Проверьте, где и как создаются резервные копии: локальные бэкапы, облачные, ленточные архивы.
4. Выясните, шифруются ли бэкапы и кто управляет ключами.
5. Проверьте, есть ли тестовые среды с реальными ПДн — и если есть, обезличьте их немедленно.

5.2. Политики и процедуры

1. Разработайте или обновите политику хранения и уничтожения ПДн с явными сроками для каждой категории данных.
2. Создайте отдельную процедуру для резервных копий: что происходит при поступлении запроса на удаление, как обеспечивается режим «вне использования», как данные удаляются при восстановлении.
3. Введите процедуру обработки DSR (Data Subject Requests): от получения запроса до документального подтверждения исполнения.
4. Опишите порядок вывода из эксплуатации носителей с бэкапами.

5.3. Технические меры

1. Внедрите шифрование всех резервных копий с управлением ключами (ключи хранятся отдельно от данных).
2. Настройте автоматическую ротацию бэкапов с удалением устаревших копий.
3. Внедрите RBAC для бэкап-систем: разделите роли «создание бэкапа», «восстановление», «администрирование».
4. Настройте детальное логирование всех операций с резервными копиями.
5. Тестируйте процедуру восстановления регулярно, фиксируя результаты — и включите в неё шаг повторного применения запросов на удаление.
6. Рассмотрите применение технологии тегирования данных субъектов в базах для облегчения поиска и удаления.

5.4. Документирование и аудит

1. Внедрите систему ведения актов об уничтожении ПДн в соответствии с Приказом РКН № 179 [10].
2. Обеспечьте экспорт/выгрузку из журнала регистрации событий ИСПДн для каждого факта уничтожения.
3. Храните акты и выгрузки не менее 3 лет.
4. Проводите внутренние аудиты не реже одного раза в год: проверяйте фактическое наличие и полноту документов об уничтожении.
5. Актуализируйте карту персональных данных при каждом изменении ИТ-ландшафта.

Часть 6. Ошибки и риски: как компании подставляют себя

6.1. Типичные ошибки при работе с бэкапами

Ошибка первая: «удалили из базы — значит удалили везде». Это самая распространённая и самая дорогостоящая иллюзия. Удаление из продуктивной базы не затрагивает ни один существующий бэкап.

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

Ошибка третья: отсутствие шифрования бэкапов. Незашифрованная резервная копия, попавшая не в те руки (при утере, краже, взломе), — это прямая утечка в чистом виде. По статистике InfoWatch, в 2024 году в России было зафиксировано 592 случая компрометации ПДн, при этом общий объём скомпрометированных данных превысил 1,5 млрд записей [19].

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

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

Ошибка шестая: облачные бэкапы у иностранного провайдера. После вступления в силу изменений в статью 18 152-ФЗ с 1 июля 2025 года [8] это является прямым нарушением требований о локализации.

Ошибка седьмая: игнорирование подрядчиков. Если обработку ПДн (включая резервное копирование) осуществляет внешний подрядчик, ответственность за надлежащее уничтожение данных при истечении срока хранения не снимается с оператора. Это должно быть закреплено в договоре поручения [3].

6.2. Риски при восстановлении из бэкапа

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

Без процедуры «replay erasure» (повторного применения запросов на удаление после восстановления) каждое восстановление из бэкапа потенциально является нарушением права субъекта на удаление данных.

Часть 7. Масштаб проблемы: что говорит статистика

Роскомнадзор по итогам 2024 года зафиксировал 135 фактов утечек персональных данных, содержащих более 710 млн записей о россиянах [20]. При этом, по оценке аналитического центра InfoWatch, реальное количество инцидентов с компрометацией ПДн в 2024 году составило 592 случая [19] — расхождение объясняется разными методологиями подсчёта.

За первое полугодие 2025 года, несмотря на введение жёсткой ответственности, Роскомнадзор зафиксировал ещё 35 утечек с компрометацией более 39 млн записей [21]. Заместитель председателя правления Сбербанка Станислав Кузнецов на SOC-форуме в ноябре 2024 года заявил, что, по имеющимся данным, около 90% взрослого населения России в той или иной части имеют свои персональные данные в открытом доступе [22].

Что касается санкций: с 30 мая 2025 года штрафы за первичную утечку ПДн составляют для юридических лиц от 3 до 15 млн рублей в зависимости от объёма скомпрометированных данных [1]. За повторную утечку — 1–3% годовой выручки (минимум 20–25 млн рублей, максимум 500 млн рублей) [2]. Помимо этого, новая статья 272.1 УК РФ предусматривает лишение свободы до 10 лет за незаконные операции с ПДн [2].

Часть 8. Международный опыт и альтернативные подходы

8.1. Как регуляторы разных стран решают дилемму «бэкап vs право на удаление»

Международный опыт показывает, что жёсткого единообразия нет даже среди европейских регуляторов GDPR [12, 13, 15].

Британский ICO (Information Commissioner's Office) признаёт, что данные могут оставаться в бэкапах в течение определённого времени, но требует принять все разумные меры для их удаления и поместить данные «вне использования» [13].

Французский CNIL не требует немедленного удаления из бэкапов при обращении с правом на забвение — но обязывает чётко информировать субъекта о том, что данные в бэкапе будут удалены в соответствии с расписанием ротации [15].

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

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

В российском праве специальных разъяснений Роскомнадзора по вопросу резервных копий на сегодняшний день не публиковалось (данные не найдены в открытых источниках). Однако буква закона — «уничтожить персональные данные» — не делает исключений для резервных копий. Поэтому наиболее безопасная позиция: применять технические меры в той мере, в которой это возможно, и документировать режим «вне использования» там, где немедленное удаление невозможно.

8.2. Подход privacy-by-design для бэкап-инфраструктуры

Концепция privacy-by-design предполагает встраивание требований защиты ПДн в архитектуру систем с самого начала, а не добавление их «поверх» как надстройки. Применительно к резервному копированию это означает:

1. Шифрование бэкапов — базовая характеристика, а не опция.
2. Минимизация данных в бэкапах: бэкапировать только то, что действительно нужно для восстановления.
3. Разделение бэкапов по категориям данных и срокам хранения.
4. Автоматическая ротация с документированием.
5. Встроенный механизм replay erasure при восстановлении.

Часть 9. Будущее и тренды

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

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

Обязательное шифрование с отечественными алгоритмами. В 2025 году приоритетом стали серверы с аппаратным шифрованием и сертификацией ФСТЭК [9]. Для ИСПДн высоких уровней защищённости требуется применение СКЗИ, сертифицированных ФСБ, реализующих алгоритмы по ГОСТ Р 34.12-2015 [23].

Расширение требований к локализации. После вступления в силу ФЗ-23 с 1 июля 2025 года [8] требования к локализации существенно ужесточились. Тенденция продолжится: ожидается усиление контроля за соблюдением этих требований и рост штрафов.

Автоматизация управления жизненным циклом данных. Крупные организации переходят к автоматизированным платформам управления данными (Data Governance), которые отслеживают местонахождение ПДн во всех системах, включая бэкапы, и автоматически применяют политики удаления.

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

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

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

Практический путь вперёд строится из нескольких шагов. Сначала — инвентаризация: где и в каких бэкапах хранятся ПДн. Затем — технические меры: шифрование, разграничение доступа, автоматическая ротация. Параллельно — процедурная часть: политика хранения, процедура replay erasure, акты уничтожения. И наконец — мониторинг: непрерывный контроль за изменениями ИТ-ландшафта, чтобы новые системы и интеграции не создавали новых слепых зон.

О платформе «Пятый фактор»

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

«Пятый фактор» — это on-prem платформа для автоматического обнаружения, инвентаризации и контроля персональных данных в корпоративных системах: базах данных, файловых хранилищах, почте, Active Directory/LDAP, CRM, 1С, API. Ключевое отличие — принцип privacy-by-design: платформа работает исключительно с метаданными, структурой и агрегированными профилями, не передавая и не сохраняя «сырые» значения ПДн. Это означает, что само решение не становится источником дополнительного риска.

Для задач, описанных в этой статье, «Пятый фактор» даёт организации:

1. Живую «карту ПДн»: где и какие данные хранятся, включая резервные системы, кто владелец, что изменилось.
2. Раннее обнаружение новых рисков: появились новые поля в БД, новая интеграция, новый подрядчик с доступом к данным — платформа фиксирует это до того, как изменение превратилось в нарушение.
3. Готовность к аудиту: вместо разрозненных ручных проверок — структурированный реестр с владельцами, статусами и историей изменений.
4. Сокращение времени аудита: компании получают непрерывный контроль, а не «аврал» перед проверкой Роскомнадзора.

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

Источники

[1] Федеральный закон от 30.11.2024 № 420-ФЗ «О внесении изменений в Кодекс Российской Федерации об административных правонарушениях» — consultant.ru

[2] Штрафы за персональные данные с 30 мая 2025 года, КонсультантПлюс — consultant.ru

[3] Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных», Роскомнадзор — 72.rkn.gov.ru

[4] Статья 21 ФЗ-152, КонсультантПлюс — consultant.ru

[5] Сроки уничтожения персональных данных по 152-ФЗ — data-sec.ru

[6] Сроки хранения первичных учётных документов и персональных данных, ГАРАНТ — garant.ru

[7] Срок хранения персональных данных в 2025 году, Pro-Personal — pro-personal.ru

[8] Федеральный закон от 28.02.2025 № 23-ФЗ «О внесении изменений в 152-ФЗ», анализ Lidings — lidings.com

[9] Как хранить персональные данные по 152-ФЗ в 2025 году, Itelon — itelon.ru

[10] Приказ Роскомнадзора от 28.10.2022 № 179 «Об утверждении требований к подтверждению уничтожения персональных данных», RPPA — rppa.pro

[11] Right to be Forgotten: GDPR Erasure Rights Guide, ComplyDog — complydog.com

[12] How the GDPR Right to Be Forgotten Impacts Your Backup Strategy, Arcserve — arcserve.com

[13] Right to Erasure (ICO), UK Information Commissioner's Office — ico.org.uk

[14] Data Retention Policy Best Practices, Forcepoint — forcepoint.com

[15] GDPR: Do I Need to Erase Personal Data from Backup Systems, VeraSafe — verasafe.com

[16] Защищённое хранение резервных копий, Хабр — habr.com

[17] 7 Methods of Secure Data Sanitization, Human-I-T — human-i-t.org

[18] Backup Compliance Tips, Duplicator — duplicator.com

[19] Количество слитых ПДн в 2024 году выросло на треть, InfoWatch — infowatch.ru

[20] Роскомнадзор зафиксировал 135 утечек баз данных в 2024 году, Forbes.ru — forbes.ru

[21] В первой половине 2025 года РКН выявил 35 фактов утечек, Хабр — habr.com

[22] «Сбер» оценил долю утекших данных взрослых россиян в 90%, РБК — rbc.ru

[23] Шифрование персональных данных согласно 152-ФЗ, Integrus — integrus.ru