Правила хранения электронной почты по GDPR

Правила хранения электронной почты по GDPR: практический чек-лист для хранения и удаления почтовых данных

Хранение электронной почты кажется скучным — до тех пор, пока на ваш стол не ложится жалоба. Тогда сразу важны и старый экспорт из почты, и резервная лента, и папка поддержки с пометкой «временная».

Фраза правила хранения электронной почты по GDPR звучит аккуратно, но на практике всё куда сложнее. Нужны понятная схема, график и процесс удаления, которым реально можно пользоваться во вторник после обеда. Именно поэтому хранение электронной почты по GDPR должно быть не набором общих обещаний, а рабочим регламентом с понятными ролями и сроками.

1. Составьте карту всех категорий почтовых данных, которые вы храните

Начните со списка точных категорий почтовых данных, которые у вас есть. Не просто «письма» в целом. Отдельно перечислите содержимое ящика, темы писем, заголовки, метаданные отправителя и получателя, вложения, журналы доставки и резервные копии.

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

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

Хорошая карта также помогает находить скрытое хранилище. Одна команда может удалить письмо из почтового ящика, но забыть о системе тикетов, заметке в CRM и папке с экспортом на ноутбуке. Так «удалённая» почта и остаётся в трёх местах.

2. Установите срок хранения, исходя из цели

Хранение должно определяться целью, а не привычкой. Если вы сохраняете письма клиентов для поддержки, укажите, как долго длится эта функция. Если вы храните счета для бухгалтерии, привяжите срок к бухгалтерской необходимости, а не к расплывчатому «на всякий случай».

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

Для каждой категории запишите одну причину хранения. Затем укажите триггер, который завершает хранение: закрытие дела, оплата счёта, окончание гарантии, завершение срока исковой давности или передача записи. Нет триггера — нет правила хранения.

Именно здесь люди часто заходят слишком далеко. Входящие письма службы поддержки не должны превращаться в постоянный архив только потому, что их удобно искать. Удобство — не правовое основание.

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

3. Разделяйте хранение в живом ящике, архиве и резервных копиях

Живые почтовые ящики нужны для текущей работы. Архивы — для хранения записей. Резервные копии — для восстановления. Эти три уровня не взаимозаменяемы и не должны подчиняться одному бесконечному правилу хранения.

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

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

Полезная практика — указывать уровень хранения в каждом правиле. Например: «Почта поддержки: 180 дней; архив: 3 года; резервная копия: 35 дней». Такая строка показывает сотрудникам, где происходит удаление, а где — нет.

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

4. Постройте процессы удаления и анонимизации

Удаление не должно быть просто пожеланием. Это должен быть процесс со шагами, ответственными и журналом. Безвозвратное удаление, псевдонимизация и редактирование — это разные действия, и команде нужно понимать, какое из них применять. Именно поэтому удаление писем по GDPR должно быть описано как воспроизводимая процедура, а не как разовая ручная команда.

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

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

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

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

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

5. Обрабатывайте запросы сотрудников и клиентов на удаление почтовых ящиков

С ящиками сотрудников часто возникают неловкие ситуации. У уволенного сотрудника может быть 20 000 сообщений, в общем ящике могут быть подписи нескольких человек, а в цепочке поддержки клиента могут содержаться данные другого человека. Для таких запросов нужен назначенный ответственный.

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

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

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

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

Если ваш бизнес отправляет клиентские письма через те же системы, которые получают ответы, грамотная настройка помогает сократить случайное хранение. Хорошая маршрутизация, более качественные журналы и понятное поведение блокировок делают последующую очистку проще; поэтому команды часто совмещают работу с хранением и управлением списком исключений электронной почты · YourTrend.

6. Применяйте исключения для юридического удержания и споров очень узко

Юридическое удержание должно быть исключением, а не стандартом. Останавливайте удаление только при наличии задокументированного юридического обязательства, активного иска или конкретного спора, для которого нужны данные. Затем сужайте рамки удержания максимально точно.

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

Сохраняйте запись о том, почему удержание введено, кто его утвердил, какие данные оно охватывает и когда его нужно пересмотреть. Без даты пересмотра удержание легко превращается в постоянное хранение.

Когда претензия заканчивается, данные должны вернуться к обычному сроку хранения. Этот шаг часто забывают. Одно судебное дело может оправдать 18 месяцев хранения; оно не оправдывает ещё 18 месяцев после завершения дела.

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

Есть ещё одно ограничение, о котором стоит помнить. Юридическое удержание — это не удобный повод хранить данные просто потому, что они могут пригодиться потом. «Может быть» — недостаточно.

7. Документируйте правила хранения и регулярно пересматривайте их

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

Этот документ должен позволять новому сотруднику понять, что делать, без долгих встреч. Если единственный человек, который его понимает, уходит, политика слаба. Если политика существует только в памяти одного менеджера, это и не политика вовсе.

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

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

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

И последний шаг: назначьте живого ответственного за каждое правило. Конкретный человек заметит, когда ящик на 90 дней вдруг превращается в ящик на 900 дней.