Онлайн-сервис почти всегда работает с персональными данными.
Даже если кажется, что проект просто принимает заявки или продает цифровой продукт, в нем уже могут быть email, телефон, имя, IP-адрес, cookies, данные аккаунта, история платежей, переписка, документы, адрес доставки, сведения о сотрудниках клиента, логи входа, обращения в поддержку и другая информация, по которой можно прямо или косвенно связать данные с человеком.
Проблема в том, что персональные данные часто вспоминают слишком поздно: сайт уже запущен, формы собирают заявки, оплата подключена, CRM работает, рассылка идет, аналитика стоит, пользователи регистрируются, а документов и понятной схемы обработки нет.
Потом возникают вопросы: нужно ли уведомлять Роскомнадзор, где разместить политику, какие галочки ставить в форме, можно ли отправлять рекламу, что писать про cookies, можно ли использовать иностранный сервис рассылки, где хранить базу, как передавать данные подрядчикам, что отвечать пользователю на запрос об удалении данных и кто отвечает при утечке.
Персональные данные — это не только «политика конфиденциальности» в подвале сайта. Для онлайн-сервиса это часть юридической архитектуры продукта: регистрация, заявки, личный кабинет, платежи, подписка, поддержка, аналитика, рассылки, подрядчики, хостинг, безопасность и документы.
ZLATA LEGAL помогает онлайн-сервисам, SaaS-проектам, приложениям, маркетплейсам, платформам, сайтам, Telegram-ботам и цифровым продуктам во Владивостоке, Приморском крае, на Дальнем Востоке и дистанционно по России подготовить документы и процессы по персональным данным до запуска.
Короткий ответ
До запуска онлайн-сервиса нужно понять, какие персональные данные собираются, зачем, где они хранятся, кто имеет к ним доступ, кому они передаются, какие сервисы подключены, есть ли рассылка, cookies, платежи, личный кабинет, аналитика, подрядчики и иностранные инструменты.
Обычно нужно подготовить политику обработки персональных данных, согласия на обработку данных, отдельное согласие на рекламную рассылку, cookie-уведомление, уведомление в Роскомнадзор, документы для передачи данных подрядчикам, правила хранения и удаления данных, порядок ответов на запросы пользователей и внутренние меры безопасности.
Главная ошибка — думать, что достаточно скачать чужую политику и заменить название компании.
Документы должны совпадать с реальным сервисом. Если на сайте есть форма заявки, в политике должна быть заявка. Если есть платежи, должны быть платежи. Если есть личный кабинет, должны быть аккаунты и логи. Если есть рассылка, должно быть согласие на рассылку. Если используются CRM, хостинг, аналитика, платежный агрегатор, email-сервис или техподдержка, это тоже нужно учитывать.
Что считается персональными данными
Персональные данные — это не только паспорт и адрес регистрации.
Для онлайн-сервиса персональными данными могут быть ФИО, телефон, email, никнейм, ID аккаунта, IP-адрес, cookies, адрес доставки, платежные сведения, история заказов, переписка с поддержкой, фото, документы, данные устройства, должность, компания, голос, геолокация, сведения о действиях в личном кабинете и иная информация, если она относится к конкретному человеку или позволяет его определить.
Поэтому даже простой сайт с формой «оставьте телефон» уже работает с персональными данными. Сервис с регистрацией, подпиской, личным кабинетом, оплатой и аналитикой — тем более.
Для SaaS и B2B-сервисов есть отдельная особенность. Клиентом может быть компания, но в сервис попадают данные ее сотрудников, клиентов, представителей, водителей, менеджеров, подрядчиков или контрагентов. Это тоже персональные данные, хотя договор заключен с юридическим лицом.
Кто такой оператор персональных данных
Оператор — это тот, кто определяет, зачем и как обрабатываются персональные данные.
Если компания запускает онлайн-сервис, собирает заявки, регистрирует пользователей, принимает оплату, хранит аккаунты и использует данные для оказания услуги, она обычно является оператором персональных данных.
При этом подрядчики могут быть обработчиками или лицами, которым поручена обработка. Например, хостинг, CRM, сервис рассылки, платежный агрегатор, техподдержка, аналитика, облачное хранилище, коллтрекинг, чат-виджет или разработчик, который имеет доступ к базе.
Важно не просто написать в политике «оператор — ООО Ромашка», а понять реальную схему: кто собирает данные, кто хранит, кто администрирует, кто видит заявки, кто отправляет рассылки, кто обрабатывает платежи и кто отвечает пользователю.
Карта данных до запуска
Перед подготовкой документов нужно сделать карту данных.
Не обязательно сложную. На первом этапе достаточно ответить на практические вопросы: какие формы есть на сайте, какие поля заполняет пользователь, есть ли регистрация, какие данные в личном кабинете, какие данные собирает аналитика, какие данные идут в CRM, кто получает уведомления, где хранится база, кто имеет доступ, какие подрядчики подключены, есть ли рассылки, платежи, подписка, cookies, чат, бот, мобильное приложение, API, файлы и документы.
После этого становится понятно, какие документы нужны и что писать в политике.
Без карты данных политика обычно получается декоративной. В ней написано одно, а сервис фактически делает другое.
Политика обработки персональных данных
Политика обработки персональных данных — базовый публичный документ для сайта или онлайн-сервиса.
В ней нужно описать оператора, цели обработки, категории персональных данных, категории субъектов, способы обработки, сроки хранения, основания обработки, права пользователей, порядок обращений, передачу данных третьим лицам, меры защиты, cookies, трансграничную передачу при наличии и контакты оператора.
Политика должна быть размещена так, чтобы пользователь мог ознакомиться с ней до передачи данных. Обычно ссылка ставится в подвале сайта, рядом с формами заявок, при регистрации, на странице оплаты и в приложении.
Не стоит называть документ только «политика конфиденциальности», если по сути речь об обработке персональных данных. В России правильнее и понятнее использовать формулировку «Политика обработки персональных данных». Можно добавить привычное название в скобках, но основной смысл лучше не терять.
Согласие на обработку персональных данных
Политика сама по себе не всегда равна согласию.
Если обработка строится на согласии пользователя, согласие нужно получить так, чтобы можно было подтвердить его факт. Обычно это галочка рядом с формой, регистрацией, заявкой, оплатой или подпиской.
Согласие должно быть конкретным и понятным. Пользователь должен видеть, кто обрабатывает данные, какие данные, для каких целей и где можно ознакомиться с политикой.
Плохой вариант — одна общая фраза «нажимая кнопку, вы соглашаетесь со всем». Особенно если туда одновременно спрятаны оферта, персональные данные, рекламная рассылка, cookies, передача партнерам и автосписания.
Для онлайн-сервиса лучше разделять ключевые действия: принятие оферты отдельно, согласие на обработку персональных данных отдельно, согласие на рекламную рассылку отдельно.
Формы на сайте
Каждая форма на сайте должна быть юридически осмыслена.
Форма заявки, обратного звонка, регистрации, подписки, оплаты, бронирования, скачивания файла, записи на консультацию, запроса демо, отправки резюме или обращения в поддержку — все они собирают разные данные для разных целей.
Рядом с формой нужна понятная ссылка на политику и текст согласия, если обработка идет на основании согласия. Не нужно собирать лишние поля. Если для заявки достаточно имени и телефона, не стоит просить дату рождения, паспорт, адрес и должность.
Чем меньше лишних данных собирает сервис, тем проще его защищать юридически и технически.
Уведомление в Роскомнадзор
Многие операторы должны уведомить Роскомнадзор о начале обработки персональных данных.
Для онлайн-сервиса этот вопрос лучше проверить до запуска. Если есть регистрация, формы заявок, личный кабинет, подписка, платежи, рассылка, данные сотрудников клиентов или база пользователей, вероятность обязанности уведомления высокая, если нет применимого исключения.
Уведомление — это не просто формальность. В нем указываются цели обработки, категории персональных данных, категории субъектов, правовые основания, меры защиты, сведения о базах данных, трансграничной передаче, ответственном лице и другие сведения.
Если потом меняется модель сервиса, появляются новые цели, новые категории данных, новая CRM, трансграничная передача или прекращается обработка, сведения нужно актуализировать.
Cookies, аналитика и пиксели
Даже если пользователь ничего не вводит в форму, сайт может собирать технические данные.
Cookies, Яндекс Метрика, рекламные пиксели, чат-виджеты, сервисы A/B-тестов, продуктовая аналитика, логи, сквозная аналитика и коллтрекинг могут собирать IP-адрес, идентификаторы устройств, сведения о браузере, источнике перехода, действиях на сайте и сессиях.
Поэтому cookie-баннер не должен быть отдельной декоративной плашкой. Он должен совпадать с политикой обработки персональных данных и реальными инструментами сайта.
Если сайт использует только технические cookies для авторизации, это один уровень. Если используются рекламные пиксели, ретаргетинг и аналитика поведения, это другой уровень. Документы и интерфейс должны это отражать.
Рекламные рассылки
Рекламная рассылка — отдельный блок.
Покупка продукта, регистрация или заявка не должны автоматически превращаться в согласие на любые рекламные сообщения. Для рекламной рассылки лучше получать отдельное согласие: email, SMS, мессенджеры, push-уведомления, Telegram-бот или другой канал.
Нужно разделять сервисные уведомления и рекламу. Сообщение о заказе, оплате, чеке, безопасности аккаунта, изменении тарифа или восстановлении пароля — это сервисная коммуникация. Акции, допродажи, новости продукта и маркетинговые предложения — рекламная.
Также нужно дать пользователю понятный способ отказаться от рассылки. Если отписка есть только на бумаге, но технически не работает, риск сохраняется.
Личный кабинет
Личный кабинет усиливает требования к данным.
В нем могут храниться профиль пользователя, документы, история заказов, платежи, заявки, файлы, переписка, сотрудники компании, роли, отчеты, результаты работы сервиса, настройки уведомлений и логи действий.
В документах нужно описать, какие данные пользователь размещает сам, какие формируются сервисом, кто имеет доступ, как пользователь может изменить или удалить данные, что происходит при блокировке аккаунта, окончании подписки или удалении профиля.
Для B2B-сервиса особенно важно определить администратора корпоративного аккаунта. Если сотрудник зарегистрировал компанию на личную почту и потом ушел, у клиента и сервиса может возникнуть конфликт по доступу к данным.
Платежи и персональные данные
Платежи тоже связаны с персональными данными.
Сервис может обрабатывать email для чека, телефон, имя, ID заказа, историю оплат, статус подписки, данные о возвратах, последние цифры карты, платежный токен, сведения от платежного агрегатора и переписку по спорным списаниям.
Полные данные банковской карты обычно обрабатывает платежный агрегатор или банк, но сервис все равно должен описать платежную механику в политике и оферте.
Если есть подписка и автоплатежи, нужно хранить доказательства согласия на рекуррентные списания, дату подключения, тариф, сумму, версию оферты и историю отмены. Это важно не только для платежных споров, но и для обработки персональных данных.
SaaS и B2B-данные
В SaaS-сервисе данные часто сложнее, чем на обычном сайте.
Клиент может загружать в систему базы клиентов, договоры, заявки, счета, отчеты, документы ВЭД, складские остатки, переписку, маршруты, данные сотрудников, водителей, менеджеров, подрядчиков и контрагентов.
Часть этих данных является персональными данными, часть — коммерческой информацией, часть — пользовательским контентом, часть — внутренними бизнес-данными клиента.
В документах нужно разделить эти слои. Персональные данные регулируются политикой и договорными условиями. Коммерческие данные — конфиденциальностью. Пользовательский контент — правилами сервиса. Права на саму программу — лицензионными условиями.
Если все назвать просто «данные пользователя», важные риски потеряются.
Передача данных подрядчикам
Онлайн-сервис почти всегда использует подрядчиков.
Хостинг хранит данные. CRM принимает заявки. Платежный агрегатор обрабатывает оплату. Сервис рассылки отправляет письма. Чат-виджет видит обращения. Разработчик имеет доступ к базе. Техподдержка читает тикеты. Аналитика собирает события. Облачное хранилище держит файлы.
Если такие лица получают доступ к персональным данным, это нужно отразить в документах и урегулировать договорно.
В политике не всегда нужно перечислять каждого подрядчика по названию, но пользователь должен понимать категории получателей и цели передачи. С самими подрядчиками нужно проверить договоры, условия обработки данных, место хранения, безопасность, доступы и возможность удаления данных.
Трансграничная передача
Трансграничная передача возникает, когда персональные данные передаются на территорию иностранного государства.
Для онлайн-сервиса это может быть неочевидно. Например, иностранная CRM, email-рассылка, облачное хранилище, аналитика, сервис поддержки, платежный инструмент, CDN, мессенджер, таск-трекер или AI-инструмент могут приводить к передаче данных за пределы России.
Если трансграничная передача есть, ее нужно оценить до запуска. Может потребоваться отдельное уведомление в Роскомнадзор, проверка страны, получателя, целей передачи, категории данных и договорной базы.
Ошибка — писать в политике «трансграничная передача не осуществляется», когда фактически сайт отправляет заявки или аналитику в иностранный сервис.
Хранение данных в России
При сборе персональных данных граждан РФ через интернет нужно учитывать требование о российских базах данных для записи, систематизации, накопления, хранения, уточнения и извлечения таких данных.
Практически это означает, что до запуска нужно понять, где находится база пользователей, CRM, хостинг, резервные копии, база личного кабинета и сервисы, которые первично принимают данные.
Если проект использует иностранную инфраструктуру, нужно отдельно проверить, как организован сбор и хранение данных, есть ли российская база, что уходит за рубеж, на каком этапе и с какой целью.
Для раннего проекта проще сразу выбрать инфраструктуру и сервисы так, чтобы потом не переделывать архитектуру под требования по данным.
Безопасность персональных данных
Документы не заменяют безопасность.
Нужно определить, кто имеет доступ к базе, как выдаются и отзываются доступы, используются ли сложные пароли и двухфакторная аутентификация, есть ли резервные копии, шифрование, журналирование, разграничение ролей, порядок работы разработчиков, правила экспорта базы, защита админки и порядок реагирования на инциденты.
Для маленького сервиса это не обязательно должно быть корпоративное чудовище на сто страниц. Но базовый порядок должен быть: кто за что отвечает, кто видит данные, где они лежат, как удаляются, как фиксируются инциденты и что делать при утечке.
Самая частая проблема — доступы остаются у бывших сотрудников, подрядчиков, фрилансеров или администраторов, которые давно не работают с проектом.
Запросы пользователей
Пользователь может обратиться к сервису с вопросом о своих персональных данных.
Он может попросить подтвердить обработку, уточнить данные, удалить их, отозвать согласие, прекратить рассылку, исправить ошибку, предоставить информацию о целях обработки или объяснить передачу третьим лицам.
До запуска нужно определить, куда такие запросы направляются, кто отвечает, как проверяется личность заявителя, в какие сроки готовится ответ, как фиксируется исполнение и что делать, если данные нужны для договора, бухгалтерии, спора или исполнения закона.
Нельзя просто удалить все данные по первому сообщению в мессенджере. Но и игнорировать запросы нельзя. Нужен рабочий порядок.
Удаление аккаунта и данных
Для онлайн-сервиса важно заранее описать удаление аккаунта.
Пользователь должен понимать, как удалить профиль, что будет с подпиской, платежами, заказами, документами, перепиской, пользовательским контентом и данными, которые сервис обязан хранить по закону или для защиты своих прав.
Не все данные удаляются мгновенно. Например, сведения о платежах, чеках, договоре, споре или бухгалтерских документах могут храниться дольше. Но это должно быть объяснено в политике и правилах сервиса.
Для SaaS нужно отдельно описать выгрузку данных перед удалением. Если клиент вел бизнес в сервисе, потеря данных после отключения тарифа может стать серьезным конфликтом.
Инциденты и утечки
Если произошла утечка, случайная передача, неправомерный доступ или иной инцидент с персональными данными, у оператора должен быть план действий.
Нужно быстро понять, какие данные затронуты, сколько пользователей, кто получил доступ, устранена ли причина, нужно ли уведомлять Роскомнадзор, как проводить внутреннее расследование, что сообщать пользователям и как фиксировать меры.
Для маленького проекта это может казаться избыточным до первого инцидента. Но когда база заявок уходит подрядчику, доступ к CRM остается у бывшего сотрудника или файл с пользователями случайно отправляется не туда, времени на придумывание порядка уже нет.
Дети, специальные данные и чувствительные категории
Некоторые данные требуют особого внимания.
Если сервис работает с детьми, медицинскими данными, биометрией, сведениями о здоровье, фото, геолокацией, документами, финансовыми данными, семейной ситуацией, образованием, трудоустройством или иными чувствительными сведениями, обычной политики может быть недостаточно.
Например, сервис для обучения детей, медицинских консультаций, психологической поддержки, фитнеса, HR, финансов, юридических документов, страхования или проверки клиентов будет иметь более высокий риск, чем простой лендинг с заявкой.
До запуска нужно честно оценить, какие данные реально нужны продукту. Если чувствительные данные не нужны, лучше их не собирать.
Публичные профили и отзывы
Если сервис публикует профили пользователей, исполнителей, экспертов, отзывы, рейтинги, фото, имена, должности, карточки специалистов или портфолио, нужно отдельно оценить распространение персональных данных.
Пользователь может согласиться на обработку данных для регистрации, но это не всегда означает согласие на публикацию его имени, фото, отзыва или профиля для неограниченного круга лиц.
Для маркетплейсов, платформ исполнителей, образовательных проектов, сервисов отзывов, рейтингов и каталогов этот блок особенно важен.
Нужно описать, какие данные отображаются публично, кто управляет профилем, как скрыть данные, как удалить отзыв и что происходит после прекращения участия в сервисе.
Персональные данные и оферта
Оферта и персональные данные связаны, но не заменяют друг друга.
Оферта отвечает на вопрос, на каких условиях пользователь покупает продукт или пользуется сервисом. Политика обработки персональных данных отвечает на вопрос, что происходит с его данными.
В интерфейсе эти документы часто стоят рядом: пользователь принимает оферту и дает согласие на обработку данных. Но юридически это разные действия.
Если все спрятать в одну галочку, потом сложнее доказать, что пользователь отдельно понял обработку данных, отдельно принял оплату, отдельно согласился на рекламу и отдельно понял автоплатеж.
Что должно быть на сайте до запуска
До запуска на сайте должны быть понятные юридические точки.
В подвале сайта — политика обработки персональных данных, пользовательское соглашение или оферта, контакты оператора. Рядом с формами — текст согласия и ссылка на политику. При регистрации — принятие условий сервиса и согласие на обработку данных. При оплате — оферта, политика, правила возврата и чековая логика. Для рассылки — отдельное согласие. Для cookies — уведомление и отражение в политике. Для личного кабинета — правила аккаунта, доступа, удаления и хранения данных.
Если есть мобильное приложение, документы должны совпадать с сайтом и карточкой приложения. Если есть Telegram-бот, ссылка на документы должна быть доступна до передачи данных и оплаты.
Частые ошибки
Первая ошибка — скачать чужую политику и не сравнить ее с реальным сервисом. Вторая — не подать уведомление в Роскомнадзор, хотя сервис уже собирает данные. Третья — использовать одну галочку на оферту, персональные данные и рекламу. Четвертая — поставить аналитику и cookies, но ничего не написать о них в политике. Пятая — отправлять рекламные рассылки без отдельного согласия. Шестая — не проверить хостинг, CRM, рассылку и другие подрядные сервисы. Седьмая — написать, что трансграничной передачи нет, хотя используются иностранные инструменты. Восьмая — не описать удаление аккаунта и хранение данных после окончания подписки. Девятая — дать доступ к базе всем подрядчикам без контроля. Десятая — не обновлять документы после изменения продукта.
Обычно проблема не в том, что у сервиса вообще нет документов. Проблема в том, что документы живут отдельно, а продукт работает отдельно.
Как правильно подготовиться до запуска
Сначала нужно описать карту данных: какие данные собираются, зачем, где, через какие формы, кто имеет доступ, кому передаются и сколько хранятся.
Затем нужно проверить правовые основания: где достаточно договора или оферты, где нужно согласие, где нужна отдельная рекламная галочка, где есть cookies, где возникает трансграничная передача и нужно ли уведомление в Роскомнадзор.
После этого готовятся документы: политика обработки персональных данных, согласия, cookie-уведомление, блоки для форм, положения для оферты и пользовательского соглашения, договорные условия с подрядчиками, порядок запросов пользователей, удаления данных и реагирования на инциденты.
Затем документы нужно встроить в интерфейс: формы, чекбоксы, регистрацию, оплату, личный кабинет, рассылку, поддержку и приложение.
Только после этого персональные данные становятся не стихийной базой в CRM, а управляемым процессом.
Локальный аспект: Владивосток, Приморье и Дальний Восток
Во Владивостоке и Приморском крае онлайн-сервисы часто запускаются вокруг реального бизнеса: логистика, ВЭД, поставки из Китая, склады, морская отрасль, заявки, ремонт, услуги для бизнеса, обучение, CRM, Telegram-боты, сервисы автоматизации, маркетплейсы и B2B-платформы.
Такие проекты быстро переходят от простой формы заявки к полноценному хранению данных: клиенты, сотрудники, менеджеры, водители, подрядчики, документы, маршруты, платежи, заявки и переписка.
На этом этапе персональные данные уже нельзя оформлять как «что-нибудь потом». Если сервис собирает данные клиентов и сотрудников компаний, работает с платежами, подпиской, личным кабинетом или рассылкой, документы и процессы нужно готовить до масштабирования.
Для B2B-клиентов это еще и вопрос доверия. Компания охотнее подключает сервис, если понимает, где хранятся данные, кто имеет доступ, как оформлена обработка, можно ли выгрузить информацию и кто отвечает при проблеме.
Как ZLATA LEGAL помогает с персональными данными онлайн-сервисов
ZLATA LEGAL помогает онлайн-сервисам, SaaS-проектам, платформам, маркетплейсам, сайтам, приложениям, Telegram-ботам и цифровым продуктам подготовить документы и процессы по персональным данным.
Мы анализируем продукт: формы заявок, регистрацию, личный кабинет, подписку, оплату, рассылку, cookies, аналитику, CRM, хостинг, платежный агрегатор, поддержку, подрядчиков, трансграничную передачу, хранение данных, роли пользователей, B2B-клиентов и удаление аккаунта.
Готовим политику обработки персональных данных, согласия, cookie-документы, тексты для форм, блоки для оферты и пользовательского соглашения, условия передачи данных подрядчикам, документы для рассылок, порядок обработки запросов пользователей и рекомендации по уведомлению Роскомнадзора.
Проверяем не только текст, но и путь пользователя: где он видит политику, где дает согласие, как принимает оферту, как подписывается на рассылку, как оплачивает, как удаляет аккаунт, как обращается в поддержку и как сервис хранит доказательства.
Работаем с проектами во Владивостоке, Приморском крае, на Дальнем Востоке и дистанционно по России.
Персональные данные лучше приводить в порядок до запуска. Так сервис не тормозит продажи, не переделывает интерфейс после первых пользователей и не строит юридическую защиту поверх уже накопленного хаоса.
Частые вопросы
Нужна ли политика персональных данных для сайта?
Да, если сайт собирает персональные данные: заявки, телефоны, email, регистрацию, оплату, сообщения, cookies, аналитику или данные аккаунтов. Политика должна быть доступна пользователю до передачи данных.
Достаточно ли политики конфиденциальности?
Не всегда. Нужна именно политика обработки персональных данных, а также согласия, cookie-уведомление, согласие на рассылку, уведомление Роскомнадзора и договорные условия с подрядчиками, если они применимы к сервису.
Нужно ли согласие под каждой формой?
Если обработка идет на основании согласия, лучше фиксировать согласие рядом с формой или действием пользователя. При этом не нужно делать одну галочку на все сразу: оферта, персональные данные и рекламная рассылка должны быть разделены.
Нужно ли уведомлять Роскомнадзор?
Во многих случаях да. Если онлайн-сервис собирает и обрабатывает персональные данные, нужно проверить обязанность уведомления до запуска, если нет применимого исключения.
Что писать в политике обработки персональных данных?
Оператора, цели обработки, категории данных, категории пользователей, основания обработки, способы обработки, сроки хранения, передачу третьим лицам, cookies, трансграничную передачу при наличии, меры защиты, права пользователей и контакты для обращений.
Нужно ли отдельное согласие на рекламную рассылку?
Да, лучше получать отдельное согласие. Регистрация, заявка или покупка продукта не должны автоматически означать согласие на рекламные сообщения.
Cookies — это персональные данные?
Cookies и технические идентификаторы могут быть связаны с пользователем и его устройством, поэтому их нужно учитывать в политике и cookie-уведомлении, особенно если используются аналитика, рекламные пиксели и ретаргетинг.
Можно ли использовать иностранную CRM или сервис рассылки?
Можно только после оценки трансграничной передачи, условий сервиса, места хранения данных, договора, уведомлений и соответствия российским требованиям. Просто подключить иностранный сервис и написать, что передачи за рубеж нет, рискованно.
Что такое трансграничная передача персональных данных?
Это передача персональных данных на территорию иностранного государства. Она может возникать при использовании зарубежной CRM, рассылки, аналитики, облака, поддержки, AI-инструмента или другого внешнего сервиса.
Нужно ли хранить данные в России?
При сборе персональных данных граждан РФ через интернет нужно учитывать требование о российских базах данных для записи, систематизации, накопления, хранения, уточнения и извлечения таких данных.
Что делать с данными после удаления аккаунта?
Нужно заранее описать, какие данные удаляются, какие могут храниться дольше из-за договора, платежей, бухгалтерии, спора или закона, как пользователь может запросить удаление и как сервис подтверждает исполнение.
Что важно для SaaS-сервиса?
Личный кабинет, роли пользователей, корпоративные аккаунты, данные сотрудников клиента, бизнес-данные, хранение файлов, выгрузка данных, подрядчики, безопасность, подписка, платежи и удаление данных после окончания тарифа.
Что важно для маркетплейса или платформы услуг?
Данные пользователей и исполнителей, публичные профили, отзывы, рейтинги, переписка, передача данных между сторонами, платежи, претензии, модерация и договоры с исполнителями.
Какие документы нужны до запуска?
Политика обработки персональных данных, согласия, cookie-уведомление, согласие на рекламную рассылку, уведомление в Роскомнадзор при необходимости, блоки для оферты и пользовательского соглашения, условия с подрядчиками и порядок обработки запросов пользователей.
Когда обращаться к юристу?
Лучше до запуска форм заявок, регистрации, оплаты, подписки, личного кабинета, рассылки, мобильного приложения или маркетплейса. На этой стадии документы можно встроить в продукт без переделки интерфейса и базы данных.
Связанные материалы