Уведомление об обработке персональных данных подают через личный кабинет на pd.rkn.gov.ru, и большая часть отказов и повторных запросов от Роскомнадзора связана не с фактом подачи, а с тем, как заполнены конкретные поля формы. Образец заполнения, который берут за основу из шаблонов в сети, редко подходит без изменений: за общими фразами вроде обработка персональных данных клиентов инспектор видит несоответствие с тем, что реально происходит на сайте, в CRM или в отделе кадров.
Дальше - разбор формы поле за полем: что писать, какую формулировку выбрать и на чем чаще всего спотыкаются те, кто заполняет уведомление в Роскомнадзор впервые. Кто вообще обязан подавать уведомление и в каких случаях закон освобождает от этой обязанности - тема отдельная, здесь она затронута только там, где влияет на заполнение конкретного поля.
Сведения об операторе - первый блок формы
Первые графы формы - организационные: полное и сокращенное наименование оператора, ОГРН (или ОГРНИП для ИП), ИНН, юридический адрес и адрес места обработки персональных данных, если он отличается от юридического, телефон и email для связи, а также ФИО и контакты ответственного за организацию обработки персональных данных.
Типичная ошибка - указать только юридический адрес компании, хотя фактически данные обрабатываются в другом месте: например, интернет-магазин зарегистрирован по адресу директора, а склад и колл-центр, где менеджеры вносят заказы в базу, находятся в другом городе. Роскомнадзор при проверке может запросить именно фактический адрес обработки, и расхождение с уведомлением выглядит как повод для вопросов.
Вторая частая ошибка - в поле ответственного лица механически ставят директора, потому что он и так за все отвечает. Если фактически с базой данных работает другой сотрудник или подрядчик на аутсорсе, в уведомлении должен быть указан тот, кто реально организует обработку и может ответить на запрос регулятора по существу. Формальный ответственный, который не в курсе, какие данные и как обрабатываются, создает проблему уже на этапе первого запроса от РКН.
Телефон и email в этом блоке - не формальность: если Роскомнадзор присылает запрос по контактам из уведомления, а письмо возвращается или телефон не отвечает, это фиксируется отдельно и работает не в пользу оператора при проверке. Стоит держать эти данные актуальными и сверять их с реальными контактами компании, а не с теми, что были указаны при первой подаче несколько лет назад.
У индивидуального предпринимателя и самозанятого этот блок часто вызывает вопрос: заполнять ли его вообще, если нет юридического лица. Заполняется - оператором является и ИП, и самозанятый, если он сам решает, как обрабатывать данные клиентов, например, ведет базу для записи на услуги. Вместо ОГРН указывается ОГРНИП, юридический адрес заменяется адресом регистрации по месту жительства, если отдельного офиса нет.
Цель обработки персональных данных
Поле цели обработки - то место, где общие формулировки подводят чаще всего. Формулировки вроде для обеспечения деятельности организации или для работы сайта не описывают ничего конкретного, и по факту это не цель, а декларация о существовании компании.
Правильная формулировка - операционная и привязана к реальному процессу: прием и обработка заказов интернет-магазина через форму на сайте, запись пациентов на прием и ведение медицинской документации, ведение кадрового делопроизводства и расчет заработной платы, рассылка информационных и рекламных сообщений подписчикам, давшим согласие. Если целей несколько, каждую указывают отдельно, а не объединяют в одну общую фразу.
Клиника, например, отдельно указывает цель запись на прием - для нее хватает ФИО и телефона, и отдельно ведение медицинской документации - здесь уже данные о здоровье, специальная категория со своим набором требований. Объединение этих целей в одну строку не экономит время, а просто размывает картину: неясно, зачем клинике данные о здоровье, если в уведомлении заявлена только запись на прием.
Категории субъектов и перечень персональных данных
Категории субъектов, чьи данные обрабатываются
Форма требует перечислить группы людей, а не написать одним словом физические лица. Обычный набор для сайта с формой заявки: посетители сайта (данные из cookies и метрики), клиенты по договору, потенциальные клиенты, оставившие заявку, работники, соискатели, подрядчики - физические лица.
У школы или детского сада набор свой: обучающиеся, их родители или законные представители, педагогические и иные работники. У каждой категории свой объем данных и своя цель обработки, поэтому смешивать их в одну строку учащиеся и родители неточно: правильнее развести по отдельным категориям, как и требует форма.
Отдельная категория, которую часто забывают, - подписчики на рассылку, если она существует отдельно от разовых покупателей: человек мог оставить только email для получения новостей, ни разу не совершив покупку, и формально это уже отдельная категория субъектов со своей целью обработки и, как правило, отдельным согласием.
Перечень обрабатываемых персональных данных
Здесь работает та же логика: формулировка все необходимые персональные данные - то, что Роскомнадзор обычно возвращает с запросом на уточнение. Нужен конкретный перечень: фамилия, имя, отчество, номер телефона, адрес электронной почты, дата рождения, при необходимости - паспортные данные, адрес регистрации. Для сотрудников отдельно - сведения о трудовой деятельности, СНИЛС, ИНН, сведения об образовании.
У школы, например, перечень включает не только ФИО и дату рождения ученика, но иногда данные об успеваемости и о состоянии здоровья, если это сведения для организации питания или занятий физкультурой в специальной группе. Такие данные относятся к специальным категориям и требуют более аккуратной формулировки в уведомлении, а не общей строки данные обучающихся.
Если среди обрабатываемых данных есть специальные категории - о здоровье, биометрия, - их указывают отдельной строкой, а не растворяют среди общих. Полный перечень того, что закон относит к персональным данным, с примерами по каждой категории, разобран в материале что такое персональные данные.
Перечень действий с персональными данными
Форма отдельно перечисляет операции, которые оператор совершает с данными: сбор, запись, систематизация, накопление, хранение, уточнение, извлечение, использование, передача, обезличивание, блокирование, удаление, уничтожение. Частая ошибка - скопировать весь стандартный список из шаблона, не сверяя его с реальностью: например, отметить трансграничную передачу, хотя данные никуда не уходят за пределы России, или, наоборот, не указать уничтожение, хотя по истечении срока хранения компания действительно удаляет анкеты и заявки.
Правильный подход - пройти путь данных от момента, когда человек оставил заявку, до момента, когда данные удаляются, и отметить только реально происходящие действия. Для формы заявки на сайте интернет-магазина это обычно выглядит так: сбор при заполнении формы, запись и хранение в CRM, использование при обработке заказа менеджером, передача - если данные уходят курьерской службе для доставки, и уничтожение по истечении срока хранения или по запросу клиента. У школы к этому списку добавляется систематизация - распределение данных учеников по классам и электронным журналам, а у клиники - уточнение, потому что медицинские данные регулярно обновляются при каждом визите.
Правовое основание обработки
Поле правового основания - не место для универсальной формулировки согласие субъекта персональных данных. Правовые основания обработки перечислены в статье 6 152-ФЗ, и для разных целей они разные: обработка данных работников по трудовому договору не требует отдельного согласия, потому что основание - Трудовой кодекс и сам факт трудовых отношений; обработка данных клиента для исполнения договора - тоже не про согласие, а про необходимость этот договор исполнить.
Согласие как основание нужно там, где закон и договор сами по себе не дают права обрабатывать данные: например, для email-рассылки с рекламными предложениями или для передачи данных партнеру, с которым у субъекта нет договорных отношений. Подробно о том, в каких случаях обработка законна без отдельного согласия, - в материале о шести законных основаниях обработки без согласия.
Кадровик обычно как раз тот человек в компании, кто точно знает, какие данные обрабатываются по трудовому договору, а какие - по добровольному согласию, например фото сотрудника для сайта компании или страницы о команде. Это разграничение стоит сверить с кадровой службой перед подачей формы, а не заполнять поле по шаблону.
Частая ошибка - указать единственным основанием согласие даже там, где данные обрабатываются по трудовому или гражданско-правовому договору. Формально это не всегда фатально, но при проверке несоответствие между заявленным основанием и реальной практикой - нет подписанного согласия, потому что для этой цели оно и не требовалось, - выглядит как повод для дополнительных вопросов.
Отдельное основание, которое часто забывают вписать, - исполнение обязанности, возложенной на оператора законом: например, бухгалтерский и налоговый учет требует обработки данных сотрудников и контрагентов независимо от их согласия. Если компания ведет такой учет, это тоже законное основание, и его стоит указать наравне с договором и трудовыми отношениями, а не сводить все к согласию.
Способ обработки и меры по обеспечению безопасности
Способ обработки
Форма спрашивает, обрабатываются ли данные с использованием средств автоматизации, без них или смешанным способом, а также идет ли передача по сетям связи. Механически поставить вариант с использованием средств автоматизации и не задумываться - обычная практика, но не всегда точная: если компания параллельно ведет бумажный архив анкет или договоров, это смешанный способ обработки, и поле стоит заполнять с учетом этого архива, а не только электронной базы.
Отдельный флажок в этом же блоке - идет ли передача данных по сетям связи, включая интернет. Для сайта с формой заявки ответ почти всегда положительный: данные уходят с браузера пользователя на сервер, а часто и дальше - в CRM или сервис рассылок. Пропустить этот пункт, отметив только способ обработки, - распространенная неточность, хотя оба поля в форме идут рядом и логически связаны друг с другом.
Пример из практики - клиника, где часть медицинских карт остается бумажной, а запись на прием и биллинг ведутся в электронной системе: указать только автоматизированную обработку в этом случае - не соответствует действительности. Кадровик, который ведет часть личных дел на бумаге, а часть - в 1С или в облачном сервисе кадрового учета, тоже работает со смешанным способом обработки, даже если сама компания небольшая и вопрос сверки способа обработки с реальностью раньше не возникал.
Меры по обеспечению безопасности
Здесь тоже подводит обобщение вроде приняты все необходимые организационные и технические меры - фраза без содержания, которая ничего не говорит проверяющему. Требования к мерам по обеспечению безопасности персональных данных при обработке прописаны в статье 19 152-ФЗ, и в уведомлении их стоит перечислить конкретно: утверждена политика обработки персональных данных, назначен ответственный, ограничен круг сотрудников с доступом к базе, используется шифрование канала передачи на сайте, установлено антивирусное программное обеспечение, ведется журнал учета обращений.
Для интернет-магазина минимальный набор обычно выглядит так: SSL-сертификат на сайте, разграничение прав доступа в CRM, парольная политика, регулярное обновление CMS и плагинов. Этого достаточно для полей уведомления, но не заменяет реальную настройку: если меры перечислены, а на сайте нет действующего сертификата, несоответствие видно любому, кто откроет страницу.
Для организаций, которые обрабатывают специальные категории данных - клиник, психологов, детских учреждений, - список мер обычно шире: добавляется физическое ограничение доступа к бумажным носителям, отдельный порядок допуска сотрудников к медицинской документации и, если это предусмотрено внутренними правилами, журнал выдачи документов на руки.
Трансграничная передача персональных данных
Поле про трансграничную передачу спрашивает, передаются ли данные за пределы России, и если да - в какие страны и на каком основании. По умолчанию многие ставят отрицательный ответ, не проверяя, что происходит на самом деле.
На практике трансграничная передача случается там, где ее не замечают: форма на сайте отправляет данные в зарубежный сервис email-рассылок, CRM развернута на серверах за пределами РФ, чат-бот работает через иностранного провайдера, аналитика или антиспам-сервис хранит данные на серверах в другой юрисдикции. Если хотя бы один такой сервис подключен, поле нужно заполнять с указанием факта передачи, страны и правового основания. Подробный порядок и актуальный список стран, куда передача возможна на упрощенных условиях, разобран в материале про трансграничную передачу персональных данных.
Основанием для трансграничной передачи обычно служит либо согласие субъекта на передачу именно в конкретную страну, либо международный договор, либо то, что страна включена в перечень государств, обеспечивающих адекватную защиту прав субъектов. Для большинства зарубежных сервисов, которыми пользуется малый бизнес, проще всего опираться на прямое согласие, сформулированное отдельно от общего согласия на обработку данных.
Расхождение по этому полю - одно из самых заметных при проверке, потому что стек сервисов сайта виден технически: достаточно посмотреть, куда уходят запросы со страницы, чтобы увидеть подключенные внешние сервисы. Если в уведомлении трансграничная передача не указана, а по факту она есть, это несоответствие обнаруживается быстрее, чем большинство остальных.
Дата начала обработки и срок хранения
Дата начала обработки - не дата регистрации компании и не дата составления самого уведомления, а момент, когда организация фактически начала собирать и использовать персональные данные: запуск сайта с формой заявки, первый заключенный договор, первый принятый на работу сотрудник. Если компания существует несколько лет, а сайт с формой запустили позже, датой начала обработки в контексте этой формы указывают именно запуск сайта или конкретного процесса, а не дату из выписки ЕГРЮЛ.
Если обработка данных приостанавливалась и потом возобновлялась - например, компания закрыла интернет-магазин на паузу и через полгода перезапустила сайт с той же формой заявки, - в уведомлении разумно отразить именно актуальный период, а не оставлять неизменной первоначальную дату многолетней давности, особенно если за это время менялся состав обрабатываемых данных.
Отдельное поле - срок или условие прекращения обработки. Оставить его пустым или написать, что обработка бессрочная, - частая практика, но она не отвечает на вопрос закона: обработка не может продолжаться неограниченно без причины. Корректнее сформулировать условие: обработка ведется до достижения ее целей или отзыва согласия субъектом, либо указать конкретный срок, если он определен внутренними документами, например сроком хранения кадровых документов по номенклатуре дел компании. Формулировка без условия прекращения выглядит как недоработка, даже если по сути данные действительно хранятся, пока актуальны.
Частые ошибки при заполнении: сводная таблица
Собранные по полям формы ошибки и корректные формулировки - в одной таблице, чтобы свериться перед отправкой уведомления в Роскомнадзор:
| Поле формы | Типичная ошибка | Как правильно |
|---|---|---|
| Цель обработки | Для обеспечения деятельности организации | Прием и обработка заказов через форму на сайте |
| Категории субъектов | Одной строкой: физические лица | Отдельно: клиенты, работники, соискатели, подрядчики |
| Перечень персональных данных | Все необходимые персональные данные | Конкретный список: ФИО, телефон, email, дата рождения |
| Правовое основание | Везде указано только согласие субъекта | Согласие, договор, Трудовой кодекс - по каждой цели свое |
| Способ обработки | По умолчанию: с использованием средств автоматизации | Смешанный способ, если часть данных хранится на бумаге |
| Меры безопасности | Приняты все необходимые меры | Конкретный перечень: SSL, разграничение доступа, антивирус |
| Трансграничная передача | Отрицательный ответ без проверки подключенных сервисов | Положительный ответ с указанием страны, если есть зарубежный сервис |
| Дата начала обработки | Дата регистрации компании из ЕГРЮЛ | Реальная дата запуска сайта или первого договора |
Что делать после отправки уведомления
Роскомнадзор не присылает мгновенное подтверждение о приеме - заявка обрабатывается в фоновом режиме, и организация появляется в реестре операторов персональных данных не в день подачи, а через некоторое время. Само по себе отсутствие ответа в первые дни - не повод переподавать уведомление заново. Проверить, появилась ли организация в реестре, можно самостоятельно - через открытый поиск по реестру операторов на сайте Роскомнадзора, по названию компании или по ИНН.
Уведомление - не разовая формальность на старте бизнеса. Если поменялись цели обработки, добавились новые категории данных, подключился новый сервис с трансграничной передачей или компания начала обрабатывать данные новой категории субъектов, например запустила программу лояльности и начала собирать данные не только клиентов, но и их детей, в уведомление нужно вносить изменения. На практике это делают редко: подали один раз при регистрации и забыли, а через два-три года набор используемых сервисов и процессов уже не совпадает с тем, что заявлено.
Изменения вносятся через тот же личный кабинет на pd.rkn.gov.ru - формой уточнения к уже поданному уведомлению, а не повторной регистрацией с нуля. На практике проще держать под рукой текст последнего поданного уведомления и раз в год, например при подготовке отчетности, сверять его с тем, что реально происходит с данными в компании.
Если уведомление вообще не подавалось, стоит сначала проверить, не попадает ли компания под одно из исключений, которые статья 22 152-ФЗ выводит из-под этой обязанности, а если не попадает - подать его, не дожидаясь проверки. Отдельный штраф за отсутствие уведомления и то, как его избежать, разобраны в материале про штраф за отсутствие уведомления.
Перед подачей или обновлением уведомления стоит пройти короткий список:
- Сверить формулировки целей обработки с реальными процессами - сайтом, CRM, кадровым делопроизводством.
- Проверить перечень категорий субъектов и данных: не упущена ли какая-то группа, например соискатели, подрядчики, дети клиентов.
- Убедиться, что поле трансграничной передачи отражает все подключенные зарубежные сервисы, включая рассылки и аналитику.
- Указать конкретные меры безопасности, которые действительно применяются, а не общую фразу.
- Сохранить копию отправленного уведомления и дату подачи - это пригодится при любой проверке.
Если после сверки остаются сомнения, правильно ли сформулированы поля или нужно ли вообще подавать уведомление в конкретной ситуации, доработку документов и формулировок под задачи сайта можно заказать на 152fzpro.ru.
Частые вопросы
Где подается уведомление об обработке персональных данных?
Через личный кабинет на портале pd.rkn.gov.ru. Большая часть отказов и повторных запросов Роскомнадзора связана не с фактом подачи, а с тем, как заполнены конкретные поля формы - общие формулировки вроде "обработка персональных данных клиентов" инспектор сверяет с тем, что реально происходит на сайте и в CRM.
Что писать в поле цель обработки, чтобы его не вернули на доработку?
Конкретную операционную формулировку, привязанную к реальному процессу: прием и обработка заказов через форму на сайте, запись пациентов на прием, ведение кадрового делопроизводства. Общие фразы вроде "для обеспечения деятельности организации" не описывают ничего конкретного, и Роскомнадзор обычно запрашивает уточнение по такой формулировке.
Нужно ли указывать трансграничную передачу, если данные вроде не уходят за границу?
Стоит проверить подключенные сервисы: зарубежный сервис рассылок, CRM на серверах за пределами РФ, чат-бот через иностранного провайдера - все это трансграничная передача. Если хотя бы один такой сервис подключен, поле заполняется с указанием факта передачи, страны и правового основания, иначе расхождение видно быстрее прочих.
Какую дату указывать как дату начала обработки персональных данных?
Не дату регистрации компании из ЕГРЮЛ, а момент, когда организация фактически начала собирать и использовать данные - запуск сайта с формой заявки, первый заключенный договор или первый принятый на работу сотрудник. Если сайт запустили позже регистрации компании, указывается именно дата запуска сайта.