Уведомление в Роскомнадзор об обработке ПДн: когда и как

MAATRIX

> Это обзорный материал, а не юридическая консультация. Мы описываем общую логику процедуры уведомления регулятора, но не заменяем разбор вашей конкретной ситуации со специалистом по персональным данным или юристом. Точный состав исключений, формулировки и процедурные детали могут отличаться от изложенного здесь — перед подачей уведомления или отказом от неё сверьтесь с действующим текстом закона и, по возможности, проконсультируйтесь с профильным юристом. Если у вас сайт с формой обратной связи, интернет-магазин или CRM, где хранятся имена и телефоны клиентов — вы, скорее всего, уже оператор персональных данных. И один из первых практических вопросов, который встаёт после осознания этого факта: нужно ли уведомлять об этом Роскомнадзор, и что будет, если этого не сделать. Разберём, что вообще такое уведомление, в каких случаях оно обычно требуется, а в каких закон предусматривает исключения, и как устроена сама процедура на уровне общей логики.

Что такое уведомление в Роскомнадзор об обработке ПДн

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

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

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

Когда уведомление обычно требуется, а когда есть исключения

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

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

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

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

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

Как устроена подача уведомления на практике

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

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

1. Определить, что вы действительно являетесь оператором персональных данных и обязанность уведомить у вас возникла (или же убедиться, что применимо исключение — и сохранить это обоснование на будущее).
2. Собрать информацию о своей деятельности: наименование организации, цели обработки данных, категории субъектов данных, категории самих данных, правовые основания обработки.
3. Заполнить форму уведомления на официальном портале регулятора, указав всю запрашиваемую информацию максимально точно и без формальных «на всякий случай» пунктов — то, что реально не относится к вашей деятельности, указывать не нужно.
4. Дождаться внесения сведений в реестр операторов и сохранить подтверждение подачи уведомления — это важный документ на случай проверки.
5. В дальнейшем отслеживать, не изменился ли характер обработки данных настолько, что потребуется подавать уточнённые сведения — например, если вы начали собирать новую категорию данных или начали передавать данные за рубеж, которых раньше не передавали.

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

Что нужно будет описать в уведомлении

Хотя точные поля формы лучше смотреть непосредственно на портале в момент подачи, на уровне смысла уведомление обычно требует описать несколько ключевых блоков информации.

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

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

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

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

Факт трансграничной передачи данных, если она есть. Если ваши данные хранятся или обрабатываются на серверах, физически расположенных за пределами России — например, вы используете зарубежный email-сервис, CRM с серверами в другой юрисдикции, или сам VPS с базой данных клиентов размещён не в России — это, как правило, нужно отразить в уведомлении отдельно, указав факт трансграничной передачи и, если применимо, страну. Здесь также важно не путать простое размещение технической инфраструктуры (например, VPS без персональных данных) с фактической передачей персональных данных за рубеж — характер конкретной архитектуры вашего проекта и определяет, есть трансграничная передача или нет, и это тоже вопрос для отдельной проверки, а не для самостоятельного домысливания по аналогии.

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

Что будет, если не подать уведомление вовремя

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

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

На уровне общей логики риски выглядят так:

• Административная ответственность. Отсутствие уведомления там, где оно было обязательным, — это, как правило, самостоятельное нарушение, за которое предусмотрена ответственность, причём отдельно от возможных штрафов за другие нарушения в сфере обработки персональных данных (например, за неправомерную обработку как таковую).
• Внимание при проверках. Если регулятор или иной надзорный орган начинает проверку по жалобе субъекта данных или по иному поводу, отсутствие уведомления в реестре операторов — один из первых формальных фактов, который будет зафиксирован, и он может усугубить общую картину нарушений, даже если сама обработка данных велась в целом аккуратно.
• Накопительный эффект. Чем дольше компания работает без уведомления, тем больше период, за который к ней потенциально могут быть вопросы — это не разовая история «подал с опозданием и забыл», а состояние, которое сохраняется до момента фактической подачи.
• Репутационные и договорные риски. Отдельно от штрафов, у крупных партнёров и заказчиков всё чаще есть собственные требования к комплаенсу подрядчиков по части персональных данных — отсутствие в реестре операторов может стать неудобным вопросом на этапе due diligence, особенно в B2B.

Важная практическая деталь: если вы обнаружили, что должны были подать уведомление раньше, но не сделали этого — разумная стратегия почти всегда в том, чтобы подать его сейчас, а не тянуть дальше в ожидании «пока не заметят». Более подробно про экономику и практические затраты на приведение сайта в соответствие требованиям о персональных данных — в статье сколько стоит соответствие 152-ФЗ.

Как это связано с выбором сервера и хостинга

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

Если ваш проект ориентирован на российскую аудиторию и обрабатывает персональные данные, для которых законодательство требует хранения на территории России, разумный подход — держать именно тот компонент инфраструктуры, где физически лежат персональные данные (база данных, файлы с документами клиентов и так далее), на сервере в российской юрисдикции, а остальные компоненты (например, статический фронтенд, CDN, вспомогательные сервисы без персональных данных) размещать там, где это удобнее и выгоднее с точки зрения производительности и цены. Здесь же стоит учитывать разницу в подходах к персональным данным между разными юрисдикциями — если часть вашей аудитории или партнёров в Евросоюзе, стоит отдельно посмотреть на европейское регулирование, оно устроено по другой логике и описано в статье о законодательстве о персональных данных в ЕС применительно к серверу.

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

Частые вопросы