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

Достаточно одного клиента из Германии, одного визита с европейского IP — и ваша организация попадает под его действие. Именно поэтому тему игнорировать нельзя: слишком велик риск штрафов.

Что такое GDPR и зачем он нужен российским компаниям

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

Как и для чего появился GDPR

До 2018 года в Европе действовала Директива 95/46/EC — регламентировала обработку персональных данных, но давала странам ЕС много свободы в трактовке. В результате у каждой юрисдикции были свои правила, а бизнесу приходилось адаптироваться к десяткам вариаций.

Всё изменилось с принятием GDPR (General Data Protection Regulation):

• В 2016 году регламент был утверждён Европарламентом.
• В мае 2018 года он вступил в силу во всех странах ЕС.
• Объединил правила в единый набор требований и заменил директиву.

Регламент GDPR исходит из идеи «если у вас есть мои данные, я имею право знать, что вы с ними делаете и влиять на процесс». Бизнесу GDPR сигналит — обрабатывайте данные этично, не нарушайте приватность.

Кто есть кто в терминологии GDPR: controller, processor, DPO

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

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

• интернет-магазин, который собирает адреса доставки;
• SaaS-сервис, хранящий профили пользователей;
• медицинская клиника, ведущая электронную карту пациента.

Контролёр несёт основную юридическую ответственность перед субъектом данных и регулятором.

Processor, обработчик данных — подрядчик или партнёр, который действует от имени контролёра. Он не решает, что собирать и зачем, а выполняет конкретную задачу.
Примеры:

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

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

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

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

В российских реалиях роль DPO часто исполняет ИБ-специалист, юрист или IT-директор. Но по требованиям GDPR это должна быть независимая обученная фигура, защищённая от конфликта интересов.

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

На кого распространяется GDPR

Когда говорят, что GDPR действует и в России, это звучит странно: почему европейский закон должен касаться компании, работающей в Нижнем Тагиле или Новосибирске? Дело в том, что GDPR работает не по географии офиса, а по маршрутам персональных данных. Если пользователь из ЕС заходит на ваш сайт, оформляет заказ, оставляет email — включается регламент.

Многие российские компании сталкиваются с этим незаметно: подключили Google Analytics,  разместили английскую версию сайта. Тем самым открыли двери для европейских пользователей. Иногда достаточно одной галочки в кабинете рекламной сети, чтобы попасть под юрисдикцию Европейского союза.

Экстерриториальный принцип

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

Пример из практики: российская B2B-компания запускает лендинг с формой для заявки. Сайт открыт для Европы, адреса не фильтруются. Пользователь из Франции отправляет email — обработка попадает под действие GDPR. Формальный повод для штрафа может появиться даже при отсутствии коммерческой сделки.

Предложение товаров или услуг резидентам ЕС

Намерение взаимодействовать с европейской аудиторией — один из критериев действия регламента.

Оно проявляется в интерфейсах, маркетинге, договорах. Вот что может считаться «предложением»:

• отображение цен в евро или других европейских валютах;
• локализация сайта под языки ЕС;
• информация о доставке в Германию, Францию, Италию;
• таргетированная реклама на пользователей из ЕС;
• акцент на отзывах европейских клиентов.

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

Сбор cookie и аналитики, доступной в ЕС

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

Обычно это происходит в двух случаях:

• сайт открыт для визитов с IP-адресов из Европы (не стоит технический запрет на доступ);
• подключены аналитика и реклама (Google Analytics, Яндекс.Метрика, соцсети, маркетплейсы).

Здесь вступают в силу правила согласия: GDPR требует, чтобы пользователь сам выбрал, какие cookie разрешить, прежде чем они будут установлены. Автоматическая установка без opt-in считается нарушением, даже если cookie «безобидные».

Подрядчики и трансграничные процессы

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

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

• подписывать соглашение об обработке данных (Data Processing Agreement);
• соблюдать условия передачи данных за границу;
• использовать меры защиты, описанные в ст.32 GDPR.

Кроме того, если данные передаются в третью страну (например, из ЕС в Россию), необходимо обеспечить законность трансграничной передачи: заключить стандартные договорные положения (SCC), применить технические меры (например, шифрование с хранением ключей в ЕС), предусмотреть аудит.

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

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

Принципы обработки данных —ст. 5

Статья 5 GDPR задаёт базовые правила: как бизнес должен относиться к данным. Вот как можно коротко сформулировать принципы обработки персональных данных по GDPR:

