GDPR для небольшого SaaS: 5-часовой сетап, которого достаточно

Большинство фаундеров небольших SaaS в ЕС знают, что им нужен GDPR. Большинство также думают, что это требует юридического аудита за €10K, платформы управления согласиями и штатного DPO. Нет — не на маленьком масштабе.

Я настраивал GDPR-комплаенс для 6 клиентских проектов. Вот минимально жизнеспособный сетап, который занимает около 5 часов и покрывает то, что реально имеет значение.

Что GDPR реально требует (короткая версия)

1. Законное основание для обработки: Нужна юридическая причина для сбора данных. Для SaaS: согласие (для маркетинга) или исполнение контракта (для самого сервиса).
2. Прозрачность: Расскажите пользователям, что вы собираете, зачем и как долго храните.
3. Минимизация данных: Не собирайте больше, чем нужно.
4. Право на доступ/удаление: Пользователи могут запросить свои данные или их удаление.
5. Безопасность: Защищайте хранимые данные.
6. Уведомление об утечке: Сообщите регулятору в течение 72 часов.

Всё. Остальное (DPO, DPIA, записи об обработке) имеет пороги, которые маленький SaaS редко достигает.

5-часовой сетап

Час 1: Политика конфиденциальности (настоящая)

Не юридический шаблон, скопированный у корпорации из Fortune 500. Документ на понятном языке, покрывающий:

• Что вы собираете: email, имя, аналитика использования, платёжные данные (через Stripe — вы не храните карты)
• Зачем собираете: предоставление сервиса, транзакционные письма, улучшение продукта
• С кем делитесь: Stripe (платежи), Vercel (хостинг), Sentry (трекинг ошибок), Plausible (аналитика)
• Как долго храните: данные активного аккаунта хранятся, пока аккаунт существует; удаляются в течение 30 дней после удаления аккаунта
• Права пользователей: доступ, исправление, удаление, переносимость, возражение против обработки
• Контакт: email для запросов данных

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

Час 2: Согласие на куки (минимальное)

Если вы используете только необходимые куки (сессия, аутентификация), баннер кук вообще не нужен по GDPR. Необходимые куки имеют исключение.

Если используете аналитику:

• Plausible и Fathom: Аналитика без кук. Баннер не нужен.
• PostHog в режиме без кук: Баннер не нужен при соответствующей настройке.
• Google Analytics: Требует согласия. Нужен баннер.

Моя рекомендация: используйте Plausible или PostHog в режиме без кук и пропустите баннер кук полностью. Баннер стоит вам 5–15% точности аналитики (пользователи, которые отклоняют) и добавляет UX-трение.

Час 3: Флоу удаления данных

Когда пользователь удаляет аккаунт, вы должны реально удалить его данные. Не soft-delete — hard delete из базы данных.

async function deleteUserData(userId: string) {
  // 1. Отменить активные подписки
  await stripe.subscriptions.cancel(user.stripeSubscriptionId)

  // 2. Удалить из базы данных
  await db.transaction(async (tx) => {
    await tx.delete(sessions).where(eq(sessions.userId, userId))
    await tx.delete(preferences).where(eq(preferences.userId, userId))
    await tx.delete(activities).where(eq(activities.userId, userId))
    await tx.delete(users).where(eq(users.id, userId))
  })

  // 3. Удалить из сторонних сервисов
  await posthog.deleteUser(userId)
  await sentry.deleteUser(userId)

  // 4. Залогировать удаление (без PII)
  logger.info('User data deleted', { userId, timestamp: new Date() })
}

Лог удаления (шаг 4) — ваше доказательство, что вы исполнили запрос. Храните 3 года.

Час 4: Эндпоинт экспорта данных

GDPR даёт пользователям право получить свои данные в машиночитаемом формате. Один эндпоинт:

// app/api/user/export/route.ts
export async function GET(request: Request) {
  const user = await getAuthenticatedUser(request)

  const data = {
    profile: await db.query.users.findFirst({ where: eq(users.id, user.id) }),
    preferences: await db.query.preferences.findMany({
      where: eq(preferences.userId, user.id),
    }),
    activities: await db.query.activities.findMany({
      where: eq(activities.userId, user.id),
    }),
  }

  delete data.profile.passwordHash
  delete data.profile.stripeCustomerId

  return new Response(JSON.stringify(data, null, 2), {
    headers: {
      'Content-Type': 'application/json',
      'Content-Disposition': `attachment; filename="user-data-${user.id}.json"`,
    },
  })
}

JSON — валидный машиночитаемый формат. CSV или XML не нужны.

Час 5: Аудит третьих сторон

Перечислите каждый сервис, который касается данных пользователей. Для каждого:

DPA = Data Processing Agreement (Соглашение об обработке данных). У большинства SaaS-провайдеров оно есть. Нужно подписать — обычно просто галочка в их дашборде.

Что можно пропустить (на маленьком масштабе)

• Data Protection Officer: Требуется только если ваша основная деятельность включает систематический мониторинг лиц в большом масштабе. SaaS на 500 пользователей не квалифицируется.
• Data Protection Impact Assessment: Требуется только для обработки высокого риска. Стандартный SaaS не квалифицируется.
• Платформа согласия на куки (Cookiebot, OneTrust): Оверкилл при аналитике без кук. Сама платформа стоит больше в год, чем ценность комплаенса, которую она даёт.

Стоимость бездействия

Штраф GDPR для маленькой компании начинается с €10K–€50K. Реалистичнее — первым наказанием будет предупреждение от надзорного органа. Но реальная стоимость — потерять B2B-сделку, потому что команда закупок покупателя увидела отсутствие политики конфиденциальности и DPA.

5 часов сетапа. Ноль текущих затрат при аналитике без кук. И страница конфиденциальности, которая реально понятна живым людям.

Нужен GDPR-комплаенс для вашего SaaS? Напишите — я включаю это в каждый EU-ориентированный проект.