С чего начинаем подготовку
Сначала выясняем, кто обрабатывает данные, для каких задач и подавалось ли уведомление раньше. Затем сверяем сведения с сайтом, документами и подключенными сервисами. Если запись в реестре уже есть, нужно оценить ее содержание и изменения в обработке, прежде чем готовить новое обращение.
Общую обязанность уведомить до начала обработки и исключения устанавливает статья 22 закона о персональных данных. Наличие сайта само по себе не дает всех ответов о деятельности оператора. Поэтому не заполняем документ только по главной странице.
Как определяем состав сведений оператора
Сайт помогает обнаружить формы и сервисы, но не показывает всю работу с персональными данными. Заявки могут обрабатываться сотрудниками, передаваться подрядчикам и храниться после завершения общения. Поэтому сначала определяем вместе с владельцем, какие процессы нужно описать, кто предоставляет исходные сведения и кто будет проверять итоговый документ.
Если у оператора несколько сайтов, полезно подготовить их перечень и обозначить назначение каждого. Разные домены не означают автоматически разных операторов; одинаковое оформление тоже не подтверждает, что сведения получает одна организация. Реквизиты и распределение функций выясняем до заполнения проекта, чтобы не привязать весь процесс к случайно выбранному названию из подвала.
Отдельно просим сообщить о действующих процессах вне сайта. Это могут быть отношения с сотрудниками, соискателями и контрагентами, если они относятся к фактической деятельности оператора. Мы не добавляем такие цели по предположению, но и не объявляем уведомление полным только на основании проверки одной формы обратной связи.
При наличии предыдущей подачи нужны ее сведения и доступное подтверждение статуса. Скриншот заполненного проекта не равнозначен факту подачи. Если оператор сообщает, что уведомление уже направлено, уточняем, какой документ или запись позволяет это подтвердить, и только затем обсуждаем дальнейшие действия.
Какие сведения поможем собрать
- Реквизиты оператора и контактные сведения ответственного лица.
- Цели обработки, категории людей и данных по каждой цели.
- Правовые основания, действия с данными и способы обработки.
- Сведения о месте нахождения баз данных и используемых сервисах.
- Описание фактически принятых мер защиты в пределах сведений оператора.
- Информацию о ранее поданном уведомлении и необходимых уточнениях.
Для сайта это означает разбор форм, заявок, CRM, почтовых сервисов и аналитики. При этом у организации могут быть сотрудники, подрядчики, офлайн-клиенты и другие процессы. Попросим указать их, чтобы уведомление не описывало только небольшую часть реальной обработки.
Откуда берем сведения для заполнения
Реквизиты и сведения об ответственном подтверждает оператор. Цели разбираем по реальным действиям с людьми, а состав данных сопоставляем с используемыми формами и документами. Для каждой цели уточняем, чьи сведения обрабатываются и какие операции с ними выполняются. Один общий перечень полей сайта может не отражать различия между заявкой клиента и другой деятельностью организации.
Информацию о базах данных уточняем у тех, кто управляет соответствующей системой. Для хостинга это могут быть сведения поставщика об услуге, для CRM или сервиса записи потребуется подтверждение их конкретного размещения. Юридический адрес владельца продукта не используем автоматически как адрес базы. Если информация не получена, фиксируем открытый вопрос и его источник.
Описание мер защиты должно отражать принятые действия. Уточняем, кто имеет доступ к заявкам, как организован вход в используемые системы и какие сведения оператор может подтвердить документами или настройками. Не переносим в проект названия средств и мероприятий, которые существуют только в образце. При необходимости более глубокого обследования сначала определяем его границы.
Сторонние сервисы рассматриваем по их роли в процессе. Важно установить, что именно передается с сайта, кому и для какой задачи. Если есть признаки отдельного вопроса о трансграничной передаче, не скрываем его внутри общего описания уведомления. Соответствующий порядок требует самостоятельной оценки по подтвержденным сведениям, без автоматического вывода только из названия сервиса.
Как фиксируем незакрытые вопросы
- Какое поле проекта нельзя подтвердить сейчас.
- У кого запросить сведения: у оператора, хостинга или поставщика системы.
- Какой ответ или документ позволит продолжить подготовку.
- Что должно быть повторно проверено после получения ответа.
Порядок работы
- Получаем адрес сайта, исходные реквизиты и сведения о предыдущей подаче.
- Составляем список вопросов и сверяем ответы с документами и настройками.
- Готовим проект сведений и отмечаем места, требующие подтверждения.
- Передаем итоговый вариант оператору для проверки и подачи.
Пример вопроса при подготовке: заявки попадают в CRM, но адрес размещения ее базы неизвестен. В таком случае нужно получить информацию у поставщика сервиса. Название компании и страна ее регистрации не заменяют сведения о месте хранения базы.
Неизвестные меры защиты и должности не подставляем из шаблона. Если сведений не хватает, фиксируем, что именно нужно уточнить. Это позволяет оператору проверить документ до отправки и не подтверждать выдуманные факты.
Как согласуем проект перед подачей
Рабочий проект передаем так, чтобы оператор мог проверить смысл каждого заполненного раздела. Поясняем, из каких исходных сведений получена формулировка, и отделяем установленные факты от вопросов. Если ответственного сотрудника или место хранения еще предстоит уточнить, такой пункт остается незавершенным. Подготовка документа не должна превращать отсутствие информации в правдоподобное утверждение.
Полезно проверить согласованность проекта с опубликованной политикой и действующими настройками сайта. Например, новый приемник заявок должен быть учтен в описании процесса, если он действительно используется. При этом механически копировать любой текст политики в уведомление нельзя: сначала нужно понять, отражает ли сам документ текущую работу оператора.
После уточнений согласуем итоговую версию. Оператору нужно подтвердить, что указанные цели, категории сведений, системы и меры соответствуют его деятельности. Если в ходе подготовки меняется форма или подключается другой сервис, проверяем затронутые разделы повторно. В финальной версии отражаем подтвержденные изменения и первоначальные сведения.
До начала работы определяем, что входит в передачу результата: подготовленные сведения, пояснения к заполнению и перечень необходимых подтверждений. Перед подачей сверяем поля действующей формы и выбранный способ подачи. Объясняем оператору, какие сведения перенести из согласованного проекта и какие действия выполнить для подтверждения отправки.
Участие в последующей переписке, исправление сведений после подачи и проверку появления записи обсуждаем отдельно. Если такая помощь нужна, фиксируем ее объем до выполнения. Ее нельзя молча считать включенной в подготовку одного проекта или обещать неограниченное сопровождение независимо от причин уточнения.
Результат и границы ответственности
Вы получите подготовленные сведения, пояснения к заполнению и перечень вопросов, которые нужно закрыть перед подачей. Финальный документ проверяет оператор или его уполномоченное лицо. Подачу подтверждают от имени оператора; пароль от учетной записи для этой подготовки не требуется.
Подготовленный проект, отправленное уведомление и запись в реестре имеют разный статус. Завершение подготовки не означает автоматического включения в реестр. Если нужна проверка результата подачи, порядок такой проверки согласуем отдельно по доступному подтверждению.
Актуальность согласованных сведений
При передаче результата отмечаем, на каких исходных сведениях подготовлен проект. Если между согласованием и подачей оператор меняет сервис, получателя или состав обработки, затронутые формулировки нужно перепроверить. Это помогает избежать ситуации, когда правильно подготовленная версия описывает уже прекращенный процесс. Сама дата файла не подтверждает актуальность содержания без сверки изменений.
Условный пример: заявки на сайте и внешняя CRM
Представим оператора, который получает заявки через сайт и передает контакты во внешнюю CRM. В существующей политике указана только почта, а сотрудник не знает, где размещена база CRM. По такому набору исходных сведений можно начать разбор, но нельзя достоверно заполнить все связанные поля уведомления.
Сначала уточняем реальный путь обращения и получателей. Затем оператор запрашивает у поставщика CRM необходимые сведения о размещении, а мы сопоставляем ответы с проектом. Одновременно проверяем, не устарело ли описание обработки на сайте. Если оператор обрабатывает и другие категории данных, их нужно рассмотреть на основании его сведений, а не ограничиться видимой клиентской формой.
Для приемки подготовки в этом примере важно, чтобы оператор мог проверить каждую использованную формулировку и увидеть оставшиеся вопросы. Сам файл с заполненными строками еще не показывает качество исходной проверки. Отсутствие ответа поставщика обозначаем прямо и не заменяем названием известного дата-центра без подтверждения.
После передачи проекта сохраняется различие между готовностью сведений, направлением документа и внесением записи в реестр. Для каждого этапа требуется собственное подтверждение. Этот пример описывает порядок работы с недостаточной фактурой, не относится к конкретному заказчику и не устанавливает новый обязательный срок завершения процедуры.
Сроки и стоимость
Объем помощи и срок определяем после просмотра исходных сведений. На подготовку влияют количество целей, сервисов и необходимость уточнять данные у подрядчиков. Утверждать срок появления записи в реестре как срок нашей работы нельзя.
Рассмотрение уведомления и внесение сведений в реестр по статье 22 не оплачиваются оператором. Стоимость нашей работы относится к подготовке и разбору сведений. Вопросы трансграничной передачи требуют отдельной оценки: уведомление об общей обработке не заменяет другие предусмотренные законом действия.
