Правила зберігання електронної пошти за GDPR

Правила зберігання електронної пошти за GDPR: практичний чекліст для збереження та видалення поштових даних

Зберігання електронної пошти здається нудним, аж поки на вашому столі не з’являється скарга. Тоді старий експорт скриньки, резервна стрічка й «тимчасова» папка підтримки раптом стають важливими всі разом.

Фраза правила зберігання електронної пошти за GDPR звучить охайно, але на практиці все складніше. Потрібні справжня карта даних, графік і процес видалення, якому люди реально зможуть слідувати у вівторок після обіду; саме тому варто окремо прописати строки зберігання електронних листів GDPR для кожної категорії даних.

1. Складіть карту всіх категорій поштових даних, які ви зберігаєте

Почніть із переліку точних поштових даних, які ви тримаєте. Не просто «листи» загалом. Окремо внесіть вміст вхідних листів, теми, заголовки, метадані відправника й отримувача, вкладення, журнали доставки та резервні копії.

Таке розділення важливе, бо для кожного елемента потрібен різний строк зберігання. Розмова з відділом продажів із підписаним замовленням — це не те саме, що журнал недоставки, а відповідь клієнта зі сканом паспорта — не те саме, що маршрутний заголовок із вашого поштового сервера.

Зручний спосіб — зробити простий реєстр із шістьма колонками: категорія даних, система, відповідальний, мета, строк зберігання та спосіб видалення. Якщо якийсь рядок неможливо заповнити, запис ще не готовий до контролю зберігання.

Хороша карта також допомагає виявити приховане зберігання. Одна команда може видалити листи з поштової скриньки, але забути про систему тікетів, нотатку в CRM і папку з експортом на ноутбуці. Саме так «видалені» листи лишаються у трьох місцях.

2. Визначте строк зберігання на основі мети

Зберігання має випливати з мети, а не зі звички. Якщо ви тримаєте листи клієнтів для підтримки, скажіть, як довго триває ця підтримка. Якщо ви зберігаєте рахунки для бухгалтерії, прив’яжіть строк до бухгалтерської потреби, а не до розмитого «про всяк випадок».

Різні цілі можуть виправдовувати різні строки. Листування щодо білінгу може зберігатися довше, ніж маркетингова відповідь. Журнал розслідування інциденту безпеки може потребувати коротшого та жорсткішого строку, ніж договірний запис, бо після закриття інциденту його цінність швидко падає.

Для кожної категорії напишіть одну причину. Потім запишіть тригер, який завершує зберігання: справа закрита, рахунок оплачено, гарантія закінчилася, сплив строк позовної давності або завершено передання запису. Немає тригера — немає правила зберігання.

Саме тут часто перегинають палицю. Скринька підтримки не повинна ставати постійним архівом лише тому, що там зручно шукати. Зручність — не правова підстава.

Якщо ваша команда зберігає транзакційні поштові дані, пов’яжіть правило зберігання з реальним бізнес-використанням. Журнали доставки можуть бути потрібні лише на час підтримки, тоді як вміст часто можна видалити значно раніше. Якщо події відмови чи журнали подій важливі для вашого процесу, дивіться події webhook для транзакційних листів — там розібрано операційний бік цих даних.

3. Розділяйте зберігання в живій скриньці, архіві та резервних копіях

Живі поштові скриньки — для поточної роботи. Архіви — для записів. Резервні копії — для відновлення. Ці три рівні не взаємозамінні й не повинні мати одне безкінечне правило зберігання.

Повідомлення може бути видалене з живої скриньки через 90 днів, збережене в архіві на 7 років і все одно зникнути з резервної копії після наступного циклу перезапису. Це нормально. Ненормально — тримати те саме повідомлення всюди за замовчуванням, а потім називати це «політикою зберігання».

Живу скриньку слід чистити для швидкості роботи. Архів має регулюватися правилами ведення записів. Резервна копія повинна відповідати потребам відновлення, а не потребам обліку. Якщо резервна копія зберігається 30 днів, вона не повинна непомітно перетворюватися на довгостроковий архів.

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

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

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

Видалення не повинно бути бажанням. Це має бути процес із кроками, відповідальними особами й журналом. Жорстке видалення, псевдонімізація та редагування — різні дії, і команда повинна знати, яка саме потрібна; якщо вам потрібно практично зрозуміти, як видаляти електронну пошту за GDPR, почніть із формалізованого робочого процесу.

