Штраф до 20 млн евро или 4% мирового годового оборота по GDPR может возникнуть не из-за одной ошибки в Privacy Policy, а потому, что сервис изначально собирает больше сведений, чем нужно, не разделяет роли пользователей и не контролирует передачу данных подрядчикам. Когда эти решения уже зафиксированы в коде, исправление становится дорогим: меняются формы регистрации, события аналитики, схема базы, договоры и процессы поддержки.
Для SaaS-платформы, агрегатора цен, маркетплейса или сервиса веб-сбора персональная информация не является задачей только юридического отдела. Она проходит через продуктовые требования, API, логи, CRM, облачное хранилище, подрядчиков рассылок и техподдержку. Поэтому правовой контроль должен появляться до релиза функции, а не после первого запроса субъекта данных или уведомления от регулятора.
Что означает конфиденциальность при создании сервиса
Конфиденциальность по проектированию продукта — это практическое применение принципа защиты данных на стадии разработки. В GDPR этот подход закреплен статьей 25 как защита данных по умолчанию и на этапе проектирования. Требование относится не только к крупным платформам: оно затрагивает любую компанию, которая определяет цели и способы обработки данных лиц из ЕЭЗ.
Смысл статьи 25 не в том, чтобы получить универсальный набор галочек. Компания должна соразмерно риску внедрить технические и организационные меры. Для продукта, который хранит только корпоративные контакты, набор мер будет одним. Для сервиса, объединяющего профили пользователей, историю покупок, геолокацию и поведенческие события, — существенно строже.
Правовая команда должна понимать архитектуру, а продуктовая и инженерная команды — цель каждого поля, события и интеграции. Если на этот вопрос нет четкого ответа, данные не следует собирать до появления законного основания и документированной цели обработки.
Где риск появляется еще до запуска
Наиболее дорогие проблемы возникают в привычных продуктовых решениях. Форма регистрации запрашивает дату рождения на всякий случай. Система аналитики получает идентификатор пользователя вместе с полной историей действий. Сотрудник выгружает клиентскую базу в таблицу для проверки гипотезы. Подрядчик получает доступ к CRM без ограничений по ролям и сроку.
Каждый из этих сценариев меняет профиль риска. GDPR требует соблюдать принципы законности, прозрачности, ограничения цели, минимизации и ограничения хранения согласно статье 5. ФЗ-152 также требует, чтобы содержание и объем персональных данных соответствовали заявленным целям обработки. Если сервис собирает контактные данные для доступа к личному кабинету, использовать их затем для самостоятельной лидогенерации или передавать партнерам без надлежащего основания нельзя.
Отдельная зона риска — веб-скрапинг. Публичность страницы не означает, что любой объем информации можно свободно собирать, объединять и коммерчески использовать. Необходимо отдельно оценивать условия сайта, ограничения API, режим базы данных, авторские права на структуру и содержание, наличие персональных данных, а также правила прямого маркетинга в целевых юрисдикциях.
Для команды, которая парсит цены, критично разделять техническую доступность и юридическую допустимость. Агрессивные запросы могут привести к блокировке IP, претензии конкурента — к спору о нарушении условий использования и прав на базу данных, а включение в выгрузку контактов физических лиц — к дополнительным требованиям по privacy-комплаенсу.
Решения, которые нужно принять до первой строки кода
Хорошее проектирование начинается с карты потоков данных. Она показывает не только то, что пользователь вводит в интерфейсе, но и сведения из cookie, логов, обращений в поддержку, платежных провайдеров, интеграций и выгрузок в сторонние сервисы. Без такой карты невозможно корректно подготовить Privacy Policy, реестр обработки и договоры с обработчиками.
До запуска новой функции следует зафиксировать четыре вопроса:
- какая конкретная бизнес-цель оправдывает сбор каждого типа данных;
- какое правовое основание применяется для обработки и передачи;
- кто получает доступ, в какой стране размещаются данные и на какой срок;
- как пользователь реализует право на доступ, удаление, исправление или возражение против обработки.
Для B2B-сервиса не всегда требуется согласие. В зависимости от сценария основанием могут быть исполнение договора, законная обязанность или законный интерес. Но законный интерес нельзя объявить формулой по умолчанию: необходимо сопоставить интерес бизнеса с правами человека, оценить ожидания субъекта и предусмотреть понятный механизм возражения.
Если продукт ориентирован на Калифорнию, необходимо учитывать требования CCPA с поправками CPRA: прозрачность категорий собираемых сведений, целей использования и передачи, а в применимых случаях — возможность отказаться от продажи или передачи персональной информации. Для российских операций параллельно проверяется локализация, основания обработки и уведомительные обязанности по ФЗ-152. Один документ для всех рынков редко закрывает эти вопросы без адаптации.
Минимизация данных как продуктовая экономия
Юристы часто слышат возражение, что дополнительные поля могут пригодиться позднее. Но запасной сбор создает постоянные расходы: больше данных нужно защищать, учитывать в запросах субъектов, удалять по истечении срока и включать в контур реагирования на утечки.
Практичный подход — разделить обязательные и факультативные поля, отключить сбор идентификаторов там, где достаточно агрегированной статистики, а события аналитики связать с псевдонимами. Псевдонимизация снижает риск, но не превращает информацию автоматически в обезличенную: если организационно или технически можно восстановить связь с человеком, GDPR продолжает применяться.
Для дата-брокера или владельца коммерческого набора данных особенно важна проверка происхождения записей. Нужно документировать источник, условия получения, объем разрешенного использования, сроки хранения и ограничения на передачу покупателю. Лицензионный договор на базу данных не исправит незаконный сбор, но может точно определить права на использование, запретить перепродажу и распределить ответственность сторон.
Подрядчики, облака и доступы
Большинство инцидентов происходит не в момент сбора, а на этапе передачи. CRM, хостинг, служба поддержки, платежный провайдер, аналитическая система и подрядчик рассылок могут действовать как обработчики данных. В отношениях с ними необходимы договорные условия, соответствующие статье 28 GDPR, включая предмет и срок обработки, инструкции контролера, требования безопасности, правила привлечения субподрядчиков и возврата либо удаления информации.
DPA не должен быть приложением, которое подписывают без сверки с реальной архитектурой. Если подрядчик фактически использует данные для собственных целей, статус сторон и договорная модель могут измениться. Если информация передается за пределы ЕЭЗ, потребуется отдельно проверить механизм международной передачи и меры защиты.
На техническом уровне нужны разграничение прав доступа, многофакторная аутентификация для административных учетных записей, журналирование действий, контроль выгрузок и процесс немедленного отключения доступа при увольнении или завершении проекта. Это не заменяет юридические документы, но позволяет доказать, что заявленные меры действительно работают.
Когда требуется оценка воздействия
Статья 35 GDPR предусматривает оценку воздействия на защиту данных, если обработка вероятно создает высокий риск для прав и свобод физических лиц. Это может касаться масштабного профилирования, систематического мониторинга, обработки специальных категорий данных или объединения крупных массивов информации из нескольких источников.
Оценка воздействия полезна не как формальность перед запуском. Она выявляет, какие данные можно исключить, где нужна дополнительная защита, почему выбран конкретный срок хранения и как снизить последствия потенциального инцидента. Если высокий риск нельзя уменьшить доступными мерами, до начала обработки может потребоваться консультация с надзорным органом.
Готовность к утечке проверяется заранее
Статья 33 GDPR устанавливает общее правило уведомления надзорного органа в течение 72 часов после того, как контролер узнал о нарушении, если оно может создать риск для прав и свобод физических лиц. Это короткий срок для компании, которая сначала пытается понять, какие таблицы затронуты, кто имел к ним доступ и какие сведения содержались в резервных копиях.
Поэтому в продукте и корпоративных процессах заранее определяют владельца инцидента, каналы эскалации, порядок сохранения логов, критерии оценки риска и шаблоны коммуникаций. Команда должна уметь быстро отличить ошибочную отправку одного письма от компрометации базы клиентов, не скрывая проблему и не делая преждевременных публичных заявлений.
Юридическая проверка проектных решений дает бизнесу не абстрактную защиту, а возможность выпускать функции, подключать новые рынки и заключать сделки без накопления скрытого регуляторного долга. Дата-юристы помогут провести аудит потоков данных, подготовить DPA и Privacy Policy, проверить легальность скрапинга и выстроить регламент реагирования на утечки до того, как риск станет претензией регулятора или контрагента.