Цена соответствия GDPR для небольшого сервиса: считаем по статьям

MAATRIX

Клиент из Германии спрашивает в переписке: «А вы GDPR compliant?» — и разработчик небольшого сервиса зависает. Гуглить регламент бесполезно: это несколько глав юридического текста, который писали не для инженеров. Нанимать юриста страшно — непонятно, за что платить и сколько это вообще стоит. В этой статье мы не будем пересказывать формулировки регламента и тем более выдумывать номера статей — вместо этого разберём вопрос так, как его видит бухгалтерия: по статьям бюджета. Откуда берутся расходы на соответствие, что можно сделать самому, а где без юриста не обойтись.

Когда GDPR вообще всплывает в вашей истории

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

• у сервиса есть пользователи из ЕС, которые регистрируются, оставляют email, платят картой;
• среди сотрудников или подрядчиков есть люди, работающие из ЕС;
• партнёр или клиент из Европы прямо просит подтверждение соответствия перед подписанием договора;
• в цепочке подрядчиков (email-рассылка, аналитика, платёжный шлюз, CRM) есть европейские сервисы, и вопрос всплывает уже с их стороны.

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

Юридическая консультация: без неё все остальные пункты — гадание

Это первая и, по сути, обязательная статья расходов, потому что всё остальное строится на её результате. Без консультации с юристом невозможно достоверно понять:

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

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

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

Техническая доработка: что обычно приходится менять в коде и инфраструктуре

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

• Механизм согласия на обработку данных — баннер или экран, где пользователь явно соглашается на определённые категории обработки (аналитика, маркетинг, персонализация), с возможностью отдельно отказаться от необязательных категорий.
• Реализация права на удаление данных — сценарий, при котором пользователь может запросить удаление своей учётной записи и связанных с ней данных, а система гарантированно выполняет это во всех местах хранения, включая бэкапы и логи.
• Экспорт данных пользователя — возможность выгрузить всё, что сервис хранит о конкретном человеке, в машиночитаемом формате.
• Журналирование доступа к персональным данным — кто, когда и к каким записям обращался, особенно в админ-панели.
• Шифрование данных в состоянии покоя и при передаче — для баз данных и бэкапов, содержащих персональные данные.

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

#!/usr/bin/env bash
# purge_user.sh — пример структуры скрипта удаления данных пользователя
# Реальные таблицы, объекты хранилища и правила хранения бэкапов
# нужно определить под конкретный продукт вместе с юристом.

USER_ID="$1"

psql "$DB_URL" -c "DELETE FROM sessions WHERE user_id = '${USER_ID}';"
psql "$DB_URL" -c "DELETE FROM support_tickets WHERE user_id = '${USER_ID}';"
psql "$DB_URL" -c "UPDATE users SET email = NULL, name = NULL, deleted_at = now()
                    WHERE id = '${USER_ID}';"

# Объектное хранилище (аватары, вложения)
aws s3 rm "s3://user-uploads/${USER_ID}/" --recursive

# Отдельно фиксируем факт удаления для истории обработки запросов
echo "$(date -Is) user=${USER_ID} action=purge status=done" >> /var/log/privacy/purge.log

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

# пример: не пишем в лог access-токены и email в query string
log_format privacy_safe '$remote_addr - [$time_local] "$request_method $uri" $status';
access_log /var/log/nginx/access.log privacy_safe;

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

Документирование: реестр обработки и политики, которые придётся написать

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

Обычно в эту категорию попадает:

• Реестр процессов обработки данных — таблица или документ, где по каждому процессу зафиксировано: какие данные собираются, зачем, где хранятся, кто имеет доступ, как долго хранятся.
• Политика конфиденциальности для пользователей — публичный документ, написанный понятным языком, а не скопированный у конкурента (это тот случай, когда копирование чужого текста создаёт риск, потому что описывает чужие процессы, а не ваши).
• Договоры с подрядчиками, обрабатывающими данные по поручению — email-рассылки, аналитика, облачные хранилища: с каждым таким подрядчиком имеет смысл иметь понимание, на каких условиях он получает доступ к данным ваших пользователей.
• Процедура реагирования на инцидент — кто, что и в какие сроки делает, если произошла утечка или инцидент безопасности, включая то, кого и как нужно уведомить.

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

Юрисдикция инфраструктуры: почему выбор дата-центра — тоже статья расходов

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

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

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

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

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