Таблица помогает быстро определить срок хранения персональных данных и момент их удаления по закону | Марина Погодина, PROMAREN
Сроки хранения данных кажутся скучной бюрократией, пока к вам не приходит первый запрос от Роскомнадзора. По состоянию на февраль 2026 сроки хранения данных в РФ — это уже не про «на всякий случай», а про выживание между 152-ФЗ, НК РФ и реальными утечками.
Обновлено: 7 февраля 2026
Время чтения: 12-14 минут
- Что такое персональные данные?
- Как долго хранить данные?
- Почему важно удалять данные?
- Можно ли удалить данные?
- Чем опасно долгосрочное хранение данных?
В начале 2026 я снова села разбирать один и тот же вопрос: почему у компаний идеально настроена аналитика, AI, Yandex Neuro, но при этом полный хаос в сроках хранения данных. Логи лежат годами, резервные копии множатся как кролики, а политики хранения висят отдельным файлом, который никто не открывал с 2020 года.
Кофе к этому моменту уже остыл, а я в третий раз перечитывала НК РФ и перечень Росархива. Стоп, вернусь назад: чтобы не закапываться в «надо хранить всё», я стала собирать простую таблицу по категориям и смотреть на сроки как на инструмент — где мы обязаны хранить, а где честно можем удалить и выдохнуть.
Что такое персональные данные?
3 из 5 спорных кейсов в PROMAREN за 2025-2026 годы упирались не в сроки хранения данных, а в базовый вопрос: это вообще персональные данные или нет. Если на старте ошибиться с категорией, вся таблица сроков потом поедет.
Персональные данные — это любая информация, по которой можно прямо или косвенно узнать человека: ФИО, email, телефон, паспорт, СНИЛС, но и более «серые» штуки вроде IP в логах, user-id, куки в веб-аналитике. По 152-ФЗ критичен не формат, а сама возможность идентификации субъекта, и в 2026 регулятор смотрит на это шире, чем раньше.
Представь, ты ведешь CRM в Yandex 360: ФИО клиента, история заказов, комментарии менеджеров, иногда номер карты в заметке «на всякий случай». Всё это уже персональные данные, а не просто «заявки». Даже если в интерфейсе это одна карточка, для закона — несколько категорий разной чувствительности, которым нужны разные сроки хранения данных и уровни защиты.
Где грань между персональными и обезличенными?
Тут я раньше ошибалась сама: думала, что если убрать ФИО — уже обезличивание. Нет, не так. Обезличенные данные — это когда по совокупности информации нельзя обратно «собрать» человека разумными способами. Если в Google Analytics включена анонимизация IP, а идентификаторы не связаны с CRM, это уже не персональные данные, но стоит подтянуть отчёты к базе клиентов — статус меняется.
В РФ это особенно заметно на примере Yandex и AI-инструментов. Логи запросов в Yandex Neuro вроде бы технические, но если там есть аккаунт, телефон, история оплат — привет, персональные данные. Роскомнадзор в свежих разъяснениях на это прямо намекает, а в проверках любит спрашивать, как именно вы «обезличивали».
Какие категории данных чаще всего забывают?
На практике в 8 из 10 компаний провисают три зоны: журналы доступа к сервисам, переписка в почте и мессенджерах, а также бэкапы разных лет. Все их касаются сроки хранения данных, но в политике они обычно живут в одной строке «иные данные». Удобно, но очень небезопасно.
Это означает, что любой утечке из почтового архива или старой резервной копии регулятор задаст простой вопрос: «Где у вас прописаны сроки, чем обосновали продолжительность, почему не удалили?». И вот тут становится явно, что отдельная таблица по категориям нужна не юристу, а ИТ и безопасности, иначе они просто физически не видят зону ответственности.
Как только картина с категориями становится прозрачной, следующий логичный вопрос — а сколько вообще хранить всё это добро и что точно нельзя трогать до истечения обязательных сроков.
Как долго хранить данные?
По состоянию на начало 2026 примерно половина вопросов «как хранить данные» сводится к простому конфликту: бухгалтерия хочет хранить вечно, безопасность — удалить завтра. Закон в этом споре довольно прагматичен: держим ровно столько, сколько нужно для цели и учётных обязательств.
Если укрупнить, сроки хранения данных складываются из двух слоёв. Первый — жёсткие требования НК РФ, закона о бухучёте 402-ФЗ и перечня Росархива №236. Второй — ваша внутренняя цель обработки по 152-ФЗ: договор отработан, гарантийный срок прошёл, претензионный период истёк — значит, для персональных данных можно запускать обратный отсчёт до удаления.
Реальность при этом далека от идеала: я вижу компании, которые хранят кадровые документы и бухгалтерские данные «на всякий пожарный» 10-15 лет, хотя по базовому набору им достаточно 5. Вроде бы перестраховка, но она же раздувает массив персоналки и делает дороже инфраструктуру и аудит.
Таблица сроков хранения по основным категориям
Чтобы не держать в голове десятки норм, я свела рабочий минимум в таблицу. Здесь только самые частые категории данных, которые всплывают в проектах PROMAREN, без экзотики уровня «планы ликвидации ЧС». Нормативные ссылки дублирую, чтобы можно было открыть первоисточники на consultant.ru или garant.ru.
Категория Примеры Срок Основание Налоговый учет Декларации, расчеты, книги продаж 5 лет НК РФ ст.23, перечень №236 Бухгалтерские данные Проводки, регистры, счета-фактуры 5 лет (минимум 4 с последней записи) НК РФ, 402-ФЗ Кадровые документы Лицевые счета, приказы, стаж 50-75 лет для старых форм Перечень №236 Обычные персональные данные CRM, заявки, лог форм До достижения цели 152-ФЗ ст.5
Сроки хранения бухгалтерских данных здесь самый частый источник путаницы: убытки по налогу на прибыль, например, живут столько, сколько вы реально используете их для уменьшения базы. Как только право переноса исчерпано, держать эти документы «на всякий случай» уже не про закон, а про личные страхи.
Как перенести сроки в практику и автоматизацию
Таблица — это база, но пока она лежит в PDF на общем диске, автоматизации ноль. В 2025-2026 я все чаще вижу рабочий сценарий: сроки хранения данных прошиваются в систему как параметры — в n8n, Make.com или даже в нативную политику хранения в Yandex Cloud. Записали дату исполнения договора — система сама посчитала дату удаления и поставила задачу.
По данным Gartner, на которые я ориентируюсь в разговорах с ИТ, грамотные политики хранения режут до 30% затрат на инфраструктуру. В моих проектах цифры чуть скромнее, но ощущение одинаковое: как только у данных появляется предсказуемый «срок годности», ИТ, безопасность и юристы перестают ругаться, и можно спокойно переходить к самому болезненному — теме удаления.
Почему важно удалять данные?
Если коротко: лишние данные всегда превращаются в лишние риски. В 2026 хранить всё подряд «для ML» уже не модно, и Яндекс, и Google в своих политиках делают акцент на минимизации данных и контроле их жизненного цикла.
На практике я вижу простую закономерность: там, где нет привычки удалять, сроки хранения данных воспринимаются как абстрактный юр-документ. Люди продолжают тянуть старые выгрузки в новые сервисы, делать личные копии «для подстраховки», а старые почтовые архивы так и висят в облаках годами, пока однажды не всплывают в новостях как «утечка персональных данных 2023».
152-ФЗ в связке с подзаконкой говорит достаточно прямолинейно: достигли цели обработки или отпало основание — блокируем и уничтожаем. Роскомнадзор в свежих проверках любит спрашивать именно про это звено: не только сколько вы храните, но и как именно удаляете и кто за это отвечает.
Что даёт компании регулярное удаление
Здесь работает сразу несколько эффектов. Во-первых, сокращается поверхность атаки: меньше баз — меньше сценариев для злоумышленников и инцидентов. Во-вторых, инфраструктура перестает пухнуть от «цифрового хлама»: резервные копии, старые бэкапы виртуалок, исторические выгрузки из CRM, которые никто уже не открывал. В-третьих, аккуратные сроки хранения данных снижают стоимость аудита и due diligence — меньше вопросов на сделках, понятнее картинка.
В одном из проектов PROMAREN мы как-то просто выключили «вечно зелёную» ретеншн-политику в почте и включили ограничение три года с автоматическим архивом. Это заняло пару часов полтора дня, но эффект был забавный: безопасность вздохнула, а юристы сказали «ну наконец-то, мы так и писали в политике».
Чем не удаление опаснее штрафов
Штрафы за нарушение 152-ФЗ, конечно, неприятны, но редко убивают бизнес. Гораздо больнее последствия утечек: потеря доверия клиентов, разборы в СМИ, проверки по всей цепочке подрядчиков. Когда из-за старого бэкапа наружу выходят данные по «мертвым» клиентам, вопрос уже не только к безопасности, но и к тем, кто решил, что сроки хранения данных можно игнорировать ради спокойствия.
Я поняла для себя важную вещь: удаление — это не про уничтожение ценности, а про честное признание, что ценность уже исчерпана. Договор закрыт, претензий нет, сроки давности прошли — значит, держим только то, что прямо требуют законы о данных и бухгалтерский учёт, а остальное отправляем в цифровой шредер и освобождаем место для нового.
И вот тут возникает вечный вопрос от команд: «ладно, убедила, а можно ли вообще всё это удалить и как не ошибиться с моментом».
Можно ли удалить данные?
Да, и закон прямо этого хочет: по 152-ФЗ оператор обязан уничтожить персональные данные, как только цель достигнута или субъект отозвал согласие. Тут сроки хранения данных заканчиваются и начинается зона ответственности по корректному удалению.
В начале 2026 у нас уже есть чёткие ориентиры по срокам реакции. По разъяснениям Роскомнадзора и судебной практике, на уничтожение после достижения цели обработки обычно отводят до 30 дней. Если субъект прислал мотивированное требование и доказал нарушение принципов обработки, у вас около недели, чтобы либо удалить, либо очень хорошо объяснить, почему это пока невозможно.
В теории всё звучит аккуратно. На практике появляются нюансы: архивные обязательства по НК РФ и 402-ФЗ, необходимость хранить кадровые данные десятилетиями, кейсы с судебными спорами. Там просто нажать DELETE нельзя, и приходится балансировать между правом человека «забыть» и обязанностью компании отчитаться перед налоговой.
Как правильно удалить личные данные в реальных системах
Я часто вижу, как удаление сводится к фразе «мы отключили доступ». Это неплохо как первый шаг, но для закона это только блокировка, а не уничтожение. Чтобы не путаться, я обычно раскладываю удаление на несколько уровней, которые можно прошить в автоматизацию через n8n или Make.com.
- Отвязать данные от человека: убрать ссылки на идентификаторы, где это допустимо, превратить запись в анонимную статистику.
- Блокировать запись: закрыть доступ операторам и бизнесу, оставить только техническое хранение до конца обязательного срока.
- Уничтожить: перезаписать или физически удалить носитель, заактировать процесс по требованиям 152-ФЗ и Роскомнадзора.
- Синхронизировать системы: удалить копии в резервных бэкапах по расписанию, чтобы не тянуть «хвосты» годами.
- Сообщить субъекту: отправить короткое подтверждение, особенно если запрос пришёл через форму на сайте или поддержку.
В Yandex 360 или Google Workspace это можно реализовать через политики удержания и сценарии: тег «удалить по дате», автоматическое перемещение в корзину, затем полное уничтожение. Критично зафиксировать в логах, что именно и когда удаляли, иначе на проверке вы никак не докажете, что соблюдали свои же сроки хранения данных.
Как договориться между юристами, ИТ и бизнесом
Самые жёсткие споры я видела как раз вокруг удаления: юристы боятся потерять доказательства, ИТ переживает за нагрузку на системы, бизнесу нужны «все данные за всё время». Здесь помогает одна простая конструкция — матрица категорий, сроков и оснований, которую можно собрать в том же Notion или на сайте PROMAREN в виде живого реестра.
Как только у каждой категории появляется понятный срок и ссылка на норму, разговор переходит из плоскости эмоций в плоскость цифр. Юрист показывает, где без НК РФ никак, ИТ — где можно включить автоматическое удаление, бизнес — какие данные ему реально нужны дольше. А дальше это всё уже можно отдать на реализацию в n8n-сценарии, про которые я подробно пишу в подборке «кейсы автоматизации» на блоге PROMAREN.
И всё же даже при аккуратных политиках многие компании по инерции тянут данные годами. Здесь включается последний вопрос — а чем именно опасно такое долгосрочное хранение.
Чем опасно долгосрочное хранение данных?
Опыт 12 проектов PROMAREN за последние два года показывает: там, где сроки хранения данных не ограничены, рано или поздно случается либо утечка, либо «неприятный» аудит. Не всегда с огромными штрафами, но почти всегда с испорченными нервами и переработанными выходными.
Формальные риски уже много раз проговорены: штрафы по 152-ФЗ и КоАП, возможные иски от субъектов, повышенное внимание регуляторов. По данным Роскомнадзора и обзорам судебной практики, суммы штрафов растут, а проверять начали не только публичные компании, но и средний бизнес, который раньше как будто был «под радаром».
Меня больше волнуют тихие последствия, про которые в новостях не пишут. Это когда команда боится запускать новые AI-сервисы, потому что «у нас везде персоналка», или когда проект по миграции в облако откладывается на год, пока кто-то вручную вычищает старые архивы. Тут уже не только про конфиденциальность, но и про прямые потери времени и денег.
Типичные грабли долгого хранения
Раньше я думала, что главная проблема — в незнании законов по хранению персональных данных. После десятка внедрений увидела другую картину: люди в целом знают, что сроки есть, но недооценивают накопительный эффект «ну давайте пока оставим». Проходит три года — и у вас уже пять разных копий одной и той же базы в разных системах.
- Вечные бэкапы: никто не знает, что в них лежит, но удалить страшно «вдруг понадобится налоговой».
- Личные архивы сотрудников: выгрузки из CRM, чаты, файлики «для отчёта», которые уходят вместе с человеком.
- Технические логи без сроков: их собирают «для безопасности», но не чистят годами.
- Отсутствие единой таблицы сроков: каждый отдел живет в своей логике и дублирует хранение.
По данным консалтинговых отчётов McKinsey и Gartner, на которые я иногда опираюсь при расчетах, до 60% корпоративных данных в мире — «dark data», то есть хранятся, но активно не используются. В локальном контексте РФ это ещё и зона повышенных регуляторных рисков, потому что персональные данные в этих массивах почти всегда есть, а политики хранения — почти никогда.
Как использовать сроки хранения как инструмент безопасности
Хорошая новость в том, что сроки хранения данных легко превращаются из «обузы» в рабочий инструмент. Для этого нужно чуть-чуть сместить фокус: это не про запреты, а про осознанное решение, какие данные действительно нужны бизнесу и как долго. Всё остальное мы честно архивируем или уничтожаем.
Я для себя формулирую это так: чем прозрачнее сроки и правила удаления, тем проще жить всем — и аудиторам, и ИТ, и бизнесу. В методике white-data PROMAREN мы всегда начинаем не с того, «что нам запрещено», а с инвентаризации ценности: где данные приносят деньги, где нужны для закона, а где держатся «чтобы было». И уже от этого раскладываем по категориям, таблицам и автоматизациям.
Если хочется покопаться глубже, в канале PROMAREN я регулярно разбираю живые кейсы, а на сайте PROMAREN можно посмотреть, как мы прошиваем сроки хранения в сценарии n8n и Cursor без лишней магии. А сейчас давай соберем всё в одну точку, чтобы картинка сложилась.
Когда данные наконец можно отпустить
Сроки хранения данных сами по себе не спасают, если они живут только в локальной политике. Работают они тогда, когда у каждой категории есть понятный «срок годности», место в таблице, привязка к закону и сценарий автоматизации, который не ломается при первом же обновлении CRM.
Критично помнить три вещи: данные храним под цель, удаляем с доказательствами и не боимся признавать, что часть архива уже не про пользу, а про риск. Всё остальное — вопрос техники: матрица категорий, аккуратный реестр в Notion или на своем сайте, плюс пара сценариев в n8n или Make.com, которые действительно доводят политику до железа.
Если чувствуешь, что у тебя уже вырос маленький цифровой архивный монстр 🙂 — не обязательно рушить систему за раз. Начни с одной зоны: бухгалтерские данные, CRM или почта, считай сроки и смотри, сколько времени и денег освобождается, когда данные получают право быть удалёнными.
Обо мне. Марина Погодина, основательница PROMAREN и AI Governance & Automation Lead. С 2024 года помогаю в РФ выстраивать автоматизацию, сроки хранения и white-data архитектуру под 152-ФЗ. Пишу в блоге и делюсь кейсами в Telegram.
Если хочется превратить политики и сроки хранения данных в работающие сценарии, а не в «папку на диске» — заглядывай на сайт PROMAREN и в бот с разбором автоматизации. Там больше примеров с n8n, Make.com и Cursor без хайпа, но с цифрами.
Что ещё важно знать про хранение и удаление
Можно ли хранить персональные данные «до отзыва согласия» без конкретного срока?
Только на это опираться нельзя, потому что закон требует хранить данные не дольше, чем этого требует цель обработки. Формулировка «до отзыва согласия» без описанной цели и разумного предела выглядит подозрительно для проверяющих. Лучше привязать срок к объективным событиям: окончание договора, гарантии, претензионного периода, а уже сверх этого отдельно обосновывать продление.
Нужно ли удалять данные из всех бэкапов, если пришёл запрос на уничтожение?
В идеале да, но закон здесь допускает разумный компромисс. Если резервные копии используются только для аварийного восстановления и к ним нет операционного доступа, их можно не чистить мгновенно, а уничтожать по расписанию. Главное — прописать это в политике, ограничить доступ и обеспечить, чтобы при восстановлении не вернулись «воскрешённые» записи, которые должны были быть удалены навсегда.
Что делать, если бухгалтерские сроки хранения и запрос на удаление конфликтуют?
В такой ситуации приоритет имеют нормы НК РФ и закона о бухучёте, поэтому полностью удалить документ до истечения обязательного срока нельзя. Правильный путь — максимально сократить доступ: заблокировать использование этих данных в маркетинге, аналитике, AI-сервисах и оставить только минимальный набор для отчётности. В ответе субъекту это честно объясняют, с указанием конкретных статей законов.
Можно ли хранить персональные данные только в облаке Yandex или Google без локальных копий?
Да, хранить данные исключительно в облаке можно, если у провайдера есть нужные сертификаты и заключены корректные договоры обработки. При этом ответственность перед субъектами всё равно несёт оператор, а не Yandex или Google. Поэтому политики хранения, сроки удаления и журналирование действий нужно выстраивать у себя, а не полагаться на «умный сервис», который якобы сам всё сделает правильно.
Как часто пересматривать таблицу сроков хранения документов?
Оптимально делать ревизию хотя бы раз в год или при любом значимом изменении закона, например, обновлении перечня Росархива или поправках в 152-ФЗ. Заодно стоит проверять, насколько фактические практики совпадают с таблицей: что реально удаляется, что копится, какие автоматизации ломаются. Такой регулярный обзор помогает вовремя убрать лишнее и не обнаружить внезапно терабайты «ничейных» данных в старых системах.