GDPR для российского бизнеса с клиентами из Европы

MAATRIX

> Важная оговорка сразу. Этот текст — обзорный инженерный материал, а не юридическая консультация. Мы не приводим точные формулировки статей GDPR, не называем точные суммы штрафов и не даём окончательного заключения о том, применяется ли регламент к вашей компании. Для конкретного ответа по вашей ситуации нужна консультация юриста, специализирующегося на международном праве данных — особенно если речь о платежах, здоровье или иных чувствительных данных клиентов. Компания зарегистрирована в России, сервер стоит в Москве, директор никогда не был в Европе — а вопрос «а нас вообще касается GDPR» всё равно всплывает, как только среди клиентов появляются жители ЕС. Это не паранойя: европейский регламент устроен так, что применяется не по прописке компании, а по тому, чью личную информацию она обрабатывает. Дальше — без юридического жаргона о том, когда это стоит проверить всерьез и что конкретно придётся чинить технически, если ответ окажется «да, касается».

Право на удаление: от декларации к рабочей функции

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

Проблема в том, что «удаление» часто реализуется как пометка is_deleted = true в одной таблице — а личные данные тем временем продолжают жить в десятке других мест: в бэкапах, в логах приложения, в аналитической базе, в письмах поддержки, в кэше CDN, в дампах для аналитиков, в очереди сообщений, в сторонних сервисах (email-рассылки, платёжный шлюз, CRM). Формальный ответ пользователю «данные удалены» при таком раскладе не соответствует действительности.

Что технически означает работающее право на удаление:

• Каскадное удаление в основной БД. Не одна таблица users, а весь граф связанных записей — заказы (или их обезличенные версии, если нужна бухгалтерская история), адреса, платёжные токены, история обращений в поддержку, согласия на рассылку. Стоит заранее нарисовать этот граф явно, а не выяснять постфактум, что забыли таблицу.
• Обезличивание вместо жёсткого удаления там, где нужна история. Если заказ нельзя удалить из-за требований бухгалтерского или налогового учёта, персональные поля (имя, email, телефон, адрес) заменяются на плейсхолдеры, а сама транзакционная запись остаётся.
• Политика по бэкапам. Полное немедленное удаление из архивных бэкапов физически не всегда возможно и не всегда требуется — но должна быть внятная политика ротации (например, старые бэкапы с чувствительными данными не хранятся дольше определённого срока и не восстанавливаются в прод без дополнительной проверки на удалённых пользователей).
• Очистка логов и кэшей. Персональные данные не должны годами жить в логах приложения или веб-сервера в открытом виде. Разумный подход — не писать email и телефон в логи вовсе (маскировать при логировании), тогда и вопрос их удаления из логов не встаёт.
• Уведомление сторонних сервисов. Если данные пользователя передавались в email-рассылку, аналитику или CRM — при удалении нужно инициировать удаление и там, через API соответствующего сервиса, а не молча забыть про них.

Практический пример на уровне архитектуры: вместо DELETE FROM users WHERE id = ?, который может упасть на внешних ключах или молча оставить сироток в связанных таблицах, разумнее реализовать сервис-функцию deleteUserData(userId), которая последовательно проходит по всем известным источникам данных пользователя и либо удаляет, либо обезличивает запись, логируя каждый шаг для последующего аудита самого факта исполнения запроса.

-- пример каскадной очистки в PostgreSQL, где это оправдано историей заказов
BEGIN;

UPDATE orders
SET customer_name = 'deleted_user',
    customer_email = NULL,
    customer_phone = NULL,
    shipping_address = NULL
WHERE user_id = 12345;

DELETE FROM support_tickets WHERE user_id = 12345;
DELETE FROM marketing_consents WHERE user_id = 12345;
DELETE FROM sessions WHERE user_id = 12345;
DELETE FROM users WHERE id = 12345;

COMMIT;

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

Право на экспорт данных в машиночитаемом формате

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

На практике это означает: эндпоинт или админ-функцию, которая по идентификатору пользователя собирает все его данные из всех источников (профиль, заказы, история активности, согласия) в один файл; формат JSON или CSV — оба общеприняты как «машиночитаемые» (плоские таблицы удобнее в CSV, вложенные структуры — в JSON); разумный срок на выполнение запроса — не мгновенно, но и не «через два месяца»; процедуру подтверждения личности запрашивающего — отдавать дамп персональных данных по первому непроверенному запросу с почты нельзя, это отдельная дыра в безопасности.

{
  "user_id": 12345,
  "profile": {
    "name": "...",
    "email": "...",
    "registered_at": "2024-03-01T10:00:00Z"
  },
  "orders": [
    { "id": 987, "date": "2024-05-12", "total": 129.90, "currency": "EUR" }
  ],
  "consents": [
    { "type": "marketing_email", "given_at": "2024-03-01T10:05:00Z", "withdrawn_at": null }
  ]
}

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

Документирование оснований обработки для каждой категории данных

Это требование почти невидимо для пользователя, но заметно для разработки и для того, кто отвечает за соответствие в компании. Суть в следующем: для каждой категории собираемых данных нужно явно зафиксировать, зачем вы её собираете и на каком основании — согласие пользователя, необходимость для исполнения договора, законный интерес компании, юридическая обязанность и так далее (у GDPR несколько таких оснований, согласие — лишь одно из них, и не всегда самое удобное).

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

