В лог-файле стояло «done». Рядом лежала копия электронного согласия. Когда возник спор, этих двух артефактов не хватило, чтобы доказать главное: согласие дал именно тот человек, которому затем отправили рекламу.
Проблема не в одном неудачном логе. Согласие работает только внутри цепочки: человек увидел определённую версию текста, совершил действие и прошёл предусмотренную проверку. Затем система сохранила доказательство, проверила разрешение перед рекламной операцией, а при отзыве согласия передала новый статус всем задействованным системам и прекратила рассылку.
Мы сопоставили два решения ФАС, ответ Роскомнадзора на наш вопрос и публично доступную форму согласия. Получилась рабочая модель проверки всего жизненного цикла согласия — от его получения до проверки перед использованием и исполнения отзыва. Она не пытается вынести юридический вердикт по одному внешнему снимку.
Статус «done» был, доказательства согласия — нет
В деле Томского УФАС № 070/05/18-297/2026 компания представила копию электронного согласия и лог-файл с двумя отметками:
Но обязательная верификация номера не завершилась: звонок не поступил, код подтверждения не был введён, а проверка пользователя прервалась из-за технического сбоя.
Лог показал, какой статус записала система, но не связал событие с конкретным человеком. Это не делает технический след бесполезным, а показывает его место: статус — только одно звено доказательственной цепочки.
- advertisment: done
- personal data: done
Данного лог-файла недостаточно для однозначной идентификации пользователя
Бумажная подпись не решает проблему автоматически
Похожий разрыв возникает и без цифрового интерфейса. В деле Коми УФАС № 011/05/18-605/2019 в подтверждение согласия представили анкету с именем, телефоном и подписью заявителя. Заявитель сообщил, что почерк и подпись ему не принадлежат.
В анкете обнаружились исправления в дате заполнения и ошибка в отчестве. Кроме того, заявитель подтвердил, что в день заполнения находился в другом городе.
В решении нет почерковедческой экспертизы и не установлен факт подделки документа. Представленную анкету не признали достаточным подтверждением согласия, потому что она расходилась с другими обстоятельствами.
Два дела разделяют семь лет и разные носители согласия. В одном был электронный статус без завершённой идентификации, в другом — анкета с подписью. В обоих случаях слабое место одно: артефакт согласия не удалось надёжно связать с волеизъявлением конкретного человека.
Отсутствуют достаточные основания полагать, что указанная анкета содержит волеизъявление заявителя
Что должно соединиться
Документ показывает содержание выбора. Доказательство связывает этот выбор с человеком, действием и последующей операцией.
Ссылка на текущую редакцию документа не восстанавливает старую версию. Номер телефона или идентификатор сессии сам по себе не доказывает, кто совершил действие. Даже корректно собранное согласие не объясняет конкретную рекламную отправку, если перед ней система не проверила, что согласие продолжает действовать и охватывает нужную цель и канал.
- Текст и действие: какая версия согласия была показана и какое действие совершил человек — например, поставил отдельную отметку или подтвердил выбор кодом.
- Действие и человек: какой идентификатор использовала система и чем завершилась предусмотренная проверка.
- Разрешение и операция: какую именно операцию разрешает согласие. Согласие на рекламные SMS не должно автоматически разрешать email-рассылку или иной канал, если он не был охвачен выбором человека.
- Отзыв согласия и исполнение: куда передали новый статус согласия и когда фактически прекратили операции, которые больше не разрешены.
В ответе Роскомнадзора первым вопросом была цель
14 августа на Дне открытых дверей Роскомнадзора мы спросили, какие действия оператора регулятор считает наиболее убедительным доказательством надлежащего согласия. Вопрос начинается примерно с 03:12:22.
Готового технического чек-листа в ответе не было. Спикер назвал конкретную цель и объём обработки, а способ подтверждения оставил оператору: «это уже зона вашей ответственности».
Это ответ на конкретной встрече, а не нормативная методика. Но он задаёт полезный порядок вопросов: сценарий → цель → предполагаемое основание → данные → получатели и срок → документ → действие.
Внешняя проверка может сопоставить форму с политикой и связанными документами. Окончательное основание и внутренний процесс может подтвердить только оператор. Если же начинать с чекбокса, один текст легко превращается в объяснение сразу услуги, обработки данных, рекламы и передачи партнёрам.
Один экран — два сигнала о рекламе
Для проверки модели мы взяли публичную заявку Т‑Банка на дебетовую карту. 26 августа её проверили сканером Percival, а 3 сентября повторно сверили в обычном браузере; форму не заполняли и не отправляли.
На экране видны поля ФИО, телефона, email и даты рождения, а ниже — выключенный чекбокс согласия на рекламу со ссылкой на отдельный документ. Рядом размещена более общая формулировка: заполняя форму, пользователь принимает условия передачи информации и соглашается получать информацию о продуктах и услугах банка и партнёров.
Связанный документ называет рекламное согласие добровольным и не обязательным для получения продукта. При этом он говорит о ситуации, когда в заявке «не указано иное», и о чекбоксе отказа от рекламы. В интерфейсе же виден положительный чекбокс «соглашаюсь получать рекламу» в выключенном состоянии.
Это расхождение не доказывает, какое разрешение создаёт система, и тем более не доказывает нарушение. Внешний снимок видит текст, начальное состояние элемента и документы, но не обработчик кнопки, серверное событие, действие конкретного человека и передачу статуса в рассылку.
Зато он позволяет задать владельцу процесса три проверяемых вопроса:
- Какое действие активирует рекламное разрешение?
- Как система сохраняет версию каждого текста, показанного человеку?
- Где статус проверяется перед первой и последующими отправками?
Вместо одного «true» — три события
Запись «consent=true» не отвечает на эти вопросы. Для воспроизводимого процесса нужны как минимум три связанных события.
- 01Получение разрешения
Событие фиксирует сценарий и цель, ссылку на субъекта, действие, версию текста, серверное время и результат предусмотренной проверки. Телефон, ФИО и сам документ не требуется копировать в каждую систему: нужен сквозной идентификатор и воспроизводимая связь с источником. Если обязательная проверка завершилась ошибкой, разрешение не должно становиться активным только потому, что соседний обработчик записал «done».
- 02Решение перед использованием
Получение согласия и отправка сообщения — разные события. Между ними могут измениться цель, канал, подрядчик или статус отзыва. Перед операцией система отвечает на конкретный вопрос: можно ли этому субъекту сейчас выполнить эту операцию для этой цели по этому каналу? Вместе с ответом сохраняются время, актуальный статус, ограничения, система принятия решения и идентификатор исходного доказательства.
- 03Отзыв и его исполнение
Отзыв согласия — новое событие, а не перезапись исторического разрешения в «false». Нужно видеть канал и время поступления отзыва, системы и подрядчиков, получивших новый статус, и фактическое время прекращения рекламных операций. Если CRM уже показывает отзыв, а подрядчик продолжает рассылку, разрыв находится не в тексте согласия, а в исполнении отзыва.
Семь вопросов для самопроверки
Эти вопросы помогают DPO обсуждать один сценарий с владельцами продукта, CRM и рассылки.
- 01Для какой цели и операции получен выбор?
Ищите ответ в карте процессов, форме, предполагаемом основании и связанном документе.
- 02Какую версию текста видел человек?
Проверьте реестр версий, хэш или evidence-пакет.
- 03Как событие связано с субъектом?
Нужны идентификатор и результат предусмотренной проверки.
- 04Что произошло при ошибке или незавершённом шаге?
Ответ должен быть в серверном журнале и правиле активации статуса.
- 05Кто проверяет разрешение перед операцией?
Сопоставьте логику CRM или CDP, рассылки и интеграции с обработчиком.
- 06Как отзыв проходит по всем системам?
Проверьте событие отзыва, очередь доставки и подтверждения.
- 07Можно ли выгрузить цепочку для одного спора?
Понадобятся сквозной идентификатор и доказательственный пакет.
Вместо зелёной галочки
Если ответа нет во внешнем отчёте, это не означает нарушение. Если его нет и внутри, появляется конкретный разрыв, которому можно назначить владельца.
Доказуемое согласие — не файл и не строка в CRM, а воспроизводимая цепочка от цели и выбора человека до каждой разрешённой операции и, если согласие было отозвано, подтверждённого прекращения таких операций.
Внешний аудит фиксирует видимый слой и показывает, какое внутреннее доказательство запросить. Он не подменяет это доказательство и не переносит вывод из чужого дела ФАС на проверяемый сайт.
Возьмите одну форму или рассылку и пройдите семь вопросов выше.
Источники и границы
Решения ФАС подтверждают обстоятельства конкретных дел. Запись встречи не является нормативным актом или официальной методикой. Модель трёх событий — рабочая модель Percival.