Сроки хранения данных и требования к персональным данным в 2026 году: практическое руководство для DevOps и сисадминов

Что изменилось в требованиях к хранению данных к 2026 году

Сроки хранения данных в 2026 году определяют три уровня требований: 152-ФЗ, отраслевые законы и внутренний регламент оператора. Готовой таблицы «храните столько-то лет» нет ни в одном законе: 152-ФЗ задает правило, по которому данные нельзя держать дольше, чем нужно для заявленной цели обработки.

Практические ориентиры такие. Персональные данные клиентов: срок договора плюс 3 года исковой давности плюс 5 лет для документов налогового и бухгалтерского учета. Кадровые документы сотрудников: до 75 лет для отдельных категорий. Логи доступа: 6-12 месяцев. Метрики: 13 месяцев. Бэкапы: 30-90 дней. Учётные данные: пароли и токены живут до удаления аккаунта или до отзыва ключа.

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

Ключевые нормативные акты, определяющие сроки хранения в 2026 году

Базовый закон - 152-ФЗ от 27.07.2006 «О персональных данных». Он вводит понятия, на которые опирается вся практика хранения: оператор, информационная система персональных данных, обезличивание, блокирование, уничтожение. Оператор - организация или человек, которые организуют обработку ПДн, определяют цели обработки, состав данных и действия с ними. Информационная система персональных данных - совокупность баз данных и обеспечивающих их обработку технологий и технических средств.

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

Цифры дают отраслевые нормы:

• 402-ФЗ «О бухгалтерском учете»: документы бухучета хранят 5 лет после отчетного года.
• Трудовой кодекс и архивное законодательство: личные дела и кадровые документы - 50 лет, для отдельных категорий (руководители, государственные служащие) - до 75 лет.
• 323-ФЗ: медицинские документы, сроки зависят от типа документа и вида помощи.
• 149-ФЗ «Об информации»: общие правила для информационных систем и организаторов распространения информации.
• Постановления Правительства РФ и разъяснения Роскомнадзора: уточняют требования к защите, локализации и уничтожению ПДн.

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

Как Роскомнадзор проверяет соблюдение сроков хранения

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

Что проверяют на практике:

• обоснованность каждого срока: почему 5 лет, а не 1 год;
• факты уничтожения данных: акты, журналы, выгрузки из систем;
• локализацию баз с ПДн российских граждан на территории РФ;
• меры безопасности: шифрование, разграничение доступа, аудит;
• хранение учётных данных: нет ли паролей в открытом виде или в логах.

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

Как определить срок хранения для каждой категории данных

Алгоритм из пяти шагов работает для любой категории данных:

1. Инвентаризация: собрать все места, где лежат данные.
2. Цель обработки: сформулировать, зачем данные нужны.
3. Правовое основание: найти закон или договор, который задает срок.
4. Фиксация: записать срок в политике и реестре данных.
5. Автоудаление: настроить механизм, который удаляет данные по истечении срока.

Сроки хранения персональных данных: клиенты, сотрудники, контрагенты

Клиенты. Минимальный срок диктует исковая давность: 3 года, чтобы компания могла защититься в суде. Если данные входят в состав бухгалтерских и налоговых документов, добавляется 5 лет. На практике берут максимум: срок договора плюс 5 лет. Хранить дольше без новой цели нельзя.

Сотрудники. Кадровые документы и личные дела хранят 50 лет, для отдельных категорий - до 75 лет. В информационных системах полный архив не нужен: профиль держите, пока человек работает, плюс срок для расчетов и споров, а основной массив документов оставьте в архиве.

Контрагенты. Логика та же, что с клиентами: договоры, акты, доверенности и переписка по сделке живут срок договора плюс 3-5 лет в зависимости от налоговой значимости документов.

Когда одни данные нужны для нескольких целей, срок определяет самая длинная обоснованная цель. Email клиента в договоре живет срок договора плюс 5 лет, а тот же адрес в рассылке - до отзыва согласия. Хранить адрес по длинному сроку для всех задач нельзя: это превышение целей обработки.

Сроки хранения технических данных: логи, метрики, бэкапы

Логи доступа (nginx, SSH, VPN): 6-12 месяцев. Этого хватает, чтобы разобрать инцидент и подтвердить действия. IP-адрес вместе с user-agent позволяет идентифицировать пользователя, поэтому такие логи могут считаться ПДн и попадать под 152-ФЗ. Политики ILM в Elasticsearch настраивают retention и автоудаление, пошаговый пример есть в инструкции по ELK Stack для сбора и анализа логов.

Логи приложений: 30-90 дней. Чистите их от секретов: токены, пароли и номера карт не должны попадать в тексты ошибок и отладочные сообщения.