1. Обработка должна быть прозрачной — человек понимает, что у него собирают, зачем, и как это влияет на него.
2. Данные используют только для конкретных целей. Нельзя собрать email «на всякий случай» и через месяц отправить рекламу, если пользователь об этом не знал.
3. Объём должен быть минимальным. Если бизнес может работать без даты рождения — не стоит её просить.
4. Информация должна быть актуальной и точной. Ошибки в профиле, устаревшие телефоны, забытые записи — потенциальный повод для жалобы.
5. Данные хранят только до тех пор, пока это нужно. Нет активности — удаляют.
6. Компания должна защитить информацию и быть готовой доказать, что делает это системно.

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

Законные основания для обработки — ст. 6

GDPR не запрещает обрабатывать персональные данные. Он требует, чтобы у компании было на это юридическое основание.

Таких оснований всего шесть, но чаще всего применяются следующие:

1. Согласие пользователя. Чёткое, добровольное, зафиксированное. Подходит для маркетинга, подписок, опросов. Важно, чтобы человек мог его отозвать и данные удалились.
2. Исполнение договора. Например, если клиент оформил заказ, вы вправе хранить его контактные данные, потому что без этого не сможете выполнить обязательства. Это сильное основание, не требующее отдельного согласия.
3. Законный интерес. Самый тонкий вариант. Бизнес может обрабатывать данные, если это оправдано и не нарушает интересы пользователя. Пример — логирование попыток входа в систему. Но здесь нужен баланс интересов: компания обязана оценить, нет ли риска для субъекта данных.

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

Шесть легитимных причин держать персональные данные:

Права субъектов данных — ст. 12–22

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

Вот ключевые права пользователя:

1. Получить доступ к своим данным и узнать, как они обрабатываются.
2. Исправить неточности.
3. Потребовать удалить данные — «право быть забытым».
4. Ограничить обработку, если она временно неактуальна или спорна.
5. Перенести данные в другой сервис.
6. Отказаться от участия в автоматизированных решениях (например, когда система оценивает кредитоспособность без участия человека).

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

• где именно хранятся данные пользователя — в CRM, в почте, в Excel-файле у менеджера,
• можно ли их передавать, хранить или нужно удалить,
• как подтвердить, что данные действительно удалены или переданы по запросу.

Процесс лучше выстроить заранее, чтобы сотрудники понимали, что и как делать.

Требования к безопасности обработки — ст. 32

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

Что здесь важно:

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

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

Передача данных за пределы ЕС — ст. 44–50

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

Допустима такая передача только при выполнении одного из условий:

• Получатель находится в стране с официально признанным уровнем защиты (например, Канада или Япония). Россия в этот список не входит.
• Заключены стандартные договорные положения (Standard Contractual Clauses, SCC). Это шаблонный юридический документ, одобренный Еврокомиссией.
• Между компаниями в холдинге действуют внутренние корпоративные правила (Binding Corporate Rules) — сложный и дорогостоящий механизм.
• Есть согласие субъекта — если оно оформлено правильно, его можно использовать для разовой передачи.

В 2020 году требования к трансграничной передаче ужесточились.

Суд ЕС в деле Schrems II отменил механизм Privacy Shield — теперь при передаче данных из ЕС в другие страны компании обязаны сами проверять, насколько безопасно обрабатываются данные за границей. При необходимости — усиливать защиту (например, шифрованием).

Теперь недостаточно подписать договор — нужно убедиться, что у получателя данных есть технические и правовые гарантии. В частности, широко применяется клиентское шифрование с хранением ключей в ЕС.

Экспорт персональных данных возможен только при надёжных гарантиях:

GDPR требует разумного подхода к данным. Компании, которые понимают структуру регламента, быстрее внедряют соответствие и легче проходят аудит.

Чек-лист соответствия GDPR

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

 Аудит и инвентаризация персональных данных

GDPR начинается с вопроса: что именно мы обрабатываем? Без этого не получится обосновать законность, назначить роли, выстроить защиту или отвечать на запросы пользователей.

В рамках аудита бизнес анализирует:

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

Результатом становится реестр операций обработки (англ. ROPA — Record of Processing Activities), обязательный по ст. 30 GDPR. Формально — таблица, по факту — основа для всей последующей работы: на основании этих записей вы определяете основания, внедряете согласие, оцениваете риски, оформляете договоры.

