Неуместная архивность — ловушка для операторов персональных данных: мы сохраняем данные из-за инерции мышления и страха, вместо того чтобы планомерно уничтожать то, в чём нет законной надобности.
От сбора к осознанию масштаба
Большинство организаций начинает работу с персональными данными не с определения их конечного срока жизни, а с бессистемного накопления. Приходит новый клиент — заводится карточка в CRM. Заключается договор — сканируется и ложится в папку. Устраивается сотрудник — формируется личное дело. Поток не прекращается, и постепенно данные становятся частью инфраструктуры компании: они вшиты в отчёты, привязаны к внутренним процессам, интегрированы в аналитические системы. Проблема в том, что механизм их удаления, если он вообще предусмотрен, всегда отстаёт от механизма сбора.
Осознание приходит позже, часто в момент проверки или при попытке привести процессы в соответствие с требованиями регулятора. Ты открываешь базу данных, смотришь на тысячи записей о физических лицах и задаёшься вопросом: на каком основании я всё это храню? Оказывается, что многие контракты давно расторгнуты, сроки оказания услуг истекли, а бывшие сотрудники уволились несколько лет назад. Но их персональные данные по-прежнему лежат на серверах, в облачных хранилищах и резервных копиях. Право на хранение закончилось, а сам факт хранения — нет.
Это явление можно назвать «архивным люфтом» — разницей между текущим объёмом хранимых данных и тем их количеством, которое действительно необходимо для текущей деятельности и имеет правовое основание. Этот люфт постоянно растёт и представляет собой не только правовой, но и финансовый риск.
Забытые резервные копии: тихий накопитель риска
Основное производственное хранилище данных хотя бы периодически попадает в фокус внимания специалистов по информационной безопасности. С резервными копиями ситуация иная. Процедура бэкапа часто настраивается один раз и работает годами по принципу «добавляй новое, но старое не трогай». В результате на ленточных накопителях, внешних дисках или в облачных бакетах десятилетиями лежат копии баз данных десятилетней давности, содержащие персональные данные, право на обработку которых давно утрачено.
С точки зрения 152-ФЗ и позиций регуляторов, резервная копия, это такая же обработка персональных данных, как и работа с основной базой. Хранение устаревших резервных копий без актуальных оснований является нарушением. Причём обнаружить такое нарушение в ходе проверки технически сложно — для этого требуется восстанавливать и анализировать старые бэкапы, что редко делается. Но это не отменяет самого факта нарушения.
Правовое основание: что говорит закон на самом деле
Многие операторы ошибочно полагают, что само по себе согласие субъекта данных, полученное однажды, является бессрочным основанием для хранения. Это не так. 152-ФЗ прямо указывает, что обработка персональных данных должна быть ограничена достижением конкретных, заранее определённых и законных целей. Как только цель обработки достигнута или утрачена, персональные данные подлежат уничтожению или обезличиванию.
На практике цели часто носят временный характер: исполнение договора, трудоустройство, рассылка акций. Закон не устанавливает единых жёстких сроков хранения для всех случаев, это отдано на откуп оператору. Именно в этом и кроется главная ловушка: отсутствие чётких внешних сроков приводит к тому, что внутренние регламенты либо не устанавливаются вовсе, либо устанавливаются по принципу «хранить вечно, на всякий случай».
Более того, некоторые данные, например, связанные с финансовыми операциями или кадровым учётом, должны храниться в соответствии с другими отраслевыми нормативными актами (налоговое, трудовое законодательство). Здесь возникает конфликт сроков: закон требует хранить документы пять лет, но персональные данные внутри этих документов могут подлежать удалению раньше. Решением является не удаление самих документов, а обезличивание персональных данных внутри них — технически сложная, но необходимая процедура.
Практические шаги: аудит и ревизия
Первое, с чего стоит начать,, это не составление новых политик, а полная инвентаризация того, что уже накоплено.
Шаг 1: Картирование потоков и хранилищ
- Выявить все системы, где потенциально хранятся персональные данные: CRM, ERP, 1С, файловые серверы, почтовые архивы, системы аналитики, облачные сервисы (Яндекс.Облако, VK Cloud).
- Определить пути поступления данных в эти системы: веб-формы, API, импорты из файлов, ручной ввод.
- Зафиксировать, куда данные передаются дальше: в какие внутренние отчёты, внешним подрядчикам или в системы резервного копирования.
Шаг 2: Анализ оснований и сроков
- Для каждой категории данных (клиенты, сотрудники, партнёры) определить конкретную цель обработки, закреплённую в документах.
- Установить событие или срок, после которого цель считается достигнутой или утраченной (например, «3 года после расторжения договора», «1 год после отказа от рассылки»).
- Проверить, не противоречат ли установленные внутренние сроки отраслевым требованиям (например, кадровое делопроизводство).
Шаг 3: Выявление «цифрового балласта»
На основе установленных сроков выполнить технический поиск данных, срок правового основания для которых истёк. Это может быть:
-
- Записи в базе данных с датой последней транзакции старше N лет.
- Архивные папки с документами бывших сотрудников.
- Устаревшие резервные копии, не включённые в актуальный цикл ротации.
Технические сложности «точечного» удаления
Обнаружить проблему — лишь половина дела. Удалить данные зачастую сложнее, чем их собрать. Прямое удаление строк из основной базы данных — кажущееся простым решение — может нарушить целостность данных и логику работы приложений. Например, удаление профиля клиента может «положить» систему отчётности, которая ссылается на исторические заказы.
Обезличивание часто становится более предпочтительным выходом. Вместо удаления записи из базы удаляются или заменяются на псевдонимы непосредственно персональные атрибуты: ФИО, email, телефон, паспортные данные. При этом сама сущность (заказ, транзакция, обращение) сохраняется для аналитики и отчётности, но уже не может быть однозначно идентифицирована.
Для выполнения такой задачи требуется:
- Точно определить, какие поля в каждой таблице базы данных содержат персональные данные.
- Разработать алгоритмы обезличивания (хэширование, генерация псевдонимов) с учётом возможных ограничений со стороны бизнес-логики.
- Спланировать и выполнить работы в периоды минимальной нагрузки на системы, так как процесс может быть ресурсоёмким.
- Не забыть обновить или удалить соответствующие резервные копии.
Институциональные и человеческие барьеры
Технические сложности — лишь вершина айсберга. Гораздо серьёзнее могут быть организационные препятствия. Отдел маркетинга может сопротивляться удалению «холодной» клиентской базы, рассматривая её как стратегический актив для будущих кампаний. Юридический отдел может настаивать на вечном хранении «на всякий случай» для защиты от потенциальных судебных исков. Руководство может не выделять ресурсы на «невидимую» работу по очистке, которая не приносит немедленной прибыли.
Ключ к преодолению этих барьеров — перевод проблемы из правовой плоскости в плоскость управления рисками и экономики. Стоит объяснить и просчитать:
- Риск штрафов. По 152-ФЗ штрафы для юридических лиц могут достигать значительных сумм.
- Риск репутационных потерь. Утечка устаревших данных, о хранении которых уже забыли, наносит не меньший ущерб репутации, чем утечка актуальных.
- Прямые финансовые издержки. Хранение избыточных данных стоит денег: место на серверах, лицензии на СУБД, стоимость облачных гигабайтов, поддержка систем резервного копирования для растущих объёмов.
Регулярное плановое уничтожение данных, право на хранение которых истекло, должно стать таким же рутинным процессом, как и создание резервных копий.
Вывод: от обнаружения к системному управлению
Обнаружение факта избыточного хранения, это не конец, а начало наведения порядка. Ситуация, когда данных хранится больше, чем позволяют правовые основания, не является фатальной, но требует перехода от реактивного подхода к проактивному управлению жизненным циклом данных.
Необходимо внедрить принцип data minimization («минимизация данных») на этапе проектирования каждого нового процесса. Для существующих данных — установить и автоматизировать чёткие правила уничтожения или обезличивания по истечении срока их полезности с точки зрения закона. Это превращает потенциальный источник риска в демонстрируемый регулятору и партнёрам признак зрелости системы защиты персональных данных.