Метрики: 13 месяцев. Запас в месяц нужен для годового сравнения: дашборд «сентябрь к сентябрю» не построить, если прошлогодние данные удалены. Сырые точки держите 30-90 дней, агрегаты - 13 месяцев.

Бэкапы: 30-90 дней для оперативных копий. Точечно удалить запись из бэкапа сложно, поэтому срок в резервных копиях не должен превышать срок в основной системе. Для данных с длительным сроком (бухгалтерия, кадры) заведите отдельный архивный бэкап с документированным расписанием и ротацией.

Сроки хранения учётных данных пользователей

Пароли хранятся только в виде хешей: bcrypt с cost 12 и выше, argon2id, уникальная соль для каждой записи. Открытый пароль не хранится нигде: ни в базе, ни в логах, ни в тикетах поддержки. Хеш живет до удаления аккаунта.

Сессионные и refresh-токены: до истечения срока действия плюс окно ротации. Задайте максимальное время жизни: для веб-сессий 12-24 часа, для refresh - 30-90 дней. Просроченные токены удаляйте из базы и из кеша, в Redis для этого работает TTL.

API-ключи и сервисные учётки: до отзыва. Ротация раз в 90-180 дней, хранение в Vault или KMS, не в конфигах и не в Git. При компрометации ключ отзывают и удаляют немедленно.

Ключи шифрования: живут в KMS или Vault, ротация ключей раз в 1-2 года и внепланово при подозрении на утечку. Удалять ключ, пока существуют зашифрованные им данные и бэкапы, нельзя. Уничтожение ключа делает данные нечитаемыми, это законный способ крипто-удаления, но его фиксируют документально.

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

Требования к хранению персональных данных в инфраструктуре

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

Локализация данных: где можно хранить ПДн российских пользователей

152-ФЗ требует, чтобы запись, систематизация, накопление и хранение ПДн граждан РФ шли через базы на территории России. Требование распространяется и на бэкапы. Основная база с ПДн в AWS или Google Cloud нарушает закон, даже если данные зашифрованы.

Что допустимо:

• базы и бэкапы в российском облаке или на собственных серверах в РФ, например Timeweb Cloud с серверами, базами данных и хранилищем в российских дата-центрах;
• обработка обезличенной статистики за рубежом, если восстановить связь с человеком невозможно;
• трансграничная передача с согласия субъекта и после уведомления Роскомнадзора, с оценкой рисков.

Рабочая схема: мастер-база и реплики в РФ, аналитический контур с обезличенными данными можно размещать где угодно. CDN за границей для статики без ПДн нарушением не считается.

Шифрование и разграничение доступа к данным

Шифрование at-rest: LUKS (dm-crypt) для дисков Linux, нативное шифрование ZFS (AES-256-GCM) для NAS и пулов, TDE или шифрование на уровне колонок для баз данных. Ключи храните отдельно от данных: в KMS, Vault или аппаратном модуле.

Шифрование in-transit: TLS 1.3 для внешних подключений, mTLS для трафика между сервисами. Трафик внутри кластера тоже шифруйте, если по нему идут ПДн.

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

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

Особенности хранения данных в Kubernetes

etcd хранит все объекты кластера, включая секреты. Включите шифрование: EncryptionConfiguration с провайдером kms или aescbc, ключ шифрования держите вне кластера. Без этого любой, кто получил доступ к etcd или его бэкапу, читает секреты.

Kubernetes Secrets в base64 не защищают данные: это кодирование, а не шифрование. Не коммитьте секреты в Git. Рабочие варианты: External Secrets Operator, HashiCorp Vault, SOPS с KMS. Секреты монтируйте только тем подам, которым они нужны.

PersistentVolume: шифрование задается на уровне StorageClass и наследуется всеми томами класса. Проверьте reclaim policy: при политике Retain том и данные остаются после удаления PVC, и ПДн могут жить в кластере месяцами. Для данных с коротким сроком используйте Delete и отдельный контроль.

Логи контейнеров: настройте ротацию на уровне runtime (containerd, Docker) и retention в централизованном хранилище (Loki, Elasticsearch). По умолчанию логи пишутся на диск ноды и могут содержать ПДн из запросов.

Удаление namespace не удаляет данные из PV с политикой Retain, из бэкапов Velero и из внешних баз. Проверяйте все три места, иначе автоудаление останется только на бумаге.

Как разработать политику хранения данных: пошаговая инструкция

Политика хранения связывает требования закона с конкретными системами и сроками. Работа идет в восемь шагов:

1. Инвентаризация данных и систем.
2. Классификация: ПДн, финансовые, технические, служебные.
3. Определение срока для каждой категории.
4. Назначение ответственных по системам.
5. Разработка и утверждение регламента.
6. Настройка автоматического удаления.
7. Обучение сотрудников.
8. Регулярный аудит соблюдения.

