Привет, я Максим, веб-разработчик. Если ваш сайт доступен пользователям из Европы — вам нужно соблюдать GDPR (General Data Protection Regulation). Даже если компания российская и зарегистрирована в Москве. Штрафы за нарушение — до 20 млн евро или 4% годового оборота, в зависимости от того, что больше. Звучит как нечто далёкое, но на практике я сталкиваюсь с этим регулярно: российские компании, которые выходят на международные рынки, зачастую даже не подозревают, что их сайт нарушает европейское законодательство.

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

Когда GDPR касается вас

GDPR применяется, если вы обрабатываете персональные данные резидентов ЕС. «Обрабатываете» — это даже просто собираете email через форму подписки, устанавливаете аналитические cookie, используете пиксели ретаргетинга или сохраняете IP-адреса в логах сервера. Да, IP-адрес по GDPR — тоже персональные данные.

Конкретные критерии: если ваш сайт на английском языке или на языке одной из стран ЕС, если вы принимаете оплату в евро, если вы указываете цены в евро, если вы целенаправленно размещаете рекламу на европейскую аудиторию — GDPR для вас обязателен.

Есть и менее очевидные ситуации. Интернет-магазин, доставляющий товары в Европу. SaaS-сервис с регистрацией, доступной для всех. Блог на русском, но с Google Analytics, который собирает данные обо всех посетителях — включая европейцев. Компания с филиалом в ЕС, даже если головной офис в России.

На одном из моих проектов — российский B2B-производитель промышленного оборудования — сайт был на русском и английском, с формой запроса коммерческого предложения. Европейские клиенты составляли около 15% трафика. Когда мы провели аудит — обнаружили, что Google Analytics запускался без согласия, cookie LinkedIn Insight Tag ставились автоматически, а в политике конфиденциальности не упоминались права субъектов данных по GDPR. Формально — нарушение на несколько пунктов.

Что конкретно нужно сделать на сайте

Cookie consent баннер с реальным выбором

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

Критически важный технический момент: аналитические и маркетинговые cookie НЕ должны загружаться до явного согласия пользователя. Это значит, что Яндекс Метрика, Google Analytics, пиксели рекламных сетей, скрипты ретаргетинга — всё это активируется только после клика «Принять». Многие разработчики лепят баннер для вида, но скрипты всё равно подгружаются при загрузке страницы — это не соответствует GDPR и легко проверяется.

Как проверить: откройте DevTools в браузере, вкладка Network. Перезагрузите страницу без согласия на cookie. Если видите запросы к Google Analytics, Facebook Pixel или аналогичным сервисам — баннер не работает как положено.

Категоризация cookies

GDPR требует разделить cookie на категории:

Необходимые (strictly necessary) — нужны для работы сайта: сессии, авторизация, корзина. Загружаются без согласия.

Аналитические (analytics) — Яндекс Метрика, Google Analytics, Hotjar. Только с согласия.

Маркетинговые (marketing) — рекламные пиксели, ретаргетинг, A/B-тесты. Только с согласия.

Функциональные (functional) — запоминание языка, региона, настроек интерфейса. Чаще всего тоже требуют согласия, хотя некоторые можно обосновать как необходимые.

Пользователь должен иметь возможность управлять каждой категорией отдельно. Причём согласие можно отозвать в любой момент — для этого на сайте должна быть постоянная ссылка на настройки cookie (обычно в подвале).

Политика конфиденциальности

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

Политика должна быть написана понятным языком — не юридическим канцеляритом. GDPR прямо требует «ясного и простого языка», особенно если данные собираются у детей.

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

Права субъектов данных

GDPR даёт пользователям серьёзные права, и вы обязаны обеспечить их реализацию:

Право на доступ (Access). Пользователь может запросить все данные, которые вы о нём храните. У вас 30 дней на ответ.

Право на удаление (Erasure, «право на забвение»). Пользователь может потребовать полного удаления своих данных. Вы обязаны удалить — из базы, из бэкапов (по возможности), из логов.

Право на исправление (Rectification). Если данные неверны — пользователь может потребовать их исправления.

Право на переносимость (Portability). Пользователь может запросить копию всех своих данных в машиночитаемом формате — JSON, CSV.

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

На практике для малого бизнеса достаточно email-адреса, на который пользователи отправляют запросы (обычно privacy@yourdomain.com или dpo@yourdomain.com), и внутреннего процесса обработки таких запросов. Для крупных проектов с тысячами пользователей нужен личный кабинет с функцией экспорта и удаления данных.

