Украинская компания без офиса в ЕС: когда применяется GDPR и что проверить до первого европейского клиента

Типичная ситуация: украинская IT-компания или SaaS-поставщик договаривается о работе с клиентом из ЕС. До подписания договора контрагент просит DPA, перечень субпроцессоров, описание мер безопасности, правила хранения и удаления данных и объяснение, на каком основании данные будут передаваться в Украину. И именно в этот момент выясняется, что компания имеет отдельные политики, но не понимает, какие требования GDPR реально касаются ее модели.

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

Поэтому подготовку стоит начинать не с покупки “пакета GDPR-документов”, а с ответа на три вопроса: применяется ли GDPR к конкретным операциям, в какой роли работает компания — контролера или процессора, и как фактически движутся персональные данные. Это помогает не делать лишнего и одновременно не пропустить то, что может стать стопером для европейского контракта.

Когда требования GDPR compliance применяются к украинской компании

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

Итак, статья 3 GDPR использует территориальные критерии. Для украинской компании практически важны три ситуации.

1. Обработка связана с деятельностью учреждения компании в ЕС. Это может быть не только отдельное юридическое лицо: значение имеют стабильность деятельности и реальная связь обработки с европейским учреждением.
2. Компания без учреждения в ЕС предлагает товары или услуги людям, которые находятся в ЕС. Платность не является обязательной. Значение имеют признаки намерения работать именно с этим рынком: реклама для конкретных стран, доставка в ЕС, цены в соответствующей валюте, местные домены, языки и другие признаки намерения обслуживать людей в ЕС. Самого факта, что украинский сайт можно открыть из Европы, обычно недостаточно.
3. Компания отслеживает поведение людей в ЕС — например, строит профили, системно анализирует их действия для прогнозирования или персонализированной рекламы. Не каждый технический журнал является “мониторингом”, поэтому следует оценивать цель, масштаб и дальнейшее использование данных.

Отдельно важно не путать место пребывания человека с его гражданством (гражданство человека само по себе не является критерием статьи 3). Данные гражданина Франции, который находится в Украине, не подпадают под GDPR автоматически только из-за его паспорта. И наоборот, украинский гражданин, которому целенаправленно предлагают услугу во время пребывания в Польше, может быть лицом в ЕС в значении этой нормы.

Для бизнеса это означает, что определить, применяется ли GDPR к компании, только по стране ее регистрации или гражданству пользователей нельзя.

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

Поэтому первый практический вопрос для компании звучит не “есть ли у нас пользователи из Европы?”, а “какие именно операции связаны с людьми в ЕС и почему?”.

Интересно: Как создать сайт и вести бизнес в интернете: юридические аспекты для создания сайта

Распределение ролей между контролером и процессором персональных данных

Для B2B-компаний это одна из самых частых точек путаницы. Сам факт договора с компанией из ЕС не означает, что каждая операция украинского поставщика автоматически подпадает под GDPR по статье 3(2). Но требования защиты данных всё равно могут зайти в проект через договор и требования самого клиента.

Украинский разработчик или SaaS-поставщик часто обрабатывает данные не для собственных целей, а по инструкциям европейского клиента. В такой части отношений украинская компания может быть процессором, а клиент — контролером.

Сам факт, что процессор продает услуги компании из ЕС, не тождественен предложению товаров или услуг людям в ЕС по статье 3(2). Однако европейский контролер обязан привлекать процессоров с достаточными гарантиями и заключить договор по статье 28.

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

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

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

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

Семь шагов аудита перед подписанием договора DPA с контрагентом из ЕС

Сильная подготовка — это не самая длинная Privacy Policy. Контрагенту важно видеть, что документы, договоры, технические процессы и реальный путь данных не противоречат друг другу. До подписания контракта стоит пройти семь проверок.

Понять, какие именно операции подпадают под GDPR

Составьте короткую карту: кто этот человек, находится ли он в ЕС, какой продукт ему предлагают, какие признаки целевого рынка существуют, отслеживается ли поведение и где компания имеет учреждения. Вывод нужно делать не “относительно компании в целом”, а конкретных операций.

Такая карта помогает не создавать GDPR-проект вслепую. У одной компании часть операций может прямо подпадать под Регламент, другая — регулироваться требованиями через договор с клиентом, а часть вообще не иметь связи с ЕС.

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