Инвентаризация данных: с чего начать

Соберите все места, где могут лежать данные: продакшн-базы, реплики, файловые шары и NAS, объектные хранилища (S3, MinIO), бэкапы, логи, PersistentVolume в Kubernetes, облачные сервисы, CRM, почту, тикеты поддержки, выгрузки для аналитики. Копии в личных папках и на рабочих ноутбуках тоже считаются.

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

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

Шаблон политики хранения данных

Структура документа, которую можно адаптировать под компанию:

1. Общие положения и область действия.
2. Термины: ПДн, оператор, обработка, обезличивание, блокирование, уничтожение.
3. Категории данных и сроки хранения (таблица из реестра).
4. Порядок уничтожения: способы, документы, ответственные.
5. Ответственные лица и их полномочия.
6. Контроль соблюдения: аудит, метрики, отчетность.
7. Ответственность за нарушения.

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

Автоматизация удаления данных: TTL, lifecycle policies, cron

Ручное удаление не работает: через месяц про сроки забудут. Настраивайте автоматику на уровне хранилищ:

• PostgreSQL: pg_cron для регулярных задач, партиционирование по датам и удаление старых партиций через DROP PARTITION. Удаление партиции быстрее и дешевле, чем DELETE миллионов строк.
• S3 и MinIO: lifecycle-правила с expiration для объектов и версий. Object Lock включайте для данных, которые нельзя удалять (legal hold).
• Elasticsearch: ILM-политики hot-warm-cold-delete с автоматическим переходом индексов в архив и удалением.
• ZFS и NAS: auto-snapshot по расписанию с уничтожением старых снапшотов, hold для данных под юридическим запретом.
• Kubernetes: CronJobs для очистки временных данных, TTL для Job (ttlSecondsAfterFinished), retention в Velero.

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

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

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

Разница между обезличиванием и псевдонимизацией

Псевдонимизация заменяет идентификаторы на условные, но ключ для обратного преобразования сохраняется. Такие данные остаются персональными: дополнительная информация существует, пусть и отдельно. Обезличивание исключает восстановление связи с субъектом.

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

Отдельный режим - персональные данные, разрешенные субъектом для распространения: доступ неограниченного круга лиц открыт по согласию в порядке, установленном законом. Субъект может отозвать согласие, и с этого момента распространение нужно прекратить, а данные перевести в закрытый контур или удалить.

Когда можно блокировать данные вместо удаления

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

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

Риски и ответственность за нарушение сроков хранения

Ответственность за нарушения при обработке ПДн с 2025 года выросла: штрафы для организаций измеряются миллионами рублей, при повторных утечках считаются от выручки. Максимальные суммы по КоАП РФ достигают 20 млн рублей, отдельные составы касаются обработки без согласия и несоблюдения требований о локализации. Добавьте уголовную ответственность по ст. 272 УК РФ за неправомерный доступ к данным и гражданские иски субъектов о возмещении вреда.

Типичные ошибки, которые приводят к штрафам

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

Лечится это аудитом раз в полгода, автоудалением с логированием и обучением сотрудников. Новые сервисы проверяйте до запуска: добавить retention на старте быстрее, чем вычищать данные из бэкапов потом.

Как подготовиться к проверке Роскомнадзора

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

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

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

Чек-лист для DevOps и сисадминов

• Составить реестр данных: категория, система, цель, срок, ответственный.
• Настроить TTL и retention для логов, метрик и бэкапов.
• Включить шифрование дисков и томов: LUKS, ZFS encryption, StorageClass с шифрованием.
• Убрать секреты из Git и конфигов: Vault, External Secrets Operator, SOPS.
• Включить шифрование etcd в Kubernetes.
• Настроить аудит доступа к ПДн и пересмотр прав раз в квартал.
• Документировать каждое удаление: автоматическое и ручное.
• Проверить локализацию: базы и бэкапы с ПДн на территории РФ.
• Обновить политику и ознакомить сотрудников под подпись.
• Провести учебный аудит: найти и удалить данные клиента, который отозвал согласие.

Инструменты для автоматизации хранения и удаления данных

• pg_cron и партиционирование в PostgreSQL: удаление старых данных по расписанию.
• S3 и MinIO lifecycle: expiration объектов, версий и незавершенных загрузок.
• Elasticsearch ILM: горячий, теплый и холодный контур, автоудаление индексов.
• ZFS auto-snapshot и hold: снапшоты по расписанию, удаление старых, защита нужных.
• Kubernetes CronJobs и TTL: очистка временных данных и завершенных задач.
• Vault, External Secrets Operator, SOPS: управление секретами и ключами.
• Velero с retention: бэкапы кластера с ограниченным сроком хранения.
• Prometheus и алерты: контроль, что задачи удаления выполняются.

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