Если пропустить этот шаг, всё остальное превратится в фикцию.

Cookie-баннер и согласие

Баннер согласия на cookie — один из первых и самых заметных признаков того, что компания всерьёз относится к GDPR. Но это не просто формальность.

GDPR требует:

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

Сценарий «продолжая пользоваться сайтом, вы соглашаетесь…» больше не работает. Он прямо противоречит позиции европейских регуляторов.

Если сайт технически доступен в ЕС, а вы используете, например, Google Analytics или пиксели соцсетей — GDPR считает, что данные собираются. А значит, согласие необходимо.

Актуализация политики конфиденциальности

Старая добрая политика конфиденциальности — это уже не текст, который никто не читает. GDPR требует, чтобы документ:

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

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

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

DPIA и оценка рисков

Data Protection Impact Assessment (оценка воздействия на защиту данных) — нечто среднее между ИБ-анализом и юридическим аудитом. Её цель — предсказать, какие риски создаёт обработка данных, принять меры, прежде чем произойдёт нарушение.

Когда DPIA требуется:

• при массовой обработке чувствительных данных (медицина, финансы, биометрия);
• при систематическом наблюдении за поведением пользователей (например, поведенческая аналитика);
• при высоком риске для прав и свобод субъектов.

Процедура включает:

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

Если риски остаются значительными — DPO обязан проконсультироваться с регулятором до начала обработки. В реальности хорошо оформленная DPIA помогает избежать претензий при проверке.

Договоры с процессорами

Если вы используете подрядчиков: облачные хранилища, сервисы аналитики, рассылки, IT-аутсорс — вы обязаны заключить с ними специальное соглашение об обработке данных. Это документ, соответствующий требованиям статьи 28 GDPR.

В договоре указывается:

• кто контролёр, кто обработчик;
• какие именно данные передаются и зачем;
• срок, цели и способы обработки;
• меры безопасности и порядок доступа;
• условия передачи другим лицам;
• процедура удаления или возврата данных после окончания контракта.

Форма, как правило, стандартная — часто поставщик предоставляет её сам. Но важно проверить: не перекладывает ли он всю ответственность на вас. Если договор отсутствует, а обработка идёт — штраф практически гарантирован.

Реализация прав субъектов данных

Пожалуй, самый ощутимый для пользователя раздел GDPR. Любой человек имеет право:

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

Срок ответа — 30 дней, он жёстко фиксирован. Компания должна:

• создать канал для подачи запроса (форма, email, кабинет);
• идентифицировать заявителя;
• проверить обоснованность запроса;
• выдать корректный ответ или объяснение отказа.

Важно встроить реализацию прав в клиентские процессы, чтобы она не была оторвана от бизнеса.

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

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

Неполный cookie-баннер

С него всё начинается и, как правило, именно он выдаёт: «компания делает вид, что соблюдает GDPR». Баннер вроде бы есть, но:

• он появляется после загрузки сторонних скриптов, а не до;
• пользователь не может отключить аналитику или маркетинг — только «Принять»;
• нет настроек по категориям, только общее согласие;
• нет логирования согласий и отказов;
• баннер не блокирует cookie до выбора, а просто сообщает.

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

Если cookie-файлы загружаются до согласия, а баннер носит чисто информативный характер — формально вы нарушаете регламент. И неважно, работаете ли вы в Амстердаме или в Краснодаре.

Отсутствие журналирования операций

Компании часто считают, что если утечек не было, значит, всё в порядке. Но GDPR требует доказуемости: если регулятор или сам пользователь спросит, кто имел доступ к его данным, когда и зачем — нужно ответить. Без логов это невозможно.

Какие операции подлежат журналированию:

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

Журналы должны храниться в защищённом виде, исключающем незаметное изменение. Особенно критично — логи административного доступа. В крупных системах это реализуется через SIEM, в малых — хотя бы через централизованное логирование и отчёты.

Если при проверке выясняется, что вы не можете восстановить цепочку доступа к данным — нарушение считается серьёзным.

Пропуск DPIA

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

• мониторинге поведения пользователей (например, через тепловые карты, поведенческий анализ, запись сессий);
• обработке больших объёмов персональных данных;
• использовании чувствительной информации (здоровье, финансы, геолокация);
• принятии решений автоматическими системами (например, предодобрение кредита).

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

Даже базовая DPIA с описанием процессов, рисков и мер снижения — уже защита в случае претензий.

Формальное, а не явное согласие

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

Регламент требует:

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

Формула «подписываясь на рассылку, вы соглашаетесь с политикой» — допустима, но только если политика ясная и доступна по ссылке до момента согласия.

Кроме того, согласие нужно хранить: кто, когда, в каком объёме, с каким текстом. Если пользователь подаёт жалобу, а вы не можете доказать, что у вас было его согласие — регулятор встанет на сторону пользователя.

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

Чтобы не столкнуться с проблемой в самый неудобный момент, проверьте всё заранее.

GDPR и №152-ФЗ: краткое сравнение

Российский закон о персональных данных №152-ФЗ и европейский регламент GDPR говорят об одном и том же — о защите человека от злоупотреблений в обращении с его данными. Но говорят разным языком и с разными целями. №152‑ФЗ — рамочный закон, который создаёт общие требования и делегирует детали подзаконным актам. GDPR — комплексный регламент, который детализирует всё, от принципов до процессов.

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

Назначение DPO

Европейский регламент требует не только документировать процессы, но и назначать отдельного специалиста — Data Protection Officer, если:

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

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

В России аналогичной роли в законодательстве нет. №152‑ФЗ не требует назначать ответственного за защиту данных как отдельную фигуру. Однако при проверке Роскомнадзор может запросить контактное лицо — чаще всего эту функцию формально выполняет IT-директор, юрист или специалист по информационной безопасности. Но это, скорее, вопрос практики, а не юридического требования.

Если компания ориентируется на международный рынок, наличие DPO — плюс. Это упрощает диалог с партнёрами и демонстрирует зрелый подход.

Согласие на cookie

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

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

Формулировка «продолжая использовать сайт, вы соглашаетесь…» считается недопустимой. Подход — только opt-in.

В России ситуация мягче. №152‑ФЗ прямо не упоминает cookie, а Роскомнадзор рассматривает их как техническую информацию — если cookie не позволяют идентифицировать человека, они не попадают под защиту закона. При этом в письмах регулятора подчёркивается: если cookie используются для сбора персональных данных, нужно получать согласие и информировать пользователя.

На практике российские компании часто ограничиваются баннером «мы используем cookie», без возможности выбора. Такой подход приемлем по №152‑ФЗ, но не соответствует требованиям GDPR. Если сайт открыт для пользователей из ЕС, его поведение должно меняться: баннер с настройками, запрет на загрузку сторонних скриптов до выбора, логирование согласий.

Трансграничная передача данных

Тема, где российское и европейское регулирование расходятся особенно резко.

В GDPR передача возможна только при наличии достаточных гарантий:

• признание уровня защиты страны получателя (адекватность);
• стандартные договорные положения (SCC);
• корпоративные правила внутри группы компаний (BCR);
• отдельное согласие субъекта.

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

В России с 1 марта 2023 года действует обновлённая статья 12. Она требует, чтобы оператор уведомил Роскомнадзор до начала передачи и получил от него разрешение. Передача без такого уведомления возможна только в отдельных случаях — например, для исполнения международного договора или защиты жизни субъекта.

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

GDPR и №152‑ФЗ движутся в одном направлении, но с разной скоростью и уровнем детализации:

1. Российский закон формально строже в вопросе трансграничной передачи, но слабее в части пользовательских прав и ответственности.
2. GDPR требует доказуемых процессов, прозрачности и акцента на интересах субъекта.

Если бизнес работает с зарубежной аудиторией или хранит данные в иностранных сервисах, без соответствия обоим требованиям ему не обойтись.

Ответственность и штрафы по GDPR

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

Компании, работающие с ЕС, не могут просто «забыть обновить политику». Нарушения фиксируют, штрафуют и публикуют в открытых реестрах. Уровень прозрачности такой, что PR-отдел узнаёт о штрафе не из письма юриста, а из новостной ленты. Поэтому бизнесы по всему миру — от гигантов до локальных подрядчиков — всерьёз относятся к регламенту.

Максимальные санкции

GDPR предусматривает две градации штрафов — в зависимости от тяжести нарушения:

• до 10 миллионов евро или 2 % от мирового оборота — за ошибки в документации, недостатки в договорных отношениях, отсутствие DPO, непроведённую DPIA;
• до 20 миллионов евро или 4 % от оборота — за незаконную обработку данных, нарушение прав субъектов, передачу данных без оснований, утечки.

Размер определяется не автоматически. Регулятор учитывает:

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

Формально штраф может быть снижен при добросовестной позиции. Но в большинстве случаев он сохраняется в пределах десятков или сотен тысяч евро, особенно если нарушение связано с обработкой cookie, необоснованной передачей или отсутствием правовых оснований.

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

Сравнение с российским законом

Российские компании также начали сталкиваться с реальными санкциями:

С точки зрения защиты прав субъектов и уровня ответственности — GDPR значительно жёстче, особенно в части пользовательских прав и прозрачности.

Часто задаваемые вопросы по внедрению GDPR

Когда начинаешь разбираться в GDPR, возникает ощущение, что вопросов больше, чем ответов. Где заканчивается здравый смысл и начинаются юридические риски? Как отличить реальную угрозу от гипотетической? Ответим на четыре самых частых вопроса от российских компаний, которые выходят на рынок ЕС или просто пытаются привести процессы в порядок.

 Действует ли GDPR, если сайт только на русском?

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

• сайт не локализован на английский,
• нет доставки в Европу,
• реклама нацелена на РФ.

Если у сайта нет ограничений по IP или географии, а в форме можно оставить e-mail — регламент может считаться применимым. Особенно если сайт использует Google Analytics, зарубежные системы аналитики и рекламы.

Когда обязателен DPO?

Data Protection Officer обязателен, если компания:

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

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

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

Как хранить согласия?

Чтобы согласие считалось действительным по GDPR, нужно:

• зафиксировать факт добровольного выбора (нажатие, отметку, документ);
• хранить дату, время, IP-адрес, версию политики, на которую человек согласился;
• обеспечить доказуемость — при запросе вы должны показать, что согласие было и на каких условиях.

Идеальный вариант — использовать систему управления согласиями (consent management platform), которая:

• показывает баннер пользователю,
• даёт выбор по категориям,
• логирует согласие в базе,
• предоставляет историю согласий по ID.

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

Что делать при запросе на удаление данных?

Когда пользователь просит удалить его данные — это право, а не просьба. Компания обязана:

1. Убедиться, что запрос подаёт именно владелец данных. Это важно для исключения злоупотреблений.
2. Определить, какие данные можно удалить, а какие — нужно сохранить по закону (например, бухгалтерия, налоговая отчётность).
3. Удалить данные из всех систем, включая резервные копии (если это технически возможно без нарушения их целостности).
4. Подтвердить удаление в течение 30 дней.

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

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

Шаги к соответствию GDPR

Часто именно внедрение GDPR помогает навести порядок: разобраться, что собирается, кто имеет доступ, где риски и как их уменьшить.

С чего начать:

• Провести аудит данных — понять, какие сведения вы обрабатываете, где они хранятся, кто с ними работает.
• Настроить cookie-баннер, пересмотреть логику согласий.
• Переписать политику конфиденциальности, чтобы её мог прочитать живой человек.
• Подготовить реестр операций (ROPA), соглашения с подрядчиками, и, при необходимости, DPIA.
• Назначить ответственного за процесс, даже если формально это не DPO.

Один шаг за другим и регламент из пугающего PDF превращается в рабочую систему.

К кому обратиться за помощью

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

1. Интеграторы ИБ и IT — если у вас уже есть партнёр по ИБ-системам (SIEM, DLP, NGFW), он может помочь в выстраивании документации, моделей угроз и базовой архитектуры.
2. Юристы с фокусом на GDPR и персональные данные — особенно важны для договоров, DPIA и оценки правовых рисков трансграничной передачи.
3. Поставщики платформ CMP (Consent Management Platform) помогут настроить баннер, собрать согласия, хранить логи.
4. Эксперты по системам защиты данных помогут с технической реализацией: шифрование, журналирование, контроль доступа.

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

Главное

GDPR — это зрелый подход к работе с персональными данными.

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

GDPR работает вне границ.
Если сайт доступен из Европы, если вы принимаете платежи, показываете рекламу, собираете email через формы или используете cookie-аналитику — вы попадаете в зону действия регламента. Даже если всё на русском, а клиентов из ЕС вроде как нет.

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

Настроить соответствие — реально.
Всё начинается с инвентаризации: какие данные, где, зачем. Потом — работа с согласиями, договорами, логами, политиками. Главное — системность и честность. Не нужно «делать всё идеально», достаточно идти поэтапно. Ошибки возможны, но при наличии внятного процесса и логики их не будут считать умышленными.

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