Политика хранения данных в некостодиальных шлюзах

Определите, какие именно поля данных вы реально храните

Некостодиальная схема не означает «никаких данных». Она означает, что шлюз не хранит средства клиентов, но система всё равно может обрабатывать имена, адреса электронной почты, IP-логи, адреса кошельков, ID счетов, заголовки браузера и обращения в поддержку. Начните с простого перечня всех мест, где данные попадают в систему: оформление заказа, логи, аналитика, поддержка, биллинг и любые выгрузки в бухгалтерию.

Составьте список до того, как начнёте спорить о GDPR. Один продавец может хранить только e-mail и платёжную ссылку; другой — 12 месяцев логов доступа, скриншоты тикетов и полезную нагрузку вебхуков. Это разные риски, и для них не должен действовать один и тот же срок хранения.

Проверяйте каждое поле по отдельности. Связано ли оно с конкретным человеком? Можно ли установить связь через номер счёта, адрес кошелька или переписку с поддержкой? Если да, считайте это персональными данными, если только юридическая проверка не говорит иного.

Payora.money — это некостодиальный криптоплатёжный шлюз, и политика хранения данных GDPR применима к нему только в том случае, если сопутствующие процессы у продавца выстроены дисциплинированно. Модель шлюза помогает, но вопрос хранения решается в тех записях, которые вы сохраняете, а не в монетах, к которым вы никогда не прикасаетесь.

Используйте простую внутреннюю таблицу, даже если команда небольшая:

Назначьте цель хранения для каждого типа записи

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

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

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

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

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

Разделяйте платёжные доказательства и операционные логи

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

Например, продавец может хранить метаданные счёта для бухгалтерии, при этом сокращая IP-адреса в прикладных логах по истечении заданного срока. Другой продавец может хранить платёжные ссылки 7 лет, потому что этого требует местное налоговое законодательство. Тот же процесс оформления заказа — другой юридический результат.

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

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

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

Определите сроки хранения по категориям данных

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

Даты должны быть привязаны к событию. Запись о возврате может начинаться с даты возврата. Тикет поддержки — с последнего ответа. Лог доступа — с момента его создания. Звучит мелко, но это избавляет всех от догадок спустя полгода.

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

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

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

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

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

Сначала определите записи, у которых истёк срок. Затем проверьте, не действует ли на них юридический hold, спор или бухгалтерское исключение. После этого удалите, сократите или анонимизируйте запись. В конце зафиксируйте, что действие было выполнено. Просто. Скучно. Необходимо.

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

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

Подстраивайте процесс под систему, а не наоборот. У продавца с ручными выгрузками должен быть журнал удаления для таблиц. У продавца с автоматическими заданиями должны быть ID задач, временные метки и оповещение о неудачном удалении.

Контролируйте доступ к сохраняемым данным

Хранение данных не оправдывает широкий доступ. Если 12 человек могут открыть исторические платёжные записи, политика слишком мягкая. Ограничьте просмотр минимально необходимой группой и требуйте согласования для ручных выгрузок или исключений по продлённому сроку хранения.

Контроль доступа должен соответствовать типу записи. Финансам могут понадобиться счета. Поддержке — история тикетов. Инженерам — замаскированные логи. По умолчанию никому не нужно всё.

Для исключений используйте согласование поимённо. Например, аналитик по мошенничеству может запросить продление на 14 дней для подозрительного случая, но менеджер должен утвердить это до того, как файл покинет систему. Такая дополнительная ступень особенно важна, если в файле есть имена, адреса или заметки о заказе.

Ручные выгрузки — это место, где хорошие политики чаще всего игнорируют. Поставьте там контрольную точку. Логируйте, кто запросил доступ, кто одобрил, что было выгружено и когда это истекает.

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

Документируйте решения по хранению для аудиторов и партнёров

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

Во внутренней заметке должно быть больше, чем «лучшая практика». Укажите источник решения, например налоговое законодательство, обработку мошенничества, политику споров или условия договора. Если срок одобрил внешний юрист или DPO, укажите имя человека или роль. Если решение будет пересматриваться каждые 12 месяцев, напишите это.

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

Держите доказательства в актуальном состоянии. Записка о хранении данных из прошлого года может ввести в заблуждение после изменения продукта или запуска в новой стране. Версионируйте её. Ставьте дату. Перепроверяйте при изменении процесса.

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

Проверьте договоры и уведомления на соответствие срокам хранения

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

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

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

Для платформ, которые также обрабатывают подписки, сообщение должно совпадать с поведением биллинга. Уведомление со словами «мы удаляем платёжные логи немедленно» будет противоречить системе, которая хранит записи для сверки 7 лет. Такого конфликта можно избежать.

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