Что нужно знать ИТ-команде про GDPR
Зарегистрируюсь в Узбекистане и забуду про GDPR…
В нашей практике мы часто сталкивались с распространенным заблуждением, что GDPR не применяется, если компания зарегистрирована вне ЕС, к примеру, в Сербии или Узбекистане, и напрямую не работает с рынком ЕС. Стартапы предполагают, что можно разместить компанию в третьей стране, не декларировать напрямую, что их SaaS-решение работает на европейский рынок, и тогда GDPR их не касается.
Но это не так. В действительности требования GDPR применяются как к компаниям, расположенным в ЕС, так и компаниям, которые таргетят оказание своих услуг в ЕС.
Причем в первом случае приоритетным фактором для оценки места нахождения компании является не место регистрации компании, а место нахождения менеджмента компании. К примеру, если директор компании проживает в Испании и дистанционно управляет компанией в Грузии, то такая грузинская компания считается «европейской» для применения GDPR.
Во втором случае — таргетинг на рынок ЕС воспринимается достаточно широко и оценивается по совокупности факторов. Такими факторами могут быть рекламные кампании, наличие сайта на английском или одном из языков стран ЕС, возможность проведения оплаты из ЕС, возможность получения услуги в ЕС, для приложений — наличие их в сторе по гео для стран ЕС. Если факторов достаточно, то контролирующий орган делает вывод, что приложение или сайт работает на европейском рынке. На практике среднестатистический SaaS-сайт на английском, если функционал доступен для европейского пользователя, влечет обязанность соответствовать GDPR и не важно, где компания зарегистрирована.
Исключение может быть, если сайт явно не предназначен для европейского пользователя, — например, если у вас сайт только на русском языке и предлагает услуги в контексте СНГ. Пользователь из Польши может на него зайти и сделать заказ, но такая разовая покупка не всегда влечет обязанность соблюдать GDPR.
Таким образом, зарегистрировать компанию в Узбекистане и забыть про GDPR не получится.
А мы не обрабатываем персональные данные, потому про GDPR можно забыть…
Теоретически ИТ-продукт или сайт может не обрабатывать персональные данные, но на практике это невозможно, даже если продукт ориентирован на В2В-сектор.
Есть система регистрации? Будут персданные — как минимум собираете адрес электронной почты или номер телефона, имя и фамилию. Возможна оплата? Скорее всего, обрабатываете платежные данные плюс требования бухгалтерского учета и законодательства по противодействию отмыванию денежных средств никто не отменял. Собираете cookies? Тоже обязаны соблюдать требования по персональным данным. Делаете рассылки по электронной почте? Ну вы поняли...
Персональные данные — это все, что позволяет идентифицировать человека, и к этому относятся как более очевидные данные, вроде имени, фамилии и номера телефона, так и менее очевидные, как IP-адрес или адрес электронной почты.
Потому, если у вас не калькулятор (и то не факт), то персональные данные вы обрабатываете.
Да кому интересен мой инди-проект, никто меня не заметит…
Это как плавать в одном бассейне с крокодилами — возможно, укусят, возможно, нет. Ресурс Enforcement Tracker фиксирует более 2800 штрафов за нарушение GDPR, при этом большинство из них выписаны не ИТ-гигантам, а обычным компаниям, в том числе индивидуальным предпринимателям.
Действительно, внимание регуляторов обращено больше на крупный бизнес, и на небольшой ИТ-проект, тем более находящийся вне ЕС, они могут не обратить внимание. Однако всегда может поступить жалоба пользователя, что станет основанием для проведения проверки и наложения штрафа.
Следует отметить, что обеспечение безопасности персональных данных пользователей является широко распространенным трендом. Даже вне контекста гигантских штрафов, которые может наложить регулятор, безопасность данных остается фактором, влияющим на решение клиента.
Соблюдение GDPR требуют крупные площадки, например, Google и Apple. Последняя европейская тенденция — В2В-заказчики требуют от партнеров предоставить подтверждение соблюдения GDPR. Гарантии и заверения о соответствии требованиям законодательства о персональных данных уже часть договоров.
К тому же если вы планируете привлекать инвестиции, то любого инвестора при due diligence внимательно проверяют compliance, и отсутствие базовых документов может сорвать раунд.
Словом, в современном ИТ-мире без соблюдения законодательства о персональных данных уже никак не обойтрись, но все не так страшно, как можно себе представить.
Ключевые требования простыми словами
Собираем только нужное. GDPR требует, чтобы компания собирала только те данные, которые действительно нужны для работы продукта (принцип минимизации), хранила их ровно столько, сколько необходимо, и защищала от утечек. Проще говоря, запрашивать надо только те данные, которые реально будете использовать, а не просто на всякий случай.
Информируем об этом пользователей. Обязательное (но не единственное) требование — наличие Privacy Policy. Этот документ должен быть написан понятным языком и содержать информацию о том, какие данные вы собираете, зачем они нужны, кому передаются и как долго хранятся. Apple и Google требуют ссылку на Privacy Policy при публикации в сторах, но само по себе наличие документа не означает его соответствие GDPR.
Не забываем о cookies. Если ваше приложение или сайт использует cookies или аналогичные технологии для трекинга, нужно получать согласие пользователей до начала сбора данных. Причем в cookie-баннерах нельзя заранее проставлять галочки на все типы данных: должна быть опция отказаться от необязательных cookies. Обычно ситуация решается через несколько кнопок: «Принять всё», «Отказаться ото всего», «Принять только обязательные», а также следует предоставить возможность настроить кастомные согласия.
Европейский регулятор EDPB в своих рекомендациях по deceptive design patterns прямо указывает, что затруднение отказа от cookies является нарушением.
Следите, куда передаете и храните данные. Данные европейских пользователей нельзя просто так перемещать на серверы за пределами ЕС, если там нет адекватного уровня защиты.
К примеру, для передачи данных в США существует два основных механизма: Data Privacy Framework, то есть ваш американский партнер должен быть сертифицирован в этой программе (кстати, Amazon AWS сертифицирован), или на основании специального соглашения с вашим партнером (Standard Contractual Clauses) для всех остальных случаев.
Критически важно понимать, что любой из этих механизмов требует дополнительной оценки рисков.
Яркий пример — недавний штраф TikTok в размере 530 млн евро, выписанный ирландским регулятором. У компании были все необходимые Standard Contractual Clauses, но китайские сотрудники ByteDance получали удаленный доступ к данным европейских пользователей. Ведомство установило, что TikTok не смог доказать, что китайское законодательство (в частности, Anti-Terrorism Law и Counter-Espionage Law) обеспечивает уровень защиты, эквивалентный европейскому. Компания не провела адекватную оценку рисков доступа китайских властей к данным и не внедрила достаточные дополнительные меры защиты сверх SCCs.
Оцените, нужен ли вам отдельный Data Protection Officer (DPO). Для большинства стартапов DPO не обязателен. Если вы не собираете спецданные (о здоровье, биометрия и т. д.) или не собираете очень много данных, то DPO вам не нужен. Однако по мере роста, особенно B2C-продукта, этот вопрос может стать актуальным.
Типичные ошибки, которые дорого обходятся
Первая и самая распространенная ошибка — копирование готовой Privacy Policy из Интернета или от другой компании. Каждый продукт собирает свой набор данных и обрабатывает их по-своему, использует свой набор аналитических сервисов и партнеров. Скопированная политика не будет соответствовать вашей реальной ситуации, что при проверке создаст серьезные проблемы.
Вторая распространенная ошибка — Privacy Policy это не единственное, что вам нужно сделать. Могут потребоваться дополнительные документы, в частности, письменное обоснование трансфера персональных данных за границу ЕС и документация процессов обработки данных (Record of Processing Activities). Однако ключевое — у вас должны быть заранее в архитектуре приложения заложены технические решения, обеспечивающие безопасность данных.
Третья критическая ошибка — обработка специальных категорий персданных (здоровье, биометрия, религиозные взгляды и т. д.) без соблюдения повышенных требований. К примеру, модные сейчас приложения психологической или медицинской помощи посредством ИИ должны соблюдать дополнительные требования — скопированная из Интернета политика приватности точно не сработает.
Как встроить GDPR в процессы разработки
Правильный подход — думать о Privacy с момента проектирования продукта, а не пытаться натянуть compliance на готовое решение. По умолчанию продукт должен собирать минимум данных и предоставлять максимум контроля пользователю.
Должны быть корректно имплементированы сбор и хранение согласий на обработку данных, возможности экспорта данных (пользователь вправе из запросить) и их удаления по требованию пользователя. По возможности нужно обеспечить шифрование данных и минимизировать риски утечек данных.
Нужно также документировать и понимать, какие данные и где хранятся, кто к ним имеет доступ и когда они удаляются, сколько времени они хранятся. При росте продукта и добавлении новых сервисов этот документ становится критически важным для контроля за data flow.
Правильно выстроенные процессы обработки данных с самого начала обходятся дешевле, чем попытки исправить ситуацию после получения претензий от регуляторов. Начинать нужно с базовых вещей: корректной Privacy Policy, продуманного механизма получения согласий, прозрачности в работе с данными пользователей и технической возможности исполнить их права. Это не требует огромных ресурсов на старте, но предполагает осознанный подход и понимание принципов работы с персональными данными. Для растущих компаний следующим шагом становится формализация процессов, создание внутренних политик и, возможно, назначение ответственного за data protection.
Европейская регуляция продолжает развиваться, появляются новые требования к AI-системам через AI Act, меняются подходы регуляторов к конкретным практикам вроде web scraping. Но базовые принципы GDPR остаются неизменными: прозрачность, минимизация данных, безопасность и уважение прав пользователей. Компании, которые строят продукты с учетом этих принципов, создают устойчивую основу для работы не только в Европе, но и на других регулируемых рынках мира.
Опубликовано 11.11.2025