Хранит ли ресторан ПДн гостей?

На консультациях собственники ресторанов нередко говорят:

Мы почти не работаем с персональными данными. Максимум — имя и телефон для бронирования.

Потом мы начинаем разбирать процессы и выясняется, что имя и телефон гостя уже находятся:

А иногда еще и в таблице управляющего, которую кто-то создал «на время».

Современный ресторан — это уже не только зал, кухня и касса. Это небольшой digital-бизнес со сложной инфраструктурой, которую собственник зачастую не видит целиком.

Именно поэтому главный риск начинается не с отсутствующей политики конфиденциальности. Он начинается с отсутствия ответа на простой вопрос:

Куда попадают данные гостя после того, как он оставил номер телефона?

Представим обычный сценарий.

Гость заходит на сайт ресторана и бронирует столик. Он указывает имя и номер телефона.

Кажется, что эти сведения нужны только для подтверждения брони.

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

На сайте при этом работают cookie, аналитика и рекламные инструменты.

В результате одно действие гостя запускает сразу несколько процессов:

У каждого процесса своя цель, свое основание и иногда отдельный подрядчик.

При этом в документах ресторана может быть указана только одна фраза:

Мы обрабатываем данные для обратной связи.

Она не описывает реальную картину.

Когда ресторан решает «заняться персональными данными», первой задачей обычно становится обновление политики на сайте.

Это полезно, но недостаточно. Сайт — только входная точка.

Основная жизнь данных происходит дальше: внутри CRM, облачных сервисов, приложений, программ лояльности и подрядчиков.

Например, маркетолог подключил новую систему рассылок. Управляющий выбрал сервис бронирования. HR начал использовать платформу обучения персонала. Бухгалтерия хранит документы в облаке. Разработчик настроил аналитику и резервное копирование.

Каждое решение по отдельности выглядит разумным.

Проблема в том, что никто не собирает их в единую карту.

В результате собственник уверен, что данные находятся в России и доступны только сотрудникам ресторана. А при проверке выясняется, что часть информации проходит через иностранный сервис или хранится в аккаунте подрядчика.

Еще одна частая позиция:

У нас внешняя программа лояльности. Мы данные не храним, все делает сервис.

Для гостя это не имеет значения.

Он пришел в конкретный ресторан, зарегистрировался в его программе лояльности и передал данные бренду, которому доверяет.

Именно ресторан определяет, зачем нужны имя, телефон, история покупок и количество баллов. Поэтому он, как правило, остается оператором персональных данных.

Внешняя платформа технически выполняет обработку.

Это означает, что ресторану нужно понимать:

Фраза представителя сервиса «мы данные не видим» ситуацию не меняет.

Если информация поступает на сервер подрядчика, хранится, сортируется, передается или используется системой, обработка существует.

Бизнес часто воспринимает поручение на обработку персональных данных как очередной документ, который усложняет работу с сервисом.

На практике этот документ может стать главным доказательством того, что ресторан:

Без него после утечки подрядчик может сказать:

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

Ресторан, в свою очередь, будет утверждать обратное.

Во время проверки подобная неопределенность работает против обеих сторон.

Теперь о второй крайности.

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

Гость хотел забронировать столик, а ему предлагают пройти небольшой экзамен по законодательству.

Для бизнеса это плохое решение.

Не каждое использование данных требует отдельного согласия.

Если имя, телефон и адрес необходимы для доставки заказа, их обработку часто можно связать с исполнением договора. Без этих сведений ресторан просто не сможет оказать услугу.

Другая ситуация — реклама.

Согласие на рекламные сообщения нельзя незаметно включать в обязательные условия бронирования или заказа. У пользователя должна оставаться возможность получить услугу без подписки на маркетинг.

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

Сначала нужно разделить процессы:

После этого часть лишних чек-боксов часто можно убрать.

Правильный юридический дизайн должен не усложнять клиентский путь, а делать его понятнее.

Допустим, у ресторана есть аккуратная форма и правильный текст.

Через полгода гость заявляет, что никогда не соглашался на рассылку.

Что ресторан сможет предъявить?

Скриншот текущей формы не доказывает, что именно эту форму пользователь видел несколько месяцев назад.

Для защиты важны:

Это решается логированием.

Система должна сохранять не только сам факт нажатия кнопки, но и информацию о том, с какими документами согласился пользователь.

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

Во многих системах техническая возможность логирования уже существует. Но бизнес не проверяет, какие сведения сохраняются и можно ли их затем выгрузить.

Гость оставил номер для подтверждения столика.

Это не означает, что ресторан автоматически получил право присылать ему:

Сервисное сообщение и реклама — разные коммуникации.

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

Отправить спустя месяц предложение «два блюда по цене одного» — уже отдельная маркетинговая цель.

Особенно опасна ситуация, когда ресторан не может определить источник базы. Контакты могли годами накапливаться из бронирований, доставки, анкет, конкурсов, визиток и партнерских мероприятий.

Но наличие номера телефона в CRM еще не доказывает наличие согласия на рекламу.

Самый показательный риск возникает не во время плановой проверки, а при утечке.

Гость находит свои данные в открытом доступе и пишет на общий адрес ресторана.

Письмо попадает в ящик info@..., который одновременно читает администратор, маркетолог и менеджер по закупкам.

Никто не понимает, что это не просто недовольный клиент, а сообщение об инциденте.

Письмо лежит несколько дней. Затем его пересылают управляющему. Еще позже — юристу.

К этому моменту сроки реагирования уже идут.

Поэтому компании нужны не только документы, но и понятная внутренняя инструкция:

Полезно создать отдельный адрес для обращений по персональным данным и провести для команды короткое обучение.

Час обучения иногда защищает бизнес лучше, чем положение на 50 страниц, которое никто не читал.

Не всегда нужно начинать с масштабного аудита и десятков документов.

Первый этап можно провести силами собственной команды.

Сайт, приложение, бронирование, доставка, Wi-Fi, программа лояльности, рассылки, анкеты, мессенджеры, HR-процессы.

CRM, системы рассылок, сервисы доставки, хостинг, аналитика, бухгалтерия, колл-центр, программы обучения.

Если ресторану достаточно имени и телефона, не стоит собирать дату рождения, фамилию и электронную почту «про запас».

Откуда взят каждый контакт и можно ли доказать согласие на рассылку.

Фиксируется ли действие гостя и сохраняются ли версии документов.

Не обязательно создавать отдельную должность. Но внутри компании должно быть понятно, кто принимает сообщение и запускает процесс реагирования.

Ресторану не нужно становиться IT-компанией или юридическим департаментом.

Но нужно признать реальность: данные гостей сегодня являются частью операционной инфраструктуры бизнеса.

Они проходят через маркетинг, продажи, доставку, лояльность, аналитику, HR и подрядчиков.

Поэтому персональные данные — уже не отдельная юридическая задача. Это вопрос управления цифровой цепочкой ресторана.

И чем больше сервисов подключает бизнес, тем важнее не количество документов, а способность ответить на три вопроса:

Что мы собираем?

Зачем?

Кому передаем?

Если собственник не знает ответов, значит, инфраструктура уже выросла быстрее, чем система контроля.