Жорстке видалення означає, що дані прибираються із системи так, що в нормальному режимі їх не передбачено відновлювати. Псевдонімізація означає заміну прямих ідентифікаторів на інші позначення зі збереженням певної операційної цінності. Редагування означає видалення конкретного фрагмента, наприклад номера банківського рахунку, при збереженні решти запису.

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

Деякі системи не можуть повністю стерти запис одразу з усіх шарів. Для них використовуйте редагування або псевдонімізацію там, де повне видалення неможливе, і документуйте причину. «Неможливо» ніколи не має бути першою відповіддю. Зазвичай це просто знак, що ніхто не перевірив налаштування.

Команди, які вже керують відмовами, suppression або помилками доставки, зазвичай мають кращі операційні звички. Ті самі звички допомагають і тут. Документований процес із кращих практик обробки недоставок електронної пошти можна адаптувати під чергу видалення, бо в обох випадках потрібні чіткий тригер і замкнений цикл.

Один невеликий, але корисний принцип: якщо людині потрібно натиснути «видалити», для спільних записів вимагайте подвійної перевірки. Листування служби підтримки з десятьма відповідями — не місце для поспішного очищення.

5. Обробляйте запити щодо скриньок працівників і клієнтів

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

Для звільнених співробітників вирішіть, чи скриньку передають, архівують чи видаляють. Для спільних скриньок відокремте ту частину, яка належить заявнику. Для клієнтських ланцюжків перевірте, чи не зашкодить видалення даних однієї людини запису іншої або ланцюгу доказів.

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

Коли надходить запит, зафіксуйте дату, заявника, скриньку, виконану дію та будь-яке обмеження, яке ви застосували. Якщо скринька має залишатися доступною протягом місяця під час переходу, так і вкажіть. Перехідний період — це не те саме, що безстрокове зберігання.

Спільні скриньки — місце, де команди найчастіше поводяться недбало. Один запит «видаліть цей лист» може одночасно зачепити HR, фінанси та службу підтримки клієнтів. Виправлення — не в швидкості. Виправлення — у короткій перевірці від людини, яка знає структуру папок.

Якщо ваш бізнес надсилає клієнтську пошту через ті самі системи, куди надходять відповіді, правильне налаштування допомагає зменшити випадкове зберігання. Хороший роутинг, кращі журнали та зрозуміла поведінка suppression спрощують подальше очищення; саме тому команди часто поєднують роботу зі зберігання з керуванням списком suppression електронної пошти · YourTrend.

6. Застосовуйте винятки для legal hold і спорів вузько

Юридичне утримання має бути винятком, а не нормою. Призупиняйте видалення лише тоді, коли є задокументований юридичний обов’язок, активна претензія або конкретний спір, який вимагає даних. Потім звужуйте обсяг утримання якнайточніше.

Широке утримання «всіх листів» зазвичай занадто широке. Вузьке утримання для одного файлу клієнта, однієї папки проєкту або одного діапазону дат легше обґрунтувати й простіше зняти пізніше. Якщо спір стосується простроченого рахунку, це не означає, що автоматично заморожено всю внутрішню переписку.

Зберігайте запис про те, чому утримання існує, хто його затвердив, які дані воно охоплює та коли його слід переглянути. Без дати перегляду утримання має звичку перетворюватися на постійне зберігання.

Після завершення претензії поверніть дані до звичайного режиму зберігання. Цей крок легко пропустити. Одна юридична справа може виправдати 18 місяців зберігання; але вона не виправдовує ще 18 місяців після закриття справи.

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

І є ще одна межа, яку варто пам’ятати. Юридичне утримання — не зручна причина тримати дані лише тому, що комусь вони можуть колись знадобитися. «Може» — цього недостатньо.

7. Документуйте правила зберігання та регулярно їх переглядайте

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

Цей документ має пояснювати новому співробітнику, що робити, без довгої наради. Якщо єдина людина, яка його розуміє, піде з компанії, політика слабка. Якщо політика живе лише в пам’яті одного керівника, це взагалі не політика.

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

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

Також корисно перевіряти, чи працює видалення після оновлення. Правила на папері недостатньо, якщо поштова платформа зберігає копії в експортних файлах або підтримкових знімках. Якщо ваша команда спирається на моніторинг доставлюваності або перевірки репутації відправника, зберігайте пов’язані записи лише стільки, скільки потрібно, і узгоджуйте їх із кращими практиками доставлюваності електронної пошти, а не зі звичкою.

Останній крок: призначте людину, відповідальну за кожне правило. Названий працівник помітить, коли 90-денна скринька перетворюється на 900-денну.