Такая таблица не заменяет юридический документ (реестр обработки), но на основе технического аудита «какие поля у нас реально есть в базе и зачем» юрист сможет составить формальный документ. Для разработки это ещё и полезное упражнение: часто выясняется, что в базе годами лежит поле, назначение которого никто не помнит — а значит, его, скорее всего, можно удалить, что заодно снижает риск, а не только закрывает формальность. Данные, которые собираются «на всякий случай», без чёткой цели — с точки зрения GDPR слабое место: обработка без ясного основания создаёт риск, даже если сами данные никак не используются.

Уведомление об утечках данных: не «если», а «когда и как быстро»

GDPR обязывает компанию, если она соответствует критериям применимости, реагировать на инциденты с утечкой персональных данных в сжатые сроки — уведомить регулятора, а в определённых случаях и самих затронутых пользователей. Мы намеренно не называем здесь точное число часов или дней — сроки в подобных режимах обычно короткие и жёсткие (значительно короче, чем «разберёмся на следующей неделе»), и точную формулировку стоит уточнять по актуальному тексту регламента или у юриста, а не полагаться на память из статьи в блоге.

Что это означает для инфраструктуры на практике, вне зависимости от точных сроков:

• Мониторинг и алертинг должны реально работать, а не существовать формально. Аномальный объём выгрузки из БД, неожиданный доступ к бэкапам, подозрительная активность в панели администратора — всё это должно долетать до ответственного человека быстро, а не обнаруживаться через неделю при разборе логов.
• Заранее готовый план реагирования на инцидент, а не изобретение процедуры в момент паники: кто оценивает масштаб утечки, кто принимает решение об уведомлении, по какому шаблону готовится сообщение регулятору и пользователям.
• Логирование доступа к чувствительным данным, чтобы при инциденте можно было быстро ответить на вопрос «что именно и в каком объёме утекло», а не гадать. Без внятных логов доступа к базе оценка масштаба инцидента может занять недели вместо часов — а сроки уведомления от этого не сдвигаются.
• Список контактов и процедура эскалации, зафиксированные заранее, а не выясняемые в момент, когда уже нужно что-то сообщать регулятору.

Здесь же уместно напомнить: требования к логированию доступов и хранению технических журналов — тема, которая пересекается и с локальным российским регулированием, и с GDPR по-своему; если для вашей инфраструктуры уже настроен аудит подключений и доступов, часть фундамента для реагирования на инциденты уже есть.

GDPR и 152-ФЗ — это не одно и то же

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

• 152-ФЗ в первую очередь фокусируется на требовании локализации — обязанности хранить и обрабатывать первичные персональные данные россиян на серверах в России. Подробнее логика локализации разобрана в статье 152-ФЗ: где законно держать сервер с персональными данными.
• GDPR гораздо более детализированный и строгий режим: конкретные и технически проверяемые права субъекта данных (удаление, экспорт, ограничение обработки, возражение против обработки), обязательное документирование оснований обработки по каждой категории данных, короткие сроки реагирования на инциденты, а в ряде случаев — требование назначить ответственного за защиту данных (data protection officer) и вести формальный реестр операций обработки.

На практике это означает, что компания может быть полностью «чиста» перед российским регулятором — сервер с базой в РФ, все формальности 152-ФЗ соблюдены — и при этом не иметь ни одного из технических механизмов, которые требует GDPR: ни рабочей функции удаления по всем таблицам, ни экспорта данных, ни задокументированных оснований обработки, ни плана реагирования на утечки в сжатые сроки. Если у бизнеса есть аудитория одновременно в России и в ЕС, оба контура требований приходится закладывать параллельно, и один не подменяет другой. Мы разбирали похожую механику соотношения инфраструктурных затрат и юридических требований на примере одного лишь 152-ФЗ в статье сколько стоит соответствие 152-ФЗ для небольшой компании — для GDPR аналогичная смета обычно получается заметно длиннее и дороже именно из-за детализации требований.

Что можно сделать уже сейчас, не дожидаясь юриста

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

1. Провести инвентаризацию данных. Пройтись по всем таблицам БД, логам, сторонним сервисам (email-рассылка, аналитика, платёжный шлюз, CRM) и составить список: какие персональные данные где хранятся. Это тот самый технический фундамент, на основе которого потом строится и таблица оснований обработки, и функция удаления, и функция экспорта.
2. Написать (хотя бы черновую) функцию полного удаления пользователя и проверить её на тестовой копии базы — действительно ли после её выполнения не остаётся следов персональных данных там, где им не место.
3. Написать функцию экспорта данных пользователя — часто это переиспользование того же кода, который собирает данные для удаления, только с выводом в файл вместо стирания.
4. Настроить или проверить логирование доступа к базам с персональными данными и убедиться, что алерты на аномальную активность реально доходят до человека, а не просто пишутся в файл, который никто не читает.
5. Проверить бэкапы — знаете ли вы, сколько версий бэкапа с персональными данными хранится, где физически, и кто имеет к ним доступ.
6. Свести данные в таблицу категорий и оснований — даже черновой вариант такой таблицы сильно ускорит работу юриста, когда до него дойдёт очередь.

Что касается инфраструктуры: если аудитория проекта в Европе, разумно рассмотреть сервер в Великобритании или другой европейской юрисдикции — это не решает вопрос применимости GDPR само по себе (регламент определяется аудиторией, а не адресом сервера), но снижает задержку для европейских пользователей и облегчает разговор с партнёрами из ЕС на этапе due diligence, когда те спрашивают, где физически хранятся данные. Если аудитория смешанная — из России и из ЕС одновременно — стоит заранее продумать архитектуру с раздельным хранением или чётким разделением потоков данных, чтобы не пытаться усидеть на двух стульях регулирования одной и той же базой без разделения.

Частые вопросы