GDPR vs 152-ФЗ: что общего и в чём отличия

Российский 152-ФЗ и европейский GDPR — родственные законы, но с существенными различиями.

Согласие на обработку. GDPR требует явного, информированного согласия (opt-in). 152-ФЗ тоже требует согласия, но на практике российские компании привыкли к менее строгому подходу.

Хранение данных. 152-ФЗ требует хранить данные россиян на серверах в России. GDPR не привязан к конкретной территории, но ограничивает передачу данных за пределы ЕС и ЕЭЗ. Если ваш сервер в России и обрабатывает данные европейцев — нужно обосновать передачу данных из ЕС (Standard Contractual Clauses или другой механизм).

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

Штрафы. По GDPR — до 20 млн евро или 4% глобального оборота. По 152-ФЗ — штрафы тоже выросли (до 18 млн рублей по некоторым статьям с 2025 года), но всё ещё несопоставимы с европейскими.

Ответственное лицо. GDPR требует назначения DPO (Data Protection Officer) для крупных организаций. 152-ФЗ требует назначения ответственного за обработку ПДн — фактически аналог, но с меньшими требованиями.

Если ваш сайт работает и на Россию, и на Европу — нужно соблюдать оба закона одновременно. На практике это означает: серверы с данными россиян — в России, cookie consent баннер с полноценным opt-in, двуязычная политика конфиденциальности, процесс обработки запросов субъектов данных.

Техническая реализация cookie consent

Я пробовал несколько решений и остановился на следующих:

Open-source варианты. CookieConsent от Orestbida — легковесная библиотека, хорошо настраивается, бесплатная. Подходит для проектов, где вы сами контролируете код. Klaro — ещё один open-source инструмент, более функциональный, но сложнее в настройке.

Коммерческие решения. Cookiebot — популярное решение с автоматическим сканированием cookie. Стоимость от 9 евро/мес. OneTrust — для крупных проектов, предоставляет полный compliance-пакет. Осторожно — сами по себе эти скрипты загружаются из-за рубежа, что может быть проблемой для российских пользователей при блокировках.

Принцип реализации для любого решения: все сторонние скрипты загружаются через consent manager. До получения согласия скрипт не активен — вместо `<script src="...">` используется `<script type="text/plain" data-category="analytics">`. После согласия consent manager меняет тип на text/javascript, и скрипт загружается.

Для сайтов на Next.js я интегрирую consent manager в компонент верхнего уровня (layout), а скрипты аналитики оборачиваю в условный рендеринг на основе состояния согласия, хранящегося в cookie. Это позволяет не загружать ни один сторонний скрипт до момента согласия — и полностью соответствует GDPR.

Чем грозит несоблюдение на практике

Теоретически штрафы огромны. На практике европейские регуляторы фокусируются на крупных компаниях: Meta, Google, Amazon уже получили миллиардные штрафы. Малый бизнес штрафуют реже, но это не значит, что можно расслабиться.

Реальные риски для российского бизнеса: жалоба европейского пользователя в надзорный орган (это делается в пару кликов), невозможность работать с европейскими партнёрами (многие включают GDPR compliance в требования к контрагентам), репутационные потери при утечке данных.

Один мой клиент — компания, продающая ПО европейским заказчикам — потеряла крупный контракт, потому что партнёр провёл аудит сайта и обнаружил отсутствие cookie consent. Даже не штраф — просто упущенная сделка.

Пошаговый план соответствия GDPR

Для тех, кто хочет действовать: аудит текущего состояния — какие данные собираете, какие cookie ставите, какие сторонние сервисы используете (инструмент CookieMetrix или Cookiebot Scanner покажет всё автоматически). Далее — установка cookie consent баннера с реальным управлением категориями. Подготовка политики конфиденциальности, соответствующей GDPR. Настройка процесса обработки запросов субъектов данных (даже если это просто email-ящик и инструкция для менеджера). Назначение ответственного за защиту данных. Документирование всех процессов обработки данных (Record of Processing Activities).

Для сайтов, ориентированных только на Россию, GDPR формально не обязателен. Но cookie consent баннер в любом случае повышает доверие пользователей, а опыт показывает, что российское законодательство движется в сторону ужесточения — и многое из GDPR постепенно появляется в наших законах. Лучше подготовиться заранее, чем переделывать в авральном режиме.