Правильно распределить роли контролера и процессора

• Контролер определяет цели и существенные средства обработки.
• Процессор действует от его имени и по документированным инструкциям.

Название стороны в договоре не решает вопрос, если фактическое поведение другое.

От роли зависят уведомления людям, ответы на запросы, договор по статье 28, привлечение субпроцессоров, уведомление об инцидентах и распределение ответственности. Поэтому недостаточно взять договорной шаблон, в котором украинская компания уже названа “processor”. Сначала необходимо проверить, соответствует ли этому реальная модель работы.

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

Проверить путь данных из ЕЭЗ в Украину

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

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

Если же украинский получатель уже прямо подпадает под GDPR по статье 3 в отношении этой обработки, действующие положения 2021 года не следует подставлять механически. Европейская комиссия объясняет, что этот набор не рассчитан на импортера, к которому GDPR уже применяется. Механизм передачи в такой ситуации оценивают отдельно.

Для компании это один из тех участков, где готовый шаблон особенно опасен. Формально подписанный документ еще не означает, что механизм передачи выбран правильно.

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

Подготовить пакет доказательств, а не одну политику

Европейский клиент может попросить не один документ, а подтверждение того, как система работает в реальности. В зависимости от роли, масштаба и риска это могут быть:

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

И стоит понимать, что здесь цель подготовки — не собрать максимально большую папку документов. Нет.

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

Также может быть интересно: Документы для айти: юридическая безопасность ИТ-разработчиков

Проверить, нужны ли представитель в ЕС и DPO

Если к компании за пределами ЕС применяется статья 3(2), статья 27 по общему правилу предусматривает письменное назначение представителя в ЕС. Есть исключение для обработки, которая является эпизодической, не охватывает в большом масштабе особые категории или данные о судимостях и вряд ли создает риск для прав и свобод людей. Вывод об исключении стоит зафиксировать, а не просто не назначать представителя.

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

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

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

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

Во время инцидента процессор должен уведомить контролера без неоправданной задержки. Контролер оценивает риск и, когда уведомление надзорного органа необходимо, должен сделать это без неоправданной задержки и, по возможности, в течение 72 часов после того, как узнал о нарушении.

Этот этап часто требует участия не только юриста. Юридическое требование должно превратиться в конкретную возможность продукта или внутренний процесс.

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

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

Не смешивать GDPR с местными правилами отдельной страны

GDPR является общей основой для ЕС, но не отменяет национальные правила государств-членов. Для маркетинговых сообщений, файлов cookie, данных работников, видеонаблюдения или отдельных секторов могут действовать дополнительные требования. Поэтому запуск в Германии, Польше или Испании иногда требует отдельного местного приложения к общей программе соответствия.

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

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

Почему этот чек-лист не заменяет анализ конкретной компании

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

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

Интересно: Документы, которые должны быть размещены на сайте, продающем товары или услуги

Три ошибки, которые разрушают внедрение GDPR и блокируют контракты

• Ошибка первая: Компания обещает “полное соответствие GDPR”, не зная своих потоков данных. Во время проверки клиент видит неучтенные аналитические сервисы, резервные копии или доступ службы поддержки.

И проблема здесь не только в самом сервисе, который забыли указать. Для контрагента это сигнал, что компания не имеет полной картины того, куда попадают данные его пользователей.

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

То есть компания уже потратила время на документ, но во время проверки всё равно вынуждена возвращаться к анализу фактических потоков данных.

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

Все три ситуации имеют общую причину: компания начинает с документов, а не с фактической модели работы.

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

Разработка документов GDPR и сопровождение ІТ-юриста

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

Для руководителя компании конечный результат должен быть ещё проще: понятно, какие требования касаются бизнеса, где есть пробелы, что необходимо сделать до контракта и какие вопросы можно не внедрять без необходимости. Это и есть граница между формальной “GDPR-папкой” и системой, с которой бизнес может реально работать.

Юристы “Правовой Помощи” могут провести диагностику применимости GDPR, аудит пробелов, подготовить договорной и внутренний пакет и сопроводить внедрение вместе с технической командой.

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

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

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

Больше о нашей услуге здесь: Защита персональных данных